On Mon, Feb 24, 2020 at 4:33 PM Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > > Hi Chris, > > On Mon, Feb 24, 2020 at 1:56 PM chris baker <chrisbkr2020@xxxxxxxxx> wrote: > > > > On Mon, Feb 24, 2020 at 9:13 AM Barry Byford <31baz66@xxxxxxxxx> wrote: > > > > > > If the DBus API is not cutting it for you then using the MGMT API > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/mgmt-api.txt > > > is what has been recommended in the past: > > > https://www.spinics.net/lists/linux-bluetooth/msg68959.html > > > > > > On Mon, 24 Feb 2020 at 16:37, chris baker <chrisbkr2020@xxxxxxxxx> wrote: > > > > > > > > On Mon, Feb 24, 2020 at 6:08 AM Barry Byford <31baz66@xxxxxxxxx> wrote: > > > > > > > > > > Hi Chris, > > > > > > > > > > On Mon, 24 Feb 2020 at 10:12, chris baker <chrisbkr2020@xxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > So my question is, is there a way to get those missing advertisements > > > > > > through the dbus api, possibly some additional setting somewhere? > > > > > > > > > > Duplicates are disabled by default with the DBus API. This can be > > > > > controlled with the DuplicateData setting: > > > > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt#n107 > > > > > > > > > > Regards, > > > > > Barry > > > > > > > > > > > > My apologies, I guess I wasn't clear (long post) but, I turned > > > > duplicate data on when using the bluetoothctl command (via the "scan" > > > > submenu) and also used the flag, "hcitool lescan --duplicates", when > > > > running the hcitool command. So both scans should have included any > > > > duplicates (unless I've misunderstood something). Additionally, none > > > > of the missing packets were duplicates (again, unless I'm > > > > misunderstanding what "duplicates" means). each packet had a unique > > > > sequence numbers as well as the button data field toggling. > > > > Great, thank you. I'll look into the MGMT api in the coming days. That > > said, is it a problem to use both api's (MGMT/DBus) concurrently from > > the same app? My application supports both connected BLE sensors as > > well as BLE beacon type sensors. If possible I can handle them in two > > different threads, but the DBus thread for connected sensors would > > still occasionally need to scan for new sensors (using the DBus > > discovery call) and would still need to get characteristic changed > > callbacks as well. > > Have a look at the other thread subject: Adding support for > DuplicateData into the kernel > > We are discussing adding support to disable duplicate via MGMT since > DuplicateData does not currently remove it but we might want to change > that, or at least have some alternative API to do that. We could for > example have a socket that enables a more direct access to the > advertisments, that way protocol that work over advertisement would > have a way to do this, in fact this might be better for things like > mesh so it can coexist with bluetoothd. > > > Out of curiosity though, is the behavior I'm seeing normal? Or is the > > sensor doing something improper possibly? Seeing as the packets aren't > > duplicates why would they be filtered (or are they just not being > > received to begin with for some reason)? The 11 second interval seems > > kind of strange. Anyway, thanks again for the help! Chris > > > > -- > Luiz Augusto von Dentz Thanks Luiz, I don't want to sound dense, and I really appreciate you and Barry's help, but these aren't duplicate packets (unless, again, I'm misunderstanding the term). Each packet payload is completely unique. I'll have a look at the other thread for sure, but I'm really just trying to understand if the missing packets I identified in the trace should be there (in the DBus/bluetoothctl trace) or if there's a reason they were excluded. Again, they weren't duplicates and I'm reasonably sure I had the duplicate data flags set correctly each time. Also, whatever is going on is not transient, I can duplicate it with the senor I'm testing every time (both in my app or via bluetoothctl). More important for sure is to find a work-around (hopefully the MGMT api Barry pointed me to) but still just curious why these packets are getting dropped/filtered... Anyway, thanks again to you both!
