NetworkManager ignores the rfcomm port when it gets registered in blueman

[Martin List-Petersen]

Binary package hint: network-manager

When the rfcomm port get registered in blueman, network manager ignores the rfcomm port, because it thinks, that no bluetooth device is connected to it.

This is in lucid, package is network-manager 0.8.0ubuntu5-nmt5-karmic

Here's the output from syslog:
May 21 09:58:33 loke modem-manager: (rfcomm0) opening serial device...
May 21 09:58:33 loke blueman-mechanism: ** Registering modem
May 21 09:58:33 loke modem-manager: (rfcomm0): probe requested by plugin 'Generic'
May 21 09:58:33 loke blueman-mechanism: Probing device /dev/rfcomm0 for capabilities
May 21 09:58:33 loke blueman-mechanism: Device capabilities: ['GSM-07.07', 'GSM-07.05']
May 21 09:58:33 loke blueman-mechanism: Generating udev rule
May 21 09:58:34 loke udevd[383]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/60-thinkfinger.rules:13
May 21 09:58:34 loke modem-manager: (rfcomm0) closing serial device...
May 21 09:58:34 loke modem-manager: (Generic): GSM modem /sys/devices/pci0000:00/0000:00:1d.3/usb5/5-2 claimed port rfcomm0
May 21 09:58:34 loke modem-manager: Added modem /sys/devices/pci0000:00/0000:00:1d.3/usb5/5-2
May 21 09:58:34 loke modem-manager: Exported modem /sys/devices/pci0000:00/0000:00:1d.3/usb5/5-2 as /org/freedesktop/ModemManager/Modems/2
May 21 09:58:34 loke NetworkManager: modem_added: ignoring modem 'rfcomm0' (no associated Bluetooth device)
May 21 09:58:34 loke blueman-mechanism: Adding our own rfcomm device to hal

So the rfcomm device does never show up in network-manager. It used to in older versions of nm (pre 0.7.0, I think)

Establishing the connection using pon/poff is working perfectly over the rfcomm device.

Kind regards,
Martin List-Petersen

Upstream NM thread about this: "[PATCH] Fix for Blueman modem being ignored".

[Zdravko (zdravko-redhat-bugs)]

Description of problem:

Version-Release number of selected component (if applicable):

ModemManager-0.3-9.git20100409.fc12.i686
NetworkManager-0.8.0-6.git20100408.fc12.i686

How reproducible:

Always

Steps to Reproduce:
1. Connect to a bluetooth dun dial-up network service on a gsm phone using blueman

Actual results:

Blueman displays a message that the modem connection is available via NetworkManager but no Wireless Modem connection is available in NM

Expected results:

The connection should be available in NM an it should be able to connect.

Additional info:

This worked perfect before the update of NM and ModemManager

[Dan (dan-redhat-bugs)]

NetworkManager includes built-in Bluetooth DUN support. You'll want to set up a DUN connection via the bluetooth icon's "Set up new device..." wizard.

After you've completed that step, if the connection does not appear in the NM menu, we'll want to grab some logs to figure out what's going on.

[Zdravko (zdravko-redhat-bugs)]

I have done exactly that but no device shows up in NM. As I said it worked fine prior to the update (also reverting back to previous NM and MM made it work again..)

Below is the log..

