GNU bug report logs - #52520
Multicast is off by default

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52520 in the body.
You can then email your comments to 52520 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: Multicast is off by default
Date: Wed, 15 Dec 2021 20:36:06 +0100

Hello,

Since the guile-netlink switch the static IP interfaces no longer have
multicast support. This can be confirmed this way:

--8<---------------cut here---------------start------------->8---
4: eno4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b0:26:28:b7:9d:09 brd ff:ff:ff:ff:ff:ff
5: eno2: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether b0:26:28:b7:9d:0b brd ff:ff:ff:ff:ff:ff
    inet 141.80.181.40/24 brd 141.80.181.255 scope global eno2
       valid_lft forever preferred_lft forever
    inet6 fe80::b226:28ff:feb7:9d0b/64 scope link 
       valid_lft forever preferred_lft forever
--8<---------------cut here---------------end--------------->8---

eno2 that is managed by the static-networking service is lacking
multicast support, while eno4 that is not managed by this service has
multicast support.

This can be adjusted by running:

--8<---------------cut here---------------start------------->8---
ip link set multicast on eno1
--8<---------------cut here---------------end--------------->8---

which immediately fixes Avahi discovery that depends on it.

I think that we could maybe apply the following patch, even though I
didn't test it.

--8<---------------cut here---------------start------------->8---
diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 5f93483dda..af3fe015b9 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -2546,6 +2546,7 @@ (define network-set-up/linux
                                                 #$(network-address-ipv6? address))
                                       ;; FIXME: loopback?
                                       (link-set #$(network-address-device address)
+                                                #:multicast-on #t
                                                 #:up #t)))
                                 addresses)
--8<---------------cut here---------------end--------------->8---

Thanks,

Mathieu

Message #10 received at 52520 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: Julien Lepiller <julien <at> lepiller.eu>, 52520 <at> debbugs.gnu.org
Subject: Re: bug#52520: Multicast is off by default
Date: Fri, 17 Dec 2021 16:15:36 +0100

Hi,

Mathieu Othacehe <othacehe <at> gnu.org> skribis:

> Since the guile-netlink switch the static IP interfaces no longer have
> multicast support. This can be confirmed this way:

[...]

> I think that we could maybe apply the following patch, even though I
> didn't test it.
>
> diff --git a/gnu/services/base.scm b/gnu/services/base.scm
> index 5f93483dda..af3fe015b9 100644
> --- a/gnu/services/base.scm
> +++ b/gnu/services/base.scm
> @@ -2546,6 +2546,7 @@ (define network-set-up/linux
>                                                  #$(network-address-ipv6? address))
>                                        ;; FIXME: loopback?
>                                        (link-set #$(network-address-device address)
> +                                                #:multicast-on #t
>                                                  #:up #t)))

Is it #:multicast-on or #:allmulticast-on ?

Anyhow, I suggest adding a ‘multicast?’ field to <network-address>, with
#t as its default value, and honoring this.

(Someone told me they’d like to set the MTU, so we may need an ‘mtu’
field as well eventually.)

Thanks!

Ludo’.

Message #13 received at 52520 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Julien Lepiller <julien <at> lepiller.eu>, 52520 <at> debbugs.gnu.org
Subject: Re: bug#52520: Multicast is off by default
Date: Sun, 19 Dec 2021 12:08:05 +0100

Hey,

> Is it #:multicast-on or #:allmulticast-on ?

The "ip link set multicast ..." command corresponds to the the
IFF_MULTICAST flag hence to the #:multicast-on parameter.

> Anyhow, I suggest adding a ‘multicast?’ field to <network-address>, with
> #t as its default value, and honoring this.

I'm not sure <network-address> is the right place for this flag. If
there are two <network-address> records in the same list, one for ipv4
and one for ipv6 it means that we need to repeat this flag twice.

Same for the MTU, having different MTU for ipv4 and ipv6 addresses
doesn't have any meaning. The MTU and multicast properties belong to the
device itself.

I think we should introduce a <network-device> record that would gather
the properties that can be passed to the "link-set" method of
Guile-Netlink. The <static-networking> record would point to a unique
<network-device>. We would remove the device field from
<network-address>.

Then each <static-networking> service would provision (concat
'networking- (network-device-name device)) or something like that, to fix
https://issues.guix.gnu.org/52511 as well.

How does that sounds?

Thanks,

Mathieu

Message #16 received at 52520 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 52520 <at> debbugs.gnu.org,
 Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: bug#52520: Multicast is off by default
Date: Mon, 20 Dec 2021 10:29:30 -0500

Hello,

Mathieu Othacehe <othacehe <at> gnu.org> writes:

> Hey,
>
>> Is it #:multicast-on or #:allmulticast-on ?
>
> The "ip link set multicast ..." command corresponds to the the
> IFF_MULTICAST flag hence to the #:multicast-on parameter.
>
>> Anyhow, I suggest adding a ‘multicast?’ field to <network-address>, with
>> #t as its default value, and honoring this.
>
> I'm not sure <network-address> is the right place for this flag. If
> there are two <network-address> records in the same list, one for ipv4
> and one for ipv6 it means that we need to repeat this flag twice.
>
> Same for the MTU, having different MTU for ipv4 and ipv6 addresses
> doesn't have any meaning. The MTU and multicast properties belong to the
> device itself.
>
> I think we should introduce a <network-device> record that would gather
> the properties that can be passed to the "link-set" method of
> Guile-Netlink. The <static-networking> record would point to a unique
> <network-device>. We would remove the device field from
> <network-address>.
>
> Then each <static-networking> service would provision (concat
> 'networking- (network-device-name device)) or something like that, to fix
> https://issues.guix.gnu.org/52511 as well.
>
> How does that sounds?

Seems to have it on the network device would be less surprising, indeed
:-).  It makes sense to me.

Thank you,

Maxim

Message #19 received at 52520 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Julien Lepiller <julien <at> lepiller.eu>, 52520 <at> debbugs.gnu.org
Subject: Re: bug#52520: Multicast is off by default
Date: Mon, 20 Dec 2021 17:38:41 +0100

Hey,

> Can we instead use <network-link> for these purposes?  It is already
> there, just unused.

Mmh, indeed. Well it is already used to create vlan and veth
interfaces. What we could do then, is expose the <network-link> record
as a direct equivalent of the Guile-Netlink <link> record.

The links list of the <static-networking> record would contain all the
links that are managed by Guix. We would require all "device" fields
that appear in the <network-address> records to have their matching link
declared. If the link doesn't already exists (vlan, veth type) then
link-add is called, otherwise nothing happens. The link existence can be
tested using link-name->index. link-set would always be called
afterwards to setup link properties.

static-networking-shepherd-service would then create on service per link
present in the <static-networking> links list. The provisioned name
would be (concat 'networking- (network-link-name link)).

On tear down, which is equivalent to "herd stop networking-<link>", we
would call link-del if the link was created by Guix with link-add, or
(link-set ... #:down #t) if the link was already present. I'm not sure
how to distinguish between those two cases at this step.

This sounds like a complex plan, that will moreover require and
adaptation of existing static-networking configurations, but I cannot
think of anything easier to fix this issue and the other one I reported.

Thanks,

Mathieu

Message #22 received at 52520 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: Julien Lepiller <julien <at> lepiller.eu>, 52520 <at> debbugs.gnu.org
Subject: Re: bug#52520: Multicast is off by default
Date: Mon, 20 Dec 2021 22:33:44 +0100

Mathieu Othacehe <othacehe <at> gnu.org> skribis:

>> Can we instead use <network-link> for these purposes?  It is already
>> there, just unused.

BTW, for the purposes of fixing the bug you initially reported, I
suggest simply adding #:multicast-on #t as you initially proposed.
We discuss the proper API separately.

> Mmh, indeed. Well it is already used to create vlan and veth
> interfaces. What we could do then, is expose the <network-link> record
> as a direct equivalent of the Guile-Netlink <link> record.
>
> The links list of the <static-networking> record would contain all the
> links that are managed by Guix. We would require all "device" fields
> that appear in the <network-address> records to have their matching link
> declared. If the link doesn't already exists (vlan, veth type) then
> link-add is called, otherwise nothing happens. The link existence can be
> tested using link-name->index. link-set would always be called
> afterwards to setup link properties.
>
> static-networking-shepherd-service would then create on service per link
> present in the <static-networking> links list. The provisioned name
> would be (concat 'networking- (network-link-name link)).
>
> On tear down, which is equivalent to "herd stop networking-<link>", we
> would call link-del if the link was created by Guix with link-add, or
> (link-set ... #:down #t) if the link was already present. I'm not sure
> how to distinguish between those two cases at this step.
>
> This sounds like a complex plan, that will moreover require and
> adaptation of existing static-networking configurations, but I cannot
> think of anything easier to fix this issue and the other one I reported.

Hmm yeah.  I think it’s good to have defaults right, so #:up and
#:multicast-on set.  We could set those when a device lacks a
corresponding link.

Food for thought…

Ludo’.

Message #27 received at 52520-done <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Julien Lepiller <julien <at> lepiller.eu>, 52520-done <at> debbugs.gnu.org
Subject: Re: bug#52520: Multicast is off by default
Date: Tue, 21 Dec 2021 20:40:29 +0100

Hey,

> BTW, for the purposes of fixing the bug you initially reported, I
> suggest simply adding #:multicast-on #t as you initially proposed.
> We discuss the proper API separately.

Done with: d2f9578a9f1249dfecb0a6b4cd06fd9641fcd1a9.

Thanks,

Mathieu

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.