Belkin RT3200/Linksys E8450 WiFi AX discussion

I'm pivoting back to the mac80211 investigation from the mt7530 switch driver. So I'm going on a hunch where I suspected that a txq may be inserted multiple times in the rb tree (due to previous logs where a txq appears multiple times where it was checked for airtime), so I added a counter into the txq structure, where for each scheduling of the txq into the rb tree it will be incremented and for every unscheduling of the txq will result in a count decrement.

I obtained such logs:

[162182.886060] net_ratelimit: 8 callbacks suppressed
[162182.886071] __ieee80211_insert_txq: txq[ffffffc011a0b6e0] scheduled count = [2]!
[162182.899416] __ieee80211_unschedule_txq: txq[ffffff80037da0f0] scheduled count = [1]!

The codes to increment/decrement the counter is at the end of each respective functions. The above logs does not appear immediately upon a client being associated. I do not know what triggers it, but it shows up after a while.

I'm not sure if that's the correct location to detect such a situation. It seems logical to me.

Is this an issue? I would assume that a txq should only be in the rb tree in one and only one location.

1 Like

Yeah, it can only be in one position. As in, the data structure won't allow it to be in multiple places, and the code has checks that this doesn't happen; so your count is wrong... :slight_smile: My guess would be you forgot to decrement the count when a TXQ is being reinserted in ieee80211_resort_txq() ?

Yes, and I have to say that the OpenWrt implementation in the E8450 is way more stable and performs way better than the in the R7800. I have both routers and the E8450 is my head router.

I have not noticed any difference. The E8450 5GHz antennas handle way better the beamforming in 3D space. So, at the end, under load, it performs better in a house with 2-3 floors.

Wifi 6 routers improve wireless traffic even when only wifi 5 devices are used. Obviously not as much as when both the station and the devices are both 802.11ax, but you can instantly notice the difference under heavy wifi 5 traffic. It was a huge difference when comparing the R7800 to the E8450.

3 Likes

Spot on! ieee80211_resort_txq() also removes txq from the rb tree. Have added decrement code there. Will continue to monitor. Thanks!

Hi folks, I am trying to factory reset my RT3200 back to stock firmware. I am currently running the UBI snapshot from 1st April. I am following the restoration guide on Github but I seem to have lost the original files I backed up. I've no idea what I've done with them :frowning:

Are thre default mtdx files somewhere I can use to get past this or am I totally screwed? I belive the below is what I have to do, but can't because I don't have a backup of these files. Thank you!

ubidetach -d 0
insmod mtd-rw i_want_a_brick=1
mtd write /tmp/mtd0 /dev/mtd0
mtd write /tmp/mtd1 /dev/mtd1
mtd write /tmp/mtd2 /dev/mtd2
mtd write /tmp/mtd3 /dev/mtd3

Long time reader, first time poster. Thanks for all the hard work!

Replying to this sub-thread here... Have I have been observing the behavior of some stations not being able to connect to 2.4GHz every 5-8 days or so. Members of the household have gotten effective at restarting the entire system. I am running OpenWrt SNAPSHOT r19138-4ecf8346c0 at the minute. When I get the chance to look into the logs, I do not see too much in the kernel log but the system log is full of hostadp messages.

