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>
In-Reply-To: <CABBYNZJn3-xBUQ8h_akoKAzm4AT1COjAFLhMhg6V=VnjOZVTvQ@mail.gmail.com>
From:   chris baker <chrisbkr2020@gmail.com>
Date:   Mon, 24 Feb 2020 17:36:07 -0800
Message-ID: <CAD3n0h=A9UhCd+Aux=GLdQKWPJUma4=eYfV7xUb0tJHgnxUA0A@mail.gmail.com>
Subject: Re: Bluez blotoothctl scan vs hcitool scan
To:     Luiz Augusto von Dentz <luiz.dentz@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

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!