From: Stephan Gerhold <stephan@gerhold.net>
To: Ferry Toth <ftoth@exalondelft.nl>
Cc: Marcel Holtmann <marcel@holtmann.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1
Date: Tue, 19 Mar 2019 15:03:56 +0100 [thread overview]
Message-ID: <20190319140356.GA1076@gerhold.net> (raw)
In-Reply-To: <7b48753f-f103-f522-68c5-38479feb4552@exalondelft.nl>
Hi,
Sorry for the late response. I've been quite busy lately...
On Tue, Mar 05, 2019 at 07:26:14PM +0100, Ferry Toth wrote:
>
> Op 05-03-19 om 14:09 schreef Stephan Gerhold:
> > BCM2076B1 appears to use 20:76:A0:00:56:79 as default address.
> > This address is used by at least 5 devices with the AMPAK AP6476
> > module and is also suspicious because it starts with the chip name
> > 2076 (followed by a different revision A0 for some reason).
> With BCM43340 (Edison) it's the same principle. With the fake address I
> found everything (in user space) seems to work except PAN/NAP (bnep) and no
> decent error message anywhere making this quite hard to debug.
Not familiar with PAN/NAP, but the main reason to avoid default
addresses is that they will cause issues as soon as you have two of
those devices next to each other.
> > Add it to the list of default addresses and leave it up to the
> > user to configure a valid one.
>
> Which way is the user supposed to configure the valid one?
>
It took me a while to figure this out - there is not much
documentation for this. The following is only based on my own
investigations:
As far as the kernel is concerned, HCI_QUIRK_INVALID_BDADDR is exposed
through the btmgmt API [1]. With the quirk, the BT controller will
appear as "unconfigured" controller to userspace, and will have the
public address as missing option. As soon as the address is configured
with the "Set Public Address Command", the unconfigured controller is
removed and replaced with a regular controller.
Only then it will be usable through bluetoothd.
The btmgmt API has to be controlled from user space.
As far as I know, the only tool in bluez to set the public address
is the "btmgmt" tool:
btmgmt -i hci0 public-addr xx:xx:xx:xx:xx:xx
... will run the "Set Public Address Command" described above.
However, it was mentioned several times that "btmgmt" is not
a "stable" tool. In other words, it is not installed by default
and is only intended for debugging. It may change any time.
There was a related discussion on IRC recently: (I was not involved)
10:50 <Mis012[m]> sjanc: do I need to convince my distro to package
btmgmt, or will you revert that commit?
10:51 <sjanc> Mis012[m]: I'd ask holtmann about this :) but btmgmt
was more like testing tool than real end user tool
(ie, no manpages, rather ad-hoc design and command set etc
10:53 <sjanc> Mis012[m]: but if you really need this feature,
I'd consider starting discussion on mailing list
on how this could be handled by bluetoothd
10:53 <sjanc> as mentioned, this could be in plugin,
either common plugin or maybe platform specific,
which would set public address via mgmt api
10:54 <sjanc> open point is how bluetootd would extract public address,
which is always platform specific
10:55 <holtmann> Mis012[m]: btmgmt is not a stable tool.
10:55 <Mis012[m]> holtmann: but it's the only one which can do this
10:56 <holtmann> Then add support to bluetoothd for it or do it via an
external tool / daemon. I wrote a long post to the mailing list
about that.
I have such an external daemon for Android (since it does not use bluez)
at [2]. It would be easy to refactor it to something more portable.
[1]: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/mgmt-api.txt
[2]: https://github.com/me176c-dev/android_device_asus_K013/blob/lineage-16.0/bluetooth/bdaddr.c
> The only way I found is bd_addr (tool from bluez that is not normally
> built/installed).
>
> Using this tool requires hci0 to be up and bluetoothd to be restarted if
> that was already running, which is quite inconvenient.
>
bdaddr does not use the btmgmt API. It sends vendor-specific commands to
the HCI interface. This might be the reason why you need to restart
bluetoothd.
With HCI_QUIRK_INVALID_BDADDR set, the BT controller should not show up
at all in bluetoothctl until its public address is configured.
It does not matter if bluetoothd is started too early.
> I also saw there was a patch to put the address in dt.
>
> But nowhere did I find a kernel parameter to pass the address. Did I miss
> something?
>
I'm not familiar with setting the address from DT/kernel parameters.
Sorry :(
next prev parent reply other threads:[~2019-03-19 14:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-05 13:09 [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth Stephan Gerhold
2019-03-05 13:09 ` [PATCH 2/2] Bluetooth: btbcm: Add default address for BCM2076B1 Stephan Gerhold
2019-03-05 18:26 ` Ferry Toth
2019-03-19 14:03 ` Stephan Gerhold [this message]
2019-03-20 21:11 ` Ferry Toth
2019-03-21 9:23 ` Stephan Gerhold
2019-04-30 15:04 ` Stephan Gerhold
2019-04-30 15:06 ` Marcel Holtmann
2019-05-01 7:18 ` [PATCH RESEND] " Stephan Gerhold
2019-05-05 17:29 ` Marcel Holtmann
2019-04-08 16:55 ` [PATCH 1/2] Bluetooth: btbcm: Add entry for BCM2076B1 UART Bluetooth Stephan Gerhold
2019-04-23 17:11 ` Marcel Holtmann
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=20190319140356.GA1076@gerhold.net \
--to=stephan@gerhold.net \
--cc=ftoth@exalondelft.nl \
--cc=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=marcel@holtmann.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).