Closed Bug 1446352 Opened 3 years ago Closed 3 years ago

TRR doesn't work after captive portal (maybe?)

Categories

(Core :: Networking: DNS, enhancement, P1)

enhancement

Tracking

()

RESOLVED FIXED
mozilla61
Tracking Status
firefox61 --- fixed

People

(Reporter: ekr, Assigned: bagder)

Details

(Whiteboard: [necko-triaged][trr])

Attachments

(1 file)

I just logged in somewhere with a captive portal. I don't necessarily expect TRR to work here, but then when I triggered it with Chrome, Firefox still couldn't resolve names. A restart fixed it.

I haven't tried to repro this.
Flags: needinfo?(daniel)
Assignee: nobody → daniel
Component: Networking → Networking: DNS
Flags: needinfo?(daniel)
Priority: -- → P1
Whiteboard: [necko-triaged][trr]
Valentin, as mr captive portal, can you give the current TRRService.cpp another look and see if you think the Observe() logic for captive portal looks sound?
Flags: needinfo?(valentin.gosu)
which mode were you in? probably relevant.
3
Within a captive portal with TRRonly, there's a clear risk that we can't resolve names at all since the TRR requests will be stopped. I expect most captive portals will still use names to redirect the user to the login page etc and trronly actively avoid using the native resolver...

I think we need to consider a mode/option where trronly still allows the native resolver within captive portals.

Or can we do it differently/better?
ekr is saying his captive portal has been cleared out of band (i.e. in another browser). What in gecko is in a state that it can't figure out that connectivity has been restored? (is it trr, or is it cp?)

I don't think this is just a CP issue.. its basically undetectable from a network outage that resolves itself, right?
With trr-only it won't use TRR until CP is cleared and the CP doesn't clear itself until the name resolving works so that it can verify its connection. feels like a catch-22.

With trr-only, I figure waiting for captive-portal to go green isn't a good idea so maybe we should just make it not do that.
I agree trr-only doesn't need to pend on captive portal as long as it has its own logic to get stuff going when a portal has been cleared out of band.
Flags: needinfo?(valentin.gosu)
Comment on attachment 8959858 [details]
bug 1446352 TRR: make "only mode" not wait for CP confirmation

https://reviewboard.mozilla.org/r/228624/#review234446
Attachment #8959858 - Flags: review?(mcmanus) → review+
Pushed by daniel@haxx.se:
https://hg.mozilla.org/integration/autoland/rev/6b3f3316dd39
TRR: make "only mode" not wait for CP confirmation r=mcmanus
https://hg.mozilla.org/mozilla-central/rev/6b3f3316dd39
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in before you can comment on or make changes to this bug.