netifd, branch master

bridge: ignore a bridge priority above 65535

2026-10-28T10:07:58Z

The bridge priority is a 16-bit value, but netifd parses it as a 32-bit integer and stores it in a 16-bit field without a check. A larger value wraps: 70000 becomes 4464, and the bridge competes for the root role with a priority that the configuration does not contain. Keep the default priority for a value above 65535, like the snooping versions keep their default for an unsupported value. Fixes: 2008ae9a80fb ("add bridge priority option") Signed-off-by: Felix Fietkau

bridge: use a valid bridge priority as default

2026-10-28T10:07:30Z

The default bridge priority is 0x7fff, so that the router becomes the root against bridges at the 802.1D default of 32768, as commit 2008ae9a80fb ("add bridge priority option") describes. ustpd uses the lower 12 bits of the priority field for the MSTID and takes the priority in steps of 4096. It thus uses 28672 for this default, while the kernel bridge uses 32767. Use 28672, the step below the 802.1D default, so that kernel STP and ustpd use the same priority and the router stays ahead of bridges at the default priority. Signed-off-by: Felix Fietkau

bridge: pass the bridge priority to the userspace STP daemon

2026-10-28T10:07:12Z

The bridge priority is set on the kernel bridge, but with userspace STP the bridge identifier comes from ustpd, which only receives the protocol and the timers in stp_init. Every bridge then runs at ustpd's default priority of 32768, and a bridge that is configured with a high priority value to keep it out of the root role can become the root of the network. Add the priority to stp_init. ustpd uses it in steps of 4096, so the netifd default of 0x7fff gives 28672. An unconfigured bridge thus stays ahead of bridges at the default priority, as it does with kernel STP. Signed-off-by: Stijn Cleynhens Signed-off-by: Felix Fietkau

vrf: delete a stale device before creating it

2026-10-28T09:19:07Z

A netifd that exits without bringing its interfaces down leaves its VRF devices in the kernel. system_vrf_addvrf() creates them with NLM_F_EXCL, which fails with -EEXIST on the next start of netifd, and system_if_clear_state() deletes only stale bridges. Delete the device before creating it, as vlandev and macvlan do since commit bf7f2afae02a ("vlandev, macvlan: delete a stale device before creating it"). Signed-off-by: Felix Fietkau

main: start no helper while netifd waits for its exit

2026-10-28T09:19:07Z

While netifd waits for its helpers on exit, netifd_start_process() still kills the previous instance of the helper with SIGKILL before it refuses the start. A teardown or a notify command of a protocol handler during the wait thus kills a helper that is ending after its SIGTERM, for example pppd before it sends its PADT. Also, uc_netifd_process() starts new processes during the wait. These get no SIGTERM, so netifd waits for them until procd kills it. During the wait, refuse a helper start before any helper is killed, and refuse process starts from ucode too. Fixes: e4b847c71b50 ("main: wait for the helpers before exiting") Signed-off-by: Felix Fietkau

vlandev, macvlan: delete a stale device before creating it

2026-10-28T09:14:22Z

A netifd that exits without bringing its interfaces down, as on a stop through procd or after a crash, leaves its vlan and macvlan devices in the kernel. The next netifd creates them with NLM_F_EXCL, which fails with -EEXIST, so an interface on such a device fails with DEVICE_CLAIM_FAILED until the device is removed by hand. Delete the device before creating it, as veth does since commit df2f5c9 ("veth: delete device before creation to handle stale state"). Signed-off-by: Julius Bairaktaris

main: wait for the helpers before exiting

2026-10-28T09:14:22Z

Since procd commit 39b5aac ("service: clean up descendant processes for non-jail instances"), procd kills what is left in the cgroup of an instance as soon as its main process exits. netifd sends SIGTERM to its helpers on exit and exits at once, so they are killed while they shut down: pppd before it sends its PADT, which leaves the session open on the peer, and a running hotplug call, such as the SQM script, while it holds its lock. Keep running the event loop after signalling the helpers until they and the running hotplug call have exited, and start no other helper or hotplug call meanwhile. The term timeout of procd bounds the wait. On a PPPoE WAN, stopping netifd through procd left pppd without a PADT before. With this change, pppd sent its PADT in four runs out of four, one of them while the hotplug calls of the ifup were running, and netifd exited within 2 s. Signed-off-by: Julius Bairaktaris

system-linux: empty the event queue before the link dump

2026-10-28T08:52:50Z

After an overrun the kernel reports ENOBUFS once and then drops further messages without a report until the receive queue is empty (netlink_overrun() and netlink_rcv_wake() in af_netlink.c). netifd requested the RTM_GETLINK dump right after the error, with the queue still full. When netifd then blocked again, for example in the wifi setup at first boot, the kernel dropped the next link events silently and no new ENOBUFS asked for another dump: wan and lan1 kept carrier false although the kernel had them up. Read the queue until it is empty before the dump, so that a later overrun is reported again. A new overrun while the queue is read does not stop the loop. Signed-off-by: John Crispin

device: add ARP and per-family neighbour options

2026-10-28T08:52:50Z

Adds these device options, applied live like the other sysctl options: neigh4reachabletime ipv4/neigh//base_reachable_time_ms neigh6reachabletime ipv6/neigh//base_reachable_time_ms neigh4retranstime ipv4/neigh//retrans_time_ms neigh4mcastsolicit ipv4/neigh//mcast_solicit proxy_arp ipv4/conf//proxy_arp arp clears IFF_NOARP when true, sets it when false neighreachabletime still sets both families; a per-family option takes precedence. Note that IFF_NOARP also turns off IPv6 neighbour discovery on the device. Signed-off-by: John Crispin

bridge: add per-VLAN multicast snooping

2026-10-28T08:52:50Z

On a VLAN-aware bridge with multicast snooping, the bridge sends its IGMP/MLD queries untagged. A host on a VLAN upper of the bridge never answers them, so its memberships expire. With switch offload the local stack then stops receiving the group, and SSDP and mDNS go quiet. The kernel can run one snooping context and querier per VLAN. Add the bridge options multicast_vlan_snooping, snoop_igmp_version and snoop_mld_version, and the bridge-vlan options mcast_snooping and mcast_querier. With per-VLAN snooping the kernel ignores the bridge-wide querier settings, so apply them to each local VLAN as well. The kernel accepts multicast_vlan_snooping only with vlan_filtering, so also send it when vlan_filtering is turned on at runtime. Signed-off-by: John Crispin