Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAD3n0hm61cRPK3=Scf02y3Y3aMJ66eCC5nwFh40Y9kfLBWk-tw@mail.gmail.com>
 <CAAu3APZ4WqFd=61eUfbC8biTbygWW4k2Te3De38B2+maYoBePw@mail.gmail.com>
 <CAD3n0hnJkmXGjiei0-u=GBh0xoGb4N7tkuBh_uSvsuT7bAhXLA@mail.gmail.com>
 <CAAu3APbWouHkguPG3_FQmxPY=6q6rzmr_CbOqY2_0a0RzC++XQ@mail.gmail.com>
 <CAD3n0hnWk0rULy+RJNTAujqY5vtTR=zvoB8233rtLSGc3R-9Pw@mail.gmail.com>
 <CABBYNZJn3-xBUQ8h_akoKAzm4AT1COjAFLhMhg6V=VnjOZVTvQ@mail.gmail.com> <CAD3n0h=A9UhCd+Aux=GLdQKWPJUma4=eYfV7xUb0tJHgnxUA0A@mail.gmail.com>
In-Reply-To: <CAD3n0h=A9UhCd+Aux=GLdQKWPJUma4=eYfV7xUb0tJHgnxUA0A@mail.gmail.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Mon, 24 Feb 2020 17:51:58 -0800
Message-ID: <CABBYNZJC3xwQ0jx7k6_t0uhzpJyOsdO1n3LYqW1gC_TSnU-SHg@mail.gmail.com>
Subject: Re: Bluez blotoothctl scan vs hcitool scan
To:     chris baker <chrisbkr2020@gmail.com>
Cc:     Barry Byford <31baz66@gmail.com>,
        Bluez mailing list <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Chris,

On Mon, Feb 24, 2020 at 5:36 PM chris baker <chrisbkr2020@gmail.com> wrote:
>
> On Mon, Feb 24, 2020 at 4:33 PM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> >
> > Hi Chris,
> >
> > On Mon, Feb 24, 2020 at 1:56 PM chris baker <chrisbkr2020@gmail.com> wrote:
> > >
> > > On Mon, Feb 24, 2020 at 9:13 AM Barry Byford <31baz66@gmail.com> 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@gmail.com> wrote:
> > > > >
> > > > > On Mon, Feb 24, 2020 at 6:08 AM Barry Byford <31baz66@gmail.com> wrote:
> > > > > >
> > > > > > Hi Chris,
> > > > > >
> > > > > > On Mon, 24 Feb 2020 at 10:12, chris baker <chrisbkr2020@gmail.com> 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!

Afaik the HCI duplicate filter flag is not very granular, so the
controller may be dropping any reports found during a sort period
since it might not have enough memory to store everything, include
actual data in the advertisement, to compare with.

-- 
Luiz Augusto von Dentz