The bluez stack might be slightly updated. There are some (insecure) devices that will connect without any PIN but allow one optionally, sometimes the fixed values - GPS and serial devices often do this. I suspect that the stack changed to invoke the callback in all cases now and there is some way of saying "no pin" using it (e.g. a zero length string return, or NULL) though I haven't looked through the code.
So it might have worked because your device worked in a PINless mode. It would help if you could verify this. If it connects without any PIN being entered, it doesn't need one.
I will have to try it too - I think my GPS units will also work PINless.
@lotus49
As I noted, Pins can be up to 16 digits, and I've noted Apple uses 8 digits (The Nokia internet tablet uses 4, most phones pick 4 but accept more). If security was a concern a longer PIN should be used, so it is irrational to force PINs that are both random and short.
Perhaps adding more text to my dialog would help, e.g. "Bluetooth security requires having a random pincode which is provided below, however if your device requires a specific pincode, change the value it to the one your device needs, or if you desire more security, add more digits".
I've been dealing with Bluetooth devices for a while and if there were a few isolated "crappy devices" I would probably rethink how it should be done, but over 1/2 of the BT devices I have won't work with the current setup. I could file at least a half-dozen separate bugs right now requesting special casing, and the more I look the more special cases for both devices and PINs I find. Thirty bugs? I think I said thousands, but there would probably be hundreds just from the people on the various lists experiencing the problem.
My patch is only alpha quality (any Gtk+ wizard should be able to fix it to release quality in a very short time), but even as-is you can at least enter a fixed PIN and use your device as soon as it gets packaged and you can get the update. His approach? Daily builds just to get the latest growing list of special cases? Or devices that won't work for another few weeks or months?
@Ravi
The bluez stack might be slightly updated. There are some (insecure) devices that will connect without any PIN but allow one optionally, sometimes the fixed values - GPS and serial devices often do this. I suspect that the stack changed to invoke the callback in all cases now and there is some way of saying "no pin" using it (e.g. a zero length string return, or NULL) though I haven't looked through the code.
So it might have worked because your device worked in a PINless mode. It would help if you could verify this. If it connects without any PIN being entered, it doesn't need one.
I will have to try it too - I think my GPS units will also work PINless.
@lotus49
As I noted, Pins can be up to 16 digits, and I've noted Apple uses 8 digits (The Nokia internet tablet uses 4, most phones pick 4 but accept more). If security was a concern a longer PIN should be used, so it is irrational to force PINs that are both random and short.
Perhaps adding more text to my dialog would help, e.g. "Bluetooth security requires having a random pincode which is provided below, however if your device requires a specific pincode, change the value it to the one your device needs, or if you desire more security, add more digits".
I've been dealing with Bluetooth devices for a while and if there were a few isolated "crappy devices" I would probably rethink how it should be done, but over 1/2 of the BT devices I have won't work with the current setup. I could file at least a half-dozen separate bugs right now requesting special casing, and the more I look the more special cases for both devices and PINs I find. Thirty bugs? I think I said thousands, but there would probably be hundreds just from the people on the various lists experiencing the problem.
My patch is only alpha quality (any Gtk+ wizard should be able to fix it to release quality in a very short time), but even as-is you can at least enter a fixed PIN and use your device as soon as it gets packaged and you can get the update. His approach? Daily builds just to get the latest growing list of special cases? Or devices that won't work for another few weeks or months?