Filippo Giunchedi wrote: > Hello, > > >> Oyez, oyez! >> I have finally understood what was happening: the link_key_request >> serves as an authentication mechanism thanks to the link key storage in >> /var/lib/bluetooth/<bdaddr> (I noticed this folder's "persistence" by >> chance). Removing the folders under /var/lib/bluetooth/ is sufficient to >> make a new connection fail (if the PINs are set suitably). >> The working of the authentication certainly is not a mistake, but it is >> misleading. Since the documentation is not yet making the bluez packages >> bloated, do you think you could add this information piece in it so that >> another unskilled non-specialist user does not loose his time? >> Respectfully >> > > do you agree that this is documented in README.Debian in recent versions of > bluez-utils (3.7?) if so can be this bug be closed? > > thanks, > filippo > -- > Filippo Giunchedi - http://esaurito.net > PGP key: 0x6B79D401 > random quote follows: > > How do you feel about women's rights? I like either side of them. > -- Groucho Marx
Hello, In fact no, I do not agree. What has been added (and probably what you were referring to) is a `Note to the tech-savvy' (savvy with 2 v's). It is indeed very useful to be aware of this to setup a first PAN connection since the /etc/bluetooth/passkeys/ infrastructure has been removed. I could setup a connection by adding echo >> <remote_bdaddr> <PIN> > /var/lib/bluetooth/<local_bdaddr>/pincodes the PIN code for the outgoing connection in the mentioned file. The security option in hcid.conf have to be auto. I suggest that you moreover add to README.Debian or to hcid(8) exactly what should be put in /var/lib/bluetooth/<local_bdaddr>/pincodes (<remote_bdaddr><SPACE_or_?><pin><NEWLINE?>). Actually what I found surprising is that if you later stop bluetooth, modify (only) one of the PIN codes (in /var/lib/bluetooth/<local_bdaddr>/pincodes or previously in /etc/bluetooth/passkeys/ or probably also in the passkey agent), and restart bluetooth, then the connection is still successful. I presume that once 2 devices have the same key stored in /var/lib/bluetooth/<local_bdaddr>/linkkeys and one has been authenticated, no PIN code is ever requested again because the content of this file is reused instead. Removing the relevant information in linkkeys triggers another PIN request as far as pand is concerned. I think that THIS information should be written somewhere. I would say that it is not specific to pand since hcid seems to handle the authentication, but I do not know much about bluez. Finally I find `Note to the tech-savvy' to be inappropriate, too repulsive a title, since for a PAN connection I see the proposed solution as almost necessary: using a passkey agent is not required and also to my knowledge (I do not know how to use one even though I looked for information) not as easy as modifying the file pincodes. If there were a system wide dbus passkey agent available for use this would be different and one could probably avoid toying with /var/lib/bluetooth/. This last remark shows that PANs is only a small part of th bluetooth system that is not as important as LANs. Another hint about that is the place of the pand (bluetooth) service in the boot scripts: it is started relatively late during the start, so that ssh for instance is started before pand. Could a bluetooth network interface be considered as an interface that could possibly be used as a permanent main interface? Thanks Géraud -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]