wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Ondrej Zajicek <santiago@crfreenet.org>
Cc: bird-users@network.cz, wireguard@lists.zx2c4.com,
	Stefan Haller <stefan.haller@stha.de>
Subject: Re: [PATCH] babel: Drop check for IF_MULTICAST interface flag
Date: Mon, 19 Apr 2021 15:55:18 +0200	[thread overview]
Message-ID: <87y2degz09.fsf@toke.dk> (raw)
In-Reply-To: <YH1/umkXjyZ0AjqO@feanor.crfreenet.org>

Ondrej Zajicek <santiago@crfreenet.org> writes:

> On Thu, Apr 15, 2021 at 03:44:50PM +0200, Toke Høiland-Jørgensen wrote:
>> The babel protocol code was checking interfaces for the IF_MULTICAST flag
>> and refusing to run if this isn't present. However, there are cases where
>> this flag doesn't correspond to the actual capability of sending multicast
>> packets. For instance, Wireguard interfaces on FreeBSD doesn't set the
>> required flags, but Babel will run just fine over such an interface given
>> the right configuration.
>
> Hi
>
> Is there a reason why to disregard the IF_MULTICAST flag? This seems to me
> more like a bug in FreeBSD Wireguard implementation that should be fixed
> there. Is this flag properly checked on Linux, or is there some reason why
> the flag is missing?

We did fix Wireguard - see:
https://git.zx2c4.com/wireguard-freebsd/patch/?id=a7a84a17faf784857f076e37aa4818f6b6c12a95

However, that didn't help, Babel still refused to use the interface.
Looking at krt-sock.c, the IF_MULTICAST flag is only set on
IFF_POINTOPOINT or IFF_BROADCAST on bsd. The Linux code (in netlink.c)
has a further:

      if (fl & IFF_MULTICAST)
	f.flags |= IF_MULTICAST;

beneath the other flag checks, so maybe that's really what's missing on
the BSD side?

> Routing protocols in BIRD generally follow this flag (and perhaps use
> it to switch to unicast-only mode), so i do not see why Babel should
> behave differently.

Yeah, I do believe I originally copied that check from one of the other
protocols. I can see how it makes sense to check the flag and change
operation mode based on it, but given that Babel doesn't do that it just
seems kinda redundant? If the interface *actually* is unable to send
multicast packets, the subsequent socket operation is going to fail, and
at least that produces an error message instead of just silently
ignoring the interface like that flag check does :)

-Toke

  reply	other threads:[~2021-04-19 13:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15 13:44 [PATCH] babel: Drop check for IF_MULTICAST interface flag Toke Høiland-Jørgensen
2021-04-19 13:03 ` Ondrej Zajicek
2021-04-19 13:55   ` Toke Høiland-Jørgensen [this message]
2021-04-19 16:32     ` Ondrej Zajicek
2021-04-19 18:24       ` Toke Høiland-Jørgensen

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=87y2degz09.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=bird-users@network.cz \
    --cc=santiago@crfreenet.org \
    --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).