What may be the pros/cons to not activate it. Are there any specifics.
Enabling irqbalance helps distribute hardware interrupts across cpu cores or cpus to improve system performance.
However, you should not enable packet steering as it does not help with routing/nat aceleration in NSS cores. which are not affected by the packet steering action. Also, enabling it would cause these errors to show up in dmesg:
[ 1854.973908] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!!
[ 1854.973953] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!!
1 Like
Is there any reason why you included the iptables packages in the build? Did you include them to support packages such as banip, adblock, bcp38 etc?
iptables-mod-extra - 1.8.7-7
iptables-mod-ipopt - 1.8.7-7
iptables-mod-physdev - 1.8.7-7
iptables-zz-legacy - 1.8.7-7
The modules are pulled in from the nss packages, qca-nss-ecm for example has dependencies on iptables-mod-extra and kmod-ipt-conntrack while iptables-mod-physdev is needed by the qca-nss-ecm firewall.d script needs the physdev module, although I seem to recall this was never an explicit dependancy...
I've replaced the dependencies with kmod-nf-conntrack and dropped the firewall.d script as the traffic was allowed earlier in the default ruleset on my system, so it wasn't actually necessary. This allowed me to totally remove iptables from the system, although my use case is pretty simple and doesn't include other packages that may still have iptables dependancies...
2 Likes
modprobe nss-ifb
ip link set up nssifb
Shape ingress traffic to 900 Mbit with chained NSSFQ_CODEL
tc qdisc add dev nssifb root handle 1: nsstbl rate 900Mbit burst 1Mb
tc qdisc add dev nssifb parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 1514 target 5ms interval 100ms set_default
Shape egress traffic to 100 Mbit with chained NSSFQ_CODEL
tc qdisc add dev eth0 root handle 1: nsstbl rate 100Mbit burst 1Mb
tc qdisc add dev eth0 parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 1514 target 5ms interval 100ms set_default
SQM is disabled
Above is in my startup /etc/rc.local.
1 Like
Awesome, thank you. I'm compiling a new build at the moment. I'm going to give that set up (yours) a try with the new build. I've currently got the SQM script set up for NSS which @KONG created. Details on how to implement that afterwards on builds based on @ACwifidude are in this post. I like this implementation because it lets me quickly try settings without rebooting or enter tc qdisc commands I can never seem to remember. But hey, if the settings in /etc/rc.local are good enough, why bother right?
Based on noblem's finding, can we tune the builds for 22.03 and master snapshots so they don't need to include these iptables-related packages anymore?
Thanks.
1 Like
please see the attached picture
and if I set static ip address on my pc,you can access luci web interface again
There's an ECM startup shell script that uses iptables, so will need to figure out the equivalent configuration in nftables if we need to disable iptables. I do not think mixing iptables and nftables will be too problematic (in the short term anyway) since both ultimately ends up as netfilter rules in the kernel.
It looks like nftables does not have a physdev equivalent: https://stackoverflow.com/questions/60803101/how-to-translate-iptables-physdev-statements-to-nftables
https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared_to_xtables
physdev
- br_netfilter aims to be deprecated by nftables.
In NSS build:
cat /etc/firewall.d/qca-nss-ecm
iptables -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
Someone in the above link suggested this nftables config:
table inet filter {
chain forward {
iifname "br0" oifname "br0" accept
}
}
So assuming nssifb is a bridge (?) interface, we would use this nftables config:
table inet filter {
chain forward {
iifname "nssifb" oifname "nssifb" accept
}
}
No. nssifb is a virtual interface. Even the bridge is a virtual interface.
Physical interface would be eth0, eth1, eth0.2, etc.
The iptables rule of ECM is to accept forwarded packets from a bridged physical interface(e.g. eth1.1 if using swconfig). If you have a virtual L2 device like a tap interface that is bridged, the nftable rule you provided (for br0) will also accept it, which unlike the ECM iptables rules, will not accept packets from the tap interface.
So I suppose the ECM script has to be modified to have logics to determine which physical device(s) are bridged and construct the nftables rules dynamically.
Thanks quarky for the explanations.
BTW, does noblem's paragraph make sense to you?
From noblem: ".. dropped the firewall.d script as the traffic was allowed earlier in the default ruleset on my system, so it wasn't actually necessary. This allowed me to totally remove iptables from the system, although my use case is pretty simple and doesn't include other packages that may still have iptables dependancies"
Actually, now that I come to think of it, the ECM script is actually not required. So @noblem is right that the script can be dropped. OpenWrt default behaviour is to allow bridge traffic to be forwarded, so it essentially is more lenient compared to what the ECM script does anyway.
@quarky and @ACwifidude,
So can you please remove all the iptables related packages in NSS builds and replace them with kmod-nf-conntrack, as mentioned in noblem's message. Thanks.
kmod-ipt-conntrack
iptables-mod-extra
iptables-mod-ipopt
iptables-mod-physdev
iptables-zz-legacy
probably it's my limit (for sure, not probably 
) but i still think the move to firewall4 was done too early, we still have a lot of packages that need iptables, dnmasq 2.87 is still not out, a lot of problems just having forced everything to firewall4..
I keep waiting for dnmasq 2.8.7 and in the meantime i'm staying with 21.02..
Yeah, I'm also staying with 21.02 for my ipq806x routers for now.
I felt the same way about DSA in 21.02, but DSA has smoothed out since. With this hindsight, I think the developers have found a good balance between releasing stable versions that are rougher than they otherwise might be and using abrupt changes to force community resource alignment on forward progress.
Forcing resource alignment sounds harsh - obviously the decisions include much discussion and consensus building as well - but considering there is no budget to add paid staff whose work can be directed, it seems to me that some level of forcing things forward is also necessary.
I'm sure dnsmasq developers have to devote most of their efforts to fix many recent security vulnerabilities in 2.86, so this ipt vs. nft stuff won't be top of mind for some time.
Seems like dropping iptables ("fw3") is doable. I'll make a master build a little later today to see how it works with an attempt to strictly go to "fw4". Let me know if you have suggestions for the following:
- sqm-scripts still has a dependency on iptables. Seems like non NSS related scripts like simple.qos still have iptables rules.
- ban-ip depends on fw3, going to drop it for now.
- ipv6 - I might be looking way to far in to it but it isn't clear which packages are truly minimum set of packages for ipv6 with fw4. Seems like the wiki needs updating?
2 Likes
According to noblem and quarky, since OpenWrt's default bridge forwarding behavior already covers the action of the ECM script, there's no longer a need for the current ECM script. You can comment it out and remove the following packages because only the ECM script depends on them. Removing them will get rid of the annoying legacy warning (at the base level of your NSS builds) when going to LUCI -> Status -> Firewall page:
kmod-ipt-physdev
iptables-mod-physdev
Depending on different user needs for different additional packages that may or may not require iptables, fw3 and fw4 will surely have to co-exist for a foreseeable future until such packages have been updated to support fw4.
1 Like