Note that the previous auto-detection is wrong. IPV6_SUBTREES exists
since (at least?) Linux 2.6.32. On the other side, a recent kernel may
be built without source-based routing.

Our use of this patch is safe because we control entirely with
re6stnet which routes babeld is going to install.

To be pushed upstream.
Co-authored-by: Julien Muchembled <jm@nexedi.com>

TODO: documentation

To be pushed upstream.
Co-authored-by: Julien Muchembled <jm@nexedi.com>

Thanks to andrew-hoff.

It has been reported that some WiFi networks delay multicast
packets by up to 200ms, which breaks the PC check.  Split
the receiver's state into two last PC values, one for multicast
and one for unicast.  This is safe as the destination address
is covered by the MAC.

When something goes wrong with a netlink request, the kernel may return a
human-friendly error message using the 'extack' functionality. This is
opt-in however, so this patch adds parsing and display of such error
messages to the netlink debug output.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>

Use the up-to-date spelling of the OpenWrt project, OpenWRT is
a very old naming convention used in very early times.

This is a remainder from the disambiguation code, which was removed
back in 2020.

We now accept v4-via-v6 routes if the kernel supports installing
them, and announce them if the kernel is able to source ICMPv4
without an IPv4 address.  The latter behaviour is configurable,
the former is not.

A node with no IPv4 addresses may still be able to forward
IPv4 packets.

Its polarity is changed, and it also controls incorrectly signed packets.

Introduced by 3b3813fad09eb694a508789394679b6d3378d472.

It wasn't consistent with the naming of other option. The option is
phrased positively to match the Information Model (babel-mac-verify).

Thanks to Julien Muchembled for finding a bug in a previous version of
this commit.

Nodes with default mac-verify would not accept packets from nodes with
non-default mac-verify.
Co-authored-by: Julien Muchembled <jm@jmuchemb.eu>
Co-authored-by: Antonin Décimo <antonin.decimo@gmail.com>

Don’t call `start_message()` since it may cause an infinite loop.

The exact narration is implemented, with all the specified
optimisations.

- neighbour creation is delayed;
- if multiple PCs are found, only the first one is processed, the
  remaining ones are be silently ignored;
- a node ignores all challenge requests contained in a packet except
  the last one;
- and it ignores a challenge request in the case where it is contained
  in a packet with an Index that matches the one in the Neighbour Table
  and a PC that is smaller or equal to the one contained in the
  Neighbour Table.

s/crypto seqno/pc/g
s/challenge response/challenge reply/g
s/challenge req/challenge request/g