On 11/18/23 19:15, Zhenlei Huang wrote:
On Nov 19, 2023, at 6:20 AM, Mina Galić <free...@igalic.co
<mailto:free...@igalic.co>> wrote:
Hi folks,
Linux has an "easy" way of telling if an interface has been renamed.
See cloud-init's is_renamed function:
https://github.com/canonical/cloud-init/blob/5496745b394f9b7b9eaf57fd619330d484ce2da8/cloudinit/net/__init__.py#L338-L350 <https://github.com/canonical/cloud-init/blob/5496745b394f9b7b9eaf57fd619330d484ce2da8/cloudinit/net/__init__.py#L338-L350>
This code reads /sys/class/net/<netif>/name_assign_type and if that is
3 or 4, it's been renamed.
I can't even think of an sensible way of replicating that.
I can only think of terrible / wrong way of finding it out:
dmesg | grep "changing name to '<new-netif>'"
a less terrible method would be to check for, say:
sysctl dev.<new-netif>.0.%driver
if that fails, we probably have a renamed interface… but we don't know
what it was renamed from, and this only works for *real* interfaces,
not for cloned devices, or epairs.
Now, ignoring my terrible hacky attempts at command line tooling, I
would also happily accept a solution in C, which is fairly easily
accessible from Python, and which we already use to figure out the
uptime (or rather, the boottime):
https://github.com/canonical/cloud-init/blob/5496745b394f9b7b9eaf57fd619330d484ce2da8/cloudinit/util.py#L2073-L2105 <https://github.com/canonical/cloud-init/blob/5496745b394f9b7b9eaf57fd619330d484ce2da8/cloudinit/util.py#L2073-L2105>
Looking forward to reading your ideas.
FreeBSD currently does not preserve the old ( original ) name of
interfaces if it is renamed ( either physical or cloned ones ).
While there's an attempt https://reviews.freebsd.org/D28247
<https://reviews.freebsd.org/D28247> to get the device name (physical
ones) but it is not perfect and not completed.
So may I ask why you need to know if a network interface was renamed ?
Just last week I found this quite a pain as well; once an interface has
been renamed, if it's not a pseudo-interface with an obvious group
there's no clear way, AFAICT, to determine which driver created it
without perusing pciconf output or whatnot and hopefully being able to
associate the NICs listed with the new names (easier when there's only
one NIC, of course). Kind of a pain when you're working on a remote
machine that you're not at all familiar with.
Thanks,
Kyle Evans
