Date: Sun, 9 Jul 2017 09:54:29 -0700 From: maksim yevmenkin <maksim.yevmenkin@gmail.com> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: How to listen quietly for other Bluetooth devices? Message-ID: <9DDD63D7-52A2-4995-98E4-D60CEE5EE106@gmail.com> In-Reply-To: <ed4d6da5-9b62-66ae-2b6c-e224167c74dc@aldan.algebra.com> References: <085c77b2-9f40-5a1f-0b49-86a24e561fce@aldan.algebra.com> <CAFPOs6o_1ExGjcOZWdRTuZXHCvPnXVjCn562u6ApXPVuyhadew@mail.gmail.com> <B643CF86-6270-4BB7-9E13-D76ECFC63AD3@aldan.algebra.com> <CAFPOs6pr2sxr=egtUKD-3AkGQd5P0X1V7jsXhgwTP7qQSjTfEA@mail.gmail.com> <ed4d6da5-9b62-66ae-2b6c-e224167c74dc@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> i'm not aware (not have i ever seen) of-the-shelf bluetooth dongle that i= s capable of going into "promiscuous" mode. > Thank you, Max, for sharing your expertise... So, you are saying, the deci= sion on whether to notify the host of a particular bit of traffic the dongle= "hears" is controlled by the hard-coded logic on the dongle itself -- and c= an not be reprogrammed by the host? >=20 Host normally does not get to see past HCI (host controller interface). HCI d= efines set of commands, responses and events that can be sent and received. T= his set varies slightly from one Bluetooth specification version to another,= however bulk of commands is mostly the same.=20 The way host accesses HCI is via transport. Serial, USB etc. HCI transport s= pecifies how HCI datagrams are transferred over particular low level transpo= rt interface. For example, with USB, HCI events are transferred over USB int= errupt endpoint, ACL data are transferred as USB bulk transfers and SCO data= as isochronous transfers.=20 So, basically, host gets to access particular HCI transport (USB in your cas= e) and gets to see HCI datagrams that are received over the transport. Host d= oes not get direct access to baseband (radio). All access is indirect via HC= I commands.=20 Of course HCI has provision for so called "vendor" commands. Those are speci= fic to each vendor and generally not documented. It is possible that some ve= ndor may have implemented commands that allow low level access to baseband, h= owever, I never saw anything like that.=20 > Sad... Maybe, I will have to "broadcast" something in order to register re= sponses. >=20 One possible way to do something like this is to instruct local Bluetooth de= vices to perform "periodic inquiry". This way local device will periodically= perform inquiry scan and save results into "neighbor cache". Dumping "neigh= bor cache" periodically will give an approximate list of "discoverable devic= es" in RF proximity. Of course timing is not going to be perfect (can't tell exactly when remote d= evice was seen) but it's something. Also, remote device may choose to not a= nswer inquiry scan (not discoverable). In this case there is still and optio= n to "page" remote device (try to open baseband connection) using remote dev= ice bd_addr Thanks !=20 Max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9DDD63D7-52A2-4995-98E4-D60CEE5EE106>