mcumgr/SMP Bluetooth transport may not be reliable

[M1cha]

Description

A quote from the spec:

Since GATT guarantees ordered delivery of packets, the SMP header in the first fragment contains sufficient information for reassembly.

That's true, it does guarantee ordered delivery, but it doesn't prevent packages from being dropped. The reassembly algorithm in zephyrs implementation simply drops the current(and all previous) fragments, when the data is larger than the length field of the SMP header. There are no sequence numbers, no checksums, no frame delimiter. Depending on the situation this can lead to mis-interpreting data as an SMP-header or vise-versa. In very unfortunate situations this may prevent you from recovering from that. In even worse situations, the loss goes undetected and what happens next is up to the SMP group handler .

Additional Info

The BLE core spec is very complex and unfortunately not very clear about if and when data loss is possible. There seem to be "ATT bearers"(=l2cap channels), which allow sending data with retransmissions disabled. It's not clear if and when they are used. For BLE notifications it seems to be clear that they don't have to be retries and can get lost though.

Either way, the spec only tells you what should happen until the stack receives the data. It can still be dropped within the stack or on the way to the application code. In fact, in zephyr that can happen all the time because there are many queues between HCI and the BLE API which happily drop data if they are full. While we could ofc, fix or configure that so it can't happen on zephyrs side, we can't control what the other side(the SMP client) looks like.

[nordicjm]

This is user misconfiguration, you should not be using too large a packet that the remote device does not support, this is not related to the bluetooth transport, it will happen with them all.

[M1cha]

The SMP GATT transport has additional code and a kconfig to support reassembly of SMP packets which are larger than what's supported by the bluetooth stack. Meaning it'd be a mis-implementation, not a mis-configuration.

[nordicjm]

No, that is a misconfiguration. You need to size the buffers for your application. You can't fit 40,000 bytes into a 10 byte buffer

[M1cha]

1. But doesn't that statement contradict the Bluetooth specification? E.g. it says that delivery of notifications is not guaranteed. So if a single SMP packet has to be fragmented into 3 notifications, it's possible that one of them gets lost and you'll never know that it happened.
2. While we can control what the zephyr BLE stack does, we can't really control what e.g. an Android or iOS or Linux or Windows BLE stack does. You simply cannot know if they will drop the package or not and have no feedback for it. A full buffer may not even be the only reason that it can be dropped. There may be other reasons. That's why BLE indications exists, they are the only way to ensure that data arrives. Same with write vs write_with_response.

[nordicjm]

Notifications are guaranteed, but they are guaranteed to arrive at the radio, there is no guarantee they will arrive at the application. Notifications are responses to the client, if your client cannot handle the notifications then that is a issue with your client device (i.e. misconfiguration) because you haven't designed it or configured it so it can support the data.

Yeah I'm not being funny but you aren't going to exhaust the bluetooth stacks on those devices with notifications, they have gigabytes of RAM, this is a complete non-issue