On Thu, Jan 18, 2024 at 10:30:50AM -0500, Luiz Augusto von Dentz wrote:
On Thu, Jan 18, 2024 at 3:40 AM Johan Hovold johan@kernel.org wrote:
On Wed, Jan 17, 2024 at 05:49:07PM -0500, Luiz Augusto von Dentz wrote:
On Wed, Jan 10, 2024 at 3:12 AM Johan Hovold johan@kernel.org wrote:
On Tue, Jan 09, 2024 at 05:54:01PM +0000, Matthias Kaehlcke wrote:
And any user space tool overriding the address would currently need to provide the address in reverse order on Qualcomm platforms like this one (e.g. if generating the address for privacy reasons).
Perhaps we could attempt to resolve the address byteorder, in userspace we use hwdb_get_company to resolve the company but since this shall only really care about Qualcomm range(s) perhaps we can hardcode them check in which order the address is, that said if the device is configured with a Static Random Address then that would not work, but that is only really possible for BLE only devices.
It's not just Qualcomm ranges; The Lenovo ThinkPad X13s that I noticed this on has been assigned a Wistron OUI, for example.
Well we could still attempt to check if it has a valid OUI and then it fail swap and check again.
So in the kernel you would parse any address coming from firmware or user space to try to determine if it's given in reverse order? I don't see how this would work as presumably some of the least significant bytes would occasionally match a valid OUI even if you were somehow able to determine that.
We're still hoping to learn how to retrieve this address (from the secure world firmware) so that we can set it directly from the driver, but for now it needs to be set using btmgmt (or the local-bd-address devicetree property).
As was discussed here:
https://github.com/bluez/bluez/issues/107it would be useful to teach bluetoothd to (generate and) set an address for devices that lack (accessible) persistent storage. And any such generic tool would need to work using the standard interfaces and the address endianness that those interfaces expect.
Yep, patches are welcome in this regard, note that we do something like this:
https://github.com/bluez/bluez/blob/master/src/adapter.c#L9847
But the first thing it checks is if the controller supports BR/EDR, so if you want to extend that we need at least the OUI portion to be able to allocate a valid public address, we could perhaps attempt to fetch the manufacturer somehow or use the controller manufacturer (adapter->manufacturer) in case there is nothing else to use.
Thanks for the pointer. I'm trying nudge some of the distro folks to look into this.
And from skimming the Bluetooth spec, I was under the impression that random addresses applied also to non-BLE devices (e.g. requiring the two most-significants bits to be 1).
Not really, BR/EDR/classic addresses are always considered public addresses, the HCI interface doesn't even have an address type to be able to handle something like a random address or privacy for the same reason.
Ah, ok. Then generating an address is perhaps not an option, but reading one out from a file and setting it would still be useful for cases like the X13s which do have an address assigned (e.g. accessible through windows or written on the box the machine came in).
Johan