bug#52520: Multicast is off by default

bug#52520: Multicast is off by default

[Mathieu Othacehe]

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

bug#52520: Multicast is off by default

[Ludovic Courtès]

Hi,

Mathieu Othacehe <othacehe@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’.

bug#52520: Multicast is off by default

[Mathieu Othacehe]

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

bug#52520: Multicast is off by default

[Maxim Cournoyer]

Hello,

Mathieu Othacehe <othacehe@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

bug#52520: Multicast is off by default

[Mathieu Othacehe]

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

bug#52520: Multicast is off by default

[Ludovic Courtès]

Mathieu Othacehe <othacehe@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’.

bug#52520: Multicast is off by default

[Mathieu Othacehe]

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