firewall4/root/usr/share, branch master

fw4: list the software flowtable devices for hardware offloading too

2026-11-08T16:27:23Z

With flow_offloading_hw, fw4 lists only the devices below the zone devices. A hardware flowtable is a software flowtable too: the flows the hardware does not take run through the same ingress hooks. A WireGuard flow and a container flow then find no hook for their device and stay on the classic path. List the same devices for both. A device without hardware offload support is accepted in a hardware flowtable (pending patch 701), so the hardware check keeps its meaning. Signed-off-by: Julius Bairaktaris Link: https://github.com/openwrt/firewall4/pull/116 Signed-off-by: Robert Marko

fw4: list the layer 3 devices of zones in the software flowtable

2026-11-08T16:27:23Z

fw4 builds the software flowtable from the device each zone network is set up on. A WireGuard interface has no such device, so its device is never listed and none of its flows is offloaded. A PPPoE interface contributes the Ethernet or VLAN device below it, while its pppoe device is listed only when another interface, such as wan6, names it. List the layer 3 device of each zone network as well. In QEMU (x86-64 r37896, 6.18.55), a TCP transfer through WireGuard took the forward chain with 11024 to 45276 packets in 6 s before and with 6 to 7 after, IPv4 and IPv6, both directions, 3 runs each. 11_flow_offloading_encaps covers the device list for each encapsulation a zone network can use, from netifd's interface and device status in that setup: plain, 802.1Q, 802.1ad, PPPoE and PPPoE over VLAN, macvlan, a VLAN-filtering bridge, a VXLAN and a bond as bridge ports, GRE, IPIP, SIT, ip6tnl and WireGuard. Signed-off-by: Julius Bairaktaris Link: https://github.com/openwrt/firewall4/pull/116 Signed-off-by: Robert Marko

fw4: list the devices a zone names in the software flowtable

2026-11-08T16:27:23Z

A zone can name devices directly, such as dockerd's zone with docker0. fw4 never puts them into the software flowtable, so since 871df5007eda a flow from a container is not offloaded at all. Add the devices of the zone device option for software offloading: resolve a bridge that netifd does not manage through its sysfs DEVTYPE, and pass a "name+" wildcard as the prefix "name*", which the kernel matches against devices that appear later. A flowtable takes a name prefix since Linux 6.17 (NFTA_DEVICE_PREFIX); before that, nf_tables_parse_netdev_hooks() refuses it with -EINVAL and the whole ruleset would fail to load, so a wildcard is left out on older kernels. Hardware offloading keeps its device list, since a veth or tap device cannot carry a hardware flow. Signed-off-by: Julius Bairaktaris Link: https://github.com/openwrt/firewall4/pull/116 Signed-off-by: Robert Marko

fw4: list lower devices for software flow offloading

2026-11-08T16:27:23Z

Since Linux commit 871df5007eda ("netfilter: flowtable: bail out if forward path cannot be discovered"), a flow is offloaded only if the device at the bottom of its forward path is a flowtable device. Behind a bridge that is the bridge port, behind a VLAN its lower device. With software offloading, fw4 lists only the zone devices, so flows through br-lan or a VLAN WAN stay on the classic path. Resolve the lower devices for software offloading as for hardware offloading, including the .sta* prefix of a wireless bridge member, since a WDS port that appears after the reload is a bridge port like any other. This undoes e009588 ("fw4: do not add physical devices for soft offload"), which dropped them because a flow kept transmitting to a port its host had left; the kernel now tears such a flow down when the bridge fdb entry moves. Signed-off-by: Julius Bairaktaris Link: https://github.com/openwrt/firewall4/pull/116 Signed-off-by: Robert Marko

config: mark unsupported fw3 options correctly

2026-11-02T23:57:55Z

- mark sysctl-based fw3 options UNSUPPORTED, emitting warning - remove notion of unsupported option from default config file No change in ruleset logic. Signed-off-by: Andris PE

Set has_ports for helper rules and require helper port

2026-11-02T23:49:14Z

Helper definitions are used to generate automatic `ct helper set` rules. A helper without a port cannot produce a meaningful assignment rule, so make `port` mandatory in `parse_helper()`. The generated helper rule now also carries `has_ports: true`, which suppresses the redundant `meta l4proto` match via the normal `has_ports` guard instead of special-casing `set_helper` in the template. No behavior change for valid helpers. Suggested-by: Andris PE [require helper port and set has_ports instead of special-casing set_helper] Signed-off-by: Jo-Philipp Wich

templates: remove stray file

2026-11-02T23:29:26Z

Fixes: https://github.com/openwrt/firewall4/issues/86 Signed-off-by: Andris PE

fw4: support multiple ipset references per rule and redirect

2026-11-02T23:25:34Z

The `list ipset` option has AND semantics: all listed references are AND-ed into one nft rule. Co-Authored-By: Claude Fable 5.1 Signed-off-by: Philipp Raschdorff [shorten comment] Signed-off-by: Jo-Philipp Wich

fw4: reject unknown tokens in ipset references

2026-11-02T23:15:59Z

parse_setmatch() ignores every token after the set name that is not a direction (`src`, `dst`, `dest`). `option ipset 'setA setB'` is therefore accepted as a reference to setA only, and the rule silently matches fewer conditions than configured. With list support for the option this mistake becomes likely. Reject the value if it has more than three tokens or a token that is not a direction. An invalid value drops the section with the usual "specifies invalid value" warning (fail-closed). This is a behaviour change: a configuration that relied on unknown tokens being ignored loses the affected rule after the update. For an ACCEPT rule that closes access; for a DROP or REJECT rule it removes the block, which is the opposite of fail-closed. Both cases are reported with a warning, but nothing else draws attention to them. If that risk is considered too high, the alternative is to keep accepting the reference and only warn about the ignored tokens; this patch is submitted separately so that it can be discussed and dropped on its own. Co-Authored-By: Claude Fable 5.1 Signed-off-by: Philipp Raschdorff

fw4: add WDS ports to the flowtable by prefix

2026-11-02T23:15:59Z

fw4 reads the bridge members from sysfs when it renders the ruleset and lists each member by name in the hardware offload flowtable. hostapd creates the port of a 4-address station as .sta when the station associates. A port that comes up after the last reload under a name that was not in use then joins the bridge, but not the flowtable, and its upload takes the slow path until the next reload. The kernel binds a flowtable hook with a name prefix to each device that registers later under a matching name, the hardware block included. So list .sta* for each wireless member and drop the port names, because the kernel refuses a list that holds a prefix and a name under it. Each wireless member gets the prefix, also one without a port at the time of the render, because the reloads at boot run before the first station associates. A name prefix in a flowtable needs the NFTA_DEVICE_PREFIX attribute of Linux 6.17, which nftables 1.1.6 and later send. An older kernel refuses it, so the check of hardware offload would fail and fw4 would fall back to software offloading. So fw4 uses the prefix only on Linux 6.17 and later, and lists the port names as before on an older kernel. Software offloading lists the zone devices and does not change. Signed-off-by: Koral Ilgun