Fragmentation and Recombination of L2CAP PDUs - first fragment size is less than (sizeof*l2cap_hdr) - packet dropped though valid (?)

[shachar-limor]

Hi,
I have a real life case, android app sending high throughput WriteNR packets to a ESP32-S3 device.
Using MTU=323 (for desired user data payload of 320).
Running BLE5 in LE 1M mode.
The android device is pushing the packets through very aggressively, basically as fast as possible.
Every once in a while, on certain android devices the L2CAP is fragmented such that the first fragment is only 3 bytes long.
I believe this is valid in accordance to BLE spec, even the illustration in the core spec shows the CID cut in the border between the first and second fragments..

In ble_l2cap.c ble_l2cap_rx() it is assumed that always the first fragment includes at least 4 bytes with ble_l2cap_hdr, otherwise the complete recombined packet is consumed but dropped.

I believe the fragmentation is correct and the implementation in ble_l2cap.c is incorrect in this corner case, the header parsing should be done only after enough fragments with a full ble_l2cap_hdr are received.

Attached are HCI logs (data truncated to max 10 bytes to avoid log overflow) and the BLE core capture. Also some additional printouts I added.

Any thoughts from the experts? Is this a valid scenario? Wrong doing by the android or by the NIMBLE stack?

Shachar

capture_hci_odd_sized_DataPacketSmokingGun3_FirstFragmentSize3snippet.txt

[andrzej-kaczmarek]

That's indeed an issue in NimBLE host. I created a draft PR that reworks L2CAP RX routine and it should also fix this problem: #2022.

It seems to work fine with simple apps like bleprph so you can give it a try, but we'll need some more testing before it gets merged anyway.

[shachar-limor]

Thanks @andrzej-kaczmarek , I will hopefully also review the draft PR from my side in the next few days.

[shachar-limor]

Well, @andrzej-kaczmarek seems that I am unable to cherry pick and verify this on my level (my ESP32-S3 sdk is based off nimble_1_7_0_tag and there are too many changes to reliably pull these specific commits ).
So I will have to wait for the next "official" release /tag and verify it then.
Can you say when is the next tag planned? Are these done on a timely basis (every X months?) or per need?

[andrzej-kaczmarek]

@shachar-limor I rebased my code to 1.7.0, you can try to cherry-pick from this branch: https://github.com/andrzej-kaczmarek/apache-mynewt-nimble/tree/l2cap-rx-rework-170

As for the next official tag, we don't have anything planned yet. We try to do them every few month depending on the progress in development but it varies.

[shachar-limor]

Hi @andrzej-kaczmarek ,
Thanks for your continued help.
I wrestled with this rebase / cherry picking but it seems I am unable to converge with this process.
I will have to wait for the next official tag, whenever it comes.
Assuming this draft PR passed the necessary release gates then please merge and release it whenever possible.
Thanks,
Shcahar