Belkin RT3200/Linksys E8450 WiFi AX discussion

I have a build from mid July 2023 that does not exhibit this issue tho. Both the commits you listed works fine with my build from mid July.

So looks like something changed in the WiFi config scripts, mt76 or both since then.

Losing WiFi post-reset is going to cause issues for users.

@hnyman is right in that once the wireless interface is enabled, Luci configuration is back to normal. If the router was reset, Luci shows the device as unknown and no configuration can be done. This behaviour has changed from what it was previously.

I could see this confusing users when master's changes percolate to 23.05 or later releases.

I suppose Luci need to be enhanced to take care of when device is not enabled upon factory reset. It gives the impression that the firmware is not working for wireless.

Yeah, I just listed to those as the explanation, why things works once you "enable" the radio. I guess that one possibility is that the things may have got semi-broken by the large netifd related change by @nbd , merged yesterday. And it might even have been fixed today with , or could be something similar in the new code.

1 Like

I am not actually sure when the change has actually been made (and if there is any actual bug).

I tried to test by flashing old builds from my archive, and got strange results:
with the 7-months old 2022-12-30 build,

  • I do get "path" into config file if I flash without /etc/config/wireless
  • but if I then delete the wireless file and do "wifi config" to re-generate it, I get "phy" instead.
root@router4:/etc/config# mv wireless wireless.plain22021230
root@router4:/etc/config# wifi config
root@router4:/etc/config# diff wireless.plain22021230  wireless
<       option path 'platform/18000000.wmac'
>       option phy 'wl0'
<       option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
>       option phy 'wl1'

root@router4:/etc/config# cat /etc/Compile_info.txt
OpenWrt master r21634-7272203022 / 2022-12-30

So, the initial config in the first boot differs from the supposedly same config re-generated later.

With the r21634-7272203022 / 2022-12-30 09:20

  • If there is "path", LuCI shows the chip type immediately ok, (but you still have to enable the radio in LuCI)
  • If there is "phy", LuCI initially shows just "Generic 802.11bg" for both (wrong), and only shows the proper chips like "MediaTek MT7915E 802.11acaxn" after enabling the radio.

But the change has happened somewhere in 2022.

With r20755-582c098c09 / 2022-09-26

  • initial config has "path" AND LuCI shows already initially the correct chip (and you still need to enable radios).
  • "wifi config" still produces "path", too, so the initial config file is the same as one generated later by "wifi config".

So, the two commits from October 2022 that I linked above are more likely the reason for the changed behaviour than the later changes.

(sorry I thought it was fixed but I see people are still experiencing the bug in the Github issue)

I think you are right.

This behaviour looks to be a by-product of the two commits you have identified that was committed at the end of 2022.

And the reason my build from mid-July did not see this issue after factory reset is, I think, a by-product of this commit:

Before this commit, when the wifi config script runs, it's likely that the board.json file has not been created yet, so the wifi config script ended up with path as a config in /etc/config/wireless. After this commit, as it checks that board.json has to be created before wifi config is executed, we end up with phy as a config instead in /etc/config/wireless.

So that's why you see this behaviour when you removed /etc/config/wireless and tries to re-create it, as board.json is already created at that point.

The issue is that if a wireless interface is disabled and the router rebooted, Luci will again revert to not being able to find the wireless interface and therefore not presenting the correct options for configuring disabled wireless interfaces. This will confuse many users relying on Luci, such as myself :stuck_out_tongue:

At this point, I think one of two things should happen:

  1. Change the behaviour of wifi config scripts to align with what Luci expected for disabled wireless interfaces; or
  2. Change Luci to support phy in the config file instead of just using path to configure disabled wireless interfaces.

I think 1. is probably easier to do compared to 2.?

I have no idea why the WiFi config script's behaviour was change to configure phy instead of path if the board.json file is found tho. Probably the devs forgot to sync this change to Luci.

I've concluded that the two issues are not related. I've obtained 100% CPU usage without the "event format" patch and also some time ago the router was inaccessible after running a while having the patch applied, maybe caused by a timeout but I did not use the timeout detection script then.

My reference is the TL-wr1043nd-v2 with openwrt stable: running ok, but kept having issues with wifi internet access cutting out every few days.

Got hold of a Belkin RT3200:

  • test with 22.03.5 a few weeks ago: bad performance on wired and Wifi
  • tested today with 23.05.rc3:
    • did complete reset of the device
    • set SSIDs + password
      according recommendations:
    • set country code correct
    • configured offloading via sw and hw
    • configured wed

