GNOME Bugzilla – Bug 677588
Usability: disabling autoconnect for a network to which connecting is impossible (e.g. no known password) isn't easily doable
Last modified: 2016-03-02 11:41:12 UTC
Currently, the Gnome 3 network settings dialog only allows to edit the options of the current wlan network _if connected_. All other known networks to which the machine is currently not connected cannot be customized. nm-connections-editor is there, but the average user won't know of it. This is a scenario where the average user will be stuck: 1. user connects to a new password-secured network accidentially (user doesn't actually have the password and will never be able to connect) 2. user realizes their mistake, but now the user gets constantly prompted for the password (due to bug 677541 which makes it worse) and has no obvious way of removing the network, since for that they would need to be successfully connected Expected result: The user can open the network settings, can somehow get to a list of known networks (without nm-connections-editor magic or hidden tweak tool stuff) and remove the bogus network or disable autoconnect to it Actual result: The user is stuck with password prompt spams and will most likely need to consult help of some sort to find out how to get rid of it Please note this is based on personal experience, so maybe I missed some magic button which allows to solve this. But I actually ran into this myself and the only solution seemed to be nm-connections-editor, so if Gnome 3 can already do this it needs to be clearer/more accessible.
The actual bug is that if you click by mistake on a network for which you do not have the password, it should not be remembered as a preferred connection. I think this was discussed previously in a bug report, but I can't find it. Giovanni?
Probably it was discussed somewhere, can't remember either. The problem is, what we have now is a single autoconnect boolean. Right now, it is true by default, because generally you want to connect automatically to known wifi, but the shell can't distinguish between misclicks and willful activations, so it ends up being always true. (CC-ing Dan Williams in case there is something I'm missing, or in case it's possible to improve NetworkManager's interface). Also, at the NetworkManager layer, it would make sense to mark as permanently failed a connection for which secret retrieval failed at least once. So you would get the dialog the first time, click cancel, then be never prompted until activated manually again. Btw, IMHO the bug is that you can't forget non active connections, and that's a control-center bug, not a gnome-shell one.
Yeah, the problem is that you get prompted for the password multiple times, For a failed secret, you should re-prompt. If you hit Cancel, not really.
(In reply to comment #2) > Probably it was discussed somewhere, can't remember either. > The problem is, what we have now is a single autoconnect boolean. Right now, it > is true by default, because generally you want to connect automatically to > known wifi, but the shell can't distinguish between misclicks and willful > activations, so it ends up being always true. Isn't it possible at the Shell level to set the autoconnect boolean to FALSE if you click on Cancel the first time you try to connect to a network? There are two conditions: 1) The connection was not known before, and 2) You clicked cancel. Sounds like a reasonable behavior to me. > (CC-ing Dan Williams in case there is something I'm missing, or in case it's > possible to improve NetworkManager's interface). > > Also, at the NetworkManager layer, it would make sense to mark as permanently > failed a connection for which secret retrieval failed at least once. So you > would get the dialog the first time, click cancel, then be never prompted until > activated manually again. Would make sense too. > Btw, IMHO the bug is that you can't forget non active connections, and that's a > control-center bug, not a gnome-shell one. IMHO that's the second part of the bug. Even if the c-c part was fixed, we would still want to fix the present bug (because you don't want to require users to go to the control center just to forget a network they chose by mistake).
> Isn't it possible at the Shell level to set the autoconnect boolean to FALSE if > you click on Cancel the first time you try to connect to a network? There are > two conditions: 1) The connection was not known before, and 2) You clicked > cancel. Sounds like a reasonable behavior to me. Sounds reasonable to me aswell. Would make the situation a lot better for those not aware of nm-connections-editor who run into this unfortunate situation.
Ok, so I looked at NetworkManager sources, and here is something I think could improve the current situation. I didn't implement the autoconnect frobbing at the shell layer because that is a global property, and therefore could affect multi user system where one knows the necessary secrets and the others don't. This kind of configuration changes should be done in the control center panel. Btw, both NM patches are NOT TESTED, I don't want to mess with system daemons.
Created attachment 216439 [details] [review] SecretAgent: differentiate user actions from automatic connections Some secret agents implement system modal behavior for secret requests, and would like to differentiate it for automatic connections (as it could be annoying if a dialog pops up from nowhere)
Created attachment 216440 [details] [review] Policy: do not reset connection retries for permanently failed connections If a connection failed 4 times in a row, there are high chances it won't work 5 minutes after. This is in particular true if it failed due to missing secrets, as that condition won't change unless a new secret agent is registered, and even in case of temporary connectivity problems the user can rely on the session agents to force a connection that is known to work.
Comment on attachment 216439 [details] [review] SecretAgent: differentiate user actions from automatic connections Now that I look at it, I mentally merged this with bug 660293, but they don't need to...
<mclasen> dcbw: while I'm soliciting comments: https://bugzilla.gnome.org/show_bug.cgi?id=677588 <dcbw> mclasen: discussed that with Owen a while back actually <dcbw> mclasen: this would be an all-NM fix, but need to figure out a way to do it that doesn't screw admin-provided connections that are just dropped into client machines <dcbw> mclasen: basically, the Timestamp will get updated to something !0 if the connection was ever successful, so that's a great way to figure this out, except that you rarely set a timestamp when dropping in new connections since the timestamp was never required for autoconnect before
What we really want to do here, instead of changing the "retries" counter, is to key autoconnect off *both* the autoconnect property, and the "timestamp" property. Timestamp will get updated to !0 whenever the connection is successful, so when looking for automatic networks, we could just ignore anything that has a zero timestamp. This breaks two cases: 1) admin-deployed connections that you haven't connected to yet, but which the admin expects will autoconnect when you're in range. These may not have timestamps because they weren't useful for this sort of thing before. 2) Networks you haven't connected to in a year, since the global timestamp code landed on 2011-03-02, which was released as part of 0.9.0. Both these cases will no longer autoconnect to that saved network, but obviously it could be picked from the menu. Anyway, I think this should be fixed in NM, and that clients shouldn't have to care about it since NM should just do the right thing.
Maybe just to test this out, we only check timestamp for wifi connections, since that's where the pain really is.
*** Bug 690604 has been marked as a duplicate of this bug. ***
After my bug report was marked a duplicate I looked at this report. Temporarily disabling autoconnect for known networks that won't connect right now in order to prevent being spammed with the password window pop-up would be the elegant way to go. So could someone explain to me why this bug is still unconfirmed given these 12 comments? And is there any progress on it since June? Thanks!
(In reply to comment #14) > So could someone explain to me why this bug is still unconfirmed given these 12 > comments? We do not use the UNCONFIRMED status.
Has this been fixed? It seems fixed for me, I'm only seeing 1-2 password prompts and then the reconnect mechanism will give up. (which is good!) I'll close this for now since it seems as if it has been fixed. If someone still sees this, please comment and I'll reopen