The interface is already fetched in the beginning of the function and
doesn't change during its run, so getting the interface again at this
point is just redundant.
When decoding IPHC in a fragmented datagram, relying on the size of the
allocated space for the decoded packet is wrong when fragments are
forwarded and decoded on an intermediate node (for which the reassembly
buffer's space is used): Using the full datagram size for allocation in
this case would be wasteful, so the allocated space is only marginally
larger than the fragment's compressed form.
This in turn results in the wrong UDP payload size being chosen and
even worse being forwarded to the subsequent nodes.
This change uses the (virtual) reassembly buffer's `datagram_size`
instead of relying on the allocated space for the encoded
datagram/fragment.
This module was intended to be a test framework for GNRC but it never
really got used. It was not maintained for 3 years. It will be removed
after 2020.07 release at the latest.
Added a header to allow defining C interfaces using the default C11 atomic
types. Those types are however fully opaque and inaccessible from C++, as C11
atomics are completely incompatible with C++.
`_match_to_idx()` was removed from source address selection (which was
the only one setting the filter parameter to a non-NULL value), so it
is the parameter is not needed anymore.
When source address selection is done, both RFC and comments in the code
state, that a longest prefix match should *only* be used as a
tie-breaker between more than one viable candidate. If there is only one
address, there is
a) no need for a tie-breaker
b) in the case of either the destination address or the single remaining
address being ULAs ([which are considered to be of global scope]
[RFC4193]) possibly not matching, as `fd00::/7` and e.g. `2001::/8`
do not have a common prefix.
(b) in fact causes the match function to return -1, causing the source
address selection to return -1, causing the outer function to return the
first address it found (which most often is the link-local address),
causing e.g. a ping to an ULA to fail, even is there is a global
address.
[RFC4193]: https://tools.ietf.org/html/rfc4193
Different platforms evaluate `printf()` for NULL pointers differently,
resulting tests checking for a certain output to fail. This unifies that
(debug) output for the static packet buffer statistics.
This adds an early exit when the usb interface with the data endpoints
is not activated. This prevents the cdc_ecm_netdev code from attempting
to send the PDU when the USB device is not yet initialized or activated
by a host.
Similar as with #12513, when the NIB is compiled in 6LN mode (but not
6LR mode), the address-resolution state-machine (ARSM) functionality is
disabled in favor of the more simpler address resolution proposed in RFC
6775.
However, if a non-6LN interface is also compiled in (without making it
a router or border router) it will never join the solicited-nodes
multicast address of addresses added to it, resulting in address
resolution to that interface to fail.
If the interface is not a 6LN (which in case 6LN mode is disabled is
always false), a warning is now printed, encouraging the user to
activate the ARSM functionality if needed.
The OUT endpoint of the cdc ecm data endpoint is only expected to
receive data when the alternative interface is activated. Signalling
ready in the init function can cause issues as the endpoints are not yet
enabled in the low level USB peripheral driver.
Previously `ifconfig` would only know link-local addresses
(printed as 'local') and everything else would be 'global'.
This is wrong for site-local and unique local addresses which were
also denoted as global.
So use the already existing helper functions to determine the correct
type of IPv6 address when printing.
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
Arduino libraries often include Arduino.h. For source code compatibility this header file is required. Header guards in file arduino.hpp had to be renamed.
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
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.
