Belkin RT3200/Linksys E8450 WiFi AX discussion

I have applied the this "11a HE80 (add htmode HE80 to /etc/config/wireless - 1200 Mbit link speed)" to my configuration as mentiond in the op. I am not facing any disconnection issues on my 5G band.

Experiencing high bufferbloat (+147ms) on wifi with SQM enabled. However, zero bufferbloat on LAN with SQM enabled. Is this normal?

Okay I am going to try it. I had option htmode 'VHT80'.

LuCI support for 802.11ax should be working fine since luci^4286c84825c15f4d36f294b2ea28071667a4be7e.

guys, I have the another trouble:


root@OpenWrt:~# opkg install luci
Installing luci (git-20.074.84698-ead5e81) to root...
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/luci/luci_git-20.074.84698-ead5e81_all.ipk
Collected errors:
 * pkg_hash_check_unresolved: cannot find dependency libubus20210603 for uhttpd-mod-ubus
 * pkg_hash_fetch_best_installation_candidate: Packages for uhttpd-mod-ubus found, but incompatible with the architectures configured
 * pkg_hash_check_unresolved: cannot find dependency libubus20210603 for rpcd
 * pkg_hash_fetch_best_installation_candidate: Packages for rpcd found, but incompatible with the architectures configured
 * pkg_hash_check_unresolved: cannot find dependency libubus20210603 for rpcd-mod-file
 * pkg_hash_fetch_best_installation_candidate: Packages for rpcd-mod-file found, but incompatible with the architectures configured
 * pkg_hash_check_unresolved: cannot find dependency libubus20210603 for rpcd-mod-luci
 * pkg_hash_fetch_best_installation_candidate: Packages for rpcd-mod-luci found, but incompatible with the architectures configured
 * pkg_hash_check_unresolved: cannot find dependency libubus20210603 for cgi-io
 * pkg_hash_fetch_best_installation_candidate: Packages for cgi-io found, but incompatible with the architectures configured
 * pkg_hash_check_unresolved: cannot find dependency libubus20210603 for rpcd-mod-iwinfo
 * pkg_hash_fetch_best_installation_candidate: Packages for rpcd-mod-iwinfo found, but incompatible with the architectures configured
 * pkg_hash_check_unresolved: cannot find dependency libubus20210603 for rpcd-mod-rrdns
 * pkg_hash_fetch_best_installation_candidate: Packages for rpcd-mod-rrdns found, but incompatible with the architectures configured
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci:
 *      libubus20210603
 * opkg_install_cmd: Cannot install package luci.

What can I do with it?

Wait until buildbot has built the updated packages. Ubus was updated yesterday, and the Luci package did not yet know about the new version when you tried installing it. (Ubus is built along kernel and images by phase1 buildbot, while LuCI is built later by the phase2 packages buildbot)

(Not related to e8450 specifically)

1 Like

Using the latest trunk version. Ping modem from router will have ping spike after the router up for couple hours. Not using SQM. Disabled both WiFi won't help. Ping will go from 2ms to about 150ms every couple seconds. Reboot will fix it for couple hours. Anyone has that issue?

i have really zero problem with the router, you use the ubi version or version sysupgrade classic

i' am on 5.10.46 actually and all work perfectly

I am using the non-ubi version and no problems with Wifi. I have noticed that I don't get A+ rating on wifi with SQM and cake on dslr site. I get A+ rating on LAN.

I use ubi version. 5.10.46 trunk. Ping spike is like below. The address is the modem. Shouldn't have over 3ms ping.

PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=1.875 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=1.371 ms
64 bytes from 192.168.1.1: seq=2 ttl=64 time=1.576 ms
64 bytes from 192.168.1.1: seq=3 ttl=64 time=2.141 ms
64 bytes from 192.168.1.1: seq=4 ttl=64 time=1.939 ms
64 bytes from 192.168.1.1: seq=5 ttl=64 time=2.411 ms
64 bytes from 192.168.1.1: seq=6 ttl=64 time=231.462 ms
64 bytes from 192.168.1.1: seq=7 ttl=64 time=142.249 ms
64 bytes from 192.168.1.1: seq=8 ttl=64 time=2.103 ms
64 bytes from 192.168.1.1: seq=9 ttl=64 time=1.242 ms
64 bytes from 192.168.1.1: seq=10 ttl=64 time=1.539 ms

Yes you are right I am getting the same when pinging the gateway on wifi. That's why I am getting bad rating on SQM. Log is attached below. No issues on lan. Openwrt snapshot "r17073". Any developer can help?

