L2CAP data gets truncated if MTU is larger than 245 bytes

[fbzhomi]

Hi Folks,
Currently I am running on Zephyr 3.2 at a vendor specific platform and create an application to run BLE L2CAP stress TX test. I found an issue that when the applications tries to send a L2CAP SDU data with 2000 bytes which is beyond 245 bytes(a full L2CAP complete packet size) data via zephyr API bt_l2cap_chan_send call every 15ms, device has a chance to send a corrupted L2CAP data over the air. The symptom is like whole trunk of L2CAP start traffic is missing, and L2CAP continue packet becomes the first L2CAP packet to the air and when remote device received the corrupted L2CAP data, it wrongly consider L2CAP continue to be L2CAP start and try to parse L2CAP SDU length field and complains about invalid SDU length, then force disconnect the L2CAP channel.

My current prj.conf for L2CAP setting are
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_L2CAP_TX_MTU=2000
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_TX_COUNT=255

I can reproduce this issue in two platforms using Zephyr 2.3 and Zephyr 3.2 so it seems like a bluetooth host issue in subsys of Zephyr.
I was wondering that if Zephyr stack has been running L2CAP stress test per each version upstreams. I check the L2CAP shell zephyr/subsys/bluetooth/shell/l2cap.c only support 230 bytes L2CAP SDU and only support single TX via CLI instead of TX stress test. So it might be a mis-coverage.

[hermabe]

@jori-nordic You looked at L2CAP throughput testing a bit ago, did you test this?

Anyway, this looks like a stack issue, so converting this ta an issue.