vyos-1x.git/python, branch rolling

smoketest: T9316: do not race the DHCP client when checking VRF membership

2026-09-16T21:50:12+00:00

test_dhcp_vrf and test_dhcpv6_vrf resolved the DHCP client's PID, then read the VRF's process list and asserted the PID appeared in it. The client re-executes itself at moments of its own choosing, so between those two steps it can come back with a new PID - the process is in the VRF, it simply is not the process we asked about: AssertionError: '13502' not found in '14322 dhclient\n 14324 dhclient-script\n 14485 dhclient...' Observed failing and passing on the same image, so it costs a rerun rather than telling anyone anything. get_process_cmdline() already fights the same race for the /proc read. Resolve the PID and read the VRF's list as one step and retry, so a restart costs a retry instead of a failure. The probe itself was also loose: substring-matching the raw output of "ip vrf pids " lets a PID check be satisfied by the process name column or by a longer PID containing ours. Add vyos.utils.network.get_vrf_pids(), which parses the command's " " lines into (pid, process_name) tuples and returns an empty list for an unknown VRF, and compare the PID field as an int.

Merge pull request #5441 from ordex/T8264-openvpn-dco-lifecycle

2026-09-16T18:48:14+00:00

T8264: openvpn dco lifecycle

Merge pull request #5429 from rockfish-vyos/T9254-ike-esn

2026-09-15T12:48:01+00:00

ipsec: T9254: do not emit ESN transforms in IKE proposals

smoketest: T8264: cover adopting a pre-created DCO interface

2026-09-15T08:05:28+00:00

assertDcoDataPath() checks the link kind, the operating mode and that the daemon is up, and none of those change when the offload carries nothing. A client whose server is not up yet never opens its tun, so VyOS creates the "ovpn" device for it and OpenVPN has to adopt that device once the server appears. Get the adoption wrong and the daemon takes the device but not its ifindex: dco_new_peer() fails, the daemon exits and deletes the interface on its way out, systemd starts it again and the second attempt creates a device of its own. The tunnel comes up either way, so the state it ends in proves nothing - the restart it cost does. Ask the Kernel for its peers as well, which is the one thing no amount of userspace bookkeeping can fake.

openvpn: T8264: create the interface type the data path needs

2026-09-15T08:05:28+00:00

apply() restarts the daemon and then creates the interface itself, as a tun device. OpenVPN declines the offload when it finds a device of the wrong type, so DCO worked only until the first reconfiguration. The Kernel module takes its operating mode at creation time and iproute2 can neither set nor report it, so go through netlink - multipoint for a server, point-to-point otherwise, matching what OpenVPN asks for itself. A server adopting a point-to-point device rejects every client, and the attribute is dropped silently if it is ever unrecognised, so read the mode back. A raw option does not change this. verify() turns away the ones known to drop the offload, and beyond those "openvpn-option" is documented as the user's own responsibility - so an offloaded interface is created either way. A raw option that does decline the offload now leaves the daemon unable to open the device it is given, which is at least visible, rather than quietly carrying traffic in userspace.

ifconfig: T9313: fix removal of QinQ sub-interfaces

2026-09-14T16:47:31+00:00

EthernetIf.remove() snapshotted Section.sub_interfaces() once and then removed every entry of that list. For Q-in-Q setups the list contains both the vif-s (eth0.10) and its vif-c children (eth0.10.20), as Section.sub_interfaces() matches every configured interface whose name starts with ".". Removing eth0.10 cascades in the Kernel and also deletes eth0.10.20. Once the loop reached eth0.10.20, Interface.__init__() no longer found it and - as "create" defaults to True, re-created it via a bare "ip link add dev eth0.10.20" without any type. This failed and left a stranded interface behind which in turn broke all subsequent smoketests. The same cascade silently killed DHCP clients running on sub-interfaces of any other interface type, as only the interface itself got its addresses flushed: * deletion of a bond or bridge interface carrying vif/vif-s/vif-c * deletion of an entire vif-s, as get_removed_vlans() only populates "vif_c_remove" for a vif-s which still exists in the new configuration Move the sub-interface teardown from EthernetIf.remove() into the base class Interface.remove(), where it benefits every interface type. The list is walked deepest first (vif-c before vif-s/vif), which is what T7813 requires to stop the DHCP client and return the lease, and interfaces which vanished in the meantime are skipped so they are never accidentally re-created. As a side effect of this move, an ethernet interface is now only placed into A/D state after the base class has released the addresses - previously the lease of the interface itself was returned over an already downed link.

Merge pull request #5460 from c-po/T9228-interface-nagging

2026-09-14T14:50:38+00:00

ethernet: T9228: only warn about unsupported NIC features when node changed

ipsec: T9254: split get_esp_ike_cipher() into get_esp_cipher() / get_ike_cipher()

2026-09-14T08:19:12+00:00

get_esp_ike_cipher() took an esn flag defaulting to True (ESP/CHILD_SA semantics), and every IKE_SA call site had to remember to pass esn=False. Nothing enforced that, so a future call site could reintroduce the ESN-in-IKE bug this task fixed. Following review feedback from hedrok, split it into two public filters: get_esp_cipher(group_config, ike_group=None) ESP/CHILD_SA, esn=True get_ike_cipher(group_config) IKE_SA, esn=False always The shared implementation moves to _get_esp_ike_cipher() (no register_filter), so a template can no longer call it directly and skip picking one of the two entry points. Updated call sites: peer.j2, profile.j2, remote_access.j2, l2tp.j2 (proposals -> get_ike_cipher, esp_proposals -> get_esp_cipher), and test_template.py.

Merge pull request #5451 from c-po/T8409

2026-09-12T06:16:59+00:00

configquery: T8409: resolve op-mode config paths independent of edit level

Merge pull request #5372 from ruben-herold/T9157-fib-type-match

2026-09-11T14:28:09+00:00

firewall: T9157: add fib-type match for destination/source