GNOME Bugzilla – Bug 693024
Track connection state after initiating connection activation
Last modified: 2021-06-09 16:09:46 UTC
when you enable hotspot mode, there needs to be a spinner until the connection moves to the CONNECTED state, and if it moves to DISCONNECTED, we need to flip the switch off (including, if it moves directly from CONNECTING to DISCONNECTED without ever hitting CONNECTED)
it would also be great if we could show the number of connected devices - does nm have that information ?
not currently, though we should be able to get it...
I'm still experiencing the problem. I'm running Fedora 20 on a Lenovo B590 laptop with 02:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01) wifi hardware. The package versions are kernel-3.12.8-300.fc20.x86_64 (using the packaged b43, brcmsmac, bcma) NetworkManager-0.9.9.0-26.git20131003.fc20.x86_64 control-center-3.10.2-4.fc20.x86_64 If I turn on the wifi hotspot from the control center, there's no indication that the operation has failed and the graphical switch in the control center window stays on.
Dan, is this bug #723643?
(In reply to comment #3) > If I turn on the wifi hotspot from the control center, there's no indication > that the operation has failed and the graphical switch in the control center > window stays on. Please file a separate bug about this. (In reply to comment #0) > when you enable hotspot mode, there needs to be a spinner until the connection > moves to the CONNECTED state, and if it moves to DISCONNECTED, we need to flip > the switch off (including, if it moves directly from CONNECTING to DISCONNECTED > without ever hitting CONNECTED) Wouldn't the result of nm_client_add_and_activate_connection() tell us that this failed? I would expect the connection to be marked as CONNECTED once this function has called its callback.
(In reply to comment #5) > Wouldn't the result of nm_client_add_and_activate_connection() tell us that > this failed? I would expect the connection to be marked as CONNECTED once this > function has called its callback. No, unfortunately, a successful callback from add_and_activate() just tells you that NM has *started* activating the connection (as opposed to giving you a "permission denied" or something). You need to watch "notify::state" on the NMActiveConnection to see if the activation attempt actually succeeds.
(In reply to comment #6) > (In reply to comment #5) > > Wouldn't the result of nm_client_add_and_activate_connection() tell us that > > this failed? I would expect the connection to be marked as CONNECTED once this > > function has called its callback. > > No, unfortunately, a successful callback from add_and_activate() just tells you > that NM has *started* activating the connection (as opposed to giving you a > "permission denied" or something). You need to watch "notify::state" on the > NMActiveConnection to see if the activation attempt actually succeeds. And is there a reliable way to make the activation fail, so I can test that case?
Hm... that's tricky. Most things that would make activation fail don't apply to the hotspot case. Maybe "chmod 0 /sbin/wpa_supplicant"? (But it's possible that would cause the add_and_activate() call to fail instead.)
> (In reply to comment #5) > No, unfortunately, a successful callback from add_and_activate() just tells you > that NM has *started* activating the connection (as opposed to giving you a > "permission denied" or something). This is surely a documentation bug in libnm-glib [1] as the description of the function is very clear that it activates the connection. A reasonable programmer would not expect it to return before the connection has been activated unless the GError parameter to the NMClientAddActivateFn is set. > You need to watch "notify::state" on the > NMActiveConnection to see if the activation attempt actually succeeds. The valid documented states seem to be the integers 0, 1, 2, and 3. [2] These are hardly usable by applications. Is there additional documentation somewhere I have not found? How are we supposed to map these integers to reasonable states? Also, Bastien, we make this same mistake for all wi-fi connections (in the function connection_add_or_activate_cb), not just for hotspots. Maybe this explains why the network panel has always been fairly unreliable for me. [1] https://developer.gnome.org/libnm-glib/0.9/NMClient.html#nm-client-add-and-activate-connection [2] https://developer.gnome.org/libnm-glib/0.9/NMActiveConnection.html#NMActiveConnection--state
(In reply to comment #9) > Also, Bastien, we make this same mistake for all wi-fi connections (in the > function connection_add_or_activate_cb), not just for hotspots. Maybe this > explains why the network panel has always been fairly unreliable for me. And also in activate_new_cb in network-dialogs.c
(In reply to comment #9) > This is surely a documentation bug in libnm-glib [1] as the description of the > function is very clear that it activates the connection. Huh. Yes, that's wrong. > > You need to watch "notify::state" on the > > NMActiveConnection to see if the activation attempt actually succeeds. > > The valid documented states seem to be the integers 0, 1, 2, and 3. [2] These > are hardly usable by applications. It's an NMActiveConnectionState. (For some reason libnm-glib didn't originally use GParamSpecEnum, and fixing it now would be an ABI break. One of many things being fixed in the new "libnm".)
(In reply to comment #7) > And is there a reliable way to make the activation fail, so I can test that > case? For me, activating the hotspot only works once. It will always fail if I switch it off and try it again. (In reply to comment #11) > Huh. Yes, that's wrong. OK, I've filed bug #736233. I've also renamed this bug to generalize it to cover all cases where we activate a connection. I count 15 uses of nm_client_add_and_activate_connection or nm_client_activate_connection in the network panel, and 0 of them subscribe to state changes, so it'd be difficult to track them all in separate bugs. > It's an NMActiveConnectionState. (For some reason libnm-glib didn't originally > use GParamSpecEnum, and fixing it now would be an ABI break. One of many things > being fixed in the new "libnm".) Great, glad that's fixed in libnm. Thanks for maintaining a stable ABI!
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 bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.