I have a regression with my LE advertising after updating the kernel
from 5.15.x to 6.6.x.
At some time in the past I came to the conclusion that my Bluetooth adapter
(TP-Link UB500 with Realtek RTL8761BU) "forgets" all LE advertising when
powered off (e.g. by "rfkill block ..."). Due to this thinking I registered
a D-Bus signal handler on "org.freedesktop.DBus.Properties.PropertiesChanged"
and called "org.bluez.LEAdvertisingManager1.RegisterAdvertisement" (or
"UnregisterAdvertisement") after the "Powered" property of my "org.bluez.Adapter1"
got updated.
With Linux-5.15, there was no problem removing the advertising instance
after the HCI was powered down. In remove_advertising(), the call of
hci_req_clear_adv_instance() (and then hci_remove_adv_instance())
successfully removed the instance from struct hci_dev. As the
HCI was already powered down, no attempt was made to remove it
from the controller hardware itself.
With Linux-6.6, remove_advertising() calls hci_cmd_sync_queue(), which
checks for HCI_RUNNING and returns -ENETDOWN. So the advertising instance
is neither removed from the controller nor from struct hci_dev.
When I power up the HCI again (by "rfkill unblock ..."), the BT stack
tries to "update" the advertising (hci_powered_updat_adv_sync(), called
from hci_power_on_sync()). This fails then in hci_disable_ext_adv_instance_sync(),
I get the following output in btmon:
< HCI Command: LE Set Extended Advertising Enable (0x08|0x0039) plen 6 #257 [hci0] 55.116038
Extended advertising: Disabled (0x00)
Number of sets: 1 (0x01)
Entry 0
Handle: 0x01
Duration: 0 ms (0x00)
Max ext adv events: 0
> HCI Event: Command Complete (0x0e) plen 4 #258 [hci0] 55.117040
LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
Status: Unknown Advertising Identifier (0x42)
The kernel log shows "Bluetooth: hci0: Opcode 0x2039 failed: -38".
When my application then tries to (re-)register its advertising,
I get the following btmon output:
bluetoothd[408]: @ MGMT Command: Add Extended Advertising Parameters (0x0054) plen 18 {0x0001} [hci0] 55.260267
Instance: 1
Flags: 0x00010003
Switch into Connectable mode
Advertise as Discoverable
Contain Scan Response Data
Duration: 0
Timeout: 0
Min advertising interval: 0.000 msec (0x0000)
Max advertising interval: 0.000 msec (0x0000)
TX power: 0 dbm (0x00)
< HCI Command: LE Set Extended Advertising Enable (0x08|0x0039) plen 6 #261 [hci0] 55.311447
Extended advertising: Disabled (0x00)
Number of sets: 1 (0x01)
Entry 0
Handle: 0x01
Duration: 0 ms (0x00)
Max ext adv events: 0
> HCI Event: Command Complete (0x0e) plen 4 #262 [hci0] 55.313950
LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
Status: Unknown Advertising Identifier (0x42)
@ MGMT Event: Command Status (0x0002) plen 3 {0x0001} [hci0] 55.325430
Add Extended Advertising Parameters (0x0054)
Status: Failed (0x03)
bluetoothd[408]: = /usr/src/debug/bluez5/5.72/src/advertising.c:add_client_complete() Failed to add advertisement: Failed (0x03) 55.329010
I guess that all this happens because the controller has forgotten its advertising
during power down and now there is a mismatch between the entries in struct hci_dev
and the controller.
Is it normal that a controller clears its advertising entries when powered down?
Who (kernel / application) would be responsible for "restoring" the advertising
after the controller had a power cycle?
regards,
Christian
