Hi, On 6/27/22 13:18, Zbigniew Jędrzejewski-Szmek wrote: > 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 Thanks this was useful. I've submitted a kernel patch upstream now which fixes the described issue by using a random MAC + setting the addr_assign_type: https://lore.kernel.org/linux-wireless/20220708133712.102179-2-hdegoede@xxxxxxxxxx/ Regards, Hans > >> <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