Wifi performance is slow and lost every few minutes.
Even wired performance seems slow.

How do I best diagnose the issues?

it's very weird what connexion do you have ?

in fiber optic this is my resultat

My internet Connection is through ADSL modem.
After some more reading I'm starting to think that my ADSL modem ( and my RT3200 both having the same IP address is causing my past and present internet issues.

I tried to change the subnet of my old TPLink router to but unfortunately lost access to it.
Via LUCI - Network - Interfaces - LAN - edit button - General Settings - ipv4 address I was able to change the subnet to on the RT3200.
Things seem a lot better now. It looks like this may have solved the issues I was having.

Ok good news You Can change via winscp etc config network just in lan
save with disquette in French
Then open terminal command


You router change has changed ip :+1:

Price Alert
US residents, I think Walmart is clearing out stock on new RT3200 for $36.11 right now, no idea how long this will last.


Dunno how it looked yesterday but the price is now ~$50 and the seller is not Walmart but a private seller named "GreatDeals"

Just FYI:


For folks who have been plagued by the mt7915e timeout such as the message below:

mt7915e 0000:01:00.0: Message 000026ed (seq 13) timeout

, do you have wed turned on via /etc/modules.conf?

It could be that enabling wed may be causing the timeout.

An interesting discovery I noticed is that even though I removed the wed module entry in /etc/modules.conf and rebooted my router, I still see entries when I cat /sys/kernel/debug/ppe0/bind which suggest that wed is still enabled?

Edit: The entries described above appears to be from wired clients as I have hardware flow offload enabled. It’s not from wed.

In any case, if you see the occasional or even frequent timeouts, try removing the wed entry in /etc/modules.conf and see if it helps you.

1 Like

Yes, the entries you see in /sys/kernel/debug/ppe0/bind just show that hardware NAT acceleration is active. To check if wed is working you must find in that list the MAC addresses or IP-s of wireless clients, but wed works for latest mt76 builds only if the commit from is applied.
I usually compile and use a new build from main branch once every 3-4 days and regarding the timeout events, I did not detect any recently (the last was several weeks ago). I did encounter one or two total crashes or freezes (router inaccessible from LAN) but couldn't find something relevant in logs, the router started normal again and not in recovery mode. Maybe the new 6.1 testing kernel is the problem? And also the 100% CPU usage (for no reason) issue seems to become rarer.

1 Like

Have not had WED working in a while. I am running 23.05 snapshot and it's likely this commit restored it.

The device page suggests Hardware Flow Offloading in the Firewall section is not needed to use WED. That doesn't seem to be the case for me as I tried fully off, then with only Software Flow Offloading, both with no effect. Turning on Hardware Flow Offloading significantly reduced CPU usage.

I can now get just over 800Mbps with ~30% CPU usage, without WED working ~600Mbps with 100% usage.


@daniel I see you closed
about a week ago mentioning a better fix already being merged.

I'm not solid on the openwrt mechanics with the different repositories...
Is that better fix in the mt76 repository and would that be pulled if I install a current snapshot image?
If yes I'd give WED another try.

Does anyone with these devices face the issue mentioned here: Support for DLink M32 Mesh System and R32 Router - #56 by RolandoMagico

I saw it first on D-Link M32/R32 but I’m curious if it affects similar devices as well

What issue, exactly? The linked thread just shows the OpenWrt default, wifi being initially disabled.

In the wireless settings, all modules/devices are shown as "Generic Unknown" after startup.
Also scanning for WiFi networks doesn’t work as long as no AP is activated.

The expected behavior (tested with another OpenWrt device with different CPU): name of the WiFi devices is shown correctly and scanning networks is possible without enabling an AP before.

The issue is not present in v23.05.0-rc3 but in the latest snapshots

Thanks for mentioning this - I just flashed 23.05-RC3 on my RT3200 and I have WED enabled using bridger (dumb AP mode), and I was seeing strange timeouts in some of the iperf3 test runs that I was doing.

I haven't seen that message in my error logs, but I'd need to rerun some tests since I may have rebooted since I last saw them.

Other than the odd timeouts, the performance of 23.05-RC3 has been excellent. Crazy speeds using AX + 160Mhz and the latencies are excellent over wifi (with WED enabled).

1 Like