On Thu, 2016-12-08 at 12:29 +0000, Northfield Stuart wrote: > > > > On 8 Dec 2016, at 06:18, Marcel Holtmann <marcel@xxxxxxxxxxxx> > > wrote: > > > > Hi Don, > > > > > > > > > > > > > > > > > > > Recent discussions on the bluez mailing list revealed it was > > > > > not easy > > > > > to disable duplicate device filtering from the d-bus > > > > > interface. > > > > > > > > > > As a result, if I wanted to monitor LE devices entering and > > > > > leaving the > > > > > adapters range (using RSSI data), it was difficult. > > > > > > > > > > This patchset is a dirty hack to make this work. The first > > > > > patch enables > > > > > it on the kernel side, while the other two patches enable it > > > > > from the bluez > > > > > side. > > > > > > > > > > I understand there are concerns about flooding the d-bus > > > > > interface when > > > > > enabling this. I tried to write a throttling mechanism using > > > > > the mainloop > > > > > as my timer, but soon realized you can only have 1 device > > > > > RSSI event > > > > > per loop, so that wasn't going to work. Open to suggestions > > > > > if still a > > > > > concern. > > > > > > > > > > Posted as an RFC just to generate discussion. I expect I > > > > > missed a lot of > > > > > little details here, but wanted to post my proof of concept > > > > > to see if this > > > > > is something to work with. > > > > > > > > > > This patchset includes both the kernel and bluez patches. I > > > > > understand this is > > > > > not recommended for normal practice. But I thought for an > > > > > RFC, it is nice to > > > > > keep things together for now. > > > > > > > > I would avoid adding a new MGMT command and instead disabled > > > > duplicated filtering if RSSI filtering is set since anyway RSSI > > > > filtering needs to disable duplicates in order to do any RSSI > > > > filtering reliable. So this would mean that if the user wants > > > > to see > > > > to get duplicate filtering it needs to set a RSSI which should > > > > rate > > > > limit as we would use a threshold. > > > > > > Hi Luiz, > > > > > > Ok, fair enough. I then simplified it down to a small kernel > > > patch that > > > seems to work if I set an RSSI threshold with SetDiscoveryFilter. > > > > > > I only do this on an active_scan. Not sure if I should do it for > > > the > > > passive scans too? > > > > > > If this looks ok, I will resubmit properly. > > > > I am not sure this is the best idea. So right now the kernel > > restarts scanning to get new RSSI values when we have a quirk set > > that strict scan filtering is performed by the controller (strict > > means address only). > > > > That is for discovery. Something started by the user and something > > that does not last over long times. Discovery is using active > > scanning which takes way more TX/RX time on air than passive > > scanning. It is also known to be causing more problems then it > > solves when run constantly. The reason is that it will interrupt > > CONNECT_REQ since SCAN_REQ are more likely to win based on their > > shorter packet size. > > > > So the main question is if you are after a certain set of devices > > (based on their address) and want to monitor their RSSI or are you > > after any device and want to match based on advertising data? > > > > The first one could be dealt with by using the whitelist, the > > second one is nasty from a power consumption point of view. Any > > long term operation there would be causing major headaches. > > > > Keep in mind that besides the kernel waking up (and USB transport), > > you also end up waking userspace all the time to process the > > information and send out over D-Bus. Which means you might going to > > wakeup even more processes. > > Can I just leap in here, as this is extremely relevant to the project > I am working on. Sometimes you need to step back from what the > ‘average user’ needs, and consider whether should allow certain > behaviours to be enabled, even if they are not the default. What is > ‘nasty’ to you in the big picture, is perfectly normal for me in a > dedicated use case. > > Our application transfers data between devices (and there could be > well over a thousand within range at a single time) and the central > system using purely the MSD in the advertisements. Our linux > ‘gateway’ boxes need to have continuous reception of advertisements, > and we don’t care about the power consumption or processing > implications - that is their dedicated job. We are currently unable > to migrate our code from some older gatttool derived code to the > modern APIs because it simply isn’t possible to work in the manner we > need. (Note that our gateways use multiple BLE dongles, with at least > one dedicated to receiving beacons while the others are used to > connect to devices for archived data retrieval.) > > Please give some consideration to the fact that not everybody is > using bluetooth for simple end-user devices, and whilst these are > clearly the dominant use case, being able to engage esoteric modes of > operation allows those of us who need to to consciously engage them > as necessary for bespoke scenarios/applications. BLE is not just a > desktop/peripheral technology :) > > Hope you don’t mind the interjection… > > Regards > > Stu I want to second this as well. I have a device that always scans and processes all advertisement packets with manufacture specific data. I also constantly am updating the advertisement packets. Power really is not a worry here. In the current design I have I switch between modes where I use the management interface to perform GATT connections and then fall back to raw HCI to process the packets. --Brennan -- 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
