Avatar for Username

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Ova tema je arhivirana. Pitajte drugo pitanje ako vam je potrebna pomoć.

captive portal detection fails with redirect from detectportal.firefox.com to mymodem.modem, which does not resolve

  • 1 odgovor
  • 1 ima ovaj problem
  • 238 views
  • Posljednji odgovor poslao andrew

andrew
andrew
more options

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>

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.

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 < <html> <head><title>302 Found</title></head> <body bgcolor="white"> <center><h1>302 Found</h1></center> <hr><center>nginx</center> </body> </html> * 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.

Izabrano rješenje

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!

Pročitajte ovaj odgovor sa objašnjenjem 👍 0

All Replies (1)

andrew
andrew Vlasnik pitanja
more options

Odabrano rješenje

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!