Description

Although the problems described in issue #10672 were solved, there seem to be further problems that occur on heavy load, at least for ESP-NOW:

1. sometimes 6Lo fragments are kept in the packet buffer
2. a single ping with no data is not possible after heavy load with ping timeouts

Steps to reproduce the issue

Precondition:

• Test with two ESP32 nodes, one pinging and one answering.
• Test with heavy traffic and ping timeouts executed:

  ping6 1000 fe80::32ae:a4ff:fe18:7a3d 1232 0
  

• Packet buffers on both sides are empty after the test!

Send one single small ping:

ping6 1 fe80::32ae:a4ff:fe18:7a3d

On air, we can dump the following WiFi frame

0040   ** ** ** ** dd 3b 18 fe 34 04 01 01 41 60 00 00
0050   00 00 0c 3a 40 fe 80 00 00 00 00 00 00 32 ae a4
0060   ff fe 41 60 f9 fe 80 00 00 00 00 00 00 32 ae a4
0070   ff fe 18 7a 3d 80 00 52 cc 00 54 00 01 58 58 58
0080   58

where dd 3b 18 fe 34 04 01 01 is the ESP-NOW header including the one byte esp_now_header_t.

On answering node this leads to

6lo rfrag: entry 0x3ffbc53c (30:AE:A4:41:60:F9, 30:AE:A4:18:7A:3D, 1280, 49) created
6lo rfrag: add interval (1200, 1279) to entry (30:AE:A4:41:60:F9, 30:AE:A4:18:7A:3D, 1280, 49)