seeing as ya'll bout to be chastised by the OP for posting in this thread on something not specific to this build,
could the discussion about the random crashes be kept on the Netgear R7800 exploration (IPQ8065, QCA9984) topic? It would be easier to follow.
master-firewall4-r18722-e045e40671-20220203
Fixes to dependencies in iptables/nftables were merged today ( https://github.com/openwrt/openwrt/pull/5004 ), so the firewall4 starts to stabilise regarding the iptables/nftables availability for other packages. Also SQM dependencies were fixed. Banip and bcp38 are still missing from the build, as they require ipset. The build also included the nftables LuCI status page, although jow has not yet merged the PR officially.
Ps. For those who have personal iptables rules/commands in scripts, "nft" is the firewall rule manipulation command instead of "iptables" in master.
"iptables" is currently actually a translator from the iptables-nft package, translating the iptables syntax to nftables syntax and applying them. Possibly goes ok if vanilla commands, possibly wrong if more exotic commands. "iptables-legacy" would be the old iptables.
"nft list ruleset" shows the firewall.
root@router1:~# iptables-legacy -V
iptables v1.8.7 (legacy)
root@router1:~# iptables -V
iptables v1.8.7 (nf_tables)
root@router1:~# nft list ruleset
table inet fw4 {
chain input {
type filter hook input priority filter; policy accept;
iifname "lo" accept comment "!fw4: Accept traffic from loopback"
ct state established,related accept comment "!fw4: Allow inbound established and related flows"
tcp flags syn / fin,syn,rst,ack jump syn_flood comment "!fw4: Rate limit TCP syn packets"
iifname "br-lan" jump input_lan comment "!fw4: Handle lan IPv4/IPv6 input traffic"
iifname "eth0.2" jump input_wan comment "!fw4: Handle wan IPv4/IPv6 input traffic"
}
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept comment "!fw4: Allow forwarded established and related flows"
...
The Netgear devices (r7500/ r7500v2/ r7800/ d7800/ xr500) do have a quite sane thermal design, including a big heat sink covering most of the board, although ipq806x is still running rather hot. The ZyXEL nbg6817 less so, running even hotter. ipq8064 also seems to run cooler in general (smaller heat sinks), not quite surprising given the lower clock rate (so the additional performance in ipq8065 seems to mostly stem from running the silicon closer to its maximum, rather than process improvements).
btw i run my r7800 at 1.9 ghz and 1.7 ghz with cache for more than 40 days with no problem... thermal is really not the problem
Currently running the r18722 build. Since the last three? builds I have a small issue that I can't access my (port forwarded) services using my public IP when accessing them from my own LAN. From the internet everything works. Probably a setting in the new firewall?
One thing to consider for @hnyman : setting the min core to 800000 solves the reboot issues I had earlier...
@jow is probably currently fixing the nat reflection...
See
fw4: fix enabling NAT reflection rules for DNATs without explicit familyThat fix (firewall4 version bump) will likely be merged in to OpenWrt soon.
Yes, that'll likely fix it. As a workaround one can add option family ipv4 to the redirect sections.
Yeah, I first tested that 600000, and @Ansuel took that into the commit that got merged. Changing that into 800000 would be easy. The underlying reason is probabyl that the CPU cores are scaled independently, and so sometimes the memory cache frequency can be too log/high for one core.
That's exactly the issue i have with firewall4 too.
That works for now. Thanks!
After increasing this:
sysctl -w net.core.rmem_max=524288
No more messages from nlbwmon in syslog 
With this build?
I overclocked mine for the LULZ
master-firewall4-r18770-46e0eeb760-20220207
Jow merged today several fixes to firewall4 & related packages, as well as the firewall4 LuCI status page.
I don't understand. I'm a new owner of an R7800 and new to OpenWrt. Which of the builds (in the Dropbox account) should I use?
You might take the newest OpenWrt 21.02 stable build.
You can see the list of newest ones in the first message.
And you need the factory image for flashing from the original OEM firmware, if you are still running that. ( If you are already running some OpenWrt image, use sysupgrade.)
@hnyman had to restart my wifi 5ghz (80Mhz channel 52 / fast roaming) twice now on the last two master builds: 18770 and 18792. Should I provide some logs (if so which one?) or is it a known issue?
edit: changed to channel 36 as I found out that channel 52 @ 80Mhz is a strange choice. Will report if it changes things
Is the 5GHz Wi-Fi not responsive or you see extremely high latency? I do see the same issue with my own custom build for my R7800. Am testing a fix suggested by @tohojo and so far after 3 days of uptime, I'm not facing a much issue as I used to, for recent builds. I'm on openwrt 21.02 tho. Will monitor it for a week and week how it goes. The suggested file link can be found here.
Edit: Provided the link to the suggested fix.
What I found is that if the 5GHz Wi-Fi is on congested channel (typically that would be 36 and 149) the issue will be more apparent. Unfortunately the others are DFS channels, so even if you configure the regulatory domains and set it to auto, many times the channels will go back to either 36 or 149.
I have not ran into trouble by myself, and as there are no special source code changed in my build regaring the basic wifi functionality, it better to discuss in the generic R7800 thread (or in a ath10k-ct thread).
I'm getting:
Tue Feb 15 15:02:18 2022 daemon.err nlbwmon[6220]: Netlink receive failure: Out of memory
Tue Feb 15 15:02:18 2022 daemon.err nlbwmon[6220]: Unable to dump conntrack: No buffer space available
Tue Feb 15 17:38:10 2022 daemon.err nlbwmon[6220]: Netlink receive failure: Object busy
Tue Feb 15 17:38:10 2022 daemon.err nlbwmon[6220]: Unable to dump conntrack: I/O error
Tue Feb 15 18:07:14 2022 daemon.err nlbwmon[6220]: Netlink receive failure: Object busy
Tue Feb 15 18:07:14 2022 daemon.err nlbwmon[6220]: Unable to dump conntrack: I/O error
Even with: net.core.rmem_max = 524288
Currently running build r18792-337e942290
sysctl -w net.core.rmem_max=524288
This most likely is not not enough for a lot of people, it depends on how much traffic you have.
I recommend:
| sysctl -w net.core.rmem_max=1573376 | |
|---|---|
| sysctl -w net.core.wmem_max=1573376 |
And don't forget to change /etc/config/nlbwmon:
option netlink_buffer_size 1573376