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

Debbugs page

Mathieu Othacehe wrote 3 years ago
(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
Ludovic Courtès wrote 3 years ago
control message for bug #52520
(address . control@debbugs.gnu.org)
87h7b7qn82.fsf@gnu.org
severity 52520 important
quit
Ludovic Courtès wrote 3 years ago
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’.
Mathieu Othacehe wrote 3 years ago
(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
Maxim Cournoyer wrote 3 years ago
(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
Mathieu Othacehe wrote 3 years ago
(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
Ludovic Courtès wrote 3 years ago
(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’.
Mathieu Othacehe wrote 3 years ago
(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
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help