Skip to contentSkip to conversation

Device specific pins

Bluez-devel Dave Henriksen 3 participants 5 messages Jan 26, 2004 – Jan 27, 2004 1 message not in the archive Bluetooth drivers

lore
Share & tools
lore

Dave Henriksen

author
#0 lore raw

Hi,

Just wondering if there is any way to have pins that vary depending upon
what device you are connecting to. Currently, I just use
/etb/bluetooth/givepin to supply a pin, but this pin must be the same for every device that my Linux laptop connects to.

Thanks,

Dave Henriksen

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

maintainer
#1 lore raw

Hi Dave,

Quoted 4 lines

Just wondering if there is any way to have pins that vary depending upon
what device you are connecting to. Currently, I just use
/etb/bluetooth/givepin to supply a pin, but this pin must be the same for every device that my Linux laptop connects to.

this is a planned future for the new security manager which also includes one-time PIN codes.

For the current version you must do it by yourself in a pin-helper script. The BD_ADDR of the remote device is one of the parameters.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

A message that is not in the archive (sent off-list or not yet received): [email protected]

maintainer
#3 lore raw

Hi Dave,

Quoted 3 lines

Thanks for the reply. Are you saying that the BD_ADDR gets passed into
the pin helper script as a parameter ? Or is it an environment variable that I can reference within my pin_helper script ?

it is a parameter. For more details look at utils/hcid/security.c at line 254ff.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

#4 lore raw
In reply to Marcel Holtmann
Quoted 10 lines · Marcel Holtmann
Quoted 4 lines

Just wondering if there is any way to have pins that vary depending upon
what device you are connecting to. Currently, I just use
/etb/bluetooth/givepin to supply a pin, but this pin must be the same for every device that my Linux laptop connects to.

this is a planned future for the new security manager which also includes one-time PIN codes.

For the current version you must do it by yourself in a pin-helper script. The BD_ADDR of the remote device is one of the parameters.

Do you think it might be right to leave "low level" PIN management as it is now, via an executable helper? It is very much the same way as kernel "hotplug" works. So it can stay the same even if hcid eventually becomes a kernel thread.

The "real" PIN management, with the database, GUI prompt boxes etc. could be isolated from the BT stack, helper executable being the only interface.

E.g., a Gnome or KDE applet could listen on a unix domain socket. The helper, when invoked, would try to talk over this socket, and if the latter is not present or nobody listens on it, default to preexisting database. This way, both fancy GUI dialogues and unattended operation could be implemented rather easily.

Sorry if I say stupid or trivial things, I did not really try to learn how these things are currently done in Blues..

Eugene

maintainer
#5 lore raw

Hi Eugene,

Quoted 9 lines

Do you think it might be right to leave "low level" PIN management as it is now, via an executable helper? It is very much the same way as kernel "hotplug" works. So it can stay the same even if hcid eventually becomes a kernel thread.

The "real" PIN management, with the database, GUI prompt boxes etc. could be isolated from the BT stack, helper executable being the only interface.

Quoted 8 lines

E.g., a Gnome or KDE applet could listen on a unix domain socket. The helper, when invoked, would try to talk over this socket, and if the latter is not present or nobody listens on it, default to preexisting database. This way, both fancy GUI dialogues and unattended operation could be implemented rather easily.

Sorry if I say stupid or trivial things, I did not really try to learn how these things are currently done in Blues..

the answer for all this stuff will be D-BUS.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel