Hm, the logs you shared don't seem to show udev changing the MAC
address. In fact, it shows that udev sees the policy is "persistent",
and the addr_assign_type=0 (NET_ADDR_PERM), so it does not do anything:

nr@six:/t/tmp.xaCDBoIYgA$ grep -rn ens192 udev.log
udev.log:8817:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[632]: 
ens192: Device is queued (SEQNUM=4672, ACTION=add)
udev.log:8822:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[632]: 
ens192: SEQNUM=4672 blocked by SEQNUM=4668
udev.log:8859:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[632]: 
ens192: SEQNUM=4672 blocked by SEQNUM=4671
udev.log:8920:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[632]: 
ens192: Device ready for processing (SEQNUM=4672, ACTION=add)
udev.log:8921:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[671]: 
ens192: Processing device (SEQNUM=4672, ACTION=add)
udev.log:8928:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[632]: 
ens192: sd-device-monitor: Passed 207 byte to netlink monitor
udev.log:8941:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[671]: 
ens192: /usr/lib/udev/rules.d/75-net-description.rules:6 Importing properties 
from results of builtin command 'net_id'
udev.log:11204:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[671]: 
ens192: /usr/lib/udev/rules.d/75-net-description.rules:12 Importing properties 
from results of builtin command 'hwdb --subsystem=pci'
udev.log:11208:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[671]: 
ens192: hwdb modalias key: 
"pci:v000015ADd000007B0sv000015ADsd000007B0bc02sc00i00"
udev.log:11211:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[671]: 
ens192: /usr/lib/udev/rules.d/80-ifupdown.rules:5 RUN 'ifupdown-hotplug'
udev.log:11215:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[671]: 
ens192: /usr/lib/udev/rules.d/80-net-setup-link.rules:5 Importing properties 
from results of builtin command 'path_id'
udev.log:11220:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[671]: 
ens192: /usr/lib/udev/rules.d/80-net-setup-link.rules:9 Importing properties 
from results of builtin command 'net_setup_link'
udev.log:11226:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[671]: 
ens192: Device has name_assign_type=4
udev.log:11235:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[671]: 
ens192: Config file /usr/lib/systemd/network/99-default.link is applied
udev.log:11236:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[671]: 
ens192: Device has addr_assign_type=0
udev.log:11239:Apr 04 12:15:04 maglev-master-169-254-6-66 systemd-udevd[671]: 
ens192: MAC on the device already matches policy *persistent*

Are you sure these logs are taken from a time where the MAC address was
changed?

...

Where is this output from exactly?

> PID: 1760 (snmpd) changed MAC to 00:00:00:00:00:00
> PID: 1760 (snmpd) changed MAC to 00:00:00:00:00:00
> PID: 15073 (systemd-udevd) changed MAC to d2:29:6b:94:be:bd
> PID: 15073 (systemd-udevd) changed MAC to d2:29:6b:94:be:bd
> PID: 15073 (systemd-udevd) changed MAC to d2:29:6b:94:be:bd
> PID: 15084 (ip) changed MAC to d2:29:6b:94:be:bd
> PID: 15084 (ip) changed MAC to d2:29:6b:94:be:bd

I have no idea what snmpd is, but if it's clearing the MAC, and then
udev is triggered, in that case I would expect udev to generate a new
MAC. I'm not sure if that's what the output is suggesting, but that is a
very high PID for systemd-udevd, so it suggests that ran well after
boot. That could explain why the logs you shared don't indicate udev
generating a MAC.

** Changed in: systemd (Ubuntu Jammy)
       Status: New => Incomplete

** Changed in: systemd (Ubuntu)
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2104155

Title:
  systemd-udev interferes with MAC addresses of interfaces

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2104155/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to