Hi Christian,
On Wed, Nov 20, 2024 at 2:07 PM Christian Eggers <ceggers@xxxxxxx> wrote:
>
> 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".
Ok this shall probably be handled in the kernel and remove its
advertising instance and notify the userspace the controller has lost
tracking of this instance so we can cleanup the upper layers.
> 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?
Not really, I don't think Ive seen this behavior before at least but
perhaps the driver is powering down during rfkill which probably means
it would act as a reset was sent, that said I'm surprised nothing else
breaks with this behavior.
> regards,
> Christian
>
>
>
>
--
Luiz Augusto von Dentz
