[CM4-IOBoard]: BDADDR AA:AA:AA:AA:AA:AA
acostach opened this issue · comments
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
Before choosing a course of action we need to understand the circumstances of the failure.
- Which distribution are you running? Does it use the pure upstream kernel or is it based on our kernel branches?
- Do you have "dtparam=krnbt" in config.txt?
- Is this a CM4 with onboard WiFi? They should have an address programmed into the BT device.
Thanks @pelwell , here are the answers:
- Using agherzan/meta-raspberrypi on dunfell HEAD, with raspberry-pi/linux branch rpi-5.10.y 5.10.78
- No krnbt present in config.txt
- Yes, it's a CM4 lite R-1-3, with onboard wifi.
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?
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)
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.
See 23af66c.