Lets talk about firewall4 (default nftables firewall)

[brada4]

I got reordering only of few udp packets?

[glassdoor]

yes just a few. under 20. and most of the time just 2

[brada4]

I got 2-3 per minute before patch and after patch 2 per hour. iperf3 --bidir, dut is tuf-ax4200
unoffloaded tcp could be improved by making mssfix "global" ie without interfaces, this is only a quick bolt-on.

[brada4]

@glassdoor please check if this (mandatory per-packet iifname) also applies
-- https://github.com/openwrt/firewall4/pull/27
I had it out long before PR.

[glassdoor]

I have recently resolved udp issues when hw offload is enabled by disabling fraglist gro by default. Patch for kernel 6.6 is attached.
Turns out it has nothing to do with nftables firewall!
Do test and let me know if you see the same

--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -243,10 +243,10 @@ static inline int find_next_netdev_featu
 #define NETIF_F_UPPER_DISABLES	NETIF_F_LRO
 
 /* changeable features with no special hardware requirements */
-#define NETIF_F_SOFT_FEATURES	(NETIF_F_GSO | NETIF_F_GRO | NETIF_F_GRO_FRAGLIST)
+#define NETIF_F_SOFT_FEATURES	(NETIF_F_GSO | NETIF_F_GRO)
 
 /* Changeable features with no special hardware requirements that defaults to off. */
-#define NETIF_F_SOFT_FEATURES_OFF	(NETIF_F_GRO_UDP_FWD)
+#define NETIF_F_SOFT_FEATURES_OFF	(NETIF_F_GRO_UDP_FWD | NETIF_F_GRO_FRAGLIST)
 
 #define NETIF_F_VLAN_FEATURES	(NETIF_F_HW_VLAN_CTAG_FILTER | \
 				 NETIF_F_HW_VLAN_CTAG_RX | \

[brada4]

Well, you are not alone in this fight

WiFi download speed degraded when using VLANs on Asus RT-AX89X and kernel 6.12

(format your ```diff please)

[glassdoor]

interesting...
why the resistance to disable it by default especially for hwoffload??!! since it's not helping with performance as it is already hw offloaded.

simple way to test. iperf3 udp is no longer complaining about out of order packets. And my local voip system has been working flawlessly since.

[brada4]

rx-gro-list is disabled in snapshots, hope it comes to 24.10 soon.

[glassdoor]

i didn't see a PR for 24.10 yet. you want to volunteer?

[brada4]

Well, original author is at it. Given my UX wit contributing year is optimistic assessment of anything landing on end-user device.

[glassdoor]

sorry.. i just check mainline.. the rx-gro-list enabling patch is still there in both 6.6 and 6.12 generic hacks.

[brada4]

This, no pr yet

[nemesis]

It may be easier to just migrate to uspot, see:

OpenWISP GSoC 2025: Improving Uspot A Modern Captive Portal for OpenWrt

I'm excited to share that Uspot, a relatively new captive portal package developed for OpenWrt, is being actively improved as part of this year's OpenWISP Google Summer of Code (GSoC 2025). With this project idea we aim to make Uspot a viable replacement for CoovaChilli, which is no longer under active development. However, a few features that are heavily relied on in OpenWISP deployments have been missing so we are working with the uspot maintainer to add these, the most notable ones being: S…

[brada4]

Well, it is a complement to eachother. But if anything gets fixed down the road it is welcome.

[nemesis]

I have some experience with coova-chilli and I have noticed a few problems which are resolved with uspot:

• firewall integration with openwrt is super tricky
• Radsec is not supported in openwrt unless you edit the makefile and recompile
• debug output pollutes syslog output
• SSL redirection crashes the process
• performance is pretty bad, disabling segmentation offloading with ethtool kinda improves it, but still sucks compared to uspot
• CPU usage is pretty high on busy APs
• I was not able to get DHCP relay to work
• unplugging the WAN and replugging it causes the captive portal redirection to stop working

So the migration to nftables is just one of the many issues, at this point IMHO fixing coova-chilli it’s not worth it. But of course if anyone is able and willing to do it and has a reason to do so it’s good provide some extra lifetime to coova-chilli deployments.

[brada4]

coovachili uses iptables netlink to program old iptables, there is no possible good integration or migration to nftables possible. It is like 50 such packages that stand no chance for future.

List: https://github.com/openwrt/packages/issues/16818

[brada4]

Zero impact from ranting in that thread unless you really are to rewrite coova kmod for nftables.

[lantis1008]

Many weeks later… I have backported the changes from kernel 6.13 to 6.6.
You can apply the individual patches on their own without any impacts (that I have noticed).

One caveat going back to 6.6 was the nft_parse_register_load function definition changed, but we can undo this as well trivially rather than carry additional patches.

Having this functionality working is so much more flexible.

024-backport_nftables_bitwise_mask_xor.patch

[brada4]

Impressive, some ago i tried bit ops and just left it alone wondering that they go between noop and unpredictable

[dave14305]

Does anyone have any thoughts on how a nftables vmap statement should be displayed visually in LuCI?

You end up with multiple "Rule matches" and "Rule actions" per vmap statement. Do you just stack them up in their appropriate columns, or split them out as if they were separate rules altogether?

Thoughts? @systemcrash?