Date: Tue, 07 Mar 2006 15:38:48 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Iain Hibbert <plunky@rya-online.net> Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: apple bluetooth keyboard Message-ID: <440E1988.10202@savvis.net> In-Reply-To: <1141772196.551930.3681.nullmailer@galant.ukfsn.org> References: <440DCFF0.6090809@savvis.net> <1141761895.037384.5308.nullmailer@galant.ukfsn.org> <440DF38F.7020707@savvis.net> <1141772196.551930.3681.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Iain Hibbert wrote:
> 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..
well, this is the completely different can of worms. both hcid (in
linux) and hcsecd(8) (in freebsd), to some extend, assume that there is
only one user.
bluepin is just x11 application. it will display windows on whatever
DISPLAY is set at the moment.
> 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.
may be. but what if user 'red' also wants to run pin program. now
hcsecd(8) will have two control pipes. which pipe should it use? should
it use both? are you suggesting that hcsecd(8) should be configured to
redirect pin requests from specific devices to specific pipe?
btw, what usage scenario do you have in mind that requires multiple
users to access the same (or multiple) bluetooth devices on the same host?
> if the hcsecd program gets no response in a certain time (maybe nobody is
> listening..), then it replies with PIN_CODE_REQUEST_NEGATIVE_REPLY.
yes
> 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?
yes, its pretty much the same. both devices will get "pin code request"
event at the same (more or less) time. for example, in windows xp you
will get a dialog with few options: use pin code from documentation,
generate pin code automatically, etc. once you enter pin, you go back to
other device and enter the same pin again.
so, i think, the something like bluepin will work just fine. the only
issue here is that user required to run gui.
> 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 :)
another option is to program link keys into the device itself. this,
however, has another issue - if your device is stolen then link keys are
compromised.
thanks,
max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?440E1988.10202>