Upgraded to 22.03.3 but not running fw4/nftables

I did an Attended Sysupgrade from an older version of OpenWrt (perhaps 19 or 20) to 22.03.3. On trying to get Crowdsec up and running, I realised that nftables is not installed and neither is there an fw4 command as I would expect after reading https://openwrt.org/docs/guide-user/firewall/misc/nftables.

fw3 and iptables work.

Is there an obvious reason why? Did the Attended Sysupgrade keep me on the old firewall?

I think the question to ask here is: did sysupgrade succeed? It sounds like it did not.

I don't notice anything else odd about the install and the router is working as it always has been.

After further reading on this forum it appears that iptables is still supplied, but uses nftables in the background:

root@router:~# iptables
iptables v1.8.7 (nf_tables): no command specified
Try `iptables -h' or 'iptables --help' for more information.

So it looks kinda right. I don't have fw4 though, and fw3 complains about no ipset installed (which I think is as expected)

Try:

# nft list ruleset

AFAIK there's no nftables command.

root@router:/# nft list ruleset
-ash: nft: not found

And there are various nft packages that are not installed via opkg.... but also some that are :slight_smile:

Maybe skip attended sysupgrade for now and install a plain release image instead. Attended sysupgrade tries to install everything that was in your old installation into the new image, which is hitting problems when major dependency chains change between releases (fw3/ iptables --> fw4/ nftables), while it may have gained heuristics for known issues, slightly different circumstances might still trip them out of order, resulting in a 'weird' package mix.

Resetting this to known-good defaults default (plain release image or a manually curated one from the (online-) imagebuilder might be the easiest way to get you sorted, just sysupgrade it (again).

2 Likes

Reflashing with the built image did the trick (and is probably enough to have me avoid ASU going forward :wink: )

Well as @slh rightfully pointed out this was an edge case, and I initially overlooked it as well in your post. Shouldn't be an issue between point releases, but indeed a bad idea between major releases.

Is it really that much an (rare?) edge case?

23.xy.0 will switch from wolfssl to mbedtls and openssl 1.1 to openssl 3.x, at least the former has the potential to cause similar conflicts. I've seen similar approaches as ASU elsewhere in the past (admittedly, a general purpose linux distribution is more volatile in terms of regular soname bumps and other major migrations), they always needed more hands-on fixing, special casing, adapted heuristics and attention than working without them.

To be fair it really didn't take me that long to restore my packages using a diff, and the same diff highlighted why the firewall was strange too.

I did specify one should not use UAC on major releases.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.