Closed Bug 1666072 Opened 5 months ago Closed 3 months ago

"you must log in to this network before you can access the internet"

Categories

(Core :: Networking, defect, P1)

80 Branch
defect

Tracking

()

VERIFIED FIXED
85 Branch
Tracking Status
firefox-esr78 84+ fixed
firefox82 --- wontfix
firefox83 + wontfix
firefox84 + verified
firefox85 + verified

People

(Reporter: dev, Assigned: valentin)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(6 files)

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

Steps to reproduce:

After a very short temporary loss of Internet due to a power failure, Firefox has detected that Internet was not available.
However, it never recovers from this status. It permanently keeps showing the extra Menu bar "You must log in to this network before you can access the Internet." This keeps showing up on all new windows and tabs. When clicking on the "Open Network Login Page" button, an empty window shows with the word "Success".
Nothing changes.

The only way to fix the problem is a full close of ALL Firefox windows, and a full restart.
This problem has been here for as long as I can remember.

Bart Kindt
Developer, SARTrack Limited
https://www.sartrack.nz
New Zealand

Actual results:

As above

Expected results:

It should clear itself automatically after it detects the Internet is back online, and especially after clicking on the "Open Network Login Page" button, which reports a "Success"

Bart

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Networking
Product: Firefox → Core

Thanks for the report.
Can you reproduce the bug on demand, or is it intermittent?
By "is fixed by a full restart" do you mean of Firefox, or of the operating system?

When you hit the bug again, could you gather some HTTP logs for us?
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
And in the modules also add CaptivePortalService:5 (separated by comma)

Thanks!

Flags: needinfo?(dev)
Attached image Firefox-Bug1.jpg

This is what I get every time I open a new Firefox window, before I click on the button.
Internet is back for days, it does not clear itself.

Attachment #9176960 - Flags: ui-review+
Attachment #9176960 - Flags: review+

This is after clicking the button.
It does not make any difference. It does not clear the State Firefox is in.

Flags: needinfo?(dev)
Attachment #9176961 - Flags: ui-review+
Attachment #9176961 - Flags: review+

Hi,

I can probably reproduce on demand. However, since I reported the bug some days ago, I have not restarted Firefox, and the bug problem is still present right now: When I open a new Firefox window or tab, I still get this warning on the top of the window. Ever after having perfectly good Internet for the last few days.
I have now attached screenshots. This is several days after we had a short Internet outage.

Note that Firefox works normally, there are no Internet related issues. It simply does not clear the State 'Oh, there is no Internet' after this has happened once.
Restarting Firefox fixes the problem.

I am not familiar with "add CaptivePortalService:5 on the modules", I am not a Firefox developer, I am a Deplhi Pascal developer :)

Bart.

So basically, expected behaviour should be:

  1. Firefox should automatically dectect thet the Internet is again available, and stop adding this warning.
  2. Firefox should CLEAR this warning after the button is pushed, and getting a "success", it should then remove the warning from the (open) Window, and it should STOP adding the warning to any new Windows or tabs.

Bart

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)
Please see this link:

https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

It has step by step instructions on how to capture the logs.
After that please zip them and attach them here or email them to me.

Flags: needinfo?(dev)
Attached file log.txt.moz_log.0

Hello,

I've got the same message (in french) since about 1 hour ago (the computer just woke from suspend). I don't have any connection problem (and it's only on one device in my network). The message appears at each start of the browser.

I attach the logs requested above.

Firefox 82.0.3 on linux 64bits
Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0

Attached file log.txt .moz_log.0

I can confirm this bug with Firefox 82.0.3 (64-Bit) on Windows 10 x64 (latest updates installed), log is attached. I don't have any proxy or login barrier, yet FF keeps telling me I must login before I can access the internet. Browsing works without issues though.

FWIW, I just cleared my cache/site date/cookies and the message didn't reappear at the next restart of the browser.

See Also: → 1677026

This is caused by the HSTS header sent from firefox.com (the header includes subdomains), which is causing us to upgrade requests to the captive portal detection service. The captive portal service is designed to run on http: only (captive portals will block TLS requests or substitute their own certificate, breaking the request), which is why this breaks.

Status: UNCONFIRMED → NEW
Ever confirmed: true

[Tracking Requested - why for this release]:
Notification bars for everyone who visits firefox.com is not nice.

Flags: needinfo?(pascalc)

It would be best to ship both a fix to the captive portal fix, so prevent us trying to do any HSTS fixes, and a fix to the server code.

I have a one-liner fix ready for manual testing.
Currently writing automated tests.

Assignee: nobody → valentin.gosu
Severity: -- → S2
Priority: -- → P1
Whiteboard: [necko-triaged]
Duplicate of this bug: 1677026

https://firefox.com/ sends strict-transport-security: max-age=31536000; includeSubDomains
and http://firefox.com sends the upgrade-insecure-requests: 1 header.

Combined, these cause the captive portal check to report a redirect, which
triggers the locked captive portal banner. The fix is to exclude the captive
portal channel from the upgrade.

Comment on attachment 9188024 [details]
Bug 1666072 - Disable HSTS upgrade for captive portal channels r=Gijs

Beta/Release Uplift Approval Request

  • User impact if declined: Users who have visited firefox.com after we set the HSTS header will be presented with an annoying "Log in to captive portal" banner that keeps coming back.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Visit firefox.com
    Restart browser
    Check if firefox.com:HSTS is in SiteSecurityServiceState.txt
    See if captive portal banner shows up
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): This is a relatively simple change and the captive portal code has some test coverage.
    This likely needs manual testing too to make sure it doesn't break something in exciting new ways.
  • String changes made/needed:
