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. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/583728 Title: NetworkManager ignores the rfcomm port when it gets registered in blueman Status in “network-manager” package in Ubuntu: Confirmed Status in “network-manager” package in Arch Linux: New Status in “modemmanager” package in Fedora: Unknown Bug description: 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". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/583728/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
