Hi Johan, On Thu, Jan 18, 2024 at 3:40 AM Johan Hovold <johan@xxxxxxxxxx> 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@xxxxxxxxxx> 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/107 > > it 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 -- Luiz Augusto von Dentz
