Belkin RT3200/Linksys E8450 WiFi AX discussion

Using iperf service on my main RT3200 AP running the prior snapshot (r20856) I would use my phone to test network transitions (FT) between APs and would get pretty good results ~300-700Mpbs everywhere - working great!

After updating to snapshot (r21517), I noticed that I can no longer use iperf in this manner on the main AP because although I am still getting a good connections, iperf only works on the AP where initiated (i.e. I start on AP1, walk to AP2 iperf result =0, walk back to AP1 iperf=600). Thus I setup another iperf server not on an AP and this behavior goes away.

Definitely unexpected... I see there was a change in iperf3 (update to 3.12) in between my snapshots, but I downgraded to 3.11-1 and problem persists. Is there something weird with the wireless interface in this snapshot that might cause this?

Hey Daniel,

Still stuck in this crash loop sadly, can I snag a copy of the binaries with the debug info set up? Would love to try and solve this :sob:

Running OpenWrt SNAPSHOT r21452-1e240f60a5 ("kernel: modules/lib-lz4: add lz4hc_compress"), just spotted the following in the dmesg of my client computer (Intel AX200, iwlwifi):

[327897.958286] wlp3s0: authenticate with MA:CA:DD:RE:SS:SS
[327897.964049] wlp3s0: bad VHT capabilities, disabling VHT
[327897.964051] wlp3s0: Invalid HE elem, Disable HE
[327897.964053] wlp3s0: 80 MHz not supported, disabling VHT

From the backlog it seems that there's not been an mt76 code drop since, I wonder whether the previous mt76 fixes may have broken something in the way the RT3200 advertises it's .ac/.ax capabilities?

1 Like

Hi folks.

I am running this firmware on my belkin RT3200 since it was in beta.

Now it seems that it is in the mainstream, and RT3200 is fully compatible with version 22.03 or opewrt.

I am currently running SNAPSHOT - r20893-ffd29a55c3 on my Belkin RT3200 -Ubi snapshot loaded it is idenfified as Linksys E8450 (UBI)-.

i woul like to upgrade to the latest mainstream version -22.03.2, I think- as currently I cannot be so dependent of development issues and do not follow development evolution.

But I am not sure of how to upgrade it to that mainstream version.

And I am not sure if there will be compatibility issues.

It seems it has migrated form firewallv3 to firewallv4 (I think my system is currently using IPtablesv3 but I am not sure, as it seems that firewallv4 is installed in the system)

Would be iptables migrated transparently of there are compatibility issues yet?

How is it the best way of dealing with these upgrade?
Can it be made using luc attended sysupgrade? (it seems it only lists snapshot versions)

Thank you for any advice.

EDITED: it seems that I can confirme I am using iptable v4 and firewall 4, as firewall4 is installed in the system and I can see no firewall3 module.

It seems that I have upgraded previously in the las snapthot install.

I would like to change now to the master install to be sure I am runing a stable version.

But I cannot, there is no option to change to master, only a new snapshot version.
MAY IT BE because the snapshot version I am running is ahead of the 22.03.2 version that is the last published in the master now?

If that is the problem I can just wait to the next master upgrade and move to it.

1 Like

1.Follow this link to the firmware selector for Openwrt 22.03.2:
2.Download the sysupgrade ubi file.
3. Use the Luci GUI interface to install it.

1 Like

Thanks a lot, I will try with care.

I usually use the attended sysupgrade, so I am not sure how to preceed to perform the upgrade manually.

There are several files there: the sysupgrfade, the bootloader, kernel and preloader.

Should I flash every image or just the sysupgrade?

In your answer it seems that only sysupgrade file is need, but I want to be sure before proceeding.

If I have to flash the bootloader and kernel too, should I proceed in a particular order?

I something goes wrong I would like to revert to the current status.

Should I backup just the ubi mtdblock and configuration file or all the blocks?

1 Like

As you are already running a rather recent master snapshot version of the firmware, you only need the sysupgrade image when you downgrade to 22.03. no need to do anything for bootloader. (Kernel is part of the sysupgrade image)

It would be best to use just the 22.03.2 release image, and not auc. That would help you to get rid of possible package selection differences between master and 22.03.

You are mixing master, snapshot and 22.03.
Master and 22.03 are branches, while "snapshots" are usually daily test builds made from master. 22.03.2 is not "published from master".
You are currently likely running a master snapshot and want to downgrade to older stable 22.03.2.

Ps. As you use a recent master, you naturally use the firewall4.


Thank you for your detailed answer.