Attachment #9188024 - Flags: approval-mozilla-release?
Attachment #9188024 - Flags: approval-mozilla-esr78?
Attachment #9188024 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/17ecebdc6d8b
Disable HSTS upgrade for captive portal channels r=Gijs

I pushed to try with the beta branch to have quick builds for QA.
https://treeherder.mozilla.org/jobs?repo=try&revision=ed7cd766a061868b980da91c53fb21d1eafcc24d

Flags: needinfo?(dev)

Backed out for causing xpcshell failures.

Backout link: https://hg.mozilla.org/integration/autoland/rev/f3f800928642224aadf4c939249a81b7ec789d1e

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=Yc6RTUHAThuwv6qfcIW2SQ.0&resultStatus=testfailed%2Cbusted%2Cexception&revision=17ecebdc6d8b5b4b8fb4e20392f6380928207a14

Failure log: https://treeherder.mozilla.org/logviewer?job_id=321907073&repo=autoland&lineNumber=4218

"INFO - TEST-PASS | netwerk/test/unit/test_trr.js | test25d - [test25d : 144] Checking result for domain.other - "127.0.0.1" == "127.0.0.1"
[task 2020-11-16T14:16:36.551Z] 14:16:36 INFO - (xpcshell/head.js) | test run_next_test 43 pending (2)
[task 2020-11-16T14:16:36.551Z] 14:16:36 INFO - (xpcshell/head.js) | test test25d finished (2)
[task 2020-11-16T14:16:36.552Z] 14:16:36 INFO - netwerk/test/unit/test_trr.js | Starting test25e
[task 2020-11-16T14:16:36.553Z] 14:16:36 INFO - (xpcshell/head.js) | test test25e pending (2)
[task 2020-11-16T14:16:36.553Z] 14:16:36 INFO - (xpcshell/head.js) | test run_next_test 43 finished (2)
[task 2020-11-16T14:16:36.553Z] 14:16:36 INFO - PID 18572 | FATAL ERROR: Non-local network connections are disabled and a connection attempt to detectportal.firefox.com (192.192.192.192) was made.
[task 2020-11-16T14:16:36.554Z] 14:16:36 INFO - PID 18572 | You should only access hostnames available via the test networking proxy (if running mochitests) or from a test-specific httpd.js server (if running xpcshell tests). Browser services should be disabled or redirected to a local server.
[task 2020-11-16T14:16:36.554Z] 14:16:36 INFO - PID 18572 | AddressSanitizer:DEADLYSIGNAL
[task 2020-11-16T14:16:36.555Z] 14:16:36 INFO - PID 18572 | =================================================================
[task 2020-11-16T14:16:36.555Z] 14:16:36 ERROR - PID 18572 | ==18572==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x7f28555b5b4b bp 0x7f28417cae30 sp 0x7f28417ca5e0 T4)
[task 2020-11-16T14:16:36.555Z] 14:16:36 INFO - PID 18572 | ==18572==The signal is caused by a WRITE memory access.
[task 2020-11-16T14:16:36.556Z] 14:16:36 INFO - PID 18572 | ==18572==Hint: address points to the zero page.
[task 2020-11-16T14:16:36.556Z] 14:16:36 INFO - PID 18572 | error: address range table at offset 0x5780 has an invalid tuple (length = 0) at offset 0x5790
[task 2020-11-16T14:16:36.557Z] 14:16:36 INFO - PID 18572 | #0 0x7f28555b5b4b in mozilla::net::nsSocketTransport::InitiateSocket() /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransport2.cpp:1331:7
[task 2020-11-16T14:16:36.557Z] 14:16:36 INFO - PID 18572 | #1 0x7f28555b99ec in mozilla::net::nsSocketTransport::OnSocketEvent(unsigned int, nsresult, nsISupports*) /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransport2.cpp:2219:22
[task 2020-11-16T14:16:36.558Z] 14:16:36 INFO - PID 18572 | #2 0x7f2855603cea in mozilla::net::nsSocketEvent::Run() /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransport2.cpp:93:17
[task 2020-11-16T14:16:36.558Z] 14:16:36 INFO - PID 18572 | #3 0x7f2855273f77 in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1197:14
[task 2020-11-16T14:16:36.558Z] 14:16:36 INFO - PID 18572 | #4 0x7f285527eb0c in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:513:10
[task 2020-11-16T14:16:36.559Z] 14:16:36 INFO - PID 18572 | #5 0x7f28555cd2c0 in mozilla::net::nsSocketTransportService::Run() /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransportService2.cpp:1195:11
[task 2020-11-16T14:16:36.559Z] 14:16:36 INFO - PID 18572 | #6 0x7f28555cf28c in non-virtual thunk to mozilla::net::nsSocketTransportService::Run() /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransportService2.cpp
[task 2020-11-16T14:16:36.559Z] 14:16:36 INFO - PID 18572 | #7 0x7f2855273f77 in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1197:14
[task 2020-11-16T14:16:36.561Z] 14:16:36 INFO - PID 18572 | #8 0x7f285527eb0c in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:513:10
[task 2020-11-16T14:16:36.561Z] 14:16:36 INFO - PID 18572 | #9 0x7f2856420008 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) /builds/worker/checkouts/gecko/ipc/glue/MessagePump.cpp:302:20
[task 2020-11-16T14:16:36.561Z] 14:16:36 INFO - PID 18572 | #10 0x7f285633fb91 in RunInternal /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:334:10
[task 2020-11-16T14:16:36.561Z] 14:16:36 INFO - PID 18572 | #11 0x7f285633fb91 in RunHandler /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:327:3
[task 2020-11-16T14:16:36.561Z] 14:16:36 INFO - PID 18572 | #12 0x7f285633fb91 in MessageLoop::Run() /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:309:3
[task 2020-11-16T14:16:36.562Z] 14:16:36 INFO - PID 18572 | #13 0x7f285526d074 in nsThread::ThreadFunc(void*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:442:10
[task 2020-11-16T14:16:36.562Z] 14:16:36 INFO - PID 18572 | #14 0x7f2868f77dce in _pt_root /builds/worker/checkouts/gecko/nsprpub/pr/src/pthreads/ptthread.c:201:5
[task 2020-11-16T14:16:36.562Z] 14:16:36 INFO - PID 18572 | #15 0x7f2868b816da in start_thread /build/glibc-2ORdQG/glibc-2.27/nptl/pthread_create.c:463
[task 2020-11-16T14:16:36.563Z] 14:16:36 INFO - PID 18572 | #16 0x7f284f272a3e in clone /build/glibc-2ORdQG/glibc-2.27/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
[task 2020-11-16T14:16:36.563Z] 14:16:36 INFO - PID 18572 | AddressSanitizer can not provide additional info.
[task 2020-11-16T14:16:36.563Z] 14:16:36 INFO - PID 18572 | SUMMARY: AddressSanitizer: SEGV /builds/worker/checkouts/gecko/netwerk/base/nsSocketTransport2.cpp:1331:7 in mozilla::net::nsSocketTransport::InitiateSocket()"

