Closed
Bug 1446352
Opened 7 years ago
Closed 7 years ago
TRR doesn't work after captive portal (maybe?)
Categories
(Core :: Networking: DNS, enhancement, P1)
Core
Networking: DNS
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.
Reporter | ||
Updated•7 years ago
|
Flags: needinfo?(daniel)
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → daniel
Component: Networking → Networking: DNS
Flags: needinfo?(daniel)
Priority: -- → P1
Whiteboard: [necko-triaged][trr]
Assignee | ||
Comment 1•7 years ago
|
||
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)
Comment 2•7 years ago
|
||
which mode were you in? probably relevant.
Reporter | ||
Comment 3•7 years ago
|
||
3
Assignee | ||
Comment 4•7 years ago
|
||
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?
Comment 5•7 years ago
|
||
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?
Assignee | ||
Comment 6•7 years ago
|
||
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.
Comment 7•7 years ago
|
||
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.
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(valentin.gosu)
Comment hidden (mozreview-request) |
Comment 9•7 years ago
|
||
mozreview-review |
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+
Comment 10•7 years ago
|
||
Pushed by daniel@haxx.se:
https://hg.mozilla.org/integration/autoland/rev/6b3f3316dd39
TRR: make "only mode" not wait for CP confirmation r=mcmanus
Comment 11•7 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox61:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in
before you can comment on or make changes to this bug.
Description
•