If I have understood It well, 22.03 2 is the state of the máster at somepoint when It is decided that the introduced changes are stable.

Snapshots are ongoing development that are the state of the máster at a viven time.

My snapshot seems to be a bit more recent that the 22.03.2 so may be there would be done kind of problem if i revert to a previous state and there have been changes in parameter config in some module or if some module has been upgraded and is not fully backwards compatible.

So may be the BEST option is to wait a bit until Next stable release to install that release over current snapshot?

By the way Happy holidays you all.

Well, no. You understood it wrong.

22.03.2 is based on the March 2022 code, when the new stable 22.03 branch was branched off master of that time. Since then some bug fixes have been applied to 22.03 plus some new features backported from master to the 22.03 branch. But largely 22.03 is still the same 9 months old code. 22.03.0, 22.03.1 and 22.03.2 are release tags in that stable 22.03 branch. But they have nothing to do with the current master. The history deviated in March 2022.

But master and 22.03 are still rather compatible for rt3200. You should be able to downgrade to 22.03.2

Likely the next stable maintenance release will be 22.03.3, still made from the 22.03 branch and no relation to the current master. Waiting for that will not change anything materially.

The next new stable release (based on the current master) might be something like 23.05 brached in May 2023, and first real release in August???? Pure guess at this point, but the release cycle has been 12-18 months.


OK, thank you, so each major version is a new branch, from master, more like a fork, and only some fixes are applied from master to provide the minor versions (no new features).

If there are new features in my snapshot not implemented in 22.03 there is a risk of some incompatibility.

But as it seems that it is not so ahead from the 22.03 branch, I hope it will work with no problem.

I will make a backup of the sysupgrade and config previously just in case I have to revert to current version.

And I will make a sysupgrade with the provided 22.03.2 sysupgrade file to downgrade keeping current configuration options.

Thank you very much.

OK, I have upgraded (well technically downgraded) to 22.03.2

The interface is different (like in other router I have) as it seems it uses 2020 interface and there is no unattended sysupgrade option, only using flash to upgrade.

It seems to be working well, with the previous config settings.

The only thing is not working is wireguard.

I had been making tests with wireguard and I had a wiredguard vpn interface.

I have installed wireguard protocol and luci modules but it seems it does not work yet, it says unsupported protocol.

Is that due to wireguard protocol in the snapshot being more modern and incompatible with previous version?


AT the end, I have REVERTED to snapshot version in order to have wireguard working properly, as wireguard implementation seems to be quite more recent in snapshot that in 22.3.2

I will wait till there is a major version (23.3?) to revert jump into master branch.

It seems there is no too much problem to do that using the firmware upgrade and I can take backups previously.

Snapshots are working quite well and smooth till now.

Feel free to install other LuCI themes or luci-app-attendedsysupgrade for semi-automated updates.

You probably need also kernel modules and wireguard userland tools for the LuCI protocol to work.

There have been no significant changes to wireguard since the 22.03 release and I myself as well as many others have user wireguard on 22.03 and it works.

See also:

1 Like


I have wireguard working in snapshot.

But when i install 22.3.2 It does no work. Interface is there but It says unknown protocolo.

I have installed kmod-wireguard, wireguard-tools and luci-wireguard but It does not work and i cannot add a new wireguard interface, there is no option in the 'new interface menu' menu for that.

I had the same issue, but it turned out that you just need to restart the network service. Just restart the router after installing wireguard

1 Like

Thank you, i Will try It again

Been getting some odd segfaults recently on some of the latest snapshots. I believe its due to the WAN losing its link and/or IP address updates from WAN (this is characteristic of my ISP -- when my fiber ONT first starts, it assigns a private ip address and then shifts to DMZ mode with a public ip address) and can also be coupled with crashes on the gateway. Batman-adv / mesh seemed to make it worse, so it has been removed since then. I had deleted all of the batman/mesh out of my configuration when this last segfault occurred, but I had not uninstalled the modules (which I have now done).

With the mesh and everything else setup, I was previously able to trigger it by forcing a restart of my WAN interface. I installed a snapshot on 12-11-2022, and it seemed to be stable, but it started bombing out on 12-26-2022 with no configuration or snapshot changes. Updating to the latest snapshots in the last two days also did not solve the issue. With those configurations in place, WAN would be completely locked up and there was high CPU utilization from eth0 going up and down repeatedly (the last few lines would repeat between other syslog entries).

After removing my batman-adv and mesh configurations on the latest snapshot, a restart of the WAN interface doesn't automatically trigger the segfault anymore, but I have had it randomly occur since then.

