From owner-freebsd-bluetooth@freebsd.org Tue Sep 15 03:59:44 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6361A0406C for ; Tue, 15 Sep 2015 03:59:44 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.115.13.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBDAF137F for ; Tue, 15 Sep 2015 03:59:43 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 26720 invoked from network); 15 Sep 2015 03:59:41 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 15 Sep 2015 03:59:41 -0000 Subject: Re: Apple Magic Mouse To: Maksim Yevmenkin References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> <55F72204.5060007@erdgeist.org> Cc: "freebsd-bluetooth@freebsd.org" From: Dirk Engling X-Enigmail-Draft-Status: N1110 Message-ID: <55F797AB.5000501@erdgeist.org> Date: Tue, 15 Sep 2015 05:59:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 03:59:44 -0000 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