blueman fails to release rfcomm0 when "disconnect device" is used with SP or DUN profile connections

Bug #495696 reported by Darron Black
44
This bug affects 8 people
Affects Status Importance Assigned to Milestone
bluez (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

In the Blueman Device Manager, the bottom-most "Disconnect" context menu option doesn't work well (at least with SP and DUN profile connections). It leaves the /dev/rfcommX port open (by bluetoothd). However, the profile-specific disconnect option at the top of the menu works properly.

Blueman should keep track of open connections and properly close any associated ports.

Steps to reproduce:

1) set up a SPP or DUN connection.
2) right click on the device in blueman device manager and click the bottom-most menu item, Disconnect device.
3) try to reconnect as SPP or DUN. Result: "Connection failed: port already in use"

However, disconnecting the SPP or DUN connection using "Disconnect Serial port rfcomm0", etc works (releases rfcomm0 and a reconnect therefore works)

This occurs on my laptop using a Dell Wireless 360 bluetooth module (internal USB), and also on my desktop using an external USB bluetooth module.

Laptop lsusb line:
Bus 006 Device 002: ID 413c:8140 Dell Computer Corp. Wireless 360 Bluetooth
Desktop lsusb line:
Bus 007 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

I'm assuming it's not device specific.

Revision history for this message
Valmantas Palikša (walmis) wrote :

This should be fixed in versions >= 1.20

Changed in blueman:
status: New → Fix Released
Revision history for this message
Darron Black (darron) wrote :

Sorry, I should have been more specific... This is with the 1.21 in the PPA on both machines.

The laptop is running Karmic, and I am using a slightly custom build of modem-manager (just dropped a hard-coded init string that was failing on my phone)

The desktop is Jaunty, running stock everything except the PPA 1.21 stuff.

Darron Black (darron)
Changed in blueman:
status: Fix Released → In Progress
Revision history for this message
Darron Black (darron) wrote :

The connection is also left open when the bluetooth connection is externally severed (by walking away with the phone). This also causes the "port already in use" problem and seems to require a bluetoothd restart to clear it.

Revision history for this message
Michael Scherer (misc-zarb) wrote :

I see also the problem on fedora 12 with 1.21. It is fixed in bzr trunk.

Changed in bluez (Ubuntu):
status: New → Invalid
Revision history for this message
Giulio Malventi (giulio-people) wrote :

Still valid in Lucid. Upon disconnection I have to delete the Bluetooth device (phone), then pair and configure it again.

Revision history for this message
Nandox7 (nandox7) wrote :

I'm having the same annoying problem in Maverick with version 1.21.

Revision history for this message
AndreK (andre-k) wrote :

same problem on Ubuntu 11.10, blueman 1.22

Revision history for this message
Gaz Davidson (garethdavidson) wrote :

Same problem in Ubuntu 13.10, blueman 1.23 when connecting to a GPS sharing app on my phone over rfcomm. If the connection is lost at some point then I have to restart bluetoothd before I can connect again. I've tried using `rfcomm release rfcomm0` which deletes the serial device in /dev/ but the blueman UI still thinks something is in use.

Revision history for this message
Kristoffer (kristoffer-odmark) wrote :

I have the same problem

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.