shachar-limor opened a new issue, #2020: URL: https://github.com/apache/mynewt-nimble/issues/2020
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](https://github.com/user-attachments/files/19627714/capture_hci_odd_sized_DataPacketSmokingGun3_FirstFragmentSize3snippet.txt)  -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
