After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 647216 - NMManager:wwan-enabled is FALSE until the modem is actually connected
NMManager:wwan-enabled is FALSE until the modem is actually connected
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
: 646706 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-04-08 19:36 UTC by Dan Winship
Modified: 2011-05-23 15:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Winship 2011-04-08 19:36:02 UTC
In gnome-shell, if you click on the "Mobile Broadband" toggle switch, nothing happens. This is because it shows the value of NMManager:wwan-enabled, but that stays FALSE even after setting rstate->user_enabled to TRUE, because rstate->sw_enabled is FALSE, because manager_rfkill_update_one_type() believes that the NMDeviceModem is RFKILL_SOFT_BLOCKED, which is because it calls nm_manager_get_modem_enabled_state(), which calls nm_device_interface_get_enabled(), which calls nm_modem_get_mm_enabled(), which returns the value of the "Enabled" property on the corresponding ModemManager object, which returns "priv->state > MM_MODEM_STATE_ENABLED", which reflects whether or not the modem is connected, not whether or not it is available, and so is completely wrong for setting the WWAN rfkill state from.
Comment 1 Dan Williams 2011-04-11 23:10:25 UTC
Yeah, this is a hard nut to crack correctly, I spent a lot of time on Friday thinking about how to fix it.  The problem is that for WWAN, rfkill != power status.  This is because most WWAN devices simply drop off the USB bus when rfkilled, exactly like Bluetooth.  But when they are not killed, they have an additional 'powered' state where they are responsive, but their radios are either powered on or not according to some AT commands.

So we want to express that state in the WwanEnabled property (ie, if the wwan device is not "enabled" in ModemManager, the checkbox/switch should be off) but due to the way the rfkill code works in nm-manager.c that's a bit hard to do, since none of the other device types have this kind of second-level rfkill.

But this is clearly a bug that I"m working to fix.
Comment 2 Dan Williams 2011-04-14 03:08:48 UTC
9152c304ff0f88308ae6176b8c2dddfb1988c434 (master)
d0a1b23ea1803fc46567af4bb38d0078c873c357 (0.8.x)

Note that we'll still get failures if the modem isn't properly set up (like you forgot to insert the SIM) or if the modem doesn't support any usable character sets (some phones don't) so we'll still need to pay attention in the shell to the device states and the reason codes for device changes, because the D-Bus properties API can't return any errors when setting a property fails (mostly the fault of GObject's property API).  So we'll still see some cases of nothing happening when you hit the WWAN on/off switch, but in this case they should be hard failures of the modem instead of NM.
Comment 3 Dan Winship 2011-05-23 15:17:09 UTC
*** Bug 646706 has been marked as a duplicate of this bug. ***