wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
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 */
>> 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))

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...


  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 FreeBSD if_wg POINTTOPOINT and MULTICAST behaviour 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:

* 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 \


* 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).