FreeBSD if_wg POINTTOPOINT and MULTICAST behaviour

[Toke Høiland-Jørgensen]

Stefan Haller <stefan.haller at stha.de> writes:

> Hi Toke,
>
> On Thu, Apr 15, 2021 at 12:14:04AM +0200, Toke Høiland-Jørgensen wrote:
>> That's because the babel protocol code is checking for Bird's internal
>> MULTICAST flag, which is set like:
>> 
>>   else if (fl & IFF_POINTOPOINT)    /* PtP */
>>     f.flags |= IF_MULTICAST;
>>   else if (fl & IFF_BROADCAST)      /* Broadcast */
>>     f.flags |= IF_MULTIACCESS | IF_BROADCAST | IF_MULTICAST;
>> 
>> so it needs either the OS-level POINTOPOINT or the BROADCAST flag set.
>> Wireguard interfaces on Linux has POINTOPOINT which is enough for Bird.
>
> That explains a lot. I expected something like this, but did not have
> time yet to look more closely.
>
>> And yeah, for now Babel only speaks multicast; the spec does allow for
>> unicast communication, but the code in Bird doesn't implement that yet
>> (I'm the author of the Babel implementation in Bird). Even for unicast,
>> Babel still needs multicast for discovery, but in the case of Wireguard
>> that could be replaced by reading the peers directly from the Wireguard
>> kernel module. Add in updating of Wireguard AllowedIPs, and presto,
>> there's you completely dynamic mesh requiring only a single wg interface
>> on each peer :)
>
> Overall, this sounds like a great idea. Having to create so many
> wireguard p2p tunnels to form a mesh is quite cumbersome. Using
> Wireguards AllowedIPs as an alternative to the kernel routing table
> sounds useful. The peer discovery could also be useful outside of the
> babel protocol implementation (even though it will always be quite
> non-standard). One could probably assume that the first configured
> v6/128 and v4/32 IPs belong to the directly connected peer.
>
>> Quite happy to review Bird patches if someone wants to hack on this,
>> BTW, but otherwise it's on my "eventually" list :P
>
> While I am interested and it sounds like a great opportunity to learn
> cool new things I don't know a lot about yet, I have to see if I am
> actually up to the task. :)
>
> Anyway, I think there is an agreement that it is better to add specific
> support for Wireguard interfaces in bird instead of changing the
> interface flags.

Yeah; in the meantime, you can just patch Bird; just get rid of this
check in proto/babel/babel.c (there are two of them):

    if (!(iface->flags & IF_MULTICAST))
      continue;

should have no ill effects. Actually I think we could just get rid of
that check entirely, it's not strictly needed for anything other than
maybe filtering a very wide glob of interfaces. I'll send a patch...

-Toke