Date: Tue, 7 Mar 2006 22:56:36 +0000 (GMT) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: apple bluetooth keyboard Message-ID: <1141772196.551930.3681.nullmailer@galant.ukfsn.org> In-Reply-To: <440DF38F.7020707@savvis.net> References: <440DCFF0.6090809@savvis.net> <1141761895.037384.5308.nullmailer@galant.ukfsn.org> <440DF38F.7020707@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 Mar 2006, Maksim Yevmenkin wrote:
> > How do bluez/linux manage this? I have seen mention of a 'bluepin'
> > application but have no idea how it works..
>
> well, i do not really know about {gnome|kde}bluetooth. linux used to have (and
> maybe still is) hcid daemon that would answer pin code requests. hcid would
> call external process (i.e. bluepin) and use simple stdin/stdout redirection
> to get pin from it. bluepin was/is essentially a python script that displays X
> dialog window with pin input box and some buttons and waits for user to enter
> a pin code. bluepin prints pin code on stdout, hcid gets it and sends pin code
> reply.
the problem I see with this, is that hcid (hcsecd) is running as a system
daemon - if it wants to fire off a program to fetch a pin then it needs to
know which user, and where to find them. This needs to be able to change
as users log in and out I guess, so it should work the other way around..
In the hcsecd.conf file, you extend the 'pin' statement to specify that
there is a) no pin, b) fixed pin, c) user pin.
for user pin then, there would be a control pipe that hcsecd would
shout PIN_CODE_REQUEST down
If user 'blue' wants to enable pin code requests, he can run the pin
program (maybe from .login) and it would open the control socket (which
can have ownership and permissions specified?) and sleep, listening for
pin requests, and wake up with a window when something happens.
If user 'red' does not care about bluetooth, she just does nothing and
will never be bothered.
if the hcsecd program gets no response in a certain time (maybe nobody is
listening..), then it replies with PIN_CODE_REQUEST_NEGATIVE_REPLY.
Hm, but this does nothing to address the issue that when pairing outwards,
there is no way to indicate that the user should enter the pin on the
other device, or is that the same thing?
Also, I am not sure how it would work with multiple users..
I haven't looked at this part of it in detail yet (I just borrowed hcsecd
for that :)
iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1141772196.551930.3681.nullmailer>