GNOME Bugzilla – Bug 646253
The 6-digit confirmation code is corrupted if leading zeroes occur.
Last modified: 2011-05-25 15:39:52 UTC
If bluetooth tries to connect via a 6-digit code which has leading zeroes, this code is not properly displayed in the LINUX applet. It seems - but I cannot prove it without many attempts - that the code is also trimmed to five (or maybe less) digits internally so that the connection cannot be established.
(In reply to comment #0) > If bluetooth tries to connect via a 6-digit code which has leading zeroes, > this code is not properly displayed in the LINUX applet. Screenshot? > It seems - but I cannot prove it without many attempts - that the code is also > trimmed to five (or maybe less) digits internally so that the connection cannot > be established. That's very highly unlikely. Please tell us exact reproducer steps for this, it's impossible to know what the problem is when the problem definition is so vague.
> (In reply to comment #0) > > If bluetooth tries to connect via a 6-digit code which has leading zeroes, > > this code is not properly displayed in the LINUX applet. > > Screenshot? Sorry, I can not reproduce that. I have no Bluetooth unit at hand now. The six-digit code is generated to neogiate/confirm the connection manually. It ist display as well on the smartphone (in my case) and in the apllet popup window 8where the leading zero got lost). I tried it some times, but only got 6 digit after the first occurence, so I can't deliver a screen shot. I must be easily found in the source code. > > It seems - but I cannot prove it without many attempts - that the code is > > also trimmed to five (or maybe less) digits internally so that the > > connection cannot be established. > That's very highly unlikely. Funny you know that but don't know where to look for the problem. In my 30+ years of software development this sentence has mostly been a good proof that "highly unlikely" is the case which occurs (ever heard of Murphy?). > Please tell us exact reproducer steps for this, it's impossible to know what > the problem is when the problem definition is so vague. It contained any information needed. Look for the module(s) which displays and handles the connection confirmation code.
What phone is this? And did you initiate the pairing from the phone, or from the computer?
It's a Samsung Galaxy S I9000 (Android), but this is not relevant. The 5 digit code is presented by Ubuntu as written in my first sentence. So it should be clear that the session started from the Linux side, or not?
(In reply to comment #4) > It's a Samsung Galaxy S I9000 (Android), but this is not relevant. Why do you think it wouldn't be? > The 5 digit code is presented by Ubuntu as written in my first sentence. > So it should be clear that the session started from the Linux side, or not? I wish you would stop trying to second guess me here. It's a documentation bug in bluez, which explains why gnome-bluetooth wasn't presenting the Secure Simple Pairing keys properly. Fixed in gnome-3-0 and master for GNOME 3.2.