vyos-1x.git/src/services/vyos-netlinkd, branch fix/T8955-http-api-verify-tls

wwan: T9350: wait for the modem to become dialable, not merely listed

2026-09-24T19:48:13+00:00

A modem is on the bus while still probing, so a dial could start too early and leave the interface without a session until something re-dialled it.

wwan: T9350: properly disconnect "disconnect interface wwanN"

2026-09-24T15:27:27+00:00

Two things kept an operator disconnect from taking effect. vyos-netlinkd re-dials every configured WWAN interface that has lost its session. It cannot tell a session lost to RF signal loss from one that was taken down on purpose, so the disconnect was undone on the next reconcile pass, at most 30 seconds later: $ disconnect interface wwan0 08:53:33 t+10s state=registered 08:53:43 t+20s state=registered 08:53:53 t+30s state=connected <- re-dialled 08:54:03 t+40s state=connected vyos-netlinkd: WWAN interface wwan0 is not connected, re-dialling... vyos-netlinkd: Re-dialled WWAN interface wwan0 Record the intent instead of inferring it from the session state. op-mode "disconnect" drops a marker in /run/vyos-wwan, which _reconcile_wwan() honours and "connect" removes again. conf_mode removes it too, so a commit keeps re-asserting the configured state - the marker only survives for as long as nobody says otherwise, and never across a reboot.

wwan: T9350: move session re-dial from cron into vyos-netlinkd

2026-09-24T15:26:28+00:00

/etc/cron.d/vyos-wwan re-ran the conf_mode script every 5 minutes via op-mode "connect interface wwanN" to re-establish a session lost to RF signal loss. Re-entering conf_mode from cron is unsafe: the cron job knows nothing about the boot commit or about a commit in flight, so when a tick lands before the running config is populated, get_config() returns nothing but {'ifname', 'deleted'} and apply() takes the teardown branch instead of dialling. It then stops the DHCP clients, stops ModemManager and unlinks its own cron file, leaving wwan0 down with no way to recover until the next commit: CRON[1869]: (root) CMD (/usr/libexec/vyos/vyos-check-wwan.py) systemd[1]: Stopping DHCP client on wwan0... systemd[1]: Stopping Modem Manager... This is timing dependent - it only bites when a */5 tick coincides with boot - which is why it presents as an intermittently dead WWAN interface. Move the re-dial into vyos-netlinkd, which already tracks these interfaces for DHCP and already gates all of its work behind boot_configuration_complete() and commit_in_progress2(). A re-dial can therefore no longer land on a half-applied configuration. It also dials ModemManager directly rather than re-entering conf_mode, so the teardown branch is no longer reachable from the recovery path at all.

vyos-netlinkd: T9086: drain netlink during commit to avoid stale link-DOWN

2026-08-11T19:30:35+00:00

Original bug: while a commit held the lock, the daemon called sleep(1) without reading the netlink socket. The pending message stayed queued in the kernel buffer, so once the commit ended, a stale event (e.g. a DOWN from a disable that had already been re-enabled) got processed as if it were fresh - stopping dhclient on an interface that was actually back UP. The applied fix keeps only the two pieces that are actually load-bearing: 1. Drain instead of sleep - while commit_in_progress2() is true, still call ipr.get() to read and discard any pending netlink messages, so nothing stale survives to be processed after the commit ends. 2. Reconcile on commit end - once the commit finishes, walk all matching interfaces, compare live sysfs operstate against the last state the daemon acted on (_iface_prev_operstate), and run the normal DHCP handler for any that disagree. This catches a real transition that happened only inside the drain window and would otherwise be silently lost. Dropped from the original fix: an unconditional live-sysfs override inside _handle_dhcp_events() that ran on every event, not just around commits - redundant with reconcile, and risked discarding genuine fast link flaps unrelated to any commit. Co-authored-by: Christian Breunig

vyos-netlinkd: T9143: seed operstate cache at startup

2026-07-30T03:58:13+00:00

The state tracker starts empty whenever vyos-netlinkd starts, so the first same-state RTM_NEWLINK UP notification is treated as a transition and unnecessarily restarts DHCP. Seed matching interface states from the kernel link dump after binding the rtnetlink socket. This preserves real DOWN-to-UP handling while suppressing the first redundant UP notification.

utils: T9008: migrate remaining cmd() callers to cmdl() and remove cmd()

2026-07-17T16:10:08+00:00

Complete the safer-subprocess migration started by the cmdl()/ifconfig refactoring and convert every remaining vyos.utils.process.cmd() call site to the list-based cmdl(). Drop the vyos.utils.process.cmd() implementation as it is no longer in use.

vyos-netlink: T7965: only re-apply QoS configuration to individual interface

2026-06-22T19:33:50+00:00

The previous vyos-netlinkd implementation for QoS policy re-apply was very heavy. It conducted a full CLI validation and re-apply on every interface. Instead we do not only re-apply the QoS configuration to the interface which has had an address change detected by vyos-netlinkd. This can be tested by checking "tc qdisc show" before disconnecting a PPPoE interface and during/after reconnect. There will be no qdisc until the dynamic interface has received an IP address - then the qdisc will be re-applied.

vyos-netlink: T7965: re-apply QoS configuration on dynamic interfaces

2026-06-20T20:56:18+00:00

Re-apply QoS after dynamic interfaces get addresses after connect/disconnect. When PPPoE interfaces re-connect we need to re-do QoS settings.

vyos-netlinkd: T8950: track per-interface operstate to suppress UP-to-UP DHCP restarts

2026-06-03T17:19:54+00:00

_handle_dhcp_events() restarts dhclient/dhcp6c on every RTM_NEWLINK that carries operstate=UP, regardless of whether the interface was already UP. Normal kernel events that re-notify UP without a preceding DOWN (e.g. post-migration gratuitous-ARP, promiscuous-mode toggles) trigger unnecessary DHCP restarts. Each restart also creates a feedback loop: dhclient-script runs "ip link set dev up" during PREINIT, which emits another RTM_NEWLINK(UP), which triggers another restart. One seed event becomes 10+ restarts in 15 seconds. Add a module-level dict tracking the last observed operstate per interface. Only proceed with the DHCP restart when the transition is DOWN-to-UP or when no previous state is recorded (first boot / service restart). UP-to-UP re-notifications are suppressed with a LOG_DEBUG message. Validated on a production VyOS 2026.05.26-1327-rolling router: a controlled KVM live migration after the patch produced zero DHCP restarts (all UP-to-UP events suppressed), with no impact on normal DOWN-to-UP DHCP recovery.

vyos-netlinkd: T8781: try IPRoute.bind() RTNL subscription first (#5207)

2026-05-18T15:34:47+00:00

Not all pyroute2 versions which ship IPRoute() support subscribing to RTNL multicast groups. If subscribing fails, fallback to all messages.