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’.