IPSP (IPv6 over BLE) example stop working after a short time

[jmrua]

Describe the bug
IPSP example after connection crashes after a few exchanged packets. Similar to #5289

Platform

• Zephyr Target
  • Nordic nRF52840
  • Zephyr OS build v3.1.0-rc2-113-g449516c1359f
• Host
  • Linux Kernel 5.17.9

To Reproduce

1. Flash the target with the master branch IPSP example
2. Execute the following commands with root privileges on Linux host:

 modprobe bluetooth_6lowpan
 echo "connect  <nRF MAC> <type>" > /sys/kernel/debug/bluetooth/6lowpan_control
 ip address add 2001:db8::2/64 dev bt0

3. execute anything to send a few packets to the nRF, for example a ping

ping -I bt0 2001:db8::1

Impact
After 10 packets received, the connection will crash and the nRF board will not be able to reconnect to the host until a reset of the board is performed.

Logs

• After step 2:
  • nRF:

   *** Booting Zephyr OS build v3.1.0-rc2-113-g449516c1359f  ***
[00:00:00.261,657] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.261,688] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.261,718] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 3.1 Build 0
[00:00:00.262,603] <inf> bt_hci_core: Identity: FA:72:B3:E5:CB:DF (random)
[00:00:00.262,634] <inf> bt_hci_core: HCI: version 5.3 (0x0c) revision 0x0000, manufacturer 0x05f1
[00:00:00.262,664] <inf> bt_hci_core: LMP: version 5.3 (0x0c) subver 0xffff
[00:00:00.263,183] <inf> net_config: Initializing network
[00:00:00.263,336] <inf> net_config: Waiting interface 1 (0x200018b0) to be up...
[00:00:05.465,606] <inf> net_config: Interface 1 (0x200018b0) coming up
[00:00:05.466,125] <wrn> bt_l2cap: No credits to transmit packet
[00:00:05.466,247] <inf> ipsp: Run IPSP sample
[00:00:05.466,888] <inf> ipsp: Starting to wait
[00:00:05.566,436] <inf> net_config: IPv6 address: 2001:db8::1

• After step 3:
  • Host:

$ ping -I bt0 2001:db8::1
PING 2001:db8::1(2001:db8::1) from 2001:db8::2 bt0: 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=375 ms
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=75.8 ms
64 bytes from 2001:db8::1: icmp_seq=3 ttl=64 time=73.9 ms
64 bytes from 2001:db8::1: icmp_seq=4 ttl=64 time=71.8 ms
64 bytes from 2001:db8::1: icmp_seq=5 ttl=64 time=70.6 ms
64 bytes from 2001:db8::1: icmp_seq=6 ttl=64 time=68.9 ms
64 bytes from 2001:db8::1: icmp_seq=7 ttl=64 time=67.6 ms
64 bytes from 2001:db8::1: icmp_seq=8 ttl=64 time=115 ms
64 bytes from 2001:db8::1: icmp_seq=9 ttl=64 time=64.2 ms
64 bytes from 2001:db8::1: icmp_seq=10 ttl=64 time=63.5 ms
//After this the connection is lost

• nRF:

[00:02:44.514,892] <wrn> bt_l2cap: No credits to transmit packet
[00:02:44.665,832] <wrn> bt_l2cap: No credits to transmit packet
[00:02:44.668,579] <wrn> bt_l2cap: No credits to transmit packet
[00:02:54.515,747] <wrn> bt_l2cap: Unable to allocate TX context
[00:02:54.515,777] <err> net_bt: Unable to send packet: -105

• Trying to reconnect after step 3:
  • nRF:

[00:10:47.508,728] <wrn> bt_l2cap: Unable to allocate TX context
[00:10:47.508,728] <err> net_bt: Unable to send packet: -105
[00:10:47.608,917] <inf> net_config: IPv6 address: 2001:db8::1

[jmrua]

After performing some tests, it seems that the problem may be due to the saturation of the L2CAP transmission buffer, modifying CONFIG_BT_L2CAP_TX_BUF_COUNT it seems that, although it still does not work correctly, it can receive and send more packets before blocking.

With CONFIG_BT_L2CAP_TX_BUF_COUNT=128 blocks after over 200 packets.

[kruithofa]

@alwa-nordic please see if you can reproduce this behaviour

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.