| Age | Commit message (Collapse) | Author |
|---|
|
Only the first matching link file is applied, and ours sets just the name,
so the address policy shipped with the system never ran on any interface.
Hardware with a permanent address was unaffected - there was nothing to
apply - but a modem, which has none, was left on whatever random address its
driver had picked that boot, a different one every time.
Spell the policy out again. A permanent address is still kept where there is
one, and a device without one is given an address derived from the machine
and the device, which is the same on every boot of that machine. An address
set through the CLI is applied later and is unaffected.
|
|
A modem that reports no permanent address is given a random one by its
driver at every probe. That address was read as if it identified the
hardware, so it never matched what was recorded and the modem was taken for
a different card in the same socket on each boot, warning the operator to
check a port nobody had touched. The map also kept being rewritten with the
address of the boot before, so it could never settle.
Keep no address for a modem, and compare one only where there is one. An
address recorded by an earlier version is dropped on the next pass, so a
machine already carrying one needs nothing done to it.
A card whose address really did change is still reported.
|
|
A Hyper-V NIC is known by its MAC alone. One deleted and created again on
the same VM - an Azure NIC re-created, or a Hyper-V adapter removed and
added - comes back with a new MAC, so nothing on it matched the store: its
name stayed reserved, the new NIC got a new name, and its configuration
was left on a name with no NIC. cloud-init does not run again on the same
instance, so nothing else repairs it.
At boot, a vacant name now goes to a new NIC only when the pairing is not
in doubt:
- exactly one recorded name has no NIC, and exactly one new Hyper-V NIC
appeared. With more of either, the order the NICs come up in does not
say which replaced which, so nothing is handed over and the names stay
reserved, as before;
- the name went missing at this pass. The store records which names were
missing at the last pass, so a NIC removed for good does not hand its
name to a NIC added at a later boot;
- the name's own NIC was a Hyper-V one. The store records which names sat
on a Hyper-V NIC; a MAC-keyed name can belong to other hardware, and a
store written before this was recorded hands nothing over (the boot pass
logs that when it holds a name back);
- only at boot. On a running system the configuration under a name is not
applied to the NIC that takes it, so the hotplug unit passes --hotplug,
which names the new NIC like any other and records the vacant name as
missing, so the next boot does not hand it over either.
An adoption is logged as a warning, reported under 'adopted' in the status
file (kept there across hotplug passes while it holds), and repeated by
vyos-router, as a slot match is: verify the port before relying on its
configuration.
|
|
On Azure every Hyper-V NIC shares one ID_PATH and has no slot, so it is
keyed on its MAC. Its accelerated-networking VF carries the same MAC and
matched the NIC's .link file, so udev tried to give the VF the NIC's name.
The .link file of a Hyper-V NIC now also matches Driver=hv_netvsc, so the
VF cannot match it. This holds for a lone NIC keyed on the VMBus path too.
A NIC absent at a pass cannot say what it is, so its file keeps the pin
it already carries. NICs that are not Hyper-V ones get no Driver line, and
their files do not change. The 34-to-35 migration passes the hardware it
found, so the pin is written on the first boot of an upgrade too.
|
|
The interface naming testcases gained a second variant in vyos-build, running
on a guest that presents VMware firmware - the one platform where the adapter
order comes from the firmware rather than from the PCI topology, and the one
the reported regression was found on.
CI now runs both variants and reports them separately. The target the existing
job calls was renamed along with it.
|
|
ESXi does not lay its adapters out in PCI address order. With four or more it
puts the fourth on a root port sorting ahead of the first three, so naming by
address made Network adapter 4 eth0 and shifted the rest. On the vmware-vsphere
OVA that moved the WAN, because cloud-init takes eth0 from the OVF properties.
The firmware port label carries the adapter order, and is what the VMware udev
rule this series removed matched on. Order by it, ahead of the address, for
hardware the hypervisor presented - recognised by its PCI vendor, or by DMI for
a model whose IDs are not known here. A physical server labels its ports too
and must not be reordered.
The label orders, it never identifies: a relabelled adapter is still the same
card.
|
|
Three of the tests which write the interface map went through the check for
an encrypted configuration volume, and that check asks the running system
where its persistent storage is. A build host answers "nowhere", so the tests
passed - but anywhere that does have such a volume the write is refused and
all three fail, for a reason none of them is about.
Pin the answer. What these tests cover is what the map does with a directory,
not where the directory came from.
|
|
A recorded slot was enough to claim a name, whatever turned up in it. Pull a
modem and put an ordinary USB NIC in the same port and the NIC was handed
wwan0 - a name 'interfaces wwan' reads, so a modem's configuration would be
applied to a card which can not carry it. The reverse was already handled.
Require the device to belong to the namespace the name is read under. If it
does not, the name stays reserved for the hardware that earned it and the
newcomer is named as what it is.
|
|
Cards rearranged among themselves, or a map edited by hand, leave every name
matched to a card the store knows - just not the one it had. That was filed
as an ordinary match, indistinguishable from a machine where nothing moved,
while the addresses configured under those names had quietly changed cable.
Report it separately. Which name goes to which card is unchanged, the slot
still decides; only the account of what happened is.
|
|
An interface was passed over as soon as it had a master, which covers a VF
datapath but also every bridge, bond and VRF member. Those are still their
own card in their own slot, so the naming pass reported them as hardware
which had not appeared, on any run made while they were in use.
Skip only when the master is a device itself. That is what tells the
accelerated path, which belongs to the interface it is enslaved to, apart
from a member, which does not.
|
|
Anything that was not wireless was named ethN, so an LTE module came up as an
ethernet port: bound, working and invisible, because 'interfaces wwan' looks
at wwanN and nothing else.
Give it its own namespace, keyed on DEVTYPE, and drop what an earlier version
filed under an ethernet name - that entry still matches the modem by path and
would capture it again.
|
|
Every interface created on a radio carries that phy's address, so they are
indistinguishable here. A name recorded against one of them was applied to
whichever appeared next: configuring a second interface on a phy renamed it
on top of the first, and the smoketests lost the interface they had just
asked for.
Nothing anchors a radio, and nothing needs to - wireless names come from
'physical-device'. Stop discovering them, stop writing a .link for them, and
drop what an earlier version recorded so the entry and its file go on
upgrade.
|
|
The map now records which card each name sat on. A card moved to another slot
keeps its name rather than leaving it behind for whatever turns up next, and
the slot it vacated does not lend that name out.
Where the map and the hardware disagree, the map wins: a card the store
already knows, found in a name's slot, takes that name. Only a card nothing
knows about, sitting in a slot on record, is treated as a replacement - the
one case which can quietly move a configured address onto another cable.
|
|
image
The check guarding that write looked for a marker which an activation
script creates only after interface naming has already run. On a deployed
qcow2 the marker is absent on the first boot, so nothing was recorded and
the next boot named the hardware from scratch. Removing a card then moved
every name below it onto the neighbouring port, taking that interface's
address with it.
Only an encrypted configuration has a volume which may still be locked, so
ask about that instead - everywhere else the directory is already the
persistent one.
|
|
Names used to be derived from 'hw-id' in config.boot. A node carrying an
address but no hw-id had to be matched to some NIC, and nothing available at
boot could say which one - every heuristic could bind a configured address to
the wrong physical wire.
Naming authority moves to a mapping store binding a name to the slot the
hardware occupies. The slot is the identity, so a replacement card in that
slot is that interface again. The store renders systemd .link files, leaving
udev to apply names as devices appear.
|
