We don't want to advertise ourselves as a router to the upstream router.
This also leads to the border router ignoring advertisements from the upstream
router.
In 06aa65e1ba (#10627) a new behavior was
introduced in IPv6 route resolution to try address resolution only at
interfaces that have the prefix of the address to be resolved configured
in the prefix list. This however only makes sense, if the prefix
configured is [on-link], otherwise there is small likelihood of the
address to be resolved being on that link.
For the error case presented for 06aa65e (circular routing at the border
router) this made sense, however within a 6LoWPAN, due to the prefix
being valid for the entire mesh, this leads to the nodes always trying
classic address resolution for in-network addresses instead of just
routing to the default route.
Classic address resolution however fails, as 6LoWPAN hosts typically
[don't join the solicited-node multicast address of their unicast
addresses][6LN-iface-init], resulting in in-network addresses not being
reachable.
As such, to prevent both error cases
- the fallback to address resolution by prefix list must only be used
when the prefix is on-link,
- the prefix configured by DHCPv6/UHCP at the 6LoWPAN border router
must be configured as on-link, but
- the prefix must not be advertised as on-link within the 6LoWPAN to
still be [in line with RFC 6775][RFC-6775-forbidden]
With this change these cases are covered.
[on-link]: https://tools.ietf.org/html/rfc4861#page-6
[RFC 6775]: https://tools.ietf.org/html/rfc6775
[6LN-iface-init]: https://tools.ietf.org/html/rfc6775#section-5.2
[RFC-6775-forbidden]: https://tools.ietf.org/html/rfc6775#section-6.1
When pinging to a prefix for which there is a prefix list entry on the
node (so no next hop) but a default route, a packet to a non-existent
address under that prefix results in the packet being forwarded to the
default route instead. This fixes it, so the node tries address
resolution on the interface the prefix list entry is associated to.
This change amends the `sock` API by a set of functions to `sock` that
allow provisioning of stack-internal buffers to the caller on receive.
This allows to cover two use-cases
1. Zero-copy systems: if the stacks supported the buffer space provided
by these functions can be the same that was filled in the link-layer
2. asynchronous receive within a wrapping sock layer (e.g. `sock_dtls`
wrapping `sock_udp`): to receive packets of the lower level protocol
asynchronously, the wrapping implementation layer would currently
need to allocate its own buffer space, introducing a third buffer
space in addition to the one of the application and the network
stack. For a wrapping layer this is undesirable.
While there are security considerations exposing stack internal memory
space to the caller, I believe they are minor, as in the end the
application developer is the person in control of the node.
This refactors nanocoap to seperate out the resource tree parsing. It
allows for calling the tree handler with custom resource trees. The
advantage is that a resource with COAP_MATCH_SUBTREE can parse a new
separate resource tree.
This is the radio found in NXP Kinetis KW41Z, KW21Z. Only 802.15.4 mode
is implemented (KW41Z also supports BLE on the same transceiver).
The driver uses vendor supplied initialization code for the low level
XCVR hardware, these files were imported from KSDK 2.2.0 (framework_5.3.5)