Tue Dec 27 16:55:10 2022 kern.warn kernel: [   42.117341] ------------[ cut here ]------------
Tue Dec 27 16:55:10 2022 kernel: [   42.121985] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 5 timed out
Tue Dec 27 16:55:10 2022 kern.warn kernel: [   42.129025] WARNING: CPU: 0 PID: 0 at dev_watchdog+0x304/0x310
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.134872] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet batman_adv pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7915e mt7615e mt7615_common mt76_connac_lib mt76 mac80211 cfg80211 slhc nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c hwmon crc_ccitt compat seqiv leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd gpio_button_hotplug usbcore usb_common
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.197149] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S                5.15.85 #0
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.204548] Hardware name: Linksys E8450 (UBI) (DT)
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.209422] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.216385] pc : dev_watchdog+0x304/0x310
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.220395] lr : dev_watchdog+0x304/0x310
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.224403] sp : ffffffc008003d80
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.227713] x29: ffffffc008003d80 x28: 0000000000000140 x27: 00000000ffffffff
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.234859] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.242003] x23: ffffff8000d214c0 x22: 0000000000000001 x21: ffffffc008ae6000
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.249149] x20: ffffff8000d21000 x19: 0000000000000005 x18: 0000000000000157
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.256294] x17: ffffffc0173d8000 x16: ffffffc008004000 x15: ffffffc008afa260
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.263439] x14: 0000000000000405 x13: 0000000000000157 x12: ffffffc008003aa8
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.270584] x11: ffffffc008b52260 x10: 00000000fffff000 x9 : ffffffc008b52260
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.277730] x8 : 0000000000000000 x7 : ffffffc008afa260 x6 : 0000000000000001
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.284875] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.292018] x2 : ffffff801fea5080 x1 : ffffffc0173d8000 x0 : 000000000000003f
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.299163] Call trace:
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.301606]  dev_watchdog+0x304/0x310
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.305269]  call_timer_fn.constprop.0+0x20/0x80
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.309891]  __run_timers.part.0+0x208/0x284
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.314161]  run_timer_softirq+0x38/0x70
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.318085]  _stext+0x11c/0x294
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.321226]  __irq_exit_rcu+0xdc/0xfc
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.324890]  irq_exit+0xc/0x1c
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.327942]  handle_domain_irq+0x60/0x8c
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.331872]  gic_handle_irq+0x64/0x8c
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.335537]  call_on_irq_stack+0x28/0x44
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.339461]  do_interrupt_handler+0x4c/0x54
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.343646]  el1_interrupt+0x2c/0x4c
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.347228]  el1h_64_irq_handler+0x14/0x20
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.351330]  el1h_64_irq+0x74/0x78
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.354731]  arch_cpu_idle+0x14/0x20
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.358306]  do_idle+0xc0/0x140
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.361453]  cpu_startup_entry+0x24/0x50
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.365380]  rest_init+0xc4/0xd0
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.368609]  arch_call_rest_init+0xc/0x14
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.372624]  start_kernel+0x5b4/0x5d4
Tue Dec 27 16:55:10 2022 kern.debug kernel: [   42.376289]  __primary_switched+0xa0/0xa8
Tue Dec 27 16:55:10 2022 kern.warn kernel: [   42.380303] ---[ end trace a3cc48772959d50d ]---
Tue Dec 27 16:55:10 2022 kern.err kernel: [   42.384978] mtk_soc_eth 1b100000.ethernet eth0: transmit timed out
Tue Dec 27 16:55:10 2022 kernel: [   42.391551] mtk_soc_eth 1b100000.ethernet eth0: Link is Down
Tue Dec 27 16:55:10 2022 kernel: [   42.412177] mtk_soc_eth 1b100000.ethernet eth0: configuring for fixed/2500base-x link mode
Tue Dec 27 16:55:10 2022 kernel: [   42.422298] mtk_soc_eth 1b100000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx

Thank you, I have reinstalled the firmware and wireguard protocols, rebooted and now it is working.

I have 22.03.2 installed with wireguard and everything working correctly.

Thanks to everybody that helped (or read my messages).


Would someone be able to confirm that this documenation has a typo?

EDIT: I stand corrected. I missed this in the driver when I quickely peeked at it.

config wifi-device 'radio1'
option he_su_beamformee '1'
option he_bss_color '8'


option he_su_beamformee '1' 

should be

option he_su_beamformer '1'

Thank you.

1 Like

Well, there are both of those options in the mac80211 wifi driver infra...


@hnyman thanks for pointing out my miss on this one.