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 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)
This adds a driver for the SPI based AT86RF215 transceiver.
The chip supports the IEEE Std 802.15.4-2015 and IEEE Std 802.15.4g-2012 standard.
This driver supports two versions of the chip:
- AT86RF215: dual sub-GHz & 2.4 GHz radio & baseband
- AT86RF215M: sub-GHz radio & baseband only
Both radios support the following PHY modes:
- MR-FSK
- MR-OFDM
- MR-O-QPKS
- O-QPSK (legacy)
The driver currently only implements support for legacy O-QPSK.
To use both interfaces, add
GNRC_NETIF_NUMOF := 2
to your Makefile.
The transceiver is able to send frames of up to 2047 bytes according to
IEEE 802.15.4g-2012 when operating in non-legacy mode.
Known issues:
- [ ] dBm setting values are bogus
- [ ] Channel spacing for sub-GHz MR-O-QPSK might be wrong
- [ ] TX/RX stress test will lock up the driver on openmote-b
`netopt_state_t` is an enumeration type which is not necessarily 1 byte. If `uint8_t` is used, the cast `*((const netopt_state_t*) val` in `sx127x_netdev::_set`tries to read the real size, which can be more than the given length of 1 byte. Therefore, `netstat_opt_t` has to be used instead of `uint8_t`
This updates (or adds) a compression context whenever a new prefix
arrives at the border router. This allows 6LoWPAN to compress said
prefix in the network.
Sadly, there is now way to just remove the context when the prefix is
overwritten, so I do not do it. If an administrator chooses to reset the
prefix they can use `6ctx del` which timeouts the prefix appropriately,
but IMHO it doesn't hurt to keep the old contexts.
The reassembly buffer only needs (and stores) the headers *before* the
fragment header (called per-fragment headers in RFC 8200, section 4.5).
Currently, when a subsequent IPv6 fragment is received before the first
fragment the fragment header is however not removed. With this fix it
does.
The comment exists since the introduction of the [original
implementation], but its meaning is unclear and misleading, as the code
doesn't do anything with link-local.
[original implementation]: https://github.com/RIOT-OS/RIOT/pull/3561
Rule 2 of the source address algorithm outlined in [RFC6724] states the
possible source addresses must also be compared among each other:
> Rule 2: Prefer appropriate scope.
> If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
> otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If
> Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
Our current implementation doesn't do that. It just checks if the scope
of a possible source is lesser than the scope of the destination
(which involves the second "If" in the rule).
This fix grants points according to the scope of an address. If the
scope matches, they get the highest points, ensuring that the selected
source will always be reachable from the destination.
[RFC6724]: https://tools.ietf.org/html/rfc6724
