All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brennan Ashton <brn@deako.com>
To: Don Zickus <dzickus@redhat.com>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Barry Byford <31baz66@gmail.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>
Subject: Re: d-bus or management api for beacon stuff
Date: Tue, 29 Nov 2016 13:28:42 -0800	[thread overview]
Message-ID: <1480454922.19570.9.camel@deako.com> (raw)
In-Reply-To: <20161129210137.GX35881@redhat.com>

On Tue, 2016-11-29 at 16:01 -0500, Don Zickus wrote:
> On Tue, Nov 29, 2016 at 11:56:03AM -0800, Brennan Ashton wrote:
> > 
> > > 
> > > > 
> > > > 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.
> 
> Hi,
> 
> Sorry for being ignorant (as I can't quite find the filter duplicate
> code
> other than the setting of the bit), but would throttling work
> here?  Cap the
> duplicates at say every 100ms or 10x/second.  That probably won't
> help with
> power consumption (unless start/stop of the radio is quick?).
> 
> Just trying to help move this along..  willing to code/test.
> 
> Cheers,
> Don
> 
The thread I mentioned is here:
https://marc.info/?t=147345134200002&r=1&w=2

The constant of interest is this LE_SCAN_FILTER_DUP_ENABLE.  I had to
recompile with this disabled because I never wanted the filter for my
application.  I had proposed making this an option in the adaptor
interface, but there did not seem to be any interest.

--Brennan


  reply	other threads:[~2016-11-29 21:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-23 21:40 d-bus or management api for beacon stuff Don Zickus
2016-11-24 13:07 ` Luiz Augusto von Dentz
2016-11-28 20:55   ` Don Zickus
2016-11-29 12:24     ` Barry Byford
2016-11-29 12:45       ` Luiz Augusto von Dentz
2016-11-29 19:56         ` Brennan Ashton
2016-11-29 21:01           ` Don Zickus
2016-11-29 21:28             ` Brennan Ashton [this message]
2016-11-29 21:36               ` Don Zickus
2016-11-29 21:45                 ` Brennan Ashton
2016-11-30 20:15               ` Don Zickus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1480454922.19570.9.camel@deako.com \
    --to=brn@deako.com \
    --cc=31baz66@gmail.com \
    --cc=dzickus@redhat.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.