When the NIB is compiled for 6LN mode (but not a 6LBR), the Stateless
Address Autoconfiguration (SLAAC) functionality is disabled, as it is
typically not required; see `sys/include/net/gnrc/ipv6/nib/conf.h`, ll.
46 and 55. However, if a non-6LN interface is also compiled in (still
without making the node a border router) an auto-configured address will
be assigned in accordance with [RFC 6775] to the interface, just
assuming the interface is a 6LN interface. As it then only performs
duplicate address detection RFC-6775-style then, the address then never
becomes valid, as the duplicate address detection according to [RFC
4862] (part of the SLAAC functionality) is never performed.
As auto-configuring an address without SLAAC doesn't make sense, this
fix makes the interface skip it completely, but provides a warning to
the user, so they know what to do.
[RFC 6775]: https://tools.ietf.org/html/rfc6775#section-5.2
[RFC 4862]: https://tools.ietf.org/html/rfc4862#section-5.4
The functions now are semantic distinct:
- gnrc_netif_is_6lo(): the interface is a 6Lo interface
- gnrc_netif_is_6ln(): the interface is using Neighbor Discovery
according to RFC 6775
We want to check if the interface is an interface requiring the 6Lo
adaptation layer, not if it is a 6LN according to RFC 6775 [[1]].
[1]: https://tools.ietf.org/html/rfc6775#section-2
Preparation step to introduce a semantic difference between an
interface being a 6Lo interface and a 6LN according to RFC 6775 [[1]]
(i.e. performs Neighbor Discovery as defined there).
[1]: https://tools.ietf.org/html/rfc6775#section-2
When writing to the IPv6 header the implementation currently doesn't
take the packet with the (potentially) duplicated header, but the
packet with the original one, which leads to the packet sent and then
released in `gnrc_netif_ethernet.c` first and then accessed again in
further iterations of the "writing to the IPv6 header" loop, which
causes access to an invalid pointer, causing a crash.
Fixes#11980
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.
