Date: Tue, 15 Sep 2015 05:59:39 +0200 From: Dirk Engling <erdgeist@erdgeist.org> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: Apple Magic Mouse Message-ID: <55F797AB.5000501@erdgeist.org> In-Reply-To: <CAFPOs6ozJashriYAs%2BMHBz%2BYrC4ZTELJ31gkuTObP7Y__KaVdQ@mail.gmail.com> References: <1437909200.57929.3.camel@yandex.com> <alpine.NEB.2.11.1508092034290.5638@galant.ogmig.net> <55F4362A.4050203@erdgeist.org> <CAFPOs6p%2BEZDctPodY6DBbnhfZQFz%2Bo0uKSRvvqQBcM1QL3ACXw@mail.gmail.com> <55F60ED8.8080203@erdgeist.org> <CAFPOs6pYoPGNfWheDyG2vNu46oLyN%2BSgh2rPYrew=iYmeFFuZA@mail.gmail.com> <55F72204.5060007@erdgeist.org> <CAFPOs6ozJashriYAs%2BMHBz%2BYrC4ZTELJ31gkuTObP7Y__KaVdQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14.09.15 22:22, Maksim Yevmenkin wrote: > again, i'm sorry you had so much trouble. documentation could be > better no question about it. the whole pin idea is really tricky. i've > provided very basic hcsecd to respond to PIN/key request. the tricky > part is that PIN has to entered. this required some sort of user > notification and input. in general one can not assume that hcsecd will > run in graphical environment, and, its rather tricky to get user's > attention and input from a background daemon process. and then there > is another class of devices (such as bluetooth keyboards), that do not > have any notification at all, i.e. its tricky for user to know when to > type PIN. > > so, yeah, i admit, hcsecd is kinda head-in-a-sand approach, but it can > be made to work. Maybe my email came across much harsher than it was meant. Please do not excuse yourself. After understanding how the fragments work together I think it is nicely engineered. The important take-away should be that I actually WANT to write a script that automatizes the bluetooth setup for the novice user. For reference: I know shell pretty well and am the author sysutils/ezjail, a convenient front end for jail environments. Maybe this should move to another thread, but as I see it, the tool should provide at least an interactive command bluetooth-config pair-new-device [-n node] [-a address|host] * check for presence of ng_ubt.ko, or [offer to] load it * check for all the rcvars enabled for services bluetooth, hcsecd and bthidd or [offer to] enable them using sysrc * If no node is passed as param, use "hccontrol read_node_list" to get the list of hci nodes and if multiple nodes exist, let the user chose * Ask the user to put device in pair mode * If no host is passed as param, use "hccontrol -n NODE inquiry" to scan for nearby devices. Use "bthidcontrol -a HOST query" to get all info and present the most useful entries, i.e. name, type, vendor, is-already-known, etc. Let the user select one host. * If no entry is found in /etc/bluetooth/hosts, ask the user for a human readable name and create an entry there. * If "bthidcontrol -a HOST known" does not indicate the node is known, append the "bthidcontrol -a HOST query" to /etc/bluetooth/bthidd.conf * Ask the user to put device in pair mode again (probably pairing time out) * Ask user if device presents a PIN. If yes, let user enter the PIN and dump an entry in /etc/bluetooth/hcsecd.conf, then restart hcsecd * If not, generate a PIN and (re)write entry in hcsecd.conf, present it to the user, restart hcsecd and ask the user to put device in pairing mode again * restart bthidd * If device is a keyboard, offer a text entry test field and if it does not succeed, leave some clues for debugging (i.e. if the node responds to pings, maybe switch keyboard on/off, etc) * Same if device is a mouse, i.e. hexdump /dev/sysmouse. * If device offers DUN profiles, ask the user if an entry in /etc/ppp/ppp.conf should be created * If OPUSH or SPP is offered, refer to the respective man pages to give some clues how to continue For most users, wrapping this up in a script would make the difference between setting up their mouse or giving up in the process. > just for the sake of it, i re-checked bluetooth hid spec. the sdp > record exchange seems to only happening at bluetooth hid service setup > time. both device and host initiated reconnects do not have sdp > exchange. bthidcontrol is supposed to be used during "bluetooth hid > service setup time". In my tests I could retrieve device identification service records at any time. Best, erdgeist
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55F797AB.5000501>