The patch works. I don't know if anyone wants to get it into an Ubuntu update.
On Wed, Nov 12, 2008 at 12:58 PM, matli <email address hidden> wrote:
> No, I don't think it's a kernel problem. Just to be sure I just tested
> with my old Hardy kernel (2.6.24-21), and as expected, the bug stil
> occured (got a randomly selected PIN to enter on my keyboardless GPS).
It is not in the kernel. There may be a way of plugging the bluetooth
agent within the wizard, but it uses g_random_int (around line 550) to
select a random pincode and only overrides it for certain devices with
an inline hardcoded blacklist. The bluetooth system has a callback to
get the pin (expecting a dbus message with the desired pincode in
response), and that is where the fix must occur - modifying the
pincode BEFORE the dbus message is sent. That is where my patch
intercepts the random number and lets it be changed. If no pairing is
required I don't think the callback will occur at all. And this
callback setup is in the bluez stack which should not have changed
significantly between hardy and intrepid.
I'm using a 64 bit setup, but could put a binary (and a 32 bit
version) up somewhere of my patched version for those who can't or
don't want to compile.
> And as you can see from the discussion and gnome bugzilla, the buggy
> behaviour is deliberate and is considered a feature by the developer...
Or as he says, devices which aren't easily identifiable or
classifiable as having a fixed pincode are "crappy" so he doesn't want
to bother with them even if they might be large in number and things
the users will often want to pair like
headsets/handsfree/speakerphones and GPS units. Nor are there legal
or technical reasons preventing them from working using a
user-modifiable pincode (which every other implementation I have seen
has in one way or another. And as far as I know in the bluetooth
spec, nothing specifies how the PINs are arrived at. Worse, for
security longer PINs should be used and his default is fixed to four
digits (The Mac uses 8 when it randomly selects a PIN) and I can't
even do that.
I deal in embedded with things in ROM chips that actually break
longstanding specs, and I can't just say "I won't support X". This is
much less serious.
> (Btw, note that the bug has been closed on gnome bugzilla since the
> author of the bug didn't have the exact headset mentioned in the title.)
Perhaps I should go through all my devices and submit individual bug
reports for those which wouldn't have paired without my patch as he
apparently wanted me to.
More variations (alas without the BT addr ranges):
The patch works. I don't know if anyone wants to get it into an Ubuntu update.
On Wed, Nov 12, 2008 at 12:58 PM, matli <email address hidden> wrote:
> No, I don't think it's a kernel problem. Just to be sure I just tested
> with my old Hardy kernel (2.6.24-21), and as expected, the bug stil
> occured (got a randomly selected PIN to enter on my keyboardless GPS).
It is not in the kernel. There may be a way of plugging the bluetooth
agent within the wizard, but it uses g_random_int (around line 550) to
select a random pincode and only overrides it for certain devices with
an inline hardcoded blacklist. The bluetooth system has a callback to
get the pin (expecting a dbus message with the desired pincode in
response), and that is where the fix must occur - modifying the
pincode BEFORE the dbus message is sent. That is where my patch
intercepts the random number and lets it be changed. If no pairing is
required I don't think the callback will occur at all. And this
callback setup is in the bluez stack which should not have changed
significantly between hardy and intrepid.
I'm using a 64 bit setup, but could put a binary (and a 32 bit
version) up somewhere of my patched version for those who can't or
don't want to compile.
> And as you can see from the discussion and gnome bugzilla, the buggy
> behaviour is deliberate and is considered a feature by the developer...
Or as he says, devices which aren't easily identifiable or handsfree/ speakerphones and GPS units. Nor are there legal
classifiable as having a fixed pincode are "crappy" so he doesn't want
to bother with them even if they might be large in number and things
the users will often want to pair like
headsets/
or technical reasons preventing them from working using a
user-modifiable pincode (which every other implementation I have seen
has in one way or another. And as far as I know in the bluetooth
spec, nothing specifies how the PINs are arrived at. Worse, for
security longer PINs should be used and his default is fixed to four
digits (The Mac uses 8 when it randomly selects a PIN) and I can't
even do that.
I deal in embedded with things in ROM chips that actually break
longstanding specs, and I can't just say "I won't support X". This is
much less serious.
> (Btw, note that the bug has been closed on gnome bugzilla since the
> author of the bug didn't have the exact headset mentioned in the title.)
Perhaps I should go through all my devices and submit individual bug
reports for those which wouldn't have paired without my patch as he
apparently wanted me to.
More variations (alas without the BT addr ranges):
http:// www.bb- shopping. com/Pama- Bluetooth- Car-Kits- and-Headset- Pairing- Codes.html