Apple Magic Mouse

[Dirk Engling]

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