When mode 3 is enabled the login page for a captive portal can't be reached
Categories
(Core :: Networking: DNS, defect, P2)
Tracking
()
People
(Reporter: dcicas, Assigned: valentin)
References
Details
(Whiteboard: [necko-triaged][trr][mode3])
Affected versions
*Fx 73.0b7
Affected platforms
- Windows x64
Windows 7 x64
Ubuntu 18.04
Steps to reproduce
- Launch firefox.
- Reach about:config
- Go to about:config and set:
network.trr.mode to 3
network.trr.bootstrapAddress to 104.16.248.249 - Restart Firefox.
- Connect to a captive portal Wi-Fi.
- In Firefox a banner with "You must log in to...." and a button with "Open Network Login Page" will appear.
- Click on "Open Network Login Page" button.
Expected result
- A new tab is opened and a login portal is displayed.
Actual result
- An error message is displayed saying that we can't connect to the server at primary-zd.softvision.ro
Additional notes
- This Issue does not reproduce on mac OS because the login page is not opened inside the browser but is a separate window.
Assignee | ||
Comment 2•4 years ago
|
||
This is the exact scenario I describe in bug 1608713 comment 0.
We resolve the captive portal domain, and detect there's a captive portal.
We proceed to open the login tab, which again goes to the captive portal domain.
In Fx 73 that domain is excluded from TRR. A redirect happens to primary-zd.softvision.ro but since we're in TRR mode 3, that resolution fails because TRR can't work yet.
For Fx 74 we no longer exclude the captive portal domain, instead we need to fix bug 1608713 in order to exclude just the captive portal login tab from using TRR.
Nhi, I am inclined to WONTFIX for 73 (since we have a good path to fixing it in 74). Do you think that is OK?
Comment 3•4 years ago
|
||
OK not to fix it in 73, as we're not enabling mode 3 in this release.
I hit the same problem with captive portal detection and network.trr.mode=3.
Here is a potential solution:
- add a new option "network.trr.captive-dns-resolver" (eg network.trr.captive-dns-resolver=127.0. 0.53 if one uses the systemd resolver)
- behavior: if no connectivity is detected, detect the captive portal ip/hostname using the server at "network.trr.captive-dns-resolver"
Interesting reading on that topic: A secure captive portal browser with automatic DNS detection
https://blog.filippo.io/captive-browser/
Assignee | ||
Comment 6•4 years ago
|
||
Hi Daniel,
Bug 1608713 just landed in Nightly. When you have time, can you check that it works with the captive portal you used in comment 0?
Thanks!
Reporter | ||
Comment 7•4 years ago
|
||
Hello,
I marked bug 1608713 as verified, the captive portal login page is now reachable!
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Description
•