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 PROTECTED]> 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): http://www.bb-shopping.com/Pama-Bluetooth-Car-Kits-and-Headset-Pairing- Codes.html -- bluetooth-wizard unable to pair to fixed pin devices https://bugs.launchpad.net/bugs/284994 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
