From owner-freebsd-bluetooth@FreeBSD.ORG Tue Mar 7 23:39:58 2006 Return-Path: X-Original-To: freebsd-bluetooth@FreeBSD.org Delivered-To: freebsd-bluetooth@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15BBE16A426 for ; Tue, 7 Mar 2006 23:39:58 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id F30C543D77 for ; Tue, 7 Mar 2006 23:39:00 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id k27NcoM31951; Tue, 7 Mar 2006 18:38:50 -0500 Message-ID: <440E1988.10202@savvis.net> Date: Tue, 07 Mar 2006 15:38:48 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iain Hibbert References: <440DCFF0.6090809@savvis.net> <1141761895.037384.5308.nullmailer@galant.ukfsn.org> <440DF38F.7020707@savvis.net> <1141772196.551930.3681.nullmailer@galant.ukfsn.org> In-Reply-To: <1141772196.551930.3681.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: apple bluetooth keyboard X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2006 23:39:58 -0000 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