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. 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. 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). But to summarise, I don't really see any way around fixing the Qualcomm driver. Johan
