captive portal detection fails with redirect from detectportal.firefox.com to mymodem.modem, which does not resolve
My Firefox Developer Edition just required manual help to upgrade to 73.0b2 because the auto-upgrade failed. Not sure if that is important. All new tabs and windows had the "You have to connect to the internet" captive-portal bar across the top, but I'm on a home network without captive portal. Clicking the "go to login page" button went to a "can't find that page" error page.
I tried curl from the command-line of my Mac (10.15.2) and got this:
% curl -v http://detectportal.firefox.com/success.txt
- Trying 2600:1415:1c00::17c0:6c92...
- TCP_NODELAY set
- Connected to detectportal.firefox.com (2600:1415:1c00::17c0:6c92) port 80 (#0)
> GET /success.txt HTTP/1.1 > Host: detectportal.firefox.com > User-Agent: curl/7.64.1 > Accept: */* > < HTTP/1.1 302 Moved Temporarily < Server: nginx < Date: Wed, 08 Jan 2020 10:07:46 GMT < Content-Type: text/html < Content-Length: 154 < Connection: keep-alive < Location: http://mymodem.modem < X-Frame-Options: SAMEORIGIN < Content-Security-Policy: default-src 'self';script-src 'self' 'unsafe-eval' 'unsafe-inline';style-src 'self' 'unsafe-inline' < Cache-Control: public, max-age=31536000 < <title>302 Found</title> <center>
302 Found
</center><center>nginx</center>
- Connection #0 to host detectportal.firefox.com left intact
- Closing connection 0
I'm prepared to believe that this is ISP-related, rather than Firefox, but on the off-chance that it's somehow down to a misconfiguration of the captive-portal detection servers right now, I thought that I'd report it here.
I've stopped this from happening by setting about:config network.captive-portal-service.enabled to false, but would ideally prefer that this not recur on the next profile reset.
被采纳的解决方案
Solved. ISP (Telstra) NBN router problem fixed by restarting the router. Fix might also involve clearing some telstra-related cookies, because I did that too, but that seems less likely.
Summary: turns out that Telstra's routers have some "captive portal" functionality that they use surreptitiously as a "malware prevention" mechanism. They can (and do, apparently) dynamically black-hole some IP addresses, or perhaps DNS lookups. Looks as though stale information in that list managed to collide with Firefox's local detectportal Akamai service. Telstra's on-line chat and telephone support operators were completely ineffectual in diagnosing this, by the way. Both gave up. The second advised strongly against rebooting the router. Sigh. I'm fairly sure that if the modem still had its default LAN configuration settings, the mymodem.modem URL would have resolved to it, but it doesn't, and my highest priority DNS is google's IPv6 one, I think, so that doesn't resolve to anything.
Router restart did "fix" the problem though.
It would be nice if the network.captive-portal-service.enabled frob could be exposed as a settings knob. This desktop machine isn't going to move to a captive portal at any time, so doesn't need to do the check that triggered the fault. Wouldn't want to share that with synch services though.
Thanks for listening!
定位到答案原位置 👍 0所有回复 (1)
选择的解决方案
Solved. ISP (Telstra) NBN router problem fixed by restarting the router. Fix might also involve clearing some telstra-related cookies, because I did that too, but that seems less likely.
Summary: turns out that Telstra's routers have some "captive portal" functionality that they use surreptitiously as a "malware prevention" mechanism. They can (and do, apparently) dynamically black-hole some IP addresses, or perhaps DNS lookups. Looks as though stale information in that list managed to collide with Firefox's local detectportal Akamai service. Telstra's on-line chat and telephone support operators were completely ineffectual in diagnosing this, by the way. Both gave up. The second advised strongly against rebooting the router. Sigh. I'm fairly sure that if the modem still had its default LAN configuration settings, the mymodem.modem URL would have resolved to it, but it doesn't, and my highest priority DNS is google's IPv6 one, I think, so that doesn't resolve to anything.
Router restart did "fix" the problem though.
It would be nice if the network.captive-portal-service.enabled frob could be exposed as a settings knob. This desktop machine isn't going to move to a captive portal at any time, so doesn't need to do the check that triggered the fault. Wouldn't want to share that with synch services though.
Thanks for listening!