Mon Mar 28 07:45:45 2022 daemon.info hostapd: wlan0: STA AA:AA:AA:AA:AA:AA IEEE 802.11: authenticated
Mon Mar 28 07:45:45 2022 daemon.info hostapd: wlan0: STA AA:AA:AA:AA:AA:AA IEEE 802.11: associated (aid 3)
Mon Mar 28 07:45:46 2022 daemon.info hostapd: wlan0: STA BB:BB:BB:BB:BB:BB IEEE 802.11: authenticated
Mon Mar 28 07:45:46 2022 daemon.info hostapd: wlan0: STA BB:BB:BB:BB:BB:BB IEEE 802.11: associated (aid 5)
Mon Mar 28 07:45:47 2022 daemon.info hostapd: wlan0: STA 11:11:11:11:11:11 IEEE 802.11: deauthenticated due to local deauth request
Mon Mar 28 07:45:48 2022 daemon.info hostapd: wlan0: STA CC:CC:CC:CC:CC:CC IEEE 802.11: deauthenticated due to local deauth request
Mon Mar 28 07:45:48 2022 daemon.info hostapd: wlan0: STA CC:CC:CC:CC:CC:CC IEEE 802.11: authenticated
Mon Mar 28 07:45:48 2022 daemon.info hostapd: wlan0: STA CC:CC:CC:CC:CC:CC IEEE 802.11: associated (aid 1)
Mon Mar 28 07:45:49 2022 daemon.info hostapd: wlan0: STA 22:22:22:22:22:22 IEEE 802.11: authenticated
Mon Mar 28 07:45:49 2022 daemon.info hostapd: wlan0: STA 22:22:22:22:22:22 IEEE 802.11: associated (aid 4)
Mon Mar 28 07:45:52 2022 daemon.info hostapd: wlan0: STA DD:DD:DD:DD:DD:DD IEEE 802.11: authenticated
Mon Mar 28 07:45:52 2022 daemon.info hostapd: wlan0: STA CC:CC:CC:CC:CC:CC IEEE 802.11: disassociated
Mon Mar 28 07:45:52 2022 daemon.info hostapd: wlan0: STA DD:DD:DD:DD:DD:DD IEEE 802.11: authenticated
Mon Mar 28 07:45:52 2022 daemon.info hostapd: wlan0: STA DD:DD:DD:DD:DD:DD IEEE 802.11: associated (aid 6)
Mon Mar 28 07:45:53 2022 daemon.info hostapd: wlan0: STA 33:33:33:33:33:33 IEEE 802.11: authenticated
Mon Mar 28 07:45:53 2022 daemon.info hostapd: wlan0: STA 33:33:33:33:33:33 IEEE 802.11: associated (aid 8)
Mon Mar 28 07:45:53 2022 daemon.info hostapd: wlan0: STA AA:AA:AA:AA:AA:AA IEEE 802.11: deauthenticated due to local deauth request

In another thread, it was mentioned that unknown event 60 (iw event) is to blame with the workaround being to have the radio scan a specific channel. However, I want to say that I see that event shortly after reboot of the router on 2.4GHz and 5GHz radios and things are working as they should.

Wanted to upgrade to the latest snapshot this morning but was seeing a kernel panic. That's a story for another day.

1 Like

@CmdQ, I've seen that behavior, and I just punted and was restarting the radios each night out of cron. If this works I like it better as it seems less disruptive to the network than bouncing the radios. It's interesting the folks using archers saw it, as I just took an archer out of service (to be replaced with a RT3200) as it was completely dropping clients. (Actually, i replaced all three mismatched APs in my house with RT3200s.)

I've tried a really hamfisted approach of just doing the frequency scans every 5 minutes out of cron. I looked at all the "let's do it on an event 60" and I was seeing LOTS of event 60s a couple of times a minute which seemed to closely coincide with the BEACON-REQ-TX-STATUS associated replies. I figured every 5 minutes is enough frequency that anything not connecting won't have long to wait, but its not a few times a minute like the event 60s I saw seeing when watching for an hour.

I'll report back in a couple days if this seems to result in better network behavior.

Hi @CmdQ and @ktgeek
I am running the workaround to perform a scan for every event 60 (with a threshold limit) for about a month now and seems quite OK (2.4 GHz No Connectivity Issue Thread).
But that is just a workaround, there is an underlying issue that causes the problem and as far I can understand it is not restricted to just linksys e8450 but it is a widespread ath9k driver issue.

@CmdQ do you still experience the kernel panics with the latest snapshot ?

  1. It is for me. That's not saying a lot but that's my daily driver. I know based off this thread that vlan tagging code has seen a lot of attention lately due to the CPU learning aspect. I don't use that functionality so I do not know how well it works.

  2. I have a Netgear R7000 and this model and the R7000 wins as far as signal penetration but has the barely supported Broadcom chipset and much weaker CPU compared to this one.

  3. I don't think it will make much a difference but will be good to go with Wifi 6 if you end up with Wifi 6 devices. I have about 4 AX devices mixed with about 20 AC devices and they seem happy.

