Belkin RT3200/Linksys E8450 WiFi AX discussion

It looks like we might be able to cherry pick a patch from 5.13 kernel to fix it, too. I will investigate

5 Likes

Extend lifetime, reduce power usage
By default the CPU will constantly run at the maximum frequency of 1.35Ghz. This increases heat and decreases the expected lifetime of the device. It will also consume more electricity. Therefore it's recommended for most users to change the default CPU governor to schedutil. This will allow the device to dynamically scale the CPU frequency. Changing is really easy, just add:

echo "schedutil" > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
to System → Startup → Local Startup Tab above the exit 0 statement in LuCi. Full instructions are on the forum. Performance is still good, but this change may increase latency. If you need the absolute lowest latency you can always undo this change, just know that your device will be constantly running at higher temperature.

Seems you should instruct users to also set the minimum frequency not just schedutil given the possible risk that many users following the instructions end up facing reboot issue if things change such that the ram check fails. As described above in this thread.

2 Likes

@Lynx - I edited the wiki, thanks for pointing that out.

4 Likes

I know this isn't the best issue report but I'm just curious if anyone else has encountered it.

Late January build (I believe January 29th), I had hardware and software offloading working correctly (outside of the known ipv6 issue).

Put new build from yesterday (2/1/22), which has the recent commit of the nft fixups, and only software offloading is working for me now. If I enable both, wifi clients will connect but will not transmit to WAN.

This was from a fresh install, no files used from previous builds.

Manually changed IP range in network and enable wireless, enabled packet steering, enabled hw and software offloading, no packets. Only variable in working/non-working for me is the hw offloading.

Sidenote: Thanks to everyone that has contributed to this build. It is my little $40 wonder router. It can saturate my almost gig Spectrum connection on wired. Wireless AX goes to about 600mbit from an IPad mini 6, which is a very respectable speed. I have 2 of these so I can always try patches on the secondary.

Update: Updated to today's build and HW works. Not sure what happened. Issue gone.

1 Like

I was just grepping through the kernel source wondering where one would set this. Do you have a suggestion?

Would you want to somehow restrict the find_available_min_freq?

One quick and dirty solution might be what we did in ipq806x:

ipq806x has now an init script that is run at boot, and the cpufreq parameters are set by the script. That might be an easy way to limit casual users from accidentally using the lowest OPP point.

For ipq806x the reason was similar, the lowest point was buggy on runtime if the CPU cache speed was too high.

See the forum discussion and the the commit

2 Likes

What's the fix if one gets stuck in this loop?

This is an excellent suggestion! https://github.com/openwrt/openwrt/pull/5025

1 Like

Power off via switch, wait 5 seconds or so, power on via switch.

1 Like

Ah, so it's not disastrous then. I imagined maybe it would result in not being able to recover.

1 Like

Depends... are you rebooting from a remote location without physical access to the device :angry:

2 Likes

Hi. I keep getting this error "Rejected request from RFC1918 IP to public server address" while accessing all my internal hosted websites from the internet. This issue arose immediately when I upgraded to the new snapshot "r18717-0e32c6baf3". Can someone help? I think it has something to do with the firewall.

I can see in Github that there is a lot of iptables related commits. Not sure if something is broken in those commits. Refer screenshot below for the issue.

My WiFi just became inaccessible. The SSID was still up, but I was unable to connect. In the logs I saw the following messages:

Thu Feb  3 12:24:17 2022 kern.err kernel: [592029.696011] mt7915e 0000:01:00.0: Message 00005aed (seq 2) timeout
Thu Feb  3 12:24:38 2022 kern.err kernel: [592050.175789] mt7915e 0000:01:00.0: Message 00005aed (seq 3) timeout
Thu Feb  3 12:24:58 2022 kern.err kernel: [592070.655620] mt7915e 0000:01:00.0: Message 000094ed (seq 4) timeout
Thu Feb  3 12:25:19 2022 kern.err kernel: [592091.135431] mt7915e 0000:01:00.0: Message 000026ed (seq 5) timeout
Thu Feb  3 12:25:39 2022 kern.err kernel: [592111.615247] mt7915e 0000:01:00.0: Message 00005aed (seq 6) timeout
Thu Feb  3 12:26:00 2022 kern.err kernel: [592132.095107] mt7915e 0000:01:00.0: Message 00005aed (seq 7) timeout
Thu Feb  3 12:26:20 2022 kern.err kernel: [592152.574915] mt7915e 0000:01:00.0: Message 00005aed (seq 8) timeout

Restarting the WiFi did not fix it. Rebooting did though. Any idea what might have caused this, and more importantly, how to fix this?

Looks your firewall rule is not working properly. Maybe due to the latest snapshots using Firewall4. I can see in your address bar that you are trying to access your hosted Nextcloud instance. However, from the certificate it seems you actually connected to the Luci.

