From owner-freebsd-bluetooth@FreeBSD.ORG Tue Mar 7 22:57:22 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 B3C5F16A420 for ; Tue, 7 Mar 2006 22:57:22 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 27FCC43D48 for ; Tue, 7 Mar 2006 22:57:21 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: (qmail 62168 messnum 5265620 invoked from network[83.70.176.191/unknown]); 7 Mar 2006 22:57:19 -0000 Received: from unknown (HELO rya-online.net) (83.70.176.191) by mail04.svc.cra.dublin.eircom.net (qp 62168) with SMTP; 7 Mar 2006 22:57:19 -0000 Received: (nullmailer pid 14389 invoked by uid 1000); Tue, 07 Mar 2006 22:56:36 -0000 Date: Tue, 7 Mar 2006 22:56:36 +0000 (GMT) To: Maksim Yevmenkin In-Reply-To: <440DF38F.7020707@savvis.net> References: <440DCFF0.6090809@savvis.net> <1141761895.037384.5308.nullmailer@galant.ukfsn.org> <440DF38F.7020707@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1141772196.551930.3681.nullmailer@galant.ukfsn.org> From: Iain Hibbert 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 22:57:22 -0000 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