Apr 25 13:49:35 X41 bluetoothd[2339]: link_key_request (sba=00:14:A4:DC:38:D6, dba=34:7E:39:5B:B1:08)
Apr 25 13:49:35 X41 bluetoothd[2339]: pin_code_request (sba=00:14:A4:DC:38:D6, dba=34:7E:39:5B:B1:08)
Apr 25 13:49:46 X41 bluetoothd[2339]: link_key_notify (sba=00:14:A4:DC:38:D6, dba=34:7E:39:5B:B1:08, type=0)
Apr 25 13:49:46 X41 dbus-daemon: Rejected send message, 2 matched rules; type="method_return", sender=":1.69" (uid=500 pid=2362 comm="/usr/bin/python) interface="(unset)" member="(unset)" error name="(unset)" requested_reply=0 destination=":1.64" (uid=0 pid=2338 comm="/usr/sbin/bluetoothd))
Apr 25 13:49:46 X41 bluetoothd[2339]: probe failed with driver input-headset for device /org/bluez/2338/hci0/dev_34_7E_39_5B_B1_08
Apr 25 13:49:50 X41 bluetoothd[2339]: link_key_request (sba=00:14:A4:DC:38:D6, dba=34:7E:39:5B:B1:08)
Apr 25 13:49:50 X41 modem-manager: (rfcomm0) opening serial device...
Apr 25 13:49:51 X41 modem-manager: (rfcomm0) closing serial device...
Apr 25 13:49:51 X41 modem-manager: Generic: (tty/rfcomm0) WARNING: missing udev 'device' file
Apr 25 13:49:51 X41 modem-manager: (rfcomm0) opening serial device...
Apr 25 13:49:51 X41 modem-manager: (Generic): GSM modem /sys/devices/pci0000:00/0000:00:1d.2/usb4/4-1 claimed port rfcomm0
Apr 25 13:49:51 X41 modem-manager: (rfcomm0) closing serial device...
Apr 25 13:49:51 X41 NetworkManager: <info> ignoring modem 'rfcomm0' (no associated Bluetooth device)

[Dan (dan-redhat-bugs)]

Ok, this shows that ModemManager is finding the modem correctly, but the configuration that NM requires (that the bluetooth wizard is supposed to write to GConf) somehow isn't getting set correctly.

Any chance you can take a screenshot of the applet menu for me after you've completed the bluetooth wizard? And you are using the gnome-bluetooth icon to set up the device, *not* blueman, correct?

[Zdravko (zdravko-redhat-bugs)]

Created attachment 409128
Screenshot

I am using only blueman..A screenshot is attached..

[Dan (dan-redhat-bugs)]

You're going to need to use the gnome-bluetooth applet, not blueman. I have no idea what blueman is doing underneath, but it's not really a supported way to interact with NetworkManager. NM has the functionality that you're looking for, so if there's a problem with NM or nm-applet's handling of DUN, then we can try to fix this bug.

But otherwise, it's a blueman bug. The nm-applet GConf data is an implementation detail that's not public API, and that's what blueman is modifying. The NM gnome-bluetooth plugin is the supported way of configuring PAN and DUN connections.

See:

http://blogs.gnome.org/dcbw/2009/07/10/unwire-with-networkmanager/

If that procedure fails to work, then we can investigate the issue. Otherwise, if that procedure does work, then it's a Blueman bug.

[Zdravko (zdravko-redhat-bugs)]

The connection with gnome-bluetooth works (I will contact the developers of blueman). Having said that, gnome-bluetooth's functionality is a joke compared to blueman. It should be replaced by blueman.

[Bastien (bastien-redhat-bugs)]

