[CM4-IOBoard]: BDADDR AA:AA:AA:AA:AA:AA

[acostach]

I don't know if it's driver related, perhaps not since the old check \s(B8:27:EB:|DC:A6:32:)' worked, the address on the bluetooth device isn't set on the CM4 IO Board, stays AA:AA:AA:AA:AA:AA.

Switching the check in bthelper to include this case seems to work fine:

if ( /usr/bin/hcitool -i $dev dev | grep -q -E '\s43:4[35]:|AA:AA:AA:AA:AA:AA' ); then

Is there maybe a better approach?

Thank you

[pelwell]

Before choosing a course of action we need to understand the circumstances of the failure.

1. Which distribution are you running? Does it use the pure upstream kernel or is it based on our kernel branches?
2. Do you have "dtparam=krnbt" in config.txt?
3. Is this a CM4 with onboard WiFi? They should have an address programmed into the BT device.

[acostach]

Thanks @pelwell , here are the answers:

1. Using agherzan/meta-raspberrypi on dunfell HEAD, with raspberry-pi/linux branch rpi-5.10.y 5.10.78
2. No krnbt present in config.txt
3. Yes, it's a CM4 lite R-1-3, with onboard wifi.

[pelwell]

Having just liberated a fresh WiFi CM4 from the supplies cupboard I can confirm that it has unique Ethernet MAC, WLAN MAC and Bluetooth BDADDR addresses programmed in at the factory. What does ifconfig report about the Ethernet and WLAN MACs?

[acostach]

Thanks @pelwell, these are the MACs:

root@bf36df5:~# ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr DC:A6:32:FE:74:A9  
          inet addr:192.168.0.156  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: 2a02:2f04:418:b000:281b:c48:ba69:b3/64 Scope:Global
          inet6 addr: fe80::7ef2:40fa:51d1:834d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:34 errors:0 dropped:0 overruns:0 frame:0
          TX packets:73 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:13963 (13.6 KiB)  TX bytes:11431 (11.1 KiB)

root@bf36df5:~# ifconfig eth0 
eth0      Link encap:Ethernet  HWaddr DC:A6:32:FE:74:A8  
          inet addr:192.168.0.155  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::393e:fdd5:5067:c17e/64 Scope:Link
          inet6 addr: 2a02:2f04:418:b000:4b31:cfba:10d4:fd79/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:837 errors:0 dropped:0 overruns:0 frame:0
          TX packets:922 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:226193 (220.8 KiB)  TX bytes:140022 (136.7 KiB)

root@bf36df5:~# hciconfig -a
hci0:   Type: Primary  Bus: UART
        BD Address: AA:AA:AA:AA:AA:AA  ACL MTU: 1021:8  SCO MTU: 64:1
        UP RUNNING 
        RX bytes:1478 acl:0 sco:0 events:88 errors:0
        TX bytes:2534 acl:0 sco:0 commands:88 errors:0
        Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
        Link policy: RSWITCH SNIFF 
        Link mode: SLAVE ACCEPT 
        Name: 'bf36df5'
        Class: 0x000000
        Service Classes: Unspecified
        Device Class: Miscellaneous, 
        HCI Version: 4.1 (0x7)  Revision: 0x0
        LMP Version: 4.1 (0x7)  Subversion: 0x6119
        Manufacturer: Broadcom Corporation (15)

[pelwell]

Thanks - it seems unlikely that it would have had the WLAN MAC address programmed but not the BD address, so I'm going to attribute this failure to software for now.

It seems prudent to add AA:AA:AA:AA:AA:AA as another known "unprogrammed" address.

[pelwell]

See https://github.com/RPi-Distro/pi-bluetooth/commit/23af66cff597c80523bf9581d7f75d387227f183.

[acostach]

Perfect, thank you very much for checking and confirming @pelwell