The macros CONCAT(), MIN(), and MAX() are defined over and over again in
RIOT's code base. This de-duplicates the code by moving the macros to a
common place.
Since `min(a,b)` is a very frequently used function, several libraries such as ESP8266 SDK define a `MIN` macro in their header files. Therefore the `MIN` macro should be undefined before its definition to avoid compilation errors if it is defined anywhere else before.
While 485dbd1fdac9c965c1f734b1dda711b35bb4ac1a (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, 485dbd1fdac9c965c1f734b1dda711b35bb4ac1a 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
before this commit the src address was checked for multicast, but the dst address should be checked. Therefore udp multicast packets would be flooded back to the src as ICMPv6 error, as not all nodes had a UDP receiver registered.
Once the packet buffer is full on heavy network load, gnrc_netif_hdr_build may return NULL. In that case, the following unchecked access to hdr->data leads to a crash.
Check for:
- if it exists (critical error condition -- non-IPv6 headers should
not trigger these functions) => assert
- if it has a multicast source (that shouldn't really happen but
people might try weird stuff ;-)
- if it has an unspecified source (can't determine receiver of error
message => don't send it, don't build it)
At the moment ping is crashing if one pings the loopback address.
This was caused in #8214 when we moved interfaces from `kernel_pid_t`
ID to pointer-based handling, since loopback doesn't evaluate to such
an interface.
