Bluetooth L2CAP TX fragmentation state not cleared upon disconnect

[rugeGerritsen]

Describe the bug
When reconnecting, previous l2cap TX fragmentation state is kept, resulting in that we may send l2cap fragments to the controller without an l2cap header.

To Reproduce

• Run a connection with a long connection interval.
• Set max data length to 27 bytes.
• Send long ATT/L2CAP packets
• Disconnect one of the device
• Reconnect. Observe that the next L2CAP fragment will be sent without header

Setting le_chan._pdu_remaining = 0 in bt_l2cap_chan_del() resolves this issue.

Expected behavior
Upon disconnection all previous state shall be cleared.

Impact
Showstopper

Logs and console output
Logs extracted from a custom test

bt_l2cap: L2CAP: push: pdu 0x819ddc8 len 200 cb 0x8055130 userdata (nil)
bt_l2cap: l2cap_pull: Adding L2CAP PDU header: buf 0x819ddf0 chan 0x8186280 len 200 / 200
app: disconnected: err 13 addr DC:52:5F:AA:9A:74 (random)

app: connected: err 0 addr DC:52:5F:AA:9A:74 (random)
bt_l2cap: L2CAP: push: pdu 0x819ddf0 len 200 cb 0x8055130 userdata (nil)
bt_l2cap: l2cap_pull: Not adding L2CAP header, handling remaining 123

Environment (please complete the following information):
Zephyr 3.7.0

Additional context

The bug was introduced in #72090

[EaselinkBachmann]

This bug led to repeated disconnects in an internal application (same one as in #76738). L2CAP initially works fine, but falls into a loop of connecting and disconnecting once the connection drops for the first time. Error logs:

sender:bt:l2cap: channel connected
[00:00:19.132,690] <err> bt_l2cap: chan 0x200000e8 timeout
[00:00:19.145,019] <wrn> bt_conn: conn 0x20000fc0: not connected
[00:00:19.754,211] <err> bt_conn: Unexpected first L2CAP frame
[00:00:19.755,249] <err> bt_l2cap: SDU length mismatch
sender:bt:l2cap: channel disconnected

The receiving side usually receives an invalid packet when this happens:

[00:01:37.419,250] <wrn> bt_l2cap: Ignoring data for unknown channel ID 0x0040

The fix listed above (Setting le_chan._pdu_remaining = 0 in bt_l2cap_chan_del()) works wonderfully.

[jori-nordic]

So I managed to reproduce the bug.
The thing is, it shouldn't happen:

• internal users of L2CAP (e.g. ATT, SMP) memset the struct bt_l2cap_le_chan object
• applications should always memset that struct when accepting a connection

@EaselinkBachmann What exactly are you doing with L2CAP? I know Rubin is using private APIs.

[EaselinkBachmann]

Okay, that might be it. I have a static global of a `bt_l2cap_le_chan` that I use for creating a single channel that I repeatedly use for connections without memsetting in beyween. I didn't know that users of the L2CAP API were supposed to memset their channels before each connection and assumed that the disconnect logic would leave the channel in a clean state, ready to be reused. It might be that I missed this in the docstring of the relevant functions. I will double-check this tomorrow to verify if this is the case.

[jori-nordic]

missed this in the docstring of the relevant functions

Unless you could see into the future, it wasn't there. So the fault lies with the Host.

Those two should address your issue: #76935 and #76890