1887714 - Captive portal detection warning persists but HTTPS networking works

Status: UNCONFIRMED

(Core :: Networking, defect, P2)

Description

[tim]

Attachment: firefox bug.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0

Steps to reproduce:

Fresh install, but the banner saying that I need to log in to the network comes up intermittently, even though the network works.

Actual results:

Banner comes up intermittently.

Expected results:

No banner.

Comment 1

[Ed Guloien [:edgul]]

Hi Tim, thanks for the report.

We've seen similar reports like this before, but are having a hard time with getting logs. Are you able to help us reproduce with logging enabled?

I recommend using about:logging's logging to a file method with CaptivePortalService:5 in the logging module string.
You can email the log to [e-mail].

Thanks so much.

(This is very likely a dupe, other similar reports:)
Bug 1846626
Bug 1869107
Bug 1869176

Comment 2

[Andrew Overholt [:overholt]]

Tim told me offline that he sent the logs via email so clearing the needinfo.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

Looking at the logs:

[Parent 16104: Main Thread]: I/Logger Flushing old log files
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::Notify
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::PerformCheck mRequestInProgress:1 mInitialized:1 mStarted:1
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::RearmTimer
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService - Reloading timer with delay 60000
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::Complete(success=1) mState=3
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::Observe() topic=captive-portal-login-success
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::RearmTimer
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService - Reloading timer with delay 60000
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::Notify
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::PerformCheck mRequestInProgress:0 mInitialized:1 mStarted:1
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::PerformCheck - Calling CheckCaptivePortal
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::Prepare
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::RearmTimer
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService - Reloading timer with delay 60000
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::Observe() topic=captive-portal-login
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::Notify
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::PerformCheck mRequestInProgress:1 mInitialized:1 mStarted:1
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::RearmTimer
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService - Reloading timer with delay 60000
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::Notify
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::PerformCheck mRequestInProgress:1 mInitialized:1 mStarted:1
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService::RearmTimer
[Parent 16104: Main Thread]: D/CaptivePortalService CaptivePortalService - Reloading timer with delay 60000

We see the successful login captive-portal-login-success followed by captive-portal-login.
That means the captive portal detector is definitely triggered. The question is why.

I think it would have been a lot easier to figure out what's wrong if could also see what http requests are made.
@Tim, could you capture the logs again, this time with sync,timestamp,nsHttp:5,CaptivePortalService:5 ? Thanks!

Comment 5

[Valentin Gosu [:valentin] (he/him)]

Thanks!

Comment 6

[Valentin Gosu [:valentin] (he/him)]

2024-04-05 16:42:30.486000 UTC - [Parent 13300: Socket Thread]: I/nsHttp http response [
2024-04-05 16:42:30.486000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   HTTP/1.1 200 OK
2024-04-05 16:42:30.486000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Server: nginx
2024-04-05 16:42:30.486000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Date: Fri, 05 Apr 2024 09:18:11 GMT
2024-04-05 16:42:30.486000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Cache-Control: public,must-revalidate,max-age=0,s-maxage=3600
2024-04-05 16:42:30.486000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Content-Length: 1641
2024-04-05 16:42:30.486000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Content-Type: text/html
2024-04-05 16:42:30.486000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Age: 26659
2024-04-05 16:42:30.486000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Via: 1.1 google, 1.1 GDC-GOMMPWF02S.CIHS.AD.GOV.ON.CA:80 (Cisco-WSA/12.5.5-008)
2024-04-05 16:42:30.486000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Connection: keep-alive
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Proxy-Connection: keep-alive
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Set-Cookie: xxx
f5_cspm=1234;
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp     OriginalHeaders
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Server: nginx
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Date: Fri, 05 Apr 2024 09:18:11 GMT
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Cache-Control: public,must-revalidate,max-age=0,s-maxage=3600
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Content-Length: 1641
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Content-Type: text/html
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Age: 26659
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Via: 1.1 google, 1.1 GDC-GOMMPWF02S.CIHS.AD.GOV.ON.CA:80 (Cisco-WSA/12.5.5-008)
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Connection: keep-alive
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Proxy-Connection: keep-alive
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Set-Cookie: xxx
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: E/nsHttp   Set-Cookie: f5_cspm=1234;
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Socket Thread]: I/nsHttp ]
2024-04-05 16:42:30.491000 UTC - [Parent 13300: Main Thread]: D/nsHttp nsHttpChannel::ContinueOnStopRequest [this=1154bc06400 aStatus=0, aIsFromNet=1]

It's odd that your page isn't loading. I can see the request succeeding. It's definitely intercepted.
I think what's happening in this case is the network is intercepting HTTP and DNS, but not HTTPS connections.
That means HTTPS traffic will work, but Firefox will still detect a captive portal.

Comment 7

[Andrew Overholt [:overholt]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #6)

I think what's happening in this case is the network is intercepting HTTP and DNS, but not HTTPS connections.
That means HTTPS traffic will work, but Firefox will still detect a captive portal.

Should our captive portal detection behave differently in this case?

Comment 8

[Valentin Gosu [:valentin] (he/him)]

There are two things we can do:

1. Make sure dismissing the captive portal warning does not keep bugging people while they're on the same network.
2. We could also check if HTTPS works. And if so, we'd need to decide what to do, as they're basically half way into a captive portal.

• Do we notify users at all?
• Do we enforce https-only?
• Something else.

Comment 9

[Valentin Gosu [:valentin] (he/him)]

Attachment: WIP: Bug 1887714 - See if 204 captive portal endpoint works better r=#necko

Comment 10

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1887714 - Don't trigger captive portal banner when browser used proxy r=#necko

Comment 11

[Valentin Gosu [:valentin] (he/him)]

Hi Tim,

I have two builds I'd like you to try out if possible.
[1] uses the same captive portal check as Chrome, expecting to get a 204 status. I'm curious if theirs would trigger.
[2] makes it so the captive portal is not triggered when there is a proxy active

These are builds for windows x64 - let me know if you'd prefer some other platform instead.

[1] https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/f808eVYUT_iPQhnHqO03wQ/runs/0/artifacts/public/build/setup.exe
[2] https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Udldcm0zTUabykRWUjEIhg/runs/0/artifacts/public/build/setup.exe

Thanks!

Comment 12

[tim]

Unfortunately I can't install the nightly builds - centrally managed IT restricts user installations.

Comment 13

[tim]

(although I will say that Chrome doesn't display captive portal triggers, so option 1 might work?)

Comment 14

[Valentin Gosu [:valentin] (he/him)]

Btw, it occurred to me that I didn't mention that you can disable the captive portal checker by setting network.captive-portal-service.enabled to false in about:config.

(In reply to tim from comment #12)

Unfortunately I can't install the nightly builds - centrally managed IT restricts user installations.

Are you able to run a portable executable instead? You can extract the archive and run firefox.exe

[1] https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/f808eVYUT_iPQhnHqO03wQ/runs/0/artifacts/public/build/target.zip
[2] https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Udldcm0zTUabykRWUjEIhg/runs/0/artifacts/public/build/target.zip

Comment 15

[tim]

I tried both of those builds and both seem to work with no captive portal detection. And thanks for the tip on disabling.