While 485dbd1fda (from #12175) was right
in assuming that the for most ICMPv6 error messages the originating
packet's destination address must not be a multicast, this is not the
case for _all_ ICMPv6 error messages (see [RFC 4443], section 2.4(e.3)).
Additionally, 485dbd1fda removed the
check for the source address ([RFC 4443], section 2.4(e.6)), which this
PR re-adds.
[RFC 4443]: https://tools.ietf.org/html/rfc4443#section-2.4
Some platforms issue this:
tests/pkg_fatfs/main.c: In function '_mkfs':
tests/pkg_fatfs/main.c:355:26: error: '%d' directive writing between 1 and 11 bytes into a region of size 8 [-Werror=format-overflo
w=]
355 | sprintf(volume_str, "%d:/", vol_idx);
| ^~
tests/pkg_fatfs/main.c:355:25: note: directive argument in the range [-2147483648, 0]
355 | sprintf(volume_str, "%d:/", vol_idx);
| ^~~~~~
tests/pkg_fatfs/main.c:355:5: note: 'sprintf' output between 4 and 14 bytes into a destination of size 8
355 | sprintf(volume_str, "%d:/", vol_idx);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
The cause is vol_idx being converted by atoi(), so it might be negative.
This commit increases the stack array so it cannot overflow.
- When running `BUILD_IN_DOCKER=1 make -C tests/riotboot test`
new slot binaries (fw + hdr) need to be generated.
`%.bin: %.elf` is no defined when building in docker, so the
fw binaries $(SLOT_RIOT_ELFS:%.elf=%.bin) are added to
BUILD_FILES
The description states that the tests caused issues with an ancient
toolchain.
Building these tests locally worked fine.
So remove the obsolete BOARD_INSUFFICIENT_MEMORY lists.
`-Watomic-alignment` warns when C11 atomics have to be implemented via a to one
of the functions in `core/atomic_c11.c`. Unlike to the context of Desktop or
Server class machines, the performance penalty of this calls is insignificant
(and not existing with LTO). So this is not an issue in our context.
On the other hand: Keeping `-Watomic-alignment` prevents building applications
using C11 atomics on all platforms the atomic operations are not implemented
without calls to `core/atomic_c11.c` (due to `-Werror`), reducing portability.
So not only does the warning is not useful in our context, it actually prevents
portable use of C11 atomics. It is the most sensible thing to just disable it.
Rather than dispatching the packet automatically once it is complete,
`gnrc_sixlowpan_frag_rb_add()` now only returns success, and leaves it
to the caller to dispatch the packet.