I am assuming you are trying to access your internally hosted website via it's public IP, while being connected to the same network as where the website is being hosted. And because you are actually connecting to Luci instead, you get that message because Luci does NOT allow you to connect to its public interface with a private IP.

To verify my assumptions, you can disable that behavior by installing luci-app-uhttpd and turning off the option "Ignore private IPs on public interface". This should allow you to connect to Luci properly. If that is indeed the case you need to fix two things:

  1. First, make sure your Luci is no longer accessible from the internet, as that is a major security issue. The webserver used by Luci is not hardened and should never be opened to the internet.
  2. Fix the firewall rule so that you actually connect to Nextcloud instead of Luci. Post the output of cat /etc/config/firewall here so we can help.

Also, I suggest opening a new topic, since this isn't a RT3200/E8450 specific issue.

What you said is absolutely right. I can access my internally hosted websites through my cellular internet. Disabling "Ignore private IPs on public interface" connects me to luci from public IP and not my internal hosted webserver. I am also not able to access my network drives on lan. How can I resolve all this?

Firewall config output is as follows

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list network 'wan'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config rule
        option name 'Support-UDP-Traceroute'
        option src 'wan'
        option dest_port '33434:33689'
        option proto 'udp'
        option family 'ipv4'
        option target 'REJECT'
        option enabled '0'

config include
        option path '/etc/firewall.user'

config redirect
        option target 'DNAT'
        option name 'http'
        list proto 'tcp'
        option src 'wan'
        option src_dport '80'
        option dest 'lan'
        option dest_ip '192.168.31.150'
        option dest_port '80'
        option reflection_src 'external'

config redirect
        option target 'DNAT'
        option name 'https'
        option src 'wan'
        option src_dport '443'
        option dest 'lan'
        option dest_ip '192.168.31.150'
        option dest_port '443'
        list proto 'tcp'
        list proto 'udp'
        option reflection_src 'external'

config redirect
        option target 'DNAT'
        option name 'ftp'
        list proto 'tcp'
        option src 'wan'
        option src_dport '21'
        option dest 'lan'
        option dest_ip '192.168.31.150'
        option dest_port '21'
        option reflection_src 'external'

config redirect
        option target 'DNAT'
        option src 'wan'
        option src_dport '61761'
        option dest 'lan'
        option dest_ip '192.168.31.150'
        option dest_port '61761'
        option name 'qbittorrent'

config redirect
        option target 'DNAT'
        option name 'wireguard'
        list proto 'udp'
        option src 'wan'
        option src_dport '51820'
        option dest 'lan'
        option dest_ip '192.168.31.150'
        option dest_port '51820'

config redirect
        option target 'DNAT'
        option name 'ftps'
        list proto 'tcp'
        option src 'wan'
        option src_dport '40000-45000'
        option dest 'lan'
        option dest_ip '192.168.31.150'
        option dest_port '40000-45000'
        option reflection_src 'external'

config redirect
        option target 'DNAT'
        option name 'plex'
        list proto 'tcp'
        option src 'wan'
        option src_dport '32400'
        option dest 'lan'
        option dest_ip '192.168.31.150'
        option dest_port '32400'

config rule
        option name 'Filter-Parental-Controls'
        list proto 'all'
        option src 'lan'
        list src_mac '92:EE:B9:50:14:3A'
        option dest 'wan'
        option target 'REJECT'
        option enabled '0'

config include 'miniupnpd'
        option type 'script'
        option path '/usr/share/miniupnpd/firewall.include'
        option family 'any'
        option reload '1'

config include 'opennds'
        option type 'script'
        option path '/usr/lib/opennds/restart.sh'

This is definitely not the case for me. I tried today's snapshot using firewall4, starting from default settings and was only able to get internet access briefly as I started manually adding back my settings. I had PPPoE, Wireless settings and SW offloading turned on then noticed it wasn't working even after a reboot.

Reverted back to firewall and it's working.

1 Like

Firewall4 was the issue. Reverted back to firewall

1 Like

So, it seems the new and fresh firewall4 doesn't support hw offloading (yet...). https://git.openwrt.org/?p=project/firewall4.git;a=commit;h=7cb10c809314261c20ddca069eacd469adf44be3. But firewall3 could be the cause for crashing the system according to Daniel & "netfilter folks" who suspected a race condition. Unfortunately, without solving this hw offloading issue, the wireless-ethernet-dispatch work that has been done so far is in vain... My enthusiasm has dropped :slightly_frowning_face:

It's not been done in vain. It's temporarily being disabled, but will be reenabled again once it's properly working.

Using an image with fw4 is not recommended, its alpha! The Luci-GUI is not yet working, there are no more custom rules and most packages and scripts are not prepared yet