On Fri, 2015-07-17 at 13:22 -0400, Chuck Anderson wrote: > Looks great! I've been using this daily on Fedora 21 and I have to > say it mostly works well EXCEPT for the captive portal detection stuff > which is just horrendously bad, so I'm happy to see a new design that > may work a lot better. What doesn't work in your experience with the captive portal stuff? Just wondering so we can improve it. This plan doesn't necessarily make anything about *detecting* a portal better, just the flow after one has been detected. Dan > Will the below be substantially implemented and testable > by the July 28 Change CheckPoint: Completion deadline (testable)? > That is only 10 days away... > > It would be great if the Change page could be updated with these plans > and the current status, how to test, etc. > > Thanks! > > On Fri, Jul 17, 2015 at 05:40:56PM +0200, Tomas Hozza wrote: > > Hello all. > > > > I would like to share the outcome of the discussion between GNOME and NM developers > > and the "Default DNS resolver" [1] Change for F23. > > > > The full summary can be found here [2] and recording here [3] is anyone is interested. > > > > > > Integration points: > > - Captive portal detection > > - Captive portal handling > > - User interaction > > > > > > Points we agreed on: > > * Captive portal detecion > > * NM side > > * NM will be the only daemon doing Captive portal detection > > * NM moves connectivity check before NM_DEVICE_STATE_ACTIVATED, emits signal before network is "up" > > * If portal has been detected, NM blocks NM_DEVICE_STATE_ACTIVATED for a specific device until there is no more portal > > * NM regularly does the Captive portal detection (connectivity check) to determine if the login using GNOME was already done > > * Once the login was done and Internet connectivity is detected, NM triggers some event in nm-dispatcher (or something like that) > > * GNOME side > > * GNOME Shell does not do detection itself, but relies on the NM (as already done) > > * GNOME is watching the change of "connectivity state" property in NM > > * dnssec-trigger side > > * Does not do any detection > > * does not do any user interaction > > * Only relies on events triggered by NM and acts based on the connectivity status > > > > * Captive portal handling (login) > > * GNOME side > > * If Captive portal is detected, then browser window is launched > > * The browser window ls launched with LD_PRELOAD (https://github.com/hadess/resolvconf-override) as resolv.conf override > > * GNOME should fetch the connection-provided DNS servers using NM API (existing) and use those for LD_PRELOAD solution > > * dnssec-trigger side > > * does not do any user interaction > > * Only relies on events triggered by NM and acts based on the connectivity status > > > > * User interface / user interaction > > * Fedora Workstation product > > * GNOME shell > > * informs the user about the Captive portal > > * launches the window > > * dnssec-trigger > > * the applet will be split into separate package and not installed by default (already done) > > * if all falbacks fail, it switches automatically to "Insecure" mode (no DNSSEC validation) without user interaction > > * automatic switch to insecure mode will be possible to turn off using configuration file for expert users > > * a notification can be emited about switching to insecure mode (so far by default OFF) > > * Other desktops / Spins > > * dnssec-trigger applet > > * should handle the UI that is usually handled by GNOME Shell (if there is not any specific Spin implementation to do that, i.e. if GNOME is not in use) > > * Captive portal detection will be still done in NM > > > > * under discussion: > > * notification can be turned OFF by default, but configurable in config file for expert users - unfortunatelly this will not create pressure on admins to fix the networks > > * alternative: display a message which will say that local network is broken and that admin should be woken up: > > * 'Your network is seriously broken. Go and kick your network admin NOW! > > * This broken network will stop working from Fedora 24 on because it does not support DNSSEC. (Tell this to your admin!)' > > > > > > [1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > [2] https://www.piratepad.ca/p/default-dns-resolver-f23 > > [3] https://bluejeans.com/s/8pTY/ > > > > > > Regards, > > -- > > Tomas Hozza > > Software Engineer - EMEA ENG Developer Experience > > > > PGP: 1D9F3C2D > > Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
