-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gnrc_icmpv6_echo: flood-pinging another node leads to leaks in own packet buffer #12565
Comments
BTW: when flood pinging from a |
@miri64 have there been any updates on this issue? |
No. |
Interesting side effect:
(3rd ping of this kind in a row in a mesh with 25 native nodes made by desvirt) |
That seems like an easier way of replicating the bug as well. |
The precise network setup is made with desvirts topologycreator running on a Ubuntu 18.04 LTS Notebook. |
After some more debugging I was able to discern that the packets getting lost this way are stuck in the neighbor address resolution packet queue and get stuck there because of the neighbor fails this check every time somehow. RIOT/sys/net/gnrc/network_layer/ipv6/nib/_nib-arsm.c Lines 278 to 283 in f722022
Replacing the |
Description
When flood-pinging another node, some received echo replies might get stuck in the packet buffer
Steps to reproduce the issue
Start two native instances of
tests/gnrc_udp
(forgnrc_pktbuf_cmd
) and flood-ping one from the other. See RIOT-OS/Release-Specs#142 (comment) for a detailed analysisExpected results
The packet buffer should be empty on both nodes afterwards.
Actual results
The packet buffer on the
tap1
instance is filled with echo repliesVersions
Tested with
2019.10-devel
,2019.10-RC2
, and 45ec766 (the commit that introduced the newping6
implementation. All show this behavior, so I believe this is also behaving like this on master.The text was updated successfully, but these errors were encountered: