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>,
	WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: FreeBSD if_wg POINTTOPOINT and MULTICAST behaviour
Date: Thu, 15 Apr 2021 00:14:04 +0200	[thread overview]
Message-ID: <874kg8ldjn.fsf@toke.dk> (raw)
In-Reply-To: <87371254-15f1-494b-8740-38071d7f7d68@stha.de>

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

> Hi Jason,
>
> Thanks for your clarification. I understand that setting this flag would
> be a false promise to userspace, because generally Wireguard is
> point-to-multipoint and doesn't copy messages to multiple peers (which
> is not exactly necessary in my case, where only a single peer is
> configured on both sides).
>
> I just wanted to ensure that the introduced change was intentional
> before looking into other directions, hence my question.
>
> On Wed, Apr 14, 2021 at 02:24:20PM -0600, Jason A. Donenfeld wrote:
>> Does bird completely ignore interfaces without it? Is there no setting
>> to change that?
>
> At least a brief look at the code suggests this: [1]
>
> The Babel protocol seems to rely on well-known *link-local* IPv6
> multicast addresses. I did not find anything related to unicast "hello"
> messages in the RFC or in the implementations. (OSPF is similar, but
> as far as I remember unicast hellos are explicitly allowed.)
>
> One odd thing I noticed: On Linux (5.11.13-arch1-1, so quite recent),
> the interface does not list the MULTICAST flag and the interface is
> still used by bird:
>
> # ip l show dev wg1
> 4: wg1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
>
> I will have a closer look why it doesn't work on FreeBSD but the same thing
> works on Linux. I am probably missing something important.

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.

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 :)

Quite happy to review Bird patches if someone wants to hack on this,
BTW, but otherwise it's on my "eventually" list :P

-Toke

  reply	other threads:[~2021-04-14 22:14 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 [this message]
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
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=874kg8ldjn.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).