problem with subscription notification

RE: problem with subscription notification

Edvin — Tue, 02 Jan 2024 13:13:38 GMT

Hello,

Sorry, I have been on leave since August.

There are a few issues that you can track. Mainly this one:

https://github.com/zephyrproject-rtos/zephyr/issues/56187

But these may also be interesting:

https://github.com/zephyrproject-rtos/zephyr/issues/31306

https://github.com/zephyrproject-rtos/zephyr/issues/46695

https://github.com/zephyrproject-rtos/zephyr/issues/44587

Best regards,

Edvin

RE: problem with subscription notification

dtp — Sun, 10 Dec 2023 12:43:19 GMT

Hi Edvin, I know this is an old ticket but this issue is still present on NCS v2.5.0 and I have had to implement work arounds as well.

I was hoping there would be a way for the peripheral to reset any subscriptions on disconnections, but from what I understood that would mean not following the Bluetooth spec. I haven't found a way to do this anyhow.

I was wondering if there is a plan to address this issue. Also, is there a way to track it, maybe a Zephyr GitHub issue?

RE: problem with subscription notification

Edvin — Fri, 31 Mar 2023 13:04:28 GMT

Please note that we will be very short staffed next week due to public holidays here in Norway. I will be back in the office on April 11th. Sorry for the inconvenience.

Best regards,

Edvin

RE: problem with subscription notification

Edvin — Fri, 31 Mar 2023 13:03:55 GMT

[quote user="frankbuss"]Will the fix then be mentioned in the release notes for a new SDK?[/quote]

I would assume so. It is not finalized yet, but this ticket (with others) have triggered some actions, at least.

[quote user="frankbuss"]what is a safe delay which always work?[/quote]

That is the issue. There is no delay which is guaranteed to work every time. It would depend on your connection interval, and the amount of packet loss. You can try to do some tests using your central application under different conditions (distance/surroundings) to see how long it takes. It may actually be that disabling and re-enabling notifications from the central will go faster in most cases than a "safe" delay, if the delay would allow for some packet loss.

As I see it, this is the main issue. Adding a delay will work in most cases, but you are never 100% sure that the discovery has completed. In theory, you could only get one packet through every supervision timeout. Any slower than this, and the link will disconnect. In that case, it would take N*supervision timeout for the discovery complete, where N is the amount of packets needed to go back and forth before the service discovery is complete. This depends on the application, but you can probably do a sniffer trace and count the number of packets. However, if you want to be "that" safe, disabling and reenabling notifications are probably faster.

Best regards,

Edvi

RE: problem with subscription notification

frankbuss — Tue, 28 Mar 2023 18:19:45 GMT

Ok, what is a safe delay which always work? Currently I'm using one second after connect. Will the fix then be mentioned in the release notes for a new SDK?

RE: problem with subscription notification

Edvin — Tue, 28 Mar 2023 07:48:03 GMT

Hello,

I have discussed this a bit with some of our developers. At this point, there is really no good workaround for this, other than adding a delay, as you have already done. Apparently, this is already being used in some of our use case applications (nRF Desktop, which is a wireless mouse/keyboard demo in NCS).

I see that there have been attempts to work around this, but none of them have been included so far in our released SDKs. Whether or not they will be included in the next one I don't know.

So for now, it seems you need to stick to the delay, unfortunately. Alternatively, on your central, you can try to enable, disable and re-enable notifications. It seems a bit unnecessary, and I have not tested it, but I think you will then see the "notifications enabled" callback immediately upon the connect, followed by a "notifications disabled" event, and then a "notifications enabled" event. You can use that last event to know for sure that the notifications have been enabled.

Best regards,

Edvin

RE: problem with subscription notification

Edvin — Thu, 23 Mar 2023 08:44:27 GMT

Hello,

I am sorry for the late reply. I just wanted to let you know that I have investigated a bit more, and I can confirm what you are seeing. I hoped the service discovery on the central was just a "dummy service discovery", where it also used information stored in the bonding data, but that seems to not be the case.

I have created an internal ticket, and I will let you know when I hear anything.

BR,
Edvin

RE: problem with subscription notification

frankbuss — Mon, 06 Mar 2023 21:49:19 GMT

No problem, is not urgent. I didn't do any more research after implementing the delay, which was a good enough workaround for us to continue the other work on the application.

RE: problem with subscription notification

Edvin — Mon, 06 Mar 2023 21:40:58 GMT

Hello,

Sorry for the late reply. I have not been able to do my support work lately, and I am sorry for the inconvenience. I was about to look into this, but I wanted to check whether you had any findings in the last two weeks. If not, I will do some digging tomorrow.

Best regards,

Edvin

RE: problem with subscription notification

frankbuss — Thu, 23 Feb 2023 07:32:00 GMT