Reply from 192.168.31.1: bytes=32 time=1ms TTL=64
Reply from 192.168.31.1: bytes=32 time=1ms TTL=64
Reply from 192.168.31.1: bytes=32 time=1ms TTL=64
Reply from 192.168.31.1: bytes=32 time=1ms TTL=64
Reply from 192.168.31.1: bytes=32 time=1ms TTL=64
Reply from 192.168.31.1: bytes=32 time=3ms TTL=64
Reply from 192.168.31.1: bytes=32 time=1ms TTL=64
Reply from 192.168.31.1: bytes=32 time=27ms TTL=64
Reply from 192.168.31.1: bytes=32 time=137ms TTL=64
Reply from 192.168.31.1: bytes=32 time=6ms TTL=64
Reply from 192.168.31.1: bytes=32 time=5ms TTL=64
Reply from 192.168.31.1: bytes=32 time=606ms TTL=64
Reply from 192.168.31.1: bytes=32 time=32ms TTL=64
Reply from 192.168.31.1: bytes=32 time=268ms TTL=64
Reply from 192.168.31.1: bytes=32 time=12ms TTL=64
Reply from 192.168.31.1: bytes=32 time=107ms TTL=64
Reply from 192.168.31.1: bytes=32 time=65ms TTL=64
Reply from 192.168.31.1: bytes=32 time=136ms TTL=64
Reply from 192.168.31.1: bytes=32 time=6ms TTL=64
Reply from 192.168.31.1: bytes=32 time=1ms TTL=64
Reply from 192.168.31.1: bytes=32 time=62ms TTL=64
Reply from 192.168.31.1: bytes=32 time=607ms TTL=64
Reply from 192.168.31.1: bytes=32 time=599ms TTL=64
Reply from 192.168.31.1: bytes=32 time=519ms TTL=64
Reply from 192.168.31.1: bytes=32 time=38ms TTL=64
Reply from 192.168.31.1: bytes=32 time=190ms TTL=64
Reply from 192.168.31.1: bytes=32 time=7ms TTL=64
Reply from 192.168.31.1: bytes=32 time=145ms TTL=64
Reply from 192.168.31.1: bytes=32 time=30ms TTL=64

Pings from google on Wifi

Reply from 142.250.77.46: bytes=32 time=63ms TTL=119
Reply from 142.250.77.46: bytes=32 time=413ms TTL=119
Reply from 142.250.77.46: bytes=32 time=71ms TTL=119
Reply from 142.250.77.46: bytes=32 time=1506ms TTL=119
Reply from 142.250.77.46: bytes=32 time=507ms TTL=119
Reply from 142.250.77.46: bytes=32 time=2036ms TTL=119
Reply from 142.250.77.46: bytes=32 time=321ms TTL=119
Reply from 142.250.77.46: bytes=32 time=308ms TTL=119
Reply from 142.250.77.46: bytes=32 time=361ms TTL=119
Request timed out.
Reply from 142.250.77.46: bytes=32 time=1359ms TTL=119
Reply from 142.250.77.46: bytes=32 time=196ms TTL=119
Reply from 142.250.77.46: bytes=32 time=499ms TTL=119
Reply from 142.250.77.46: bytes=32 time=294ms TTL=119
Reply from 142.250.77.46: bytes=32 time=824ms TTL=119
Reply from 142.250.77.46: bytes=32 time=127ms TTL=119
Reply from 142.250.77.46: bytes=32 time=279ms TTL=119
Reply from 142.250.77.46: bytes=32 time=1877ms TTL=119
Reply from 142.250.77.46: bytes=32 time=130ms TTL=119
Reply from 142.250.77.46: bytes=32 time=395ms TTL=119
Reply from 142.250.77.46: bytes=32 time=3ms TTL=119
Reply from 142.250.77.46: bytes=32 time=321ms TTL=119
Reply from 142.250.77.46: bytes=32 time=18ms TTL=119
Reply from 142.250.77.46: bytes=32 time=10ms TTL=119
Reply from 142.250.77.46: bytes=32 time=82ms TTL=119
Reply from 142.250.77.46: bytes=32 time=161ms TTL=119
Reply from 142.250.77.46: bytes=32 time=94ms TTL=119
Reply from 142.250.77.46: bytes=32 time=252ms TTL=119
Reply from 142.250.77.46: bytes=32 time=121ms TTL=119

I am sending ping from router to modem got that ping spike. So shouldn't related to WiFI IMO. Fresh boot/reboot won't have that issue. Only happen when router has been running for couple hours.
Developer help is needed.

I have changed the wifi 5ghz channel from "173" to "auto" and now the pings on wifi have reduced to 3-5 ms. I also changed the Country Code from "India" to "driver default". Hope this is useful to others.

