On Mon, Jun 27, 2022 at 11:20:13AM +0200, Hans de Goede wrote: > Hi, > > On 6/27/22 10:10, Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote: > >> This document represents a proposed Change. As part of the Changes > >> process, proposals are publicly announced in order to receive > >> community feedback. This proposal will only be implemented if approved > >> by the Fedora Engineering Steering Committee. > >> > >> > >> == Summary == > >> > >> The `systemd-udev` package installs > >> `"/usr/lib/systemd/network/99-default.link"`, > >> which sets `Link.MACAddressPolicy=persistent`. This proposal is to > >> change it to set `Link.MACAddressPolicy=none` to stop changing the MAC address. > >> This is particularly important for bridge and bond devices. > >> > >> This change can either only apply to bridge/bond devices, or to > >> various software devices. That is to be discussed. > > > > Hi! > > > > I already participated in the upstream discussion, so what I write > > here will be a restatement to some extent, but with a look from the > > side of Fedora specifically. > > > > The proposal has two variants: 1. just changing the policy to MACAddressPolicy=none > > or 2. limiting the change to bridge and bond devices. > > > > Re variant 1: MACAddressPolicy=persistent applies to all devices that don't have > > a hardware address. The proposal as written (blanket MACAddressPolicy=none) > > would change behaviour for all kinds of devices, incl. e.g. software > > devices like veths, and cheap hardware devices without a fixed MAC. > > The proposal doesn't provide any justification for this (except for > > simplicity of implementation) and this variant seems pretty bad and > > I'm strongly opposed. > > <a bit offtopic, sorry> > > I did not know systemd/udev can save/restore MAC addresses for devices > where there is no MAC address. I have looking into a related issue on my > todo list. There are some cheap x86 devices with wifi which don't have > a nvram (eeprom) chip instead they load nvram from /lib/firmware. On most > devices there is enough otp inside the wifi chip that they do have a unique > MAC inside the wifi chip's otp memory so everything works well. > > But on some devices that otp is either not there or not programmed, so > they take their MAC from the nvram in /lib/firmware which means that > all devices from the same model end up using the same MAC (which is > defined in the nvram in /lib/firmware). > > Am I reading the above correctly that udev/systemd already is able > to deal with this and I just need to make it so that the device has > no MAC set at all and then the first time systemd sees this it will > generate a random MAC and use that on future boots ? Yes. (With the following clarification: the MAC address is generated from as some hash of machine-id + device name. So "first time" and "any time" are the same — no state is ever saved, you're supposed to get the same result for a specific device on a specific system.) > Any docs on this / code you can point me to how systemd determines > it needs to do this ? udev looks at /sys/class/net/hub0/addr_assign_type. But the docs are not great :( The description is split between two man pages: - https://www.freedesktop.org/software/systemd/man/systemd.link.html#MACAddressPolicy= - https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html > <even further offtopic> > > The same also applies to some bluetooth devices: > > https://github.com/bluez/bluez/issues/107 > > I wonder if similar functionality for bluetooth would > be welcome in systemd ? I think so. From what I can see, we don't do much setup for bluetooth devices, so I'm not sure if udevd is a better place for this than e.g. bluez. But if yes, it's nice to do things uniformly, i.e. in this case treat bluebooth interfaces more like other network interfaces… The implementation should be simple, since it'd be a question of extending existing code to cover one more case. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