[quote userid="26071" url="~/f/nordic-q-a/96755/problem-with-subscription-notification/410801"]I see. Where did you see the callback that was discarded?[/quote]

I think it was in att.c, in bt_att_recv, because no handler was found.

[quote userid="26071" url="~/f/nordic-q-a/96755/problem-with-subscription-notification/410801"]In the meantime, I guess a delay could work as a temporary workaround, just so that you don't need to wait for this.[/quote]

Thanks, I added one second delay, and looks like this works all the time. But it is not urgent, would be good to find a better solution.

RE: problem with subscription notification

frankbuss — Tue, 21 Feb 2023 01:10:59 GMT

I created a minimal test application, which demonstrates the problem:
https://www.frank-buss.de/tmp/indicate_bug.zip
You need to flash it on 2 nRF5340 DK boards. Then press button 1 on the first board, which connects with the second board, and will pair and save the bonding information. You can see that "counter received" counts from 1 to 10 (in a connected terminal to the 2nd UART). Then press reset on the same board, and press the button 1 again. As you found out, the subscription information is restored, and the counter starts from 4 instead from 1.

RE: problem with subscription notification

Edvin — Mon, 20 Feb 2023 08:26:53 GMT

[quote user="frankbuss"]I debugged it, and could see in the Bluetooth stack on the central side that the data arrived, but that it wasn't forwarded to the application, because it thought it was not subscribed.[/quote]

I see. Where did you see the callback that was discarded?

I tried to reproduce this in the peripheral_uart and central_uart samples. I see that the callback is set in the discovery_complete event, but I am not sure whether the issue here is that discovery complete is called every time, and the callback is triggered from the central to set the notification callback. Could it be set elsewhere? I agree that the behavior is a bug, but I am not sure whether it is in the central gatt client implementation or in the bluetooth stack itself.

Also, I am not sure whether the service discovery is actually happening if the device is bonded, or if it just returns discovery complete, just like the peripheral triggers the CCC changed callback. I will do some experimenting and capture some sniffer traces. I'll try to get it done today, and I will update you.

In the meantime, I guess a delay could work as a temporary workaround, just so that you don't need to wait for this.

Best regards,

Edvin

RE: problem with subscription notification

frankbuss — Fri, 17 Feb 2023 12:06:02 GMT

Right, looks like the status is restored immediately after a connect on the peripheral side. I think this is an architectural problem, because on the central side, the callback function is only set later with the bt_gatt_subscribe function, and obviously this callback pointer can't be saved. Meanwhile the peripheral has already sent data, which is then lost. I debugged it, and could see in the Bluetooth stack on the central side that the data arrived, but that it wasn't forwarded to the application, because it thought it was not subscribed.

I've also compiled the central app for the posix target and ran it on Linux, with the hci_uart project for the Bluetooth part. I then logged the traffic with btmon, and looks like that I can see in Wireshark that the central device sends the subscription, see screenshot here:

I tested it with the bt_gatt_is_subscribed functions, but looks like they return true as well immediately after a connect.

I would appreciate any other idea. I guess as a workaround I could add a delay, but this wouldn't be very elegant or reliable. I can also try to setup a project to demonstrate the problem, but would be quite some work with the bonding etc.

RE: problem with subscription notification

Edvin — Fri, 17 Feb 2023 09:45:20 GMT

If you bond (store pairing information), then the status of the CCC (notification/indication) is stored, and will be restored the next time they connect.

Otherwise, you can just monitor the return value from sending an indication to determine whether it is enabled or not, much like the peripheral_uart sample does when trying to send a notification using bt_nus_send(). It uses:

else if (bt_gatt_is_subscribed(conn, attr, BT_GATT_CCC_NOTIFY)) {

to determine whether the central has enabled notifications or not.

Alternatively, you can try to capture a sniffer trace (nRF Sniffer for Bluetooth LE) to see whether the indication enable packet is actually sent on air or not.

Best regards,

Edvin

RE: problem with subscription notification

frankbuss — Thu, 16 Feb 2023 15:27:02 GMT

I paired my peripheral application with nRF Connect, and I can't reproduce the problem either. So I guess something is wrong with my code for the central device. Will debug it in detail and then post the solution (if I find one).

RE: problem with subscription notification

frankbuss — Thu, 16 Feb 2023 14:47:15 GMT

I tried the zephyr/samples/bluetooth/peripheral_ht example, and can't reproduce it. But indeed, the 2 devices in my application are paired. Could this be the reason?

RE: problem with subscription notification

Edvin — Thu, 16 Feb 2023 14:24:13 GMT

Hello,

What is running on your central DK?

Does your application use bonding or pairing?

Are you sure you are not triggering ccc_cfg_changed() from elsewhere? (accidentally putting it as your conneced callback?)

Is there a way for me to reproduce what you are seeing?

Best regards,

Edvin