Memory leak from fragmented payload

[nashif]

Reported by Ruslan Mstoi:

Defensics test case #6 ICMPv6.Echo.Echo-Request.IPv6-Packet.payload.protocol.icmpv6-message.icmpv6-echo-request.element

After running this test case echo server has a memory leak:

Fragment length 128 bytes
Network buffer pools:
Name Size Count Avail Address
RX 8000 100 98 0x0011ee4c
TX 8000 100 100 0x0011ee68
RX DATA (rx_bufs) 14800 100 76 0x0011e620
TX DATA (tx_bufs) 14800 100 100 0x0011e5e0

To reproduce, use attached testcase6-replay.pcap , and replay it by:

1. Enable fragmentation in echo_server
2. Set MAC address of echo_server to 10:00:00:00:00:10
3. sudo tcpreplay -i tap0 testcase6-replay.pcap

(Imported from Jira ZEP-2166)

[nashif]

by Ruslan Mstoi:

• qemu.log (size: 99755)

[nashif]

by Ruslan Mstoi:

• testcase6.pcap (size: 10618)

[nashif]

by Ruslan Mstoi:

• testcase6-replay.pcap (size: 9702)

[nashif]

by Mark Linkmeyer:

Jukka Rissanen , can you review the priority and make sure we've set it appropriately?

[nashif]

by Ruslan Mstoi:

I've applied patches from pull request 289: zephyrproject-rtos/zephyr#289

With patches applied after series of large fragmented packets echo_server still suffers from memory leak.

I've attached files from test case ICMPv6.Echo.Echo-Request.IPv6-Packet.payload.protocol.icmpv6-message.icmpv6-echo-request.element - 20, named with prefix icmpv6-echo-20

If you replay icmpv6-echo-20-replay.pcap serveral times echo_server will run out of memory and print error messages:

[net/net_pkt] [DBG] net_pkt_print: (0x001[net/buf] [ERR] net_buf_alloc_debug: net_pkt_get_reserve_data_debug():352: Failed to get free buffer
[slip] [ERR] slip_input_byte: [0x00120100] cannot allocate data fragment

and "net mem" will show:

shell> net mem
Fragment length 128 bytes
Network buffer pools:
Name Size Count Avail Address
RX 8000 100 94 0x0011fc0c
TX 8000 100 100 0x0011fc28
RX DATA (rx_bufs) 14800 100 36 0x0011f3e0
TX DATA (tx_bufs) 14800 100 100 0x0011f3a0

Note that the same error messages appear in attached log file, when running this test case once

[nashif]

by Ruslan Mstoi:

• icmpv6-echo-20.pcap (size: 36519)

[nashif]

by Ruslan Mstoi:

• icmpv6-echo-20-qemu.log (size: 175370)

[nashif]

by Ruslan Mstoi:

• icmpv6-echo-20-replay.pcap (size: 34585)

[nashif]

by Jukka Rissanen:

By default the IPv6 fragmentation is disabled so the medium priority is ok in this respect. This issue will be fixed of course.

[nashif]

by Jukka Rissanen:

Found the culprit, the static initialization of reassembly timer did not work as expected which was then seen as a memory leak.
A new version of PR #289 is sent for review zephyrproject-rtos/zephyr#289

[nashif]

by Ruslan Mstoi:

It seems there is still a memory leak with the new version of PR#289

Test case replayed several times by:
for((i=1; i<=20; i++)); do tcpreplay -i tap0 icmpv6-echo-20-replay.pcap ; done

shell> net mem
Fragment length 128 bytes
Network buffer pools:
Name Size Count Avail Address
RX 8000 100 92 0x0011fc4c
TX 8000 100 100 0x0011fc68
RX DATA (rx_bufs) 14800 100 12 0x0011f4a0
TX DATA (tx_bufs) 14800 100 100 0x0011f460

[nashif]

by Jukka Rissanen:

Indeed there was still an issue with memory handling. This is now fixed in the latest PR#289 version.

[nashif]

by Ruslan Mstoi:

Fixes in pull request solve this issue