On Mon, 2017-10-16 at 15:47 +0000, Marco Calistri wrote:
Beside the issue itself I really don't know why NM needs to check the connectivity and furthermore why in case of failure it opens a big notification window on the user desktop.
It's portal detection - the idea is to detect if you are behind a captive portal where you need to login to make use of the network connection (like is the case at every airport) Hence, NM tries to reach http://conncheck.opensuse.org, where it expects to be receiving a http/204 (empty body) answer with a X- NetworkManager-Status: online header in plus; our server setup there is as dumb as it can be: the header is unconditionally injected into a static http/204 reply (any other header would not make sense if NM could already reach that server)
IMHO from one side such NM behavior looks like a sort of a "spyware" and from the other side appears to be a bad design of its notification section.
The notification popped up because NM did not get the expected reply - but when the portal then opened, it could reach nmcheck.gnome.org - which is not something the portal code anticipated. What is not clear, though, is why conncheck.opensuse.org failed to respond correctly during the power outage: a backup server was in place during that time (the only explanation so far is that we might have missed to cater for ipv6-only clients; but I doubt there are THAT many out there yet)
But these are just my very personal impressions.
You're entitled to have them, as much as you're entitled to read the code about the 'phone home impression' so you can find out what happens. you're even able to setup your own server and change your configuration to that server to query the status, if you wish to preserve the functionality, or disable it. The beauty of open source, eh? Cheers Dominique