Date: Wed, 30 Dec 2009 21:15:41 +0000 (GMT) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: Keyboard - how? Message-ID: <1262207741.839354.13401.nullmailer@galant.ukfsn.org> In-Reply-To: <bb4a86c70912301157q60978c0ap73bb37f7b5b3c685@mail.gmail.com> References: <20091227.111711.287595822663154592.imp@bsdimp.com> <1261940371.044739.879.nullmailer@galant.ukfsn.org> <bb4a86c70912291429j26da18aflc04d255b74da0954@mail.gmail.com> <20091229.162535.190753344529111277.imp@bsdimp.com> <1262169549.695652.1010.nullmailer@galant.ukfsn.org> <bb4a86c70912301157q60978c0ap73bb37f7b5b3c685@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Dec 2009, Maksim Yevmenkin wrote: > ok, i guess, i can see the value of having dynamic pin/key > configuration, i.e. replace static /etc/bluetooht/hcsecd.conf with one > built dynamically based on client's request. i could even see how > generated link keys are stored in user's home directory together with > user's pins etc. I would like some of that but I think its a bit complex to handle properly. I wanted to associate user credentials with sockets, so that for example a user could have their own PIN/key daemon running and keep their own keys for their own devices private (also, piggybacking onto another users baseband connection would be prevented) but, I never did really work out how and where incoming connections would be dealt with. One associated thing I thought of which I forgot to mention at the time, do you think it would be useful to extend the bluetooth(3) host lookup routines (eg bt_gethostbyname()) to search in a user file (eg ~/.bluetooth/hosts ?) in addition to the system /etc/bluetooth/hosts so that users did not need root privileges to add an alias for their favourite device? That might be a fairly simple addition.. > having said all that, i do not see why executing external pin program > from hcsecd(8) is a bad idea. If the daemon runs an external program, the daemon must run as root or the logged in user otherwise it won't be able to write anything to the screen, and I think its a bit scary to have root daemons running X programs (ok I'm a coward :). Also, I'm not sure about this, but root might not actually have permission to write on the display which could be on another machine entirely. Then, if a machine has several displays, what do you set DISPLAY env variable to, and when? Its much easier I think to just have the user who wants to do PIN entering just run her own daemon.. > > If you have OSX there is a way to capture bluetooth packets and you could > > investigate more there. I think something like hold down 'option' key > > while opening the bluetooth menu and you should see it listed. Not sure if > > it shows a live stream but hcidump can interpret the packet capture files. > > oh, neat-o! i did not know about this! i will try this today. thanks! btw if you don't find the magic key combo, the program should be in /Developer/Applications/Utilities/Bluetooth iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1262207741.839354.13401.nullmailer>