GNOME Bugzilla – Bug 592819
[PATCH] libnm/libnm-glib: use Bluetooth device name as description
Last modified: 2016-06-21 15:36:56 UTC
I tested the new nice feature of NM-0.8 that allows to connect to internet via PAN bluetooth connection of a phone. It is very handy and it works with my SonyEricson k810i, but I noticed several issues: - in nm-applet there is no way to disconnect from an established PAN connection; - if you right-click on the applet and choose "Connection Information", the information presented is not complete; - the PAN-"BT-MAC-ADDRESS" selector from the applet is not very user friendly (do we really need the PAN-BT-MAC-ADDRESS here ? I think a "Connect via PAN Bluetooth" is enough);
Yup, most of these enhancements you note here are already planned, just need to be done.
*** Bug 603524 has been marked as a duplicate of this bug. ***
(1) and (3) of your list are fixed already in either git master (1) or in the 'btdun' (3) branch waiting to be merged to 0.8.1.
As I wrote earlier, there is an issue with DUN in old Siemens/Benq-Siemens phones and, I think, maybe somewhere else. Logfile for SXG75/EF81: NetworkManager: <info> Activation (rfcomm0) starting connection 'life' NetworkManager: <info> (rfcomm0): device state change: 3 -> 4 (reason 0) NetworkManager: <info> Activation (rfcomm0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager: <info> Activation (rfcomm0) Stage 1 of 5 (Device Prepare) started... NetworkManager: <info> Activation (rfcomm0) Stage 1 of 5 (Device Prepare) complete. NetworkManager: <WARN> stage1_prepare_done(): GSM modem connection failed: SIM PUK required NetworkManager: <info> (rfcomm0): device state change: 4 -> 9 (reason 1) NetworkManager: <info> Marking connection 'life' invalid. NetworkManager: <info> Activation (rfcomm0) failed. NetworkManager: <info> (rfcomm0): device state change: 9 -> 3 (reason 0) NetworkManager: <info> (rfcomm0): deactivating device (reason: 0). NetworkManager: flush_routes: assertion `iface_idx >= 0' failed NetworkManager: flush_addresses: assertion `iface_idx >= 0' failed I've even try to wrote my PIN/PUK to settings without any result. And also i have two different phones/providers here, Nokia N73 and Siemens SXG75, Nokia works fine but Siemens didn't. WVDial works fine with connected thru BlueMan rfcomm0. Maybe, there is just a way to make "Custom connect" feature without any own MN logic with APN detection for exotic phones/situations? Manual setting of AT+CGDCONT and ATD *99***1# still works.
(In reply to comment #4) > As I wrote earlier, there is an issue with DUN in old Siemens/Benq-Siemens > phones and, I think, maybe somewhere else. Logfile for SXG75/EF81: > NetworkManager: <info> Activation (rfcomm0) starting connection 'life' > NetworkManager: <info> (rfcomm0): device state change: 3 -> 4 (reason 0) > NetworkManager: <info> Activation (rfcomm0) Stage 1 of 5 (Device Prepare) > scheduled... > NetworkManager: <info> Activation (rfcomm0) Stage 1 of 5 (Device Prepare) > started... > NetworkManager: <info> Activation (rfcomm0) Stage 1 of 5 (Device Prepare) > complete. > NetworkManager: <WARN> stage1_prepare_done(): GSM modem connection failed: SIM > PUK required > NetworkManager: <info> (rfcomm0): device state change: 4 -> 9 (reason 1) > NetworkManager: <info> Marking connection 'life' invalid. > NetworkManager: <info> Activation (rfcomm0) failed. > NetworkManager: <info> (rfcomm0): device state change: 9 -> 3 (reason 0) > NetworkManager: <info> (rfcomm0): deactivating device (reason: 0). > NetworkManager: flush_routes: assertion `iface_idx >= 0' failed > NetworkManager: flush_addresses: assertion `iface_idx >= 0' failed WOuld you mind filing another separate bug with this information, but also with modem-manager debug output? http://live.gnome.org/NetworkManager/Debugging See the bits about modem-manager debugging, I'd like to see the --debug output from modem-manager if I can.
Created attachment 288426 [details] [review] 0001-libnm-libnm-glib-use-Bluetooth-device-name-as-descri.patch
The applet and GNOME Shell have already worked around this by using the NMDeviceBt.Name property, but we might as well just do the right thing in the libs anyway.
Comment on attachment 288426 [details] [review] 0001-libnm-libnm-glib-use-Bluetooth-device-name-as-descri.patch >+ if (NM_IS_DEVICE_BT (device)) { >+ priv->description = g_strdup (nm_device_bt_get_name (NM_DEVICE_BT (device))); >+ return; >+ } that seems a little lame... in libnm at least we could add a new get_description() vmethod.
Created attachment 329878 [details] [review] 0001-libnm-libnm-glib-use-Bluetooth-device-name-as-descri.patch Somewhat of a hack, but works for now and we don't have to use a free slot from NMDevice.
(In reply to Dan Williams from comment #9) > 0001-libnm-libnm-glib-use-Bluetooth-device-name-as-descri.patch LGTM
(In reply to Dan Williams from comment #9) > Created attachment 329878 [details] [review] [review] > 0001-libnm-libnm-glib-use-Bluetooth-device-name-as-descri.patch > > Somewhat of a hack, but works for now and we don't have to use a free slot > from NMDevice. It seems the only libnm device class that implements a "name" property is NMDeviceBt. But it's unclear, what a "name" property for other device types would mean... So, I see this as a hack, but then I think it should be employed in a strict way. I like the patch from comment 8 more. Anyway, fine with me.
Yeah, both patches are kinda stupid because we don't really want to use another slot from NMDeviceClass just for something like this. But then again, we have 8 slots, and we've used very, very few of them over the years. We could also replace the NM_DEVICE_IS_BT() usage in nm_device_disambiguate_names() with this hack too. We have three options: 1) check NM_IS_DEVICE_BT() in nm-device.c - pretty clear layering violation and not very clean code. I really don't like it much. 2) use the 'name' property: also not very clean, but at least it has no direct dependency on NM_DEVICE_BT() and there's a plausible argument that we could add a 'name' property to other devices too. 3) use a slot from NMDeviceClass to get the name: cleanest, but uses a slot for a single-use thing. We do have 8 slots though, and we don't use them very often. What do you guys think?
I think 2) is reasonable, and would work well for other devices that will have a 'name' property in the future (if any).
Pushed to git master and 1.2.