Bluetooth: controller: Switching to non conn adv fails for Mesh LPN

[trond-snekvik]

The Bluetooth Mesh Low Power Node feature fails sending its poll packet when GATT proxy is enabled.

The Bluetooth mesh advertises a connectable advertisement at 1 second interval for its proxy feature. The LPN role aborts this advertisement every 30 seconds to send a non-connectable 20 ms interval advertisement (the "LPN poll"). The LPN poll gets 90 ms to send a couple of advertisements before switching back to connectable 1 second advertisement, but in those 90 ms no advertisements are sent.

To Reproduce
The error can be reproduced on current master with two devices running the tests/bluetooth/mesh_shell, designating the problematic device "DUT", the other "tester":

The devices need initial setup through the shell the first time after erasing:

Tester:

$ mesh init
$ mesh provision 0 1 0
$ mesh friend on

After this, the tester only needs the mesh init command after each reboot.

DUT first time setup:

$ mesh init
$ mesh provision 0 2 0

To trigger the invalid behavior on the DUT, call:

$ mesh lpn on

This triggers the following output:

uart:~$ mesh lpn on
Friendship (as LPN) established to Friend 0x0001
[00:00:46.652,984] <inf> bt_mesh_lpn: Friendship established with 0x0001

Now, send the following command:

$ mesh poll

This triggers the following output:

uart:~$ mesh poll
[00:01:00.055,541] <wrn> bt_mesh_lpn: No response from Friend during ReceiveWindow
[00:01:02.502,227] <wrn> bt_mesh_lpn: No response from Friend during ReceiveWindow
[00:01:04.948,913] <wrn> bt_mesh_lpn: No response from Friend during ReceiveWindow
[00:01:07.395,599] <wrn> bt_mesh_lpn: No response from Friend during ReceiveWindow
[00:01:09.395,996] <err> bt_mesh_lpn: No response from Friend after 4 retries
Friendship (as LPN) lost with Friend 0x0001

If the DUT reboots, you’ll need to call mesh init, mesh lpn on and mesh poll again.

The error happens when calling mesh poll, as this triggers the non-connectable advertisement (followed by a period of scanning). Enabling CONFIG_BT_CTLR_DEBUG_PINS=y shows the controller stopping connectable advertisements, then waiting 90 ms before starting them again. The connectable advertisements start immediately after the 90 ms, as expected.

Expected behavior
The controller should send 3-4 non-connectable advertisements during the 90 ms. The correct behavior is observable if we disable the proxy feature on the shell (CONFIG_BT_MESH_GATT_PROXY=n), likely because the advertiser will be idle when the non-connectable advertisements are requested.

Impact
Mesh LPN feature is unusable with the GATT proxy feature, a quite common combination.

Environment

• nRF52832_xxAA on PCA10040
• Software based Bluetooth controller.

[trond-snekvik]

cc @jhedberg