GNOME Bugzilla – Bug 664495
prompted to connect to wireless every few minutes
Last modified: 2021-07-05 14:39:51 UTC
Apparently the wep key for my work network is wrong or something. I am prompted by a system modal to login to my wireless access point very few minutes. There are a few things annoying about this: * I'm on a wired connection * I don't care about wireless and hit cancel * When I hit cancel a non shell modal, unparented gtk dialog comes up asking me the same thing * I then get a shell banner notification telling me something went wrong * Then 2-5 minutes later I repeat the process :(
I got hit with the same thing. * When you try to kill Wireless, you'll find that instead of a switch, you have "unavailable", making you go to the Network Settings dialog and flip that one instead.
I still have the wireless switch in the network menu.
My understanding is that this one is difficult to fix: At the root NetworkManager has the concept of always trying to connect to networks that are enabled. That's at the system level. NetworkManager also can't easily in many cases know *why* connecting to a network failed - e.g. it may not be able to distinguish between a WEP key that failed and timing out. Now when connecting to a *new* network if the design is that the password prompt should appear, we could try to hardcode that. But that leaves open the question of what should happen when e.g. the WEP key does change for a network.
I guess what we need here is: What do you want to happen?
Is there a way we can tell NetworkManager to only pop up a network secrets dialog when we ask for one? That is, "as a result of a user action".
I am not certain we ever want to ask for a password of any kind out of the blue. That is really a very nasty thing to train the user to do. In the case where we can't connect to a network I'd much prefer asking the user to select a network. Most of this stuff is pretty obvious I think but: * when connected to a wired network never prompt for wireless keys * when not connected to a network of any kind and no previously connected networks are available we may want to prompt the user to select a network * when the user cancels connecting to a network do not prompt again until the user manually connects to a network * Only prompt the user for a password when she explicitly connects to a network * When a foreground application tries to use the network prompt the user to connect to a network if not already connected
As far as I understand it... (In reply to comment #6) > I am not certain we ever want to ask for a password of any kind out of the > blue. That is really a very nasty thing to train the user to do. > > In the case where we can't connect to a network I'd much prefer asking the user > to select a network. Most of this stuff is pretty obvious I think but: > > * when connected to a wired network never prompt for wireless keys Already done, with recent enough NM (0.9.2, I think) - if there is a default connection (wired, 3G), and wifi is available, it won't try to connect. > * when not connected to a network of any kind and no previously connected > networks are available we may want to prompt the user to select a network This is not done at the moment. In fact, if the network is not known, nothing is asked, and the network is kept disconnected. > * when the user cancels connecting to a network do not prompt again until the > user manually connects to a network Already implemented (if connecting fail because secrets are not available, it is internally marked invalid, and thus no longer a candidate for autoactivation, until NM is restarted. We could do more, and make Cancel actually remove the stored configuration for the network (that is, the NMConnection), but that would also remove any stored secrets, IP configs or anything else associated with the network. We could remove the autoconnect bit, but that last even after the first manual connect. > * Only prompt the user for a password when she explicitly connects to a > network Not possible with current system. Also, would break autoactivation for connections that don't have stored secrets (some VPNs or WPA2 enterprise have always-ask secrets, and it is always possible to uncheck "Save password" in nm-connection-editor) > * When a foreground application tries to use the network prompt the user to > connect to a network if not already connected This is possible in theory, but difficult to implement. My idea for this would be a nss module hooking into hosts database, calling into NetworkManager before resolving. The risk is having even more frequent interruptions, as system daemons or other sessions could trigger a connect request. On the other hand, if we go with implementing specific knowledge in applications (ignoring the burden of patching every single network using app, including third-party), I don't think we should use system modal dialogs, as they would be associated with a specific app anyway.
(In reply to comment #7) > As far as I understand it... ... > > * Only prompt the user for a password when she explicitly connects to a > > network > > Not possible with current system. Also, would break autoactivation for > connections that don't have stored secrets (some VPNs or WPA2 enterprise have > always-ask secrets, and it is always possible to uncheck "Save password" in > nm-connection-editor) I think I would still wait for the user to explicitly connect to a network that requires a password every time. Giovanni - if network manager is preventing the desired behaviour, would you be able to file a bug and mark it as blocking this one? > > * When a foreground application tries to use the network prompt the user to > > connect to a network if not already connected > > This is possible in theory, but difficult to implement. My idea for this would > be a nss module hooking into hosts database, calling into NetworkManager before > resolving. The risk is having even more frequent interruptions, as system > daemons or other sessions could trigger a connect request. > On the other hand, if we go with implementing specific knowledge in > applications (ignoring the burden of patching every single network using app, > including third-party), I don't think we should use system modal dialogs, as > they would be associated with a specific app anyway. System modals would work well for this, imo. Connecting to a network is always going to be a system level thing, and we should present it as such. I can provide a design for a system modal network selection dialog, if someone can work on this.
Bug 660293 has the necessary patches to replace the system modal dialog with a notification if the request is not a result of user interaction, and bug 677588 has a patch that should reduce the number of times the dialog is presented. Is there anything else here?
That sounds great already! I'm just wondering what cases where "the request is not a result of user interaction" are. I can only see one case where it should happen: when you are connected to a network and get disconnected for some reason, and you need a password to reconnect. It's fine to get a notification automatically to enter your password; but I think you should not get any more password requests if you hit cancel the first time a notification is shown (i.e. you get disconnected, period), or as long as you ignore the notification. Are there other cases?
Myself and a number of GNOME 3.8 users have been observing the following behaviour today: GNOME is attempting to connect to a known network (with a password entered previously), but failing. When it fails it throws up a password dialog. After having been canceled, the dialog keeps popping up.
Also note that one person has their laptop tethered to their phone for networking, and the wi-fi was still trying to connect and still throwing up password dialogs.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.