Without some sort of custom "rules" it does no make sense to me. I use i to fix bugs of fw3 (eg The firewall3 assigns zone sometimes wrong when pppd is stopped) and for many things which are not possbile by (l)uci. Makeing fw4 default even it does not yet run well is a bad idea. Additional the lack of wildcards for interface names (eg wg+)
Additional it seems there are many fixes https://git.openwrt.org/?p=project/firewall4.git;a=shortlog
Beside that it does not matter if the rules in the kernel are filled by iptables or nft command
So once we don't use xtables at all any more but native nftables, this codepath would no longer be used.
That's not the whole truth: we could (with some limitations) use the iptables-nft wrapper to remain cmdline-compatible with iptables while using the nftables backend in kernel. This is what all other distributions are doing if you use iptables executable. However, I'm not sure that covers really all features of iptables (ie. also ipsets, wild-cards in interface names, ...), I guess no...
Is it a known problem with this router, that reboot option in Luci powers off the router, and requires a cold boot switch off for 20 seconds? Reboot from the command line seemed to work ok however strangely.
This is a known problem if you have modified the CPU frequency governor to ondemand or otherwise set the CPU supply voltage to 0.9V which causes DDR RAM calibration in ARM Trusted Firmware bl2 to never complete and hang for ever, which is why the device doesn't come up when you reboot.
If you have not changed the CPU frequency governor or otherwise made sure it will not perform reboot while operating at the lowest operating point, reboot should work and what you describe would be new to me.
Users have been reporting that schedutil avoids the problem. This is coincidental as it just happens not to end up in the lowest operating point at the point the reset is asserted, so I wouldn't trust it too much and the behavior may change with future updates. Imho the best is to just
for now until the root-cause of the problem is solved.
Ideally we should do that by having ARM Trusted Firmware make sure CPU frequency and voltage are reset to default before jumping into DDR calibration. We build it from source and datasheet for MT7622 is de-facto public, so just needs someone to do it. And it would require everyone to update bl2 which is a bit dangerous.
Alternatively it could be solved by patching the Linux kernel so it would make sure to reset cpufreq to default before reboot. That's kinda ugly and most likely unacceptable for upstream, but then it's solved via normal sysupgrade and (other than updating bl2) there is no risk to brick the device if the update goes wrong.
To be on the super safe side, we could even do both of the above, so new users (and new devices using MT7622 with ATF built from source) would not suffer from that problem and existing users would still not have to replace bl2. However, you guess it, it's a bit of work.
So last but not least we could simply ignore what MediaTek engineer Sean Wang submitted to Linux and just raise the supply voltage on that lowest operating point to 1.0V or completely remove the (anyway obvious buggy as 30MHz in code but labeled more realistic sounding 300MHz) operating point from device tree. But both would be a last-resort if none of the above is implemented when we get close to 22.xx-rc1.
Lol, i installed recovery 0.62 to quick test fw4. It's complete broken!
"Status" > "Firewall" shows only "Collecting data..."
And why are there no more "Custom Rules" with fw4??
Seems nftables is a pre-alpha and should not by installed yet, even it is default now.
Yes, confirming firewall4 is the culprit. When I downgraded to the 0.6.1 release then updated to the latest snapshot with show advanced options firewall was listed and I had internet access. I tried updating today removing firewall and selecting firewall4 and internet was gone again.
Is there any way to upgrade to firewall4 at this point? Has anyone gotten 0.6.2 to work successfully?
I am ok reconfiguring everything from default if that's what it takes.
Reboot works well with ONDEMAND, but im using at least 1.0volt for all frequencies 125 and 300 mhz - as suggestet in my unmerged PR some months ago -.- , linked somewhere above
So just merger the 125mhz and 1volt commit (governor optional)
I tested the nft wrappr and some rules im using did nor work anymore, it was something that ipv6 ips where no longer as ips recognized ("f" is invalid error). I think it was at least this rule:
ip6tables -t nat -A prerouting_lan_rule -m mac ! --mac-source <2ND_DNS> -p tcp --dport 53 -j DNAT --to-destination [fd0a::1]
or ip6tables -t nat -A prerouting_wan_rule -d ::xxxx:xxff:fexx:xxxx/::ffff:ffff:ffff:ffff -p tcp --dport 123 -j DNAT --to-destination [fd0a::9999]
offload-crash: I never had this. Maybe because i no longer used it as ipv6 is unusable (see ticket) and the bug was later introduced. So I consider ipv6 is still broken...
As a workaround, set a higher frequency which uses enough voltage, eg echo 437500 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
in rc.local or just before the reboot.
Or uses non-ubi. It has a bootloader which can handle less than 1volt correctly during reboot
Reboot issues are unrelated with firewal4 problems (and problems with firewall4 or nftables transition should probably also better go into a thread of their own as their are certainly not device-specific...).
If you use auc or attended sysupgrade in LuCI then you are fine to upgrade, as that is unrelated to both of the above (you will remain on which ever firewall implementation you are using at the moment, just updated).
And yes, with 300MBit/s you are most likely better off without offloading and using qosify or sqm.
@daniel
if I use a script based on iptables like that of elan for example will it still work under nftables and firewall4 or should I convert it to nftables? thank you