I have an e8450 device that was recently upgraded from 23.05.5 to 24.10.0-rc4. Before the upgrade, the 5GHz wifi had stable performance, consistently transferring about 600 Mbps in both directions from my laptop (in the same room). After the upgrade, the 5Ghz wifi is quite unstable - sometimes it will transfer 600 Mbps and and down, but sometimes the transfers slow down to ~40 Mbps in the download direction and 1 to 2 Mbps in the upload direction. Basically, I don't think my e8450 is usable in that state.
To give a few more details:
The e8450 had been first installed using the 1.0.2 installer, and was then running the 22.03.x and later 23.05.x openwrt series.
To upgrade to the 24.10.x series, I followed the upgrade instructions and flashed the 1.1.3 (unsigned) installer first, followed by the 24.10.0-rc4 image.
I do not not have WED enabled, nor flow offloading. I already didn't have them enabled in my 23.05.x configs, so that shouldn't be a change.
I am running with the 2 GHz radio disabled, and the 5GHz radio doing VHT80 on channel 149, in AP mode, with sae-mixed encryption.
I have no idea what could be wrong, and how I could get my access point back to a usable state ? (either getting it fixed in 24.10.x, or going back to 23.05.x if there is a way to do that without breaking the installers).
Does this slowness affect only the laptop? Does it go away if you turn the WiFi on the laptop off and then on?
I am asking because I also sometimes see the upload slowdown (not as bad as yours), but it only affects Linux clients with Intel WiFi cards and a lot of uptime. And no, this is not new in 24.10, it also existed before. Try also disabling TCP segmentation offload on the clients:
My android phone (pixel 6) shows about the same performance (42 down / 0.8 up), though I did not test what it was getting before the AP upgrade. Same deal with my macbook air (old x86 model, probably 2018?) showing 30 down / ~1 up on my last test. The problem is intermittent though, some of the time (but less than half of the time) I get OK performance (on the macbook, about 300 down / 300 up).
The laptop I was referring to earlier is a lenovo chromebook, if that makes any difference. So I can't easily run ethool on it
reboot and pray for manufacturer firmware to come up...
apply 1.0.2 openwrt installer again
install openwrt 23.05.x back onto the device
@daniel , does this sound like a reasonable plan ?
Also, I already know it's not because ubidetach -d 0 fails with error! can not remove ubi0 and error 16 (Resource busy). I don't know why that is; I have verified that the device is running the recovery image when issuing this command, and that all mounted filesystems (as seen in df or in cat /proc/mounts) are tmpfs, so I don't know what would keep ubi0 busy and prevent it from being detached ???
I followed the same procedure in the past, and the manufacturer firmware did not come up. I ended up having to recover the router through the usb-serial cable.
In other words: the documented revert-to-stock procedure does not work, and bricks the router instead. The suspected root cause is that it restores the part of the flash that contains the original firmware settings, but also restores a firmware version that is not the same as before, and which is thus incompatible with these settings.
Incompatible, for me, means "cannot complete the first-boot wizard and cannot get to the firmware update page due to javascript errors".
Right. Come to think of it, the openwrt boot chain is supposed to be much more robust than the manufacturer one, so it would be surprising if the safest downgrade path was to revert to manufacturer as an intermediary state.
I wonder if the following would be workable:
boot into a 24.10.x linksys_e8450-ubi-initramfs-recovery.itb image (recent enough that a corresponding kmod-mtd-rw is available for it)
restore the first 0x2c0000 bytes of the previous 23.05.x installation, as were saved by the 1.1.3 installer. That is, restore the saved mtd0 and the first 0x240000 bytes of the saved mtd1. Zero out the rest of the mtd1 device (i.e. starting at 0x240000). In effect, this would restore the 23.05.x boot loader and factory data, but nuke the 23.05.x mtd partition.
boot into the 1.0.2 installer using tftp. I assume the 23.05.x boot loader would start tftp when it can't find an existing ubi volume, OR, by pressing the reset button when booting the device.
I expect, from there the 1.0.2 installer should be able to create the ubi partition and write out a bootable recovery image in it, from which I could then install any 23.05.x image of my choice ?
I feel like this should work, but also that maybe I only know just enough to be dangerous here. Definitely not going to try this right away
In general, I feel like it would be good to have a documented downgrade path, because a one-way upgrade is just asking for trouble.
All right, I downgraded my e8450 back to 23.05.x series, which seem to work better for me (speeds consistently above 500 mbps both ways on my chromebook, above 400 mbps both ways on my old macbook, and about 400 down / 200 up on my pixel 6 phone). The intermittent slowdowns I was seeing with 24.10.0-rc4 are gone. For the record, 24.10.0-rc5 didn't seem to help either.
I'm going to record my downgrade procedure in case it helps someone else. The preconditions for this procedure are that I had previously ran the 1.0.x installer (1.0.2 in my case), and then ran the 1.1.3 installer, just once. The procedure won't work if you didn't have 1.0.x installer before, or if you ran 1.1.x installer more than once.
PC: install a TFTP server
PC: copy 24.10.0-rc4 ubi-initramfs-recovery.itb image
to TFTP openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb
PC: set up static IP: 192.168.1.254/24
e8450: reboot, keeping the reset button pressed until orange LED is on
(forces TFTP reboot)
I ended up needing to downgrade my two RT3200’s from 24.10.0 to 23.05.5 and your instructions were incredibly helpful for restoring the previous UBI layout. Thank you!
I was experiencing issues related to 802.11r on my 5GHz radios on 24.10.0. When roaming from one AP to another, all connections would essentially “drain” themselves to nothing and I couldn’t access the internet (see below for more details). I can’t comment on if it happened on 2.4GHz because I really only use 5GHz at my house.
After downgrading to 23.05.5 the issue completely went away. This is the first time I’ve ever had problems with a stable OpenWrt release/version upgrade.
More info on the issue:
From a fresh connection/auth to my 5GHz SSID, I could do a Speedtest and get around 500-600mbps (I have gigabit through my ISP). Then when I’d roam to the other AP I’d do a Speedtest and speeds would start at 10mbps and drain to 0mbps. If I turned off WiFi and reconnected to the AP again, I’d get full speeds. It was incredibly frustrating to track it down and get something reproducible. I didn’t test locally with iperf but probably should have. When following hostapd logs I could see that ft auth should have been working but I didn’t dig into it much further. Maybe next time I’m feeling like getting into this rabbit hole I’ll upgrade to 24.10 and gather more metrics/logs.