Flags: needinfo?(valentin.gosu)

The server fix has been deployed, so the bug can't be reproduced with a new profile.
In order to reproduce, shut down Firefox, go to the profile folder, and add

firefox.com:HSTS	2	18582	1636734541693,1,1,2

to SiteSecurityServiceState.txt

Start Firefox.
You should see the captive portal banner right away (in the build without the patch)
In the build with the patch, the captive portal banner should not appear.

The test expects the only code that would call SetAllowSTS=false is the OCSP code. Making the captive portal do that too messes up expectations. A follow-up to bug 1556194 is necessary.

Depends on D97152

Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/cfb55e9e43d4
Disable HSTS upgrade for captive portal channels r=Gijs
https://hg.mozilla.org/integration/autoland/rev/44567f4bd356
Temporarily disable test_trr.js::test25e

Hello,

I can reproduce this issue on FX. 82.0.3. I can confirm that this issue is fixed in the latest nightly (BuildID: 20201116134131). While I verified this, a fix was deployed on the server, and with help from @valentin, on the profile from 82.0.3 that had the issue, it is no longer reproducible after visiting http://firefox.com/ and https://firefox.com/ .

Blocks: 1677521
Flags: needinfo?(valentin.gosu)

Given that we're likely to be landing an in-tree patch for affected releases, let's leave the status flags set to affected for now until that lands.

Comment on attachment 9188024 [details]
Bug 1666072 - Disable HSTS upgrade for captive portal channels r=Gijs

Approved for 84.0b1.

Attachment #9188024 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch

Hello,
Verified on Firefox 85.0a1.

Verified on Firefox esr 78.5.0.

On Firefox RC 83.0 the menu bar is still visible, but after 10 seconds on firefox.com the bar disappears. Seeing as this is fixed on the server side and a dot release with this issue as a driver is not planned, I will be marking this as verified.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Duplicate of this bug: 1679236

Comment on attachment 9188024 [details]
Bug 1666072 - Disable HSTS upgrade for captive portal channels r=Gijs

approved for 78.6esr

Attachment #9188024 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
Attachment #9188024 - Flags: approval-mozilla-release? → approval-mozilla-release-
You need to log in before you can comment on or make changes to this bug.