Closed Bug 1610834 Opened 4 years ago Closed 4 years ago

When mode 3 is enabled the login page for a captive portal can't be reached

Categories

(Core :: Networking: DNS, defect, P2)

73 Branch
Desktop
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1608713
Tracking Status
firefox73 --- wontfix
firefox74 --- fixed

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

  1. Launch firefox.
  2. Reach about:config
  3. Go to about:config and set:
    network.trr.mode to 3
    network.trr.bootstrapAddress to 104.16.248.249
  4. Restart Firefox.
  5. Connect to a captive portal Wi-Fi.
  6. In Firefox a banner with "You must log in to...." and a button with "Open Network Login Page" will appear.
  7. 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.

Valentin can you reproduce?

Flags: needinfo?(valentin.gosu)

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?

Assignee: nobody → valentin.gosu
Depends on: 1608713
Flags: needinfo?(valentin.gosu) → needinfo?(nhnguyen)
Priority: -- → P2
Whiteboard: [trr][mode3] → [necko-triaged][trr][mode3]

OK not to fix it in 73, as we're not enabling mode 3 in this release.

Flags: needinfo?(nhnguyen)

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/

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!

Flags: needinfo?(daniel.cicas)

Hello,

I marked bug 1608713 as verified, the captive portal login page is now reachable!

Flags: needinfo?(daniel.cicas)
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.