Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Apr 2007 15:42:04 -0700
From:      "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com>
To:        "=mato=" <gamato@pobox.sk>
Cc:        "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>
Subject:   Re: BT / hcsecd(8) -- changing PINs and dumping link keys -- bug?
Message-ID:  <bb4a86c70704141542x6cd1b030haaaaeda109b6372c@mail.gmail.com>
In-Reply-To: <462076EE.9040402@pobox.sk>
References:  <462076EE.9040402@pobox.sk>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello,

>  I think I've run into a problem (bug?) with hcsecd(8).
>
>  The documentation says that upon sending HUP signal to hcsecd it should
> reread its configuration and dump the link keys file.  So after I changed

yes, that is correct

> PINs for my BT devices on both of my laptops (in hcsecd.conf) I sent HUPs
> and reinitialised BT devices.  But reopening of connection failed
> (permission denied).  I rerun both hcsecd daemons in foreground and noticed
> that upon receiving HUP signal hcsecd does not use PIN as it does the very
> first time but use key which should have been dumped.  So then I killed the

i think you misunderstood the word "dump". in this context "dump"
means "save" the cached (in memory) link keys into the
/var/run/hcsecd.keys file. the man page states

"... To preserve link  keys between restarts the hcsecd daemon dumps
link keys for all entries in the /var/db/hcsecd.keys link keys file
..."

"dump" does not mean "forget" or "delete" here. the man page also says

"... For any given entry,  the link key takes precedence over the PIN code ..."

it seems like, in your case, link key existed and hcsecd(8) used it.
it does not matter that you have changed the pin code. pin code will
only be used if there is no link key.

> daemons, deleted their hcsecd.keys files and started up the daemons again.
> After that my new PINs got accepted and connection succeeded.

well, yes, there is no way to delete cached link key other than
deleting the key from the /var/db/hcsecd.keys and restarting
hcsecd(8). the assumption here is that pairing has to done only once.
if someone wants to re-pair the same devices then extra effort is
justified.

>  I don't think this is intended behaviour, but if it is I believe it should
> be clearly documented (the current man page suggests something else).

from what i can see, hcsecd(8) did the right thing here.

thanks,
max



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70704141542x6cd1b030haaaaeda109b6372c>