Hi Johan,
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:
hciconfig hci0: Type: Primary Bus: UART BD Address: 8C:FD:F0:40:15:DC ACL MTU: 1024:8 SCO MTU: 240:8 UP RUNNING RX bytes:1700 acl:0 sco:0 events:95 errors:0 TX bytes:128949 acl:0 sco:0 commands:578 errors:0
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.
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.
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.
But to summarise, I don't really see any way around fixing the Qualcomm driver.
Johan