1 Like

Hi folks,

I asked this question yesterday, but maybe I was a bit vague. Is it possible to reset back to Belkin factory settings if I've already install OpenWRT UBI snapshot? I've lost the backup files I took, so can't restore mtd specifically. Can I get these from somewhere or am I screwed? Thank you!

Why and how exactly did you loose those files? Unless you have re-run the installer (or otherwise wiped the flash completely yet another time) the backup files will still be on the router inside the boot_backup UBI volume.
To restore the stock firmware, you only need those, there is no need for the full backup (which is more of a safe-guard measure in case things go wrong during installation).

2 Likes

Thanks for that. I tried to flash the factory firmware from OpenWRT firmware upgrade page. I read in this thread that it would work however, mine continues to boot into recovery mode. I did have a look for boot_backup via WinSCP, but I didn't see the folder. Maybe I'm looking in the wrong place. The recovery I used was: openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery-installer.itb from the Github UBI installer page here https://github.com/dangowrt/owrt-ubi-installer

Thanks!

Once you have converted the device using the UBI installer you will need a slightly more complicated procedure to return to the stock firmware. Just uploading stock to LuCI upgrade page does not work.

The minimal backup is inside an additional volume which needs to be mounted (hence you cannot just use WinSCP to access them, you need SSH and use the console), as described here.
So step by step, what you need to do is:

  1. Login to the router and mount ubi0:boot_recovery somewhere.
  2. Copy the mtd* backup files you can now access to your computer.
  3. Follow the restore procedure as documented on the installer README.md.
2 Likes

Thank you for this explanation! It looked like I was getting somewhere. I was able to copy the mtd files and write the firmware as explained in the restore guide, but after 2 reboots it looked like I've bricked it. Oh well. Out with the serial cable then! It does say that there is a chance of bricking it, so it's purely my own fault. I'll get it sorted one way or another. I have my old router back in now, so there's no immediate panic. Cheers for the help though!

@routermuffin I am very sorry about this and you are taking it well. Seems you have experience with the serial console. I hope you are able to resolve the issue.

Is there any way at all to help safeguard against this bricking because it does crop up fairly often on this thread. Could the wiki be improved further in this respect to emphasize that going back to stock is extremely difficult and best avoided or at least highly likely to require opening up device and soldering stuff to it? Is there any way to help safeguard against bricking in the code in the device? My understanding is too limited to make a suggestion. But if there was any other way to help prevent this state it seems it would be good.

2 Likes

Just saw this: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=64f629e2078b0c76bfe176a6f2f56877391b1b4e
Can anyone explain a bit more? Is it relevant in the classic routing&wireless cases? Will it improve the performance (which is already pretty good with wed enabled)?

1 Like

Thank you. I accept full responsibilty for messing it up. The risks are metioned a-plenty. I'll get it sorted one way or another I'm sure :slight_smile:

The documentation is pretty good actually. Perhaps more of an emphasis on backing up the original mtd files would be a good addition, but I'm nitpicking here. I did do this, but somehow deleted/lost them. Again, my own fault.

The files you found in boot_backup volume should have been good enough if you also write the firmware image itself downloaded from Belkin/Linksys as described.
And that's really the only difference. Doing the complicated full-backup procedure before hand by itself also has risks -- many people thought they can just go on and flash the main firmware from the recovery image when loaded to do the backups because it's indistinguishable from the recovery image loaded after the installer has run...
Once you got the serial adapter connected, it'd be great if you can share what you find (in terms of console output) so we can see what wrong so we can do a postmortem analysis and improve the procedures for future users.

2 Likes

Thanks! I'm heading away for a few days but will look into it when I get back. Thanks for all the support! :slight_smile:

Yes maybe qosify with hwo and sfo work ?