Re: Captive portal detection on wired connections - bug or feature?
On 26/03/15 17:50, Dan Williams wrote: On Thu, 2015-03-26 at 18:29 +0200, Alexander Ploumistos wrote: On Thu, Mar 26, 2015 at 6:24 PM, Bastien Nocera bnoc...@redhat.com wrote: You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf to disable it. Is there a *proper* way to do that so that there aren't any conflicts with future updates, e.g. commenting the lines out, removing/renaming the file, setting the interval to 0, etc.? As Adam implied, you can add your own, higher-numbered file with the same options and NM will use those in preference to the Fedora-installed one. See 'man NetworkManager.conf' for specifics. --- If a default NetworkManager.conf is provided by your distribution's packages, you should not modify it, since your changes may get overwritten by package updates. Instead, you can add additional .conf files to the conf.d directory. These will be read in order, with later files overriding earlier ones. --- Sorting of filenames is strcmp()-style, so 90-my-stuff.conf takes precedence over 10-bad-stuff.conf. There are still quite a few unknowns. To summarise, does this locally disable? crudini --set /etc/NetworkManager/conf.d/21-connectivity-local.conf connectivity interval 0 systemctl reload NetworkManager thanks, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Fri, 2015-03-27 at 20:30 +0200, Alexander Ploumistos wrote: On Fri, Mar 27, 2015 at 8:09 PM, Pádraig Brady p...@draigbrady.com wrote: There are still quite a few unknowns. To summarise, does this locally disable? crudini --set /etc/NetworkManager/conf.d/21-connectivity-local.conf connectivity interval 0 systemctl reload NetworkManager Take a look at https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1 it's Dan Williams' blog post I mentioned earlier. According to that, your command should work. As stated before, all the options are documented in the NetworkManager.conf manpage. Also note that NM 1.2 will have SIGHUP-style reloading of the connectivity config parameters, so when that shows up you won't need the wield the restart hammer. 1.0 and earlier do need a restart to notice. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Fri, Mar 27, 2015 at 8:09 PM, Pádraig Brady p...@draigbrady.com wrote: There are still quite a few unknowns. To summarise, does this locally disable? crudini --set /etc/NetworkManager/conf.d/21-connectivity-local.conf connectivity interval 0 systemctl reload NetworkManager Take a look at https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1 it's Dan Williams' blog post I mentioned earlier. According to that, your command should work. As stated before, all the options are documented in the NetworkManager.conf manpage. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
- Original Message - On Thu, 2015-03-26 at 10:52 -0500, Dan Williams wrote: On Thu, 2015-03-26 at 10:45 -0500, Michael Catanzaro wrote: On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote: This was most likely caused by some issues with out proxy servers this evening. We were adding 3 new proxy servers into the rotation and there were some config issues with some of them. ;( This would have only affected some folks in North America sporadically, (when they happened to hit a proxy that wasn't working right) not everyone. Sorry this happened, everything should be back to normal now. I think it would make sense to do a second ping to some other server if the first one to fedoraproject.org fails, for robustness. Maybe to redhat.com, or something that should never be down like google.com (my vote), or to someplace that promises not to track users, like duckduckgo.com (hardly matters much for a connectivity check?). We could always use the Google servers that Android uses by default, instead of Fedora :) Those would be pretty well guaranteed to be up... You might use both so you have less chances of false positive, but *please* make it uninstallable, or easily disableable. You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf to disable it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Thu, 2015-03-26 at 18:29 +0200, Alexander Ploumistos wrote: On Thu, Mar 26, 2015 at 6:24 PM, Bastien Nocera bnoc...@redhat.com wrote: You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf to disable it. Is there a *proper* way to do that so that there aren't any conflicts with future updates, e.g. commenting the lines out, removing/renaming the file, setting the interval to 0, etc.? As Adam implied, you can add your own, higher-numbered file with the same options and NM will use those in preference to the Fedora-installed one. See 'man NetworkManager.conf' for specifics. --- If a default NetworkManager.conf is provided by your distribution's packages, you should not modify it, since your changes may get overwritten by package updates. Instead, you can add additional .conf files to the conf.d directory. These will be read in order, with later files overriding earlier ones. --- Sorting of filenames is strcmp()-style, so 90-my-stuff.conf takes precedence over 10-bad-stuff.conf. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
- Original Message - On Thu, 2015-03-26 at 10:45 -0500, Michael Catanzaro wrote: On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote: This was most likely caused by some issues with out proxy servers this evening. We were adding 3 new proxy servers into the rotation and there were some config issues with some of them. ;( This would have only affected some folks in North America sporadically, (when they happened to hit a proxy that wasn't working right) not everyone. Sorry this happened, everything should be back to normal now. I think it would make sense to do a second ping to some other server if the first one to fedoraproject.org fails, for robustness. Maybe to redhat.com, or something that should never be down like google.com (my vote), or to someplace that promises not to track users, like duckduckgo.com (hardly matters much for a connectivity check?). We could always use the Google servers that Android uses by default, instead of Fedora :) Those would be pretty well guaranteed to be up... I would hope that the Fedora infra will do better in the future to make sure that we don't run into those problems again. Using Google's servers would probably mean that we would need to start making this opt-in, to avoid information leaks. We've been working on the privacy policy to the same effect. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Thu, Mar 26, 2015 at 6:24 PM, Bastien Nocera bnoc...@redhat.com wrote: You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf to disable it. Is there a *proper* way to do that so that there aren't any conflicts with future updates, e.g. commenting the lines out, removing/renaming the file, setting the interval to 0, etc.? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Thu, 2015-03-26 at 12:24 -0400, Bastien Nocera wrote: - Original Message - On Thu, 2015-03-26 at 10:52 -0500, Dan Williams wrote: On Thu, 2015-03-26 at 10:45 -0500, Michael Catanzaro wrote: On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote: This was most likely caused by some issues with out proxy servers this evening. We were adding 3 new proxy servers into the rotation and there were some config issues with some of them. ;( This would have only affected some folks in North America sporadically, (when they happened to hit a proxy that wasn't working right) not everyone. Sorry this happened, everything should be back to normal now. I think it would make sense to do a second ping to some other server if the first one to fedoraproject.org fails, for robustness. Maybe to redhat.com, or something that should never be down like google.com (my vote), or to someplace that promises not to track users, like duckduckgo.com (hardly matters much for a connectivity check?). We could always use the Google servers that Android uses by default, instead of Fedora :) Those would be pretty well guaranteed to be up... You might use both so you have less chances of false positive, but *please* make it uninstallable, or easily disableable. You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf to disable it. It would probably be better (if NM respects it) to add a higher- numbered file to override it; that way you aren't changing the contents of a packaged file. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Thu, 2015-03-26 at 11:21 -0400, Stephen Gallagher wrote: On Thu, 2015-03-26 at 04:15 +0200, Alexander Ploumistos wrote: On Thu, Mar 26, 2015 at 4:06 AM, Adam Williamson adamw...@fedoraproject.org wrote: Lots of people have been seeing it, it may be related to some issues with the Fedora infrastructure this afternoon (the check works by trying to contact a Fedora server). That much I gathered, but when I first read about the captive portal detection feature, I thought it was supposed to work only with wireless connections, though I guess it would make sense to check with all interfaces. Can it be disabled for a particular interface/connection though? I am being bombarded with pop-ups as I am trying to write this... No, it still makes sense for wired networks. Have you ever used an ethernet wall-jack at a hotel? It generally goes through a captive portal, just like wireless. How about the detection is disabled for connections in the 'Home' zone? I suppose that's a bit of a boundary issue so long as the 'zone' concept is considered a part of firewalld, but... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On 03/26/2015 12:53 PM, Adam Williamson wrote: You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf to disable it. It would probably be better (if NM respects it) to add a higher- numbered file to override it; that way you aren't changing the contents of a packaged file. Yes, that will work (although the whole point of putting that file into a separate package was that you were supposed to be able to uninstall the package if you didn't want it). -- Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Thu, Mar 26, 2015 at 7:50 PM, Dan Williams d...@redhat.com wrote: As Adam implied, you can add your own, higher-numbered file with the same options and NM will use those in preference to the Fedora-installed one. See 'man NetworkManager.conf' for specifics. Thanks, I found your blog post NetworkManager for Administrators Part 1 and that filled in the blanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Thu, 2015-03-26 at 04:15 +0200, Alexander Ploumistos wrote: On Thu, Mar 26, 2015 at 4:06 AM, Adam Williamson adamw...@fedoraproject.org wrote: Lots of people have been seeing it, it may be related to some issues with the Fedora infrastructure this afternoon (the check works by trying to contact a Fedora server). That much I gathered, but when I first read about the captive portal detection feature, I thought it was supposed to work only with wireless connections, though I guess it would make sense to check with all interfaces. Can it be disabled for a particular interface/connection though? I am being bombarded with pop-ups as I am trying to write this... No, it still makes sense for wired networks. Have you ever used an ethernet wall-jack at a hotel? It generally goes through a captive portal, just like wireless. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Thu, Mar 26, 2015 at 5:21 PM, Stephen Gallagher sgall...@redhat.com wrote: No, it still makes sense for wired networks. Have you ever used an ethernet wall-jack at a hotel? It generally goes through a captive portal, just like wireless. Yes, I realized that later on and I discovered the messages pertaining to the implementation. I can't figure out though why it happened yesterday and not e.g. if I disconnect my ADSL router from my LAN. Perhaps a check box in NM that disables monitoring if the user chooses to do so is in order. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Thu, 2015-03-26 at 10:52 -0500, Dan Williams wrote: On Thu, 2015-03-26 at 10:45 -0500, Michael Catanzaro wrote: On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote: This was most likely caused by some issues with out proxy servers this evening. We were adding 3 new proxy servers into the rotation and there were some config issues with some of them. ;( This would have only affected some folks in North America sporadically, (when they happened to hit a proxy that wasn't working right) not everyone. Sorry this happened, everything should be back to normal now. I think it would make sense to do a second ping to some other server if the first one to fedoraproject.org fails, for robustness. Maybe to redhat.com, or something that should never be down like google.com (my vote), or to someplace that promises not to track users, like duckduckgo.com (hardly matters much for a connectivity check?). We could always use the Google servers that Android uses by default, instead of Fedora :) Those would be pretty well guaranteed to be up... You might use both so you have less chances of false positive, but *please* make it uninstallable, or easily disableable. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote: This was most likely caused by some issues with out proxy servers this evening. We were adding 3 new proxy servers into the rotation and there were some config issues with some of them. ;( This would have only affected some folks in North America sporadically, (when they happened to hit a proxy that wasn't working right) not everyone. Sorry this happened, everything should be back to normal now. I think it would make sense to do a second ping to some other server if the first one to fedoraproject.org fails, for robustness. Maybe to redhat.com, or something that should never be down like google.com (my vote), or to someplace that promises not to track users, like duckduckgo.com (hardly matters much for a connectivity check?). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Thu, 2015-03-26 at 10:45 -0500, Michael Catanzaro wrote: On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote: This was most likely caused by some issues with out proxy servers this evening. We were adding 3 new proxy servers into the rotation and there were some config issues with some of them. ;( This would have only affected some folks in North America sporadically, (when they happened to hit a proxy that wasn't working right) not everyone. Sorry this happened, everything should be back to normal now. I think it would make sense to do a second ping to some other server if the first one to fedoraproject.org fails, for robustness. Maybe to redhat.com, or something that should never be down like google.com (my vote), or to someplace that promises not to track users, like duckduckgo.com (hardly matters much for a connectivity check?). We could always use the Google servers that Android uses by default, instead of Fedora :) Those would be pretty well guaranteed to be up... Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Wed, 25 Mar 2015, Adam Williamson wrote: Lots of people have been seeing it, it may be related to some issues with the Fedora infrastructure this afternoon (the check works by trying to contact a Fedora server). I've seen them regularly in the last few hours but I'm on hotel wifi, so it could also be just crappy wifi. The dnsec-trigger package which I'm also running also has hotspot detection, using http://hotspot-nocache.fedoraproject.org/ which does not seem to cause tehse false positives. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Captive portal detection on wired connections - bug or feature?
During the last hour, I got three pop-ups on my workstation (which is connected over Ethernet) with blank windows and a title that read Captive portal. Two of them turned to the gnome.org home page, while the other one just disappeared. In my journal I have this sort of errors: Mar 26 03:39:36 hostname NetworkManager[1006]: info Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' returned status '403 Forbidden'; assuming captive portal. Mar 26 03:39:36 hostname NetworkManager[1006]: info NetworkManager state is now CONNECTED_SITE Mar 26 03:39:36 hostname NetworkManager[1006]: info Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Error performing TLS handshake: An unexpected TLS packet was received.'. Mar 26 03:39:40 hostname NetworkManager[1006]: info NetworkManager state is now CONNECTED_GLOBAL Mar 26 03:39:46 hostname NetworkManager[1006]: info Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Error performing TLS handshake: An unexpected TLS packet was received.'. Mar 26 03:39:46 hostname NetworkManager[1006]: info NetworkManager state is now CONNECTED_SITE Mar 26 03:39:48 hostname NetworkManager[1006]: info Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' returned status '403 Forbidden'; assuming captive portal. Mar 26 03:39:49 hostname NetworkManager[1006]: info NetworkManager state is now CONNECTED_GLOBAL Mar 26 03:39:55 hostname NetworkManager[1006]: info Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' returned status '403 Forbidden'; assuming captive portal. Mar 26 03:39:55 hostname NetworkManager[1006]: info NetworkManager state is now CONNECTED_SITE Mar 26 03:39:56 hostname NetworkManager[1006]: info NetworkManager state is now CONNECTED_GLOBAL Is this supposed to happen or do I need to file a bug report? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Thu, 2015-03-26 at 03:59 +0200, Alexander Ploumistos wrote: During the last hour, I got three pop-ups on my workstation (which is connected over Ethernet) with blank windows and a title that read Captive portal. Two of them turned to the gnome.org home page, while the other one just disappeared. Is this supposed to happen or do I need to file a bug report? Lots of people have been seeing it, it may be related to some issues with the Fedora infrastructure this afternoon (the check works by trying to contact a Fedora server). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Thu, Mar 26, 2015 at 4:06 AM, Adam Williamson adamw...@fedoraproject.org wrote: Lots of people have been seeing it, it may be related to some issues with the Fedora infrastructure this afternoon (the check works by trying to contact a Fedora server). That much I gathered, but when I first read about the captive portal detection feature, I thought it was supposed to work only with wireless connections, though I guess it would make sense to check with all interfaces. Can it be disabled for a particular interface/connection though? I am being bombarded with pop-ups as I am trying to write this... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Captive portal detection on wired connections - bug or feature?
On Wed, 25 Mar 2015 22:26:56 -0400 (EDT) Paul Wouters p...@nohats.ca wrote: On Wed, 25 Mar 2015, Adam Williamson wrote: Lots of people have been seeing it, it may be related to some issues with the Fedora infrastructure this afternoon (the check works by trying to contact a Fedora server). I've seen them regularly in the last few hours but I'm on hotel wifi, so it could also be just crappy wifi. The dnsec-trigger package which I'm also running also has hotspot detection, using http://hotspot-nocache.fedoraproject.org/ which does not seem to cause tehse false positives. This was most likely caused by some issues with out proxy servers this evening. We were adding 3 new proxy servers into the rotation and there were some config issues with some of them. ;( This would have only affected some folks in North America sporadically, (when they happened to hit a proxy that wasn't working right) not everyone. Sorry this happened, everything should be back to normal now. kevin pgpS_Iiaqx5sn.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
