If the fib contains a route to a subnet via another host, it can not
be on-link.
Consider fib entries when deciding whether an address is on-link.
If a route via another host is a stronger match than an on-link
prefix, the address must be off-link.
Sending a RA with ltime = 0 does not get us added to the default router
list, but the options (and therefore the RIO) are still parsed.
This even appears to work with Linux as a receiver.
When the default router was removed or could not be added, `dr` will
be NULL.
In this case, don't cease sending router solicitations - we still don't
have a default router.
Consider the following: A node tries to forward a packet to another
host for which it does not know the route yet. It assumes it to be
on-link and starts a neighbor solicitation, putting the node address
in the destinatio cache.
Later the route is known (via a second hop) but the host is still in
the NIB.
The result is that gnrc_ipv6_nib_get_next_hop_l2addr() ends up in the
"nib: %s is in NC or on-link, start address resolution" case and does
not attempt to resolve the route.
This results in the host remaining unreachable even though now a route
is present.
If a node has two interfaces A with 2001:16b8:45b5:9af8:5884:3bff:fe4f:a903
and B with 2001:16b8:45b5:9afa:5884:3bff:fe4f:a902 and receives a neighbor
solicitation on A for an address configured on interface B, answer the neighbor
solicitation instead of bailing out with
> Target address 2001:16b8:45b5:9afa:5884:3bff:fe4f:a902 is not assigned
> to the local interface
This option was unused before, honor it to make it possible to start
with router advertisements disabled and enable them at run time.
The defaults remain unchanged by that.
If we switch the interface in gnrc_ipv6_nib_get_next_hop_l2addr()
we must also re-get the nib entry from the 'proper' interface.
Otherwise we will always find the host unreachable on the 'wrong'
interface.
Consider the following configuration:
nib prefix
2001:16b8:4569:88fc::/62 dev #7 expires 7081 sec deprecates 3481 sec
2001:16b8:4569:88fe::/63 dev #6
If `_on_link()` stops at the first match, a packet received from #7 with a
destination in the downstream subnet in #6 would always be sent back via #7
if this happens to be the first entry in the list.
Instead, consider all prefixes and return the one that is the closest match.
When two threads use `gnrc_ipv6_nib_get_next_hop_l2addr()` to determine
a next hop (e.g. when there is both an IPv6 sender and a 6LoWPAN
fragment forwarder), a race condition may happen, where one thread
acquires the NIB and the other acquires the network interface resulting
in a deadlock. By releasing the NIB (if acquired) before trying to
acquire the network interface and re-acquiring the NIB after the network
interface is acquired, this is fixed.
Non-routing 6LNs do not have to join the solicited nodes address, so
probing for a neighbor using that address may be in vain and only
spamming the LLN with unnecessary messages. RFC 6775 basically assumes
this in section 5.2:
> There is no need to join the solicited-node multicast address, since
> nobody multicasts NSs in this type of network.
In accordance with RFC 6775, section 5.2 an NCE should be set STALE
when an ARO renews the address registration for the address:
> The routers SHOULD NOT garbage-collect Registered NCEs (see
> Section 3.4), since they need to retain them until the Registration
> Lifetime expires. Similarly, if NUD on the router determines that
> the host is UNREACHABLE (based on the logic in [RFC4861]), the NCE
> SHOULD NOT be deleted but rather retained until the Registration
> Lifetime expires. A renewed ARO should mark the cache entry as
> STALE. Thus, for 6LoWPAN routers, the Neighbor Cache doesn't behave
> like a cache. Instead, it behaves as a registry of all the host
> addresses that are attached to the router.
When `nce` is NULL on the duplicate check, the later re-fetching of the
`nce` might result in an actual NCE entry that then contains a
duplicate, so we need to re-check the EUI-64 again as well.
This changes the prefixes of the symbols generated from USEMODULE and
USEPKG variables. The changes are as follow:
KCONFIG_MODULE_ => KCONFIG_USEMODULE_
KCONFIG_PKG_ => KCONFIG_USEPKG_
MODULE_ => USEMODULE_
PKG_ => USEPKG_
Replace direct accesses to sched_active_thread and sched_active_pid with
the helper functions thread_getpid() and thread_get_active(). This serves
two purposes:
1. It makes accidental writes to those variable from outside core less likely.
2. Casting off the volatile qualifier is now well contained to those two
functions
