l2cap packet fragment

RE: l2cap packet fragment

chiba — Fri, 17 May 2019 06:35:17 GMT

Thank you for copying

I was also investigating.
All I feel is that the context of tx_func () affects it.
Calling tx_func () in the BLE_L2CAP_EVT_CH_TX handler reduces the likelihood of fragmentation.
Conversely, calling tx_func () in a timer handler increases the possibility of fragmentation.

RE: l2cap packet fragment

Stian Røed Hafskjold — Thu, 16 May 2019 11:26:59 GMT

I was able to reproduce this. Seems like this is how the link layer packets are buffered in the softdevice. If the buffer size is not a multiple of the link layer packet, the last packet going into the buffer will be split in order to optimize the buffer usage. Unfortunately I don't think there's much to do about this, it's not really violating the BLE spec. You can try to set the data payload to 122 bytes. At least when I tested it seemed like the packets did not split. Anyways, event though the packets split, they are still sent during the same connection interval, so it shouldn't really make any difference to the total throughput.

RE: l2cap packet fragment

chiba — Thu, 25 Apr 2019 05:09:24 GMT

Hi Stian,

thnkyou your reply.

The L2CAP MTU and MTS are 247.

Previous packet is not fragmented.

Please attach the captured data of wireshark, so please have a look.

devzone.nordicsemi.com/.../1234.l2cap_5F00_fragment.pcapng

RE: l2cap packet fragment

Stian Røed Hafskjold — Wed, 24 Apr 2019 12:42:01 GMT

If the payload is bigger than the LE data packet length (minus L2CAP header) the payload will be split over more than one packet. The data length is negotiated between the peripheral and central device, so this is implementation specific.