Multicast is off by default

  • Done
  • quality assurance status badge
Details
3 participants
  • Ludovic Courtès
  • Maxim Cournoyer
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Mathieu Othacehe
Severity
important
M
M
Mathieu Othacehe wrote on 15 Dec 2021 20:36
(address . bug-guix@gnu.org)
8735mt64pl.fsf@gnu.org
Hello,

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

Toggle snippet (10 lines)
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

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:

Toggle snippet (3 lines)
ip link set multicast on eno1

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.

Toggle snippet (13 lines)
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)

Thanks,

Mathieu
L
L
Ludovic Courtès wrote on 17 Dec 2021 16:12
control message for bug #52520
(address . control@debbugs.gnu.org)
87h7b7qn82.fsf@gnu.org
severity 52520 important
quit
L
L
Ludovic Courtès wrote on 17 Dec 2021 16:15
Re: bug#52520: Multicast is off by default
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87czlvqn3b.fsf@gnu.org
Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (3 lines)
> Since the guile-netlink switch the static IP interfaces no longer have
> multicast support. This can be confirmed this way:

[...]

Toggle quote (14 lines)
> 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’.
M
M
Mathieu Othacehe wrote on 19 Dec 2021 12:08
(name . Ludovic Courtès)(address . ludo@gnu.org)
87sfuovomi.fsf@gnu.org
Hey,

Toggle quote (2 lines)
> 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.

Toggle quote (3 lines)
> 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

How does that sounds?

Thanks,

Mathieu
M
M
Maxim Cournoyer wrote on 20 Dec 2021 16:29
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87bl1b2t2d.fsf@gmail.com
Hello,

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (30 lines)
> 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
M
M
Mathieu Othacehe wrote on 20 Dec 2021 17:38
(name . Ludovic Courtès)(address . ludo@gnu.org)
87ilvjkz8u.fsf@gnu.org
Hey,

Toggle quote (3 lines)
> 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
L
L
Ludovic Courtès wrote on 20 Dec 2021 22:33
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
874k73ezbb.fsf@gnu.org
Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (3 lines)
>> 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.

Toggle quote (25 lines)
> 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’.
M
M
Mathieu Othacehe wrote on 21 Dec 2021 20:40
(name . Ludovic Courtès)(address . ludo@gnu.org)
87ilvhbvbm.fsf@gnu.org
Hey,

Toggle quote (4 lines)
> 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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 52520@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 52520
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch