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

Status: RESOLVED FIXED

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

Description

[Eric Rescorla (:ekr)]

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.

Comment 1

[Daniel Stenberg [:bagder]]

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?

Comment 2

[Patrick McManus [:mcmanus]]

which mode were you in? probably relevant.

Comment 3

[Eric Rescorla (:ekr)]

3

Comment 4

[Daniel Stenberg [:bagder]]

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

[Patrick McManus [:mcmanus]]

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?

Comment 6

[Daniel Stenberg [:bagder]]

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

[Patrick McManus [:mcmanus]]

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.

Comment 8

[Daniel Stenberg [:bagder]]

Attachment: bug 1446352 TRR: make "only mode" not wait for CP confirmation

... to avoid a catch-22 as CP needs name resolve to work.

Review commit: https://reviewboard.mozilla.org/r/228624/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/228624/

Comment 9

[Patrick McManus [:mcmanus]]

Comment on attachment 8959858 [details]
bug 1446352 TRR: make "only mode" not wait for CP confirmation

https://reviewboard.mozilla.org/r/228624/#review234446

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6b3f3316dd39
TRR: make "only mode" not wait for CP confirmation r=mcmanus

Comment 11

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/6b3f3316dd39