Summary
The operstate tracking added for T8950 does not initialize
_iface_prev_operstate when vyos-netlinkd starts.
If the first link notification received after daemon startup is an
RTM_NEWLINK event with IFLA_OPERSTATE=UP for an interface that is already
UP, the previous state is None. The daemon therefore treats the notification
as a transition and restarts the DHCP client.
This leaves a startup/service-restart gap in the UP-to-UP suppression added by
T8950 and PR #5242.
Impact
On a DHCP-configured WAN interface, the unnecessary restart releases or removes
the current address and default route while DHCP is reacquired.
In the observed incident this caused a 2.239-second WAN interruption.
Reproduction
Use a disposable VyOS system with a DHCP-configured interface.
bash sudo systemctl restart vyos-netlinkd systemctl show dhclient@eth0.service -p MainPID -p ActiveEnterTimestamp sudo ip link set dev eth0 promisc on sleep 5 systemctl show dhclient@eth0.service -p MainPID -p ActiveEnterTimestamp sudo journalctl -u vyos-netlinkd -u dhclient@eth0.service --since "30 seconds ago" Replace eth0 with the DHCP-configured interface. The promiscuous-mode change emits RTM_NEWLINK with operstate=UP even though the interface was already UP. Actual behavior Because _iface_prev_operstate is empty after daemon startup, the first UP notification restarts dhclient@<interface>.service. The DHCP PID and activation timestamp change, and connectivity is briefly lost. Expected behavior vyos-netlinkd should establish the current interface operstates when it starts. A subsequent UP notification for an already-UP interface should be suppressed without restarting DHCP. A real DOWN-to-UP transition must continue to restart DHCP normally.