From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Stefan Haller <stefan.haller@stha.de>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: FreeBSD if_wg POINTTOPOINT and MULTICAST behaviour
Date: Thu, 15 Apr 2021 14:22:38 +0200 [thread overview]
Message-ID: <87czuvka9d.fsf@toke.dk> (raw)
In-Reply-To: <7be52421-db0d-4971-99b0-ce76307d1a33@stha.de>
Stefan Haller <stefan.haller@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
next prev parent reply other threads:[~2021-04-15 12:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-14 18:43 Stefan Haller
2021-04-14 20:24 ` Jason A. Donenfeld
2021-04-14 21:50 ` Stefan Haller
2021-04-14 22:14 ` Toke Høiland-Jørgensen
2021-04-15 4:30 ` Jason A. Donenfeld
2021-04-15 9:42 ` Toke Høiland-Jørgensen
2021-04-15 11:36 ` Stefan Haller
2021-04-15 12:22 ` Toke Høiland-Jørgensen [this message]
2021-04-15 17:22 ` Jason A. Donenfeld
2021-04-15 17:53 ` Toke Høiland-Jørgensen
2021-04-16 0:05 ` Jason A. Donenfeld
2021-04-16 8:57 ` Stefan Haller
2021-04-16 9:35 ` Toke Høiland-Jørgensen
2021-04-19 18:25 ` Toke Høiland-Jørgensen
2021-04-19 19:41 ` Stefan Haller
2021-04-19 19:42 ` Jason A. Donenfeld
2021-04-19 19:49 ` Stefan Haller
2021-04-19 21:46 ` Toke Høiland-Jørgensen
2021-04-16 12:14 ` Muenz, Michael
2021-04-16 15:17 ` Jason A. Donenfeld
2021-04-16 17:45 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czuvka9d.fsf@toke.dk \
--to=toke@toke.dk \
--cc=stefan.haller@stha.de \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).