Bug#384680: [Pkg-bluetooth-maintainers] Bug#384680: bluez-utils: cannot enable authentication by a PIN

[Géraud Meyer]

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