It's been going on through several versions.
My experience -
It happens on a reboot or an ifup wan.
MAC address doesn't change...the WAN IP and Gateway IP do.
For me, it's not an issue.
But if the WAN IP and gateway don't change on an older version, there really shouldn't be anything other than the MAC-address changing that can cause that.
Oh well, if it's a long-known issue, I guess I'll drop the discussion here.
@rseiler could probably tell you when it first started.
Custom nftables rules should be staged in /etc/nftables.d/. Support for firewall.user is intentionally absent as existing scripts most likely expect iptables and fw3 style chains and wouldn't work with fw4 based nft rulesets.
There currently is no replacement for script includes, but fw4 will likely gain back support for config include sections with rc2.
6 Likes
dnsmasq crashes on my Netgear r6700 v2 after 22.03.0-rc1. I also upgraded my TPLink Archer A7 v5 which worked successfully.
r 25 04:08:43 2022 daemon.crit dnsmasq[1]: cannot open log /var/log/dnsmasq.log: No such file or directory
Mon Apr 25 04:08:43 2022 daemon.crit dnsmasq[1]: FAILED to start up
Mon Apr 25 04:08:43 2022 daemon.info procd: Instance dnsmasq::cfg01411c s in a crash loop 15 crashes, 0 seconds since last crash
Mon Apr 25 04:08:46 2022 daemon.crit dnsmasq[1]: cannot open log /var/log/dnsmasq.log: No such file or directory
Mon Apr 25 04:08:46 2022 daemon.crit dnsmasq[1]: FAILED to start up
Mon Apr 25 04:08:46 2022 daemon.info procd: Instance dnsmasq::cfg01411c s in a crash loop 16 crashes, 0 seconds since last crash
@iointerrupt - please PM your /etc/config/dhcp and /etc/dnsmasq.conf contents. You likely enabled non-standard logging settings which are not handled by ujail
1 Like
hi how to sysupgrade snapshot to 22.03.0-rc1 with auc or sysupgrade please for belkin rt3200 thanks
Are you using adblock or other custom server/address settings with dnsmasq? Perhaps you're tripping on this problem:
22.03.0-rc1 has dnsmasq based on 2.86 which might have this bug unless it's patched locally.
Just FYI there has been a PR open by @clayface to try to address the dnsmasq log-facility issue with ujail.
Can anyone who is more knowledgeable about these things confirm whether the issue with the WiFi drops on the R7800 is still there in 22.03? I believe it was introduced in 21.02.2.
Hi
I believe that forcing nftables to your user base is wrong and will backfire.
Additionally, I strongly believe you'll have your own issues internally with it (a lot of unintentional mistakes).
While addressing some of the limitations of iptables, which is appreciative, nftables never became popular mainly because the syntax is badly designed (utter inefficient and confusing garbage) and the documentation insufficient.
Myself - I have more than 20 years experience in networking and had a few failed attempts already to switch form iptables to nftables. Being involved for so many years in networking, professionally I also got a lot of colleagues and friends in the field, with which I had a lot of exchange around the subject and the outcome was always an aversion against nftables. Wondering why they didn't just improve iptables itself (the subsystem) instead of reinventing the wheel - actually a regression instead of an evolution.
I'd suggest to keep nftables optional and stick with iptables - while still appropriate in this early stage of development.
nftables will involuntarily harm you user base security-wise, by not knowing how (or avoiding) to use nftables, thus decreasing their protection.
For a more conclusive example of how complicated it is to switch form iptables to nftables and also how bad the "improved" nftables syntax is, I'd suggest to have a read at this RedHat blog post:
Then, just for testing yourself - nftables provides an utility for converting iptables to nftables rules (one at a time) called iptables-translate
If you run a linux box, just test it - take your iptables rules and use iptables-translate to inspect the nftables output mess.
A simple syn flood protection rule set:
# original iptables rules
iptables -N syn_flood
iptables -A INPUT -i eth0 -p tcp --syn -j syn_flood
iptables -A syn_flood -m limit --limit 20/s --limit-burst 100 -j RETURN
iptables -A syn_flood -j DROP
# iptables-translate
iptables-translate -N syn_flood
iptables-translate -A INPUT -i eth0 -p tcp --syn -j syn_flood
iptables-translate -A syn_flood -m limit --limit 20/s --limit-burst 100 -j RETURN
iptables-translate -A syn_flood -j DROP
# output - nftables "simple and improved" syntax
nft add chain ip filter syn_flood
nft add rule ip filter INPUT iifname "eth0" tcp flags & (fin|syn|rst|ack) == syn counter jump syn_flood
nft add rule ip filter syn_flood limit rate 20/second burst 100 packets counter return
nft add rule ip filter syn_flood counter drop
I rest my case.
Congrats on rc1 devs this is great. Looking forward to this release. Been running my WRT32X nearly a 150 day uptime with kernel 5.10.x with SQM cake on 500Mbit cable, Samba4, USB 3.0 storage, advanced-reboot, DSA, Adblock, 5GHz wifi, and it's rock solid. Looking forward moving to a new build with nftables once things get closer to release 
@helloyello valid points for sure, but didn't the major Linux distros switch to nftables? Debian/Ubuntu, Fedora, Arch, etc.? I'm not an OpenWrt dev, but it certainly seems like the right thing to do is stick with upstream work. Yea it'll take a while to work the bugs out but that's why they switched early way before release (in late 2021). Besides this really looking forward to 5.15 kernel eventually too.
3 Likes
Running smooth on my NanoPi R4S. As always, thanks for all the work!
What do you think about BPF?
Also what about performance:
@phinn's point seems valid in that major distributions seem to be pushing nftables:
Admittedly it seems that even just implementing bridge filtering to prevent client communication on a guest bridge seems like a challenge using nftables.
@phinn
I don't know what major Linux distros mean, as I'm a decades long Slackware (& BSD) fan, kind of a Linux purist and adept of the KISS principle. nftabels was there since kernel 3.x (something) and iptables is still actively maintained. I don't believe there will be bugs the devs would need to care about, but implementation (understanding) and support issues. Furthermore, I believe it's mainly the LuCI devs benefiting from handling nftables instead of iptables.
Back to your point about some Linux distros adopting nftables as the main userspace tool for firewalling, just have a look at their support forums to learn how well it got received.
BTW, Ubuntu had its own struggle with it:
Well, I just expressed my opinion and advice. Until iptables is around and supported, I'll stick with it.
I have the same problem with the same device. But you may have noticed that IPv6 works, only IPv4 does not. I found in the log that some kernel modules related to IPv4 firewalling seem to be compiled for a different architecture and therefore cannot be used.
Are there any plans to edit these file(s) within luci like in 21.02?
Ain’t it a little bit late in the game to start the iptable or nftable “be or not to be” discussion now since the implementation of FW4 was started when 21.02 was released…over a year ago?
9 Likes
Yes, that's what I first thought, but the MAC doesn't change. Speculation is that it's some kind of DHCP issue, but as mentioned it appears to depend upon cooperation from the ISP, since I know it doesn't happen with some (cable in all cases--no idea about DSL), even when the same router model/firmware is involved.
As mentioned, ifup wan also does it, which may be a clue.
It was all coincident with v21, at least with the released versions of v21 (I never tried rc versions). Someone here who has experienced this before will know if it continues now in v22 (rc).
I never did report it.
Maybe poke around in all the mediatek folders, but I think it's these for wifi 6:
https://downloads.openwrt.org/releases/22.03.0-rc1/targets/mediatek/mt7622/
1 Like