On Tue, 2016-11-29 at 14:45 +0200, Luiz Augusto von Dentz wrote: > Hi Barry, Don, > > On Tue, Nov 29, 2016 at 2:24 PM, Barry Byford <31baz66@xxxxxxxxx> > wrote: > > > > Hello Don, > > > > > > On 28 November 2016 at 20:55, Don Zickus <dzickus@xxxxxxxxxx> > > wrote: > > > > > > On Thu, Nov 24, 2016 at 03:07:21PM +0200, Luiz Augusto von Dentz > > > wrote: > > > > > > > > Hi Don, > > > > > > > > On Wed, Nov 23, 2016 at 11:40 PM, Don Zickus <dzickus@xxxxxxxxx > > > > m> wrote: > > > > > > > > > > Hi, > > > > > > > > > > I was trying to write some code to continuously scan the > > > > > bluetooth field > > > > > for bluetooth devices sending advertising packets (ie beacon- > > > > > mode). > > > > > > > > That is tricky, if you have anyone else trying to use the > > > > adapter in > > > > this situation it will probably be blocked, we may add support > > > > for > > > > setting intervals but that will probably be a best effort in > > > > case > > > > there is no connection or other usage of the adapter by the > > > > system. > > > > > > > > > > > > > > These devices would come and go so I wanted to avoid the > > > > > cache. > > > > > > > > Beacon are not normally not connectable, connections and > > > > continuous > > > > advertisement don't go well together so we will probably have > > > > to > > > > reduce the intervals in order to maintain any traffic on the > > > > connections. > > > > > > > > > Hi Luiz, > > > > > > Thanks for the response. I am wondering if I explained it > > > wrong. I wasn't > > > looking to do advertisements but instead scan for > > > advertisements. I also > > > don't plan to connect to any of the advertising device, just read > > > the > > > advertised data. > > > > > > > > > > > > > > > > > > > > > > > > I noticed the D-Bus interface doesn't quite allow me to do > > > > > this (as it > > > > > caches the devices and I can't monitor the RSSI field). But > > > > > I think the > > > > > bluetooth management interface does. Is that the correct > > > > > approach? > > > > > > > > Yep you could in theory use the MGMT interface and manually add > > > > you > > > > beacon management on top, but I guess you don't want > > > > applications to > > > > do that since it would require root permissions to connect to > > > > the > > > > management socket, so making bluetoothd, via kernel?, to adjust > > > > the > > > > intervals is probably a better idea in the long run. We would > > > > probably > > > > have to maintain the biggest advertising window possible, and > > > > the > > > > consider: > > > > > > > > 1. Is it connectable/there any advertising instance that is > > > > connectable? If yes, the it has to adjust the window to allow > > > > them > > > > (perhaps using the default connection parameters). > > > > 2. In case of a connection is made the controller may not be > > > > able to > > > > advertise anymore, and in case it can still advertise we need > > > > to make > > > > sure it doesn't interrupt the connection (this is not very > > > > clear if > > > > the controller is suppose to manage this somehow). > > > > 3. Similar to the connection situation we may have application > > > > scanning, again there might be problems if the controller > > > > cannot scan > > > > while advertising we would probably have to stop advertising. > > > > > > Hmm, as I said above, I am wondering if I explained it wrong. > > > > > > I was wondering how much was already done because in reality, I > > > was just > > > going to mimic what android does on the phones with apple > > > ibeacons except my > > > machines stay put and the ibeacons travel. > > > > > > Currently I was using 'hcitool lescan --duplicates' and 'hcidump' > > > and trying > > > to script that. But wanted to be smarter. :-) > > > > I am planning on doing a similar application as you describe and > > understood that you should be able to do much of what you want with > > the dbus API. > > Have you taken a look at adapter/StartDiscovery? > > It is documented at > > git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/adapter- > > api.txt#n12 > > You would then monitor the PropertiesChanged signal on the system > > dbus. > > > > SetDiscoveryFilter might also be necessary/helpful. > > Yep, the SetDiscoveryFilter might be the way to go, the only missing > part that it doesn't do right now is to disable duplicate filtering, > but we might need some flag with a big warning that this will spam > the > bus like crazy or perhaps it can only be used along RSSI filtering, > which is to prevent people to use advertisement/scanning APIs as a > transport over D-Bus. > > We could offer a file descriptor based solution for transport > emulation using scanning/advertising to prevent spamming D-Bus but > that has to play nicely with other application, either that or we > only > allow this over MGMT interface which is what we suggest in case there > is no other use for Bluetooth in the system. > > And btw, I wouldn't account Android and other mobile OSes allowing > such raw access for much longer, it takes way too much power and can > probably block any other Bluetooth peripheral to work, so it is > probably only good to write packet sniffer and other debug tools on > top of the system but it really offer nothing to the regular user. I have had to resort to using the HCI interface to work with scanning and advertising beacon packets. I had mentioned in an earlier thread the issue with duplicates. Not only do you end up with a lot of spam on the dbus interface you end up with an ever increasing number of bluetooth devices. The Bluetooth mesh uses this transport, so I really would like to see a nice interface to support rx/tx of these packets. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
