tests: gnrc_ipv6_ext_frag: various fixes#21935
Conversation
… ends Otherwise the match below might fail spuriously
Otherwise the test just crashes when packet buffer runs full.
miri64
added
Type: bug
miri64
changed the title
miri64
changed the title
mguetschow
left a comment
mguetschow
left a comment
There was a problem hiding this comment.
I can confirm the test succeeds now and the segmentation fault could not be reproduced with make -C tests/net/gnrc_ipv6_ext_frag/ -j BOARD=native64 clean flash cleanterm and udp send fe80::c094:a8ff:fedb:73a8%6 20908 5950 anymore (same for native32 and 6000) as reported in #21931 (comment).
However, the other behavior is still present, where RIOT would report success, but actually only send out one or even no IPv6 fragment for some UDP payload lengths. Should we split that out into a separate issue?
That's expected. Unless you specifically ask GNRC, it does not report any errors back to the application on sending. For the sizes you reported in #21931 (comment), it is to be expected, that at some point the packet buffer just runs full and the packet is discarded en-route through the stack. Since |
native64 has sizeof(size_t) == 8 and sizeof(void *) == 8 instead of 4, so we need more slack for that board.
miri64
force-pushed
the
tests/fix/gnrc_ipv6_ext_frag+native64
branch
from
2c09890 to
3505533
Compare
| if BOARD in ["native64"]: | ||
| # size_t and pointers are 4 bytes larger in 64-bit architectures, so add some | ||
| # more slack per snip, since they are larger | ||
| slack += 96 |
There was a problem hiding this comment.
How does this work - the python scrip manages to overflow a buffer in the RIOT application?
There was a problem hiding this comment.
In this case, the python script uses the udp command, provided by the application with a large payload (in the udp_send function called below). This way the buffer is overflown.
True, forgot that. Confusing for newcomers, I guess, but well :) |
|
Backport provided in #21939 |
6 participants
Contribution description
Fixes #21931. Only the test was broken, not the implementation 😌
Testing procedure
Should now succeed (sometimes there is a timing issue where a regex is not caught properly, but rerunning the test should work).
Issues/PRs references
Fixes #21931.