[Babel-users] Babel MAC auth fails due to packet reordering

[Juliusz Chroboczek]

> > 1. Are you running with the "unicast" option set in your config file?
> 
> Aaah turns out I was, because I had it set in `default` for my wireguard
> links.
> 
> Adding `interface enpxx unicast false` magically fixes this. According to
> the docs this skips sending a duplicate hello to neighbours which would
> explain why it works.

Not quite.  Babel has three kinds of TLVs:

  - Discovery Hellos, which are always sent over multicast;
  - requests, which are always sent over unicast;
  - the bulk of the protocol, which may be sent either over multicast or
    unicast.

The unicast option controls whether the bulk of the protocol is sent over
multicast (unicast off) or sent to each peer over unicast (unicast on).
In your case, Babel was sending

  Hello multicast
  IHU unicast

The Hello and the IHU were getting reordered, so the Hello was getting
dropped due to an incorrect packet counter value.  With "unicast false",
Babel is sending a single aggregated Hello+IHU over multicast, so no
reordering can happen.

We still need to understand why you're getting systematic packet
reordering.  If it's something that cannot be avoided, then we will need
to update the HMAC implementation (and spec!) to maintain a replay window,
in the style of

  https://datatracker.ietf.org/doc/html/rfc4303#section-3.4.3

> Where are you getting the 200ms number from exactly?

Here:

  10:24:31.056310 IP6 fe80::1.6696 > fe80::c23c:59ff:fe4a:ce46.6696
  Router Id 02:0d:b9:ff:fe:4e:90:54
  Update/prefix...
  PC value 57567 index len 8

  10:24:31.257774 IP6 fe80::1.6696 > ff02::1:6.6696
  Hello seqno 36696 interval 4.00s
  PC value 57566 index len 87

It's suspiciously close to 200ms (201.5ms exactly).  Toke, you're the
world specialist of the Linux WiFi stack -- do you see a hardwired 200ms
delay somewhere?

-- Juliusz