Bug 10446 - rfcomm is completely locking up the whole system when a bound Bluetooth virtual com port is lost
Summary: rfcomm is completely locking up the whole system when a bound Bluetooth virtu...
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 3
Hardware: i586 Linux
Priority: High critical
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-06 17:28 CEST by Robert Wood
Modified: 2015-03-31 16:02 CEST (History)
0 users

See Also:
Source RPM: bluez
CVE:
Status comment:


Attachments

Description Robert Wood 2013-06-06 17:28:16 CEST
Description of problem:

When using my onboard Bluetooth module to talk to an external Bluetooth module using rfcomm - specifically in this case this command:


rfcomm connect /dev/rfcomm0 00:12:F3:1C:53:CB 1

If the port is lost because, say, power to the external module is lost, the whole system completely locks up with the only way to recover is to power the system down by removing power to the computer. 

It is possible to connect to the same external Bluetooth module like this:

rfcomm connect /dev/rfcomm1 00:12:F3:1C:53:CB 1

So, the only difference is the com port is now called /dev/rfcomm1, not rfcomm0


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


How reproducible:


Happens every time

Steps to Reproduce:
1. Power up external module
2. Issue (as root)
rfcomm connect /dev/rfcomm0 00:12:F3:1C:53:CB 1
3. Remove power from external module
4. Issue (as root)
rfcomm connect /dev/rfcomm1 00:12:F3:1C:53:CB 1

Shortly afterwards the whole system completely locks up. The computer is rendered completely useless until power is removed. CTL ATL DEL or CTL ALT BACKSPACE does not help.

For what it's worth, this is on a Macbook Pro. If I can get my hands on another laptop with a Bluetooth module I will try and reproduce it on that. 




Reproducible: 

Steps to Reproduce:
Comment 1 Robert Wood 2013-06-07 10:05:19 CEST
I can confirm this does not happen with Open Suse 12.3 on a different laptop. Therefore it is clearly an issue with Mageia 3.

Priority: Normal => High

Comment 2 Robert Wood 2013-06-07 10:11:47 CEST
Another thing to add:

With SuUSE, when the connection is lost, it is possible to bind to the lost Bluetooth module when it comes available again by connecting as /dev/rfcomm0. This, to me, suggests that SuSE is happily releasing the connection, whereas Mageia is not letting go of it, so when it disappears, the system thinks it is still there and gets horribly confused. 

Is there anything I can do to help track this down? Bear in mind I am an experienced  embedded programmer and have some experience in programming computers so I have the ability to dig deep - if I know where to look.
Comment 3 Marja Van Waes 2015-03-31 16:02:49 CEST
Mageia 3 changed to end-of-life (EOL) status 4 months ago.
http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ 

Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD


Note You need to log in before you can comment on or make changes to this bug.