BLE RX error Unexpected L2CAP continuation

RE: BLE RX error Unexpected L2CAP continuation

Alex_S@Aperia — Mon, 10 Feb 2025 20:32:16 GMT

Perfect, thank you very much !

RE: BLE RX error Unexpected L2CAP continuation

Kenneth — Mon, 10 Feb 2025 20:24:44 GMT

Hi,

I would say it's common that a central execute a DLE update shortly after connection is established. If the peripheral then is configured to support higher DLE, then it will be updated to the new value. I believe 251 is the maximum:
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

It's also possible to initiate this update from the peripheral side, but I have seen that some centrals are not handling that very well, so I suggest to let the central handle this. If you still want to try it, then the kconfig is:
CONFIG_BT_AUTO_DATA_LEN_UPDATE=y

Kenneth

RE: BLE RX error Unexpected L2CAP continuation

Alex_S@Aperia — Mon, 10 Feb 2025 15:08:01 GMT

I understand that, I didn't mean to ask for help with my central/transmitter stack.
What I meant is to ask - if I change DLE value on peripheral (Nordic) side - is the value expected to be negotiated and accepted by central ?

RE: BLE RX error Unexpected L2CAP continuation

Kenneth — Mon, 10 Feb 2025 13:46:45 GMT

[quote user="Alex_S@Aperia"]It is not Nordic/Zephyr device, uses Cordio BLE stack where all the values are hardcoded.[/quote]

I don't see any way we can help you there no.

Kenneth

RE: BLE RX error Unexpected L2CAP continuation

Alex_S@Aperia — Thu, 06 Feb 2025 22:21:22 GMT

In my case data transfer is mostly unidirectional, and the the issue manifests itself is on the receiver (Nordic peripheral), so if fragmentation does happen, it is caused by transmitter (central device, Maxim MCU)
I'm not sure if DLE is negotiated, like ATT MTU or I have to find a way to explicitly configure it on the transmitter/central. It is not Nordic/Zephyr device, uses Cordio BLE stack where all the values are hardcoded.

RE: BLE RX error Unexpected L2CAP continuation

Alex_S@Aperia — Thu, 06 Feb 2025 22:17:59 GMT

Thank you, this is very helpful, I'll try to play with DLE

RE: BLE RX error Unexpected L2CAP continuation

Kenneth — Thu, 06 Feb 2025 21:58:08 GMT

ATT MTU and DLE is not the same thing, you can read more about it here:
https://novelbits.io/bluetooth-5-speed-maximum-throughput/

So you should also increase DLE > ATT MTU, else all packets will be sent very inefficient due to fragmentation on air (and possible also why something is triggering your issue).

Kenneth

RE: BLE RX error Unexpected L2CAP continuation

Alex_S@Aperia — Thu, 06 Feb 2025 21:37:20 GMT

I actually send packets much larger than 27,
My negotiated MTU is 247

Snippet of log from peripheral (Nordic) side

(

13:24:08.219) Starting advertising for 20 seconds, 10 seconds ahead of rendez-vous #11
(13:24:20.490) Connected with MTU(20)
(13:24:20.490) MTU exchange pending
(13:24:20.731) MTU exchange successful
(13:24:20.731) Current MTU: 247
(13:24:25.660) Cmd: Request Challenge Code [30] recevied..!

Below is a snippet form my prj.conf

# NUS service
CONFIG_BT_NUS=y
#CONFIG_BT_L2CAP_TX_MTU=75
CONFIG_BT_L2CAP_TX_MTU=300
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_GATT_DM=y
CONFIG_BT_MAX_CONN=2
#CONFIG_BT_BUF_ACL_RX_SIZE=79
CONFIG_BT_BUF_ACL_RX_SIZE=300
CONFIG_BT_BUF_ACL_TX_SIZE=300
#CONFIG_BT_CTLR_DATA_LENGTH_MAX=270

I did try to increase BT_CTLR_DATA_LENGTH_MAX, it didn't seem to have an affect on negotiated MTU value, so I ;eft it at default (which apparently is 27

RE: BLE RX error Unexpected L2CAP continuation

Kenneth — Thu, 06 Feb 2025 21:27:46 GMT

It surprise me that you have CONFIG_BT_CTLR_DATA_LENGTH_MAX=27, since that will severely limit the throughput and increase fragmentation. Is there any reason why you have kept it as 27? Or maybe you just weren't aware of it.

Kenneth

RE: BLE RX error Unexpected L2CAP continuation

Alex_S@Aperia — Thu, 06 Feb 2025 16:19:06 GMT

Uploaded compressed .config as zip file.

RE: BLE RX error Unexpected L2CAP continuation

Alex_S@Aperia — Thu, 06 Feb 2025 16:12:42 GMT

Yeah, DevZone website keeps rejecting .config file, not sure why

RE: BLE RX error Unexpected L2CAP continuation

Kenneth — Thu, 06 Feb 2025 15:01:29 GMT

For some reason the .config was not attached, but you can place it in a zip files with the sniffer trace. I think it will be difficult to understand what is failing without the sniffer file in any case. If it only fails with a specific central device, it could be somewhat related to how data is fragmented on-air, though I am not aware of any issue.

Kenneth

RE: BLE RX error Unexpected L2CAP continuation

Alex_S@Aperia — Wed, 05 Feb 2025 17:19:35 GMT

Hi Kenneth,

The problem is hard to reproduce so it might be a bit problematic to capture it on sniffer, but I'll try, I do have nRF sniffer (nRF52840 DVK).

> Btw, does this happen with specific central devices?
Now that you mentioned it...
I do have several kinds of devices acting as central (all impplementing same file transfer protocol)
- Custom board based on Analog Devices Maxim 32690 MCU
- Mobil phones (all kinds)
- Seed Studio Xiao BLE device nrf52840 based
So far, I was able to reproduce the problem with Maxim board only, but that could be because it is the most used...

Attaching .config

RE: BLE RX error Unexpected L2CAP continuation

Kenneth — Wed, 05 Feb 2025 09:46:26 GMT

Hello,

Interesting, I can't find any obvious reason for this.

Are you able to provide an on-air sniffer log of when this situation occurs? You can just do a abrupt soft reset when the issue occurs, so it may be easier to know exactly where it occurred. You can for instance use the nRF sniffer for BLE and send us the .pcapng file from Wireshark if possible.

Btw, does this happen with specific central devices? Can you send us the .config from the build folder also?

Kenneth