So i had a really weird issue, my belkin rt3200:

  1. reset itself to stock openwrt at night
  2. it did not see the 5Ghz interface
  3. powering off briefly did nothing
  4. powering off for a few minutes got it back to previously configured state with both 5 GHz and 2.4GHz wifi configured and working
  5. i had read-only filesystem after that (couldn't update packages)

After i've tried reflashing openwrt-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade.itb (i used installer then this file to set it up 2 days ago) i'm stuck on 2 solid orange/amber LEDs and cannot snap the router out of it, i've tried:

  • powering off for 10 minutes
  • holding reset button on powered device
  • holding reset button while powering on the device

It looks like it responds to ping 192.168.1.1 but otherwise i can't do anything with it.
Do you have any idea how to recover from it?

Update: I read anything could be fixed through JTAG? What kind of hardware and linux software do i need to work with it? Note: i've RPi 512 MB and RPi4

Have you tried this?

Post OpenWRT "recovery mode" process

  1. Hold down the "reset" button below the "WPS" button whilst powering on the device.
  2. Release the button once the power LED turns a orange/yellow color.

This will remove any user configuration errors and allow restoring or upgrading from ssh/http/tftp.

Source: https://github.com/dangowrt/linksys-e8450-openwrt-installer

Yes i tried the reset button while powering on, nothing happened (still both leds solid orange and not exposing any service - ssh/http)

Actually I did follow loading recovery from TFTP and it worked.

Glad it did.

Is it normal that you cannot run opkg upgrade ... due to read-only filesystem?

I read this somewhere so maybe someone can confirm.

As far as I can tell the correct answer to this question is that there is no equivalent for apt upgrade on OpenWrt and no set of commands that will create equivalent functionality. OpenWrt repos aren't maintained with the intention of keeping end user's packages updated (you're expected to move from release to release by flashing) and opkg does not handle or even check dependencies.

Is anyone else having issues with 160MHz and higher AX channels? I'm trying to set my routers up to use channels between 128 and 157 (those are interference-free), but for some reason, I'm getting errors in hostapd:

Wed Jul  7 17:53:07 2021 daemon.notice hostapd: Remove interface 'wlan1'
Wed Jul  7 17:53:07 2021 daemon.notice hostapd: wlan1: interface state DISABLED->DISABLED
Wed Jul  7 17:53:07 2021 daemon.notice hostapd: wlan1: AP-DISABLED
Wed Jul  7 17:53:07 2021 daemon.notice hostapd: wlan1: CTRL-EVENT-TERMINATING
Wed Jul  7 17:53:07 2021 daemon.err hostapd: rmdir[ctrl_interface=/var/run/hostapd]: Permission denied
Wed Jul  7 17:53:07 2021 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan1 wasn't started
Wed Jul  7 17:53:07 2021 daemon.notice hostapd: nl80211: deinit ifname=wlan1 disabled_11b_rates=0
Wed Jul  7 17:53:07 2021 kern.info kernel: [ 2304.386310] device wlan1 left promiscuous mode
Wed Jul  7 17:53:07 2021 kern.info kernel: [ 2304.390865] br-lan: port 6(wlan1) entered disabled state
Wed Jul  7 17:53:07 2021 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy1.conf (phy wlan1) --> new PHY
Wed Jul  7 17:53:07 2021 kern.info kernel: [ 2304.847925] br-lan: port 6(wlan1) entered blocking state
Wed Jul  7 17:53:07 2021 kern.info kernel: [ 2304.853317] br-lan: port 6(wlan1) entered disabled state
Wed Jul  7 17:53:08 2021 kern.info kernel: [ 2304.858920] device wlan1 entered promiscuous mode
Wed Jul  7 17:53:08 2021 kern.info kernel: [ 2304.864188] br-lan: port 6(wlan1) entered blocking state
Wed Jul  7 17:53:08 2021 kern.info kernel: [ 2304.869517] br-lan: port 6(wlan1) entered forwarding state
Wed Jul  7 17:53:08 2021 daemon.notice hostapd: wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
Wed Jul  7 17:53:08 2021 kern.info kernel: [ 2304.878245] br-lan: port 6(wlan1) entered disabled state
Wed Jul  7 17:53:08 2021 daemon.notice hostapd: wlan1: interface state COUNTRY_UPDATE->HT_SCAN
Wed Jul  7 17:53:08 2021 daemon.err hostapd: Interface initialization failed
Wed Jul  7 17:53:08 2021 daemon.notice hostapd: wlan1: interface state HT_SCAN->DISABLED
Wed Jul  7 17:53:08 2021 daemon.notice hostapd: wlan1: AP-DISABLED

The funny thing is, channel 128 on ONE of the two RT3200's I have, works most of the time (but a reboot can kill it, forcing me to manually reload WiFi a few times till it works again). On the other, it just flat out refuses to work.

Setting the adapter to 80MHz + lower channels (up to channel 60) results in no such behaviour.

This started happening on the latest snapshot (previously, 160MHz didn't work at all, but higher channels did).