GNOME Bugzilla – Bug 750260
wired network icon in menu bar has an inexplicable question mark in it
Last modified: 2020-11-13 02:03:47 UTC
Created attachment 304401 [details] screen shot control-center-3.16.2-1.fc22.x86_64 There is a question mark icon in the upper right corner that turns out to be for the wired connection. A ? used in this manner suggests the system is confused about something, and wants me to know that it's confused, hoping I can do something about it. So I'd expect there'd be a notification or a way to get more information about what the confusion is about.
Created attachment 304402 [details] journal for this boot
The menu bar is part of gnome-shell. The "?" you're seeing though means that the connectivity check failed. [ 3920.153840] f21v.localdomain NetworkManager[826]: <info> Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Peer failed to perform TLS handshake'. It's either a Fedora infrastructure problem, or a NetworkManager one. Reassigning to NetworkManager. See bug 750268 for a follow-up on the icon not being self-explanatory enough.
This is the same as downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1176316
I have a similar problem with an unexplained question mark for a wireless connection that works fine. I seem to have this issue when I'm behind a proxy (both for wired and wireless network connections).
(In reply to Bastien Nocera from comment #2) > > [ 3920.153840] f21v.localdomain NetworkManager[826]: <info> Connectivity > check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with > 'Peer failed to perform TLS handshake'. In this case, the connectivity check failed because of the SSL connection. It is anyway a bad idea to use https for connectivity checking. We fixed that upstream in bug 747866 and commit http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=2a3a4eb16f9119bf434a28adc94c2684da8fd5e4 Note that this is largely a configuration issue. So, users must rectify their configuration, or (if the distribution installed configuration snippets) the distribution must fix the configuration file. For downstream/Fedora, https://bugzilla.redhat.com/show_bug.cgi?id=1176316 this will be done. Closing BZ as fixed.
(In reply to Thomas Haller from comment #5) > (In reply to Bastien Nocera from comment #2) > > > > [ 3920.153840] f21v.localdomain NetworkManager[826]: <info> Connectivity > > check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with > > 'Peer failed to perform TLS handshake'. > > In this case, the connectivity check failed because of the SSL connection. > > It is anyway a bad idea to use https for connectivity checking. Why? It protects the user's privacy, at least a tiny bit. > We fixed that upstream in bug 747866 and commit > http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/ > ?id=2a3a4eb16f9119bf434a28adc94c2684da8fd5e4 If by "fixed" you mean "worked around", then yes. > Note that this is largely a configuration issue. So, users must rectify > their configuration, or (if the distribution installed configuration > snippets) the distribution must fix the configuration file. > > > For downstream/Fedora, https://bugzilla.redhat.com/show_bug.cgi?id=1176316 > this will be done. > > > > Closing BZ as fixed. This really isn't fixed.
(In reply to Bastien Nocera from comment #6) > (In reply to Thomas Haller from comment #5) > > (In reply to Bastien Nocera from comment #2) > > > > > > [ 3920.153840] f21v.localdomain NetworkManager[826]: <info> Connectivity > > > check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with > > > 'Peer failed to perform TLS handshake'. > > > > In this case, the connectivity check failed because of the SSL connection. > > > > It is anyway a bad idea to use https for connectivity checking. > > Why? It protects the user's privacy, at least a tiny bit. there is nothing private about the connectivity-check request. Especially does the HTTP header not contain fields beside: GET /static/hotspot.txt HTTP/1.1 Host: fedoraproject.org Connection: close
(In reply to Bastien Nocera from comment #6) > (In reply to Thomas Haller from comment #5) > > (In reply to Bastien Nocera from comment #2) > > > > > > [ 3920.153840] f21v.localdomain NetworkManager[826]: <info> Connectivity > > > check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with > > > 'Peer failed to perform TLS handshake'. > > > > In this case, the connectivity check failed because of the SSL connection. > > > > It is anyway a bad idea to use https for connectivity checking. > > Why? It protects the user's privacy, at least a tiny bit. it's a bad idea, because it works bad with detecting captive portals. And a portal might not handle SSL connections at all (which means we would detect "no-connectivity", instead of "portal"). If the portal does handle SSL connections it present an invalid certificate and the connection fails again (and to NM it's again not clear that this indicates "portal"). Also, we warn now about HTTPS use: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=eab32a5252e82361a563154cd8bfc3949aaad119
(In reply to Thomas Haller from comment #8) > (In reply to Bastien Nocera from comment #6) > > (In reply to Thomas Haller from comment #5) > > > (In reply to Bastien Nocera from comment #2) > > > > > > > > [ 3920.153840] f21v.localdomain NetworkManager[826]: <info> Connectivity > > > > check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with > > > > 'Peer failed to perform TLS handshake'. > > > > > > In this case, the connectivity check failed because of the SSL connection. > > > > > > It is anyway a bad idea to use https for connectivity checking. > > > > Why? It protects the user's privacy, at least a tiny bit. > > it's a bad idea, because it works bad with detecting captive portals. > > And a portal might not handle SSL connections at all (which means we would > detect "no-connectivity", instead of "portal"). > > If the portal does handle SSL connections it present an invalid certificate > and the connection fails again (and to NM it's again not clear that this > indicates "portal"). > > Also, we warn now about HTTPS use: > http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/ > ?id=eab32a5252e82361a563154cd8bfc3949aaad119 I'd rather have a fallback to HTTP in those cases where HTTPS fails, to ensure the problem is actually with the network and not with the connection, rather than actually hit HTTP in the wide internet all the time when connected.
A question marks occurs also when you are behind a proxy, because the proxy settings are not being used when testing the connectivity. See this issue in the Fedora Bugzilla for more details: https://bugzilla.redhat.com/show_bug.cgi?id=1184406
See also: https://bugzilla.gnome.org/show_bug.cgi?id=738694
Also tracking in Ubuntu bug: https://launchpad.net/bugs/1722256 I'm seeing inconsistent behaviour between different machines on the same network. Plus no other desktop environment besides Gnome exhibits the problem, so it's a bad look regardless of the cause.
I just made a comment in Launchpad, which on second thought probably could have better been made here. See: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1722256/comments/35
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2310