(In reply to comment #6)
> The connection with gnome-bluetooth works (I will contact the developers of
> blueman). Having said that, gnome-bluetooth's functionality is a joke compared
> to blueman. It should be replaced by blueman.

Apart from the jibe at gnome-bluetooth, file bugs against gnome-bluetooth upstream (http://bugzilla.gnome.org) if you're missing specific functionality in gnome-bluetooth.

[Zdravko (zdravko-redhat-bugs)]

Bastien, my comment was not intended as a jibe...my appologies..

I do install many desktops for normal users.. and what they want is functionality and now..no matter what is providing it..The concept of filing a bug in order to receive this functionality is an alien one to them and is not likely to happen. After all, the main goal is to make linux/gnome popular, at least this is how I see it...

[Thomas Hood (jdthood)]

@Martin: Hi. What's the status of this problem in Ubuntu 12.04?

[Flittermice (flittermice)]

I can confirm his bug for 12.04 with NetworkManager 0.9.4 - the logs look similar to Martin's.

[Tried to establish a connection by this way because the internal UMTS card of the Samsung NC10 netbook is handled buggy by NM... so I ran from on problem into another. Frustrating :-/.
pon/poff in combination with rfcomm is working.]

Is there a way I can help as an ordinary user?

[Flittermice (flittermice)]

Thanks for confirming this bug!

This doesn't need to have anything to do with blueman I think.
The port gets ignored as well when I add /dev/rfcomm0 by "rfcomm bind ..." or /etc/bluetooth/rfcomm.conf.

Regards, Flitter

[Andrew (hidefromkgb)]

Seems that I`ve found a solution:
https://bbs.archlinux.org/viewtopic.php?id=147880

The root of the problem is wrong string comparison.

[eccerr0r (blc+launchpad)]

Confirmed that this works in Gentoo. I detailed the patch I made on Gentoo Forums (because as-is, the instructions are gentoo specific; but the hack is for networkmanager.)

http://forums.gentoo.org/viewtopic-t-926860-start-0-postdays-0-postorder-asc-highlight-.html

Basically I decide to remove the check alltogether, I'm not sure why it's specifically singling out bluetooth, it didn't seem right to simply invert the sense of the check. modem_added calls with const char *driver and if it's "bluetooth" it will always fail. If the sense is inverted, then anything except bluetooth will fail...

[Giulio Colavolpe (giulio-j)]

I have the same bug in ubuntu 14.04 with NetworkManager 0.9.8.8. Establishing the connection using pon/poff is working perfectly over the rfcomm device.

[Sergio Callegari (callegar)]

Dun with network manager has now been broken for a few years. We have passed from hard kernel crashes on attempts to use it to the current situation where the functionality is advertised and simply not working.

Now, I am on trusty and I do not know if my case is exactly the one mentioned in this bug.

In my case, it is modemmanager to simply ignore the rfcomm0 device.

In fact, if I set up the device and then query modem manager with mmcli, modemmanager says "no modem found". If I run modemmanager in debug mode, it says that it cannot find the parent device of rfcomm0, so it skips it.

Looks like a kernel bug. On LKML there are posts about the kernel failing to parent the rfcomm devices, causing regressions in modemmanager. Maybe the ubuntu kernel maintainers could take a look into it and backport relevant fixes to the ubuntu 3.14 kernel (if there are any).

But, even better, I really think that bluetooth DUN should be disabled altogether in networkmanager in ubuntu, until the kernel, modemmanager and networkmanager can support it properly. It has now been in a broken state for at least 3 (if not 4) ubuntu releases. If it is not working, at least do not tempt users to try it.

[Sergio Callegari (callegar)]

Yes, in fact it is a kernel bug.

Working with 3.15.6 from the ppa mainline, modemmanager can see the modem and you can connect.

So, if you really need bluetooth DUN, just move to a recent kernel.

Unfortunately it is not really enough, because after you have fixed the kernel bug, you can start having fun with the modemmanager/networkmanager bugs, and after the first connection you cannot reconnect anymore.

This is because after you ask network manager to drop the connection, for some funny reason the modemmanager/networkmanager/bluetooth stack does not drop the rfcomm connection. Conversely, it re-asks the phone for coupling permission and when this is granted it happily keeps the connection open, pinging the phone all the time to try to inquire about the signal quality level. Pure evil, since it certainly helps your phone battery to drain faster.

But do not fear, because with a couple of user friendly moves you can fix this too.

Get a console, become root, switch off the modemmanager

service modemmanager stop

then on again

service modemmanager start

and you are ready for another (just one!) bluetooth dun connection. Then, do not forget to get the console to reboot the modemmanager and be ready to start one more time.

Now, really... all this stuff is far too buggy for the average user. Please, hide it.