update packages due to the changes
cd /tmp
opkg update
opkg list-upgradable | cut -d ' ' -f 1 > list
cat list | while read ii; do sleep 1; opkg upgrade $ii; done
I tried using following one line command for above but it caused jffs2 corrupted
(WARN)#opkg update && opkg list-upgradable | cut -d ' ' -f 1 | while read ii; do sleep 1; opkg upgrade $ii; done
reboot, the iptables worked as is. you could add/remove packages and made changes to your system as usual
This procedure is not recommended. It is highly likely that this could cause major issues for some users, especially step 6 which may soft-brick the device before the process is complete[1]
Further, iptables has largely been deprecated in favor of nftables. Unless there are scenarios where the underlying firewall rules are extremely difficult to migrate[2], use iptables is likely more trouble that it is worth, especially because it only delays the inevitable need to transition to nftables at some point in the future when this 'hack' fails to work.
Upgrading packages (via the CLI opkg upgrade command or the LuCI Upgrade... button) can result in major problems. It is generally highly discouraged, unless you know what you are doing or if there is specific instruction to do so. ↩︎
Only manually defined iptables code firewall rules would be relevant here. Anything running on the level of the UCI/LuCI firewall configuration is already compliant and compatible with the iptables -> nftables migration insofar as these are higher level firewall descriptions where the underlying nftables rules are abstracted from the user. Therefore, this whole attempt to continue using iptables is not necessary for the vast majority of users. ↩︎
step 6 is safe, it's easy to recover by firstboot command.
I think this is a bug for jffs2 in openwrt due to the fast and big amount of data writing during the upgrade.
I have read some articles about the comparing of nft and iptable, the benefit only when huge transactions like enterprise router. for home router, which openwrt is the most application, iptable has a little advantage.
also, for me, when you print out the rule sets, iptable is straightforward and clearly show the package flow, while nft is more obscure and hard to understand.
in addition, under the nft, openwrt does not support the 'extra' for customize the rule sets freely
your process includes it, so someone not aware of what caused the issue will just repeat it.
There are many people who do not know the potential damage that can be caused by upgrading packages and thus those people will not be aware of how to recover.
I can't speak to performance measurements between iptables and nftables, but consider:
The vast majority of home users will probably not notice any performance impact whatsoever between the two given that the traffic flows are relatively modest and the firewall rules themselves are likely fairly simple.
With the exception of either old hardware or hardware that is too limited for the desired routing speeds, the firewall itself isn't generally responsible for taxing the CPU all that much. Thus, there's little need to try to scrape for marginal gains here.
This is a lot of work for "a little advantage" -- especially when you consider that every time a user wants to upgrade to a new release, they will need to repeat this process. That is not generally worth it for diminishing returns.
For those who actually want to read and edit the low level firewall rulesets, I can see the potential benefit here. But this does not apply for the majority of users who will interact with the firewall with the higher level UCI environment.
But as a counter argument, eventually you (and others who prefer iptables) may need to make the transition to nftables anyway. Might as well put the energy into becoming proficient in that rather than hacking your system to run an older (i.e. mostly deprecated) technology.
It's kind of like VLANs with DSA vs swconfig. When DSA was first integrated into OpenWrt, I remember how difficult it was to wrap my head around it after years of using swconfig. Many users were in the same boat. But given that it was going to be the future for how switches are addressed, it made sense to spend time learning, and now it's second nature.
Small subset of users. If you create a new thread for your specific needs, maybe someone can advise about the way to do this with nftables (not me, though -- I'm not an expert at the low level firewall rules).
your process includes it, so someone not aware of what caused the issue will just repeat it.
There are many people who do not know the potential damage that can be caused by upgrading packages and thus those people will not be aware of how to recover.
exaggerated, no harm to the HW, only jffs2's node has crc error, surely caused by bug
you are right, most people use openwrt as AP and would not aware of it. but some people has a lot of tricks used to guard their wall and don't want have some holes by installing a fancy one
just provided a way to do differently since no official way to do this. Different people have different preferences, not intended to discuss the pro and con
Yes there is!! And it is very simple.
Make sure you have iptables-nft (and its siblings xtables-nft, ebtables-nft), instead of the legacy-zzz versions. Then you can use all of your old iptables commands.
All of the iptables kmods also work just fine.
The basic stuff can stay in fw4, and fw4 can run a script containing your iptables commands for you, every time fw4 starts.
The fw4 config would be of the form:
config include 'myiptables'
option type 'script'
option path '/path/to/myscripts/custom_iptables.sh'
I am not aware of anything that cannot be translated - there might be, but that would most likely be a rare edge case that was probably done incorrectly in the first place.
Edit: Depending on what legacy packages you have installed, you might have to create the required iptables tables in your script.
ie add to your script the following lines:
the way you used is that user uses the iptable style command and it will translate/convert into nft command and nft does the real job in the back. so-called front end is iptable, back end is nft
Both kmod-nf-conntrack nd kmod-nf-conntrack6 are installed by default.
I think you misunderstood, I was actually talking about kmod-ipt-conntrack-extra as this adds full conntrack support to iptables-nft.
FYI, there were previous issues with the image on this model.
I'm guessing it may have been resolved - or you're extremely lucky, because subsequent savings to flash after the firmware (i.e., saving settings, installing packages, etc.) cause soft bricking in some cases.
I haven't followed the progress of that fix, so your recreational endeavors provided me hope.
