Just updated my main router, APU2 x86, using auc and keeping all configuration. No issues, all running as it should.
Just a heads up, the correction to the UBI code has made it into kernel 6.3-rc7, but none of the legacy branches have integrated the correction due to the fact that no PR had been generated other than for next. As such, the affected devices will remain broken forever unless using your localized patches in the future. So don't get your hopes up that the mainline will swim down.
2 Likes
sysupgrade from 22.03.2 to 22.03.4 on my Belkin RT3200 without problems
1 Like
@Synerworks Are you saying that there's never going to be a fix for the devices that are vulnerable to this UBI bug? How could OpenWRT just leave us like this?
The fix is applied to 21.02, 22.03 and master snapshots. Nevertheless no stable version has it, so 21.02.6 and 22.03.4 don't boot.
On another thread @daniel suggested that a newer stable version that includes the fix could be done.
I've understood that, @badulesia , but I've never run a snapshot. How long until the fix makes it to stable?
Sorry, I can't tell.
You can safely try a 22.03 snapshot, at some point it should be very close to your current 22.03.3.
I would recommend, to check on the device: How large is the actual firmware partition size of that v13 device? (It does not seem to be documented on the device wiki)
According to https://openwrt.org/toh/tp-link/tl-wr841nd,
v13 seems to be the only 1 of the 10 listed hardware variants having 8 Megabyte of flash. The other 9 variants only have 4 Megabyte of flash and will therefore be unusable.
If sh.. has hit the fan, it could be that TP Link took the easy way out and though v13 has an 8MB hardware flash chip, it could be that it is using the same 4MB partition schema as the other device versions (wasting the remaining space). It will likely be an unsolvable problem, if the firmware partition has been provided too small, as OpenWRT does not touch the partitioning of devices.
All good here, upgraded Belkin RT3200 (UBI) and Xiaomi Mi 4A Gigabt from OpenWrt 22.03.3 to 22.03.4. I have kept both configs, uptime 2 days and no issues observed so far. Both are used daily.
Thank you!
No 22.03.4 build for Linksys WRT1900ACS secondary to known mvebu issues (broken mv88e6176 switch) identified with 22.03.3. Figured I'd check in again to see what people with WRT1900ACS are running at present: Master vs 22.03.2 vs 21.02.6 and what their experience was with stability?
Dug an old TP-Link Archer C7 v4 out of the pile and installed 22.03.4 on it. No issues. Added adblock and updated openssh-sftp-server, did some speed tests through it, all looks good.
Upgraded my TP-Link Archer C7 v2, which is used as a WDS repeater with DAWN. Not 100% happy, because umdns did not start after the upgrade, with this message in the log:
Sun Apr 9 12:28:12 2023 user.notice ucitrack: Setting up /etc/config/dhcp reload dependency on /etc/config/system
Sun Apr 9 12:28:14 2023 daemon.notice procd: /etc/rc.d/S80umdns: Failed to parse message data <------- this is bad
Sun Apr 9 12:28:14 2023 daemon.notice netifd: Interface 'lan' is enabled
Sun Apr 9 12:28:14 2023 daemon.notice netifd: Interface 'lan' is setting up now
Sun Apr 9 12:28:14 2023 daemon.notice netifd: Interface 'lan' is now up
After restarting umdns manually, everything works.
I can confirm a successful upgrade of BT HomeHub 5a: no bootloop anymore, the device works as a dumb AP (but no DSL here, so cannot test this part).
i've been on snapshot for my wrt mvebu devices.
be prepared:
22.0.3x uses wolfssl by default
snapshot is now using mbedtls by default
my personal solution was to use openssl in liew of wolfssl or mbedtls; with minor changes in iinstalled packeges, this makes upgrading easier. i have not extensively tested performance of one vws the other.
there was also a problem with carrying forward configs across upgrades for wrt32x devices in snapshot, which i think has been resolved.
snapshot on my wrt1900ac v1 has been ok.
1 Like
Thanks for all developers, another good release, since ~2021 openwrt is rock stable for x86 / mt7601 devices!
ofc i hope openwrt for x86 would bunny hop from 5.10 to 6.1 without using 5.15 in 2023 release as a much modern kernel but i guess it would not gonna happens
Upgraded TP-Link Archer C7 v2 to 22.03.4 via luci. Things mostly seem to be ok, except I now see this entry in syslog every few minutes:
ath10k_pci 0000:00:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
I'm seeing the same on a TP-Link Archer C7 v4
kern.info kernel: [49696.489344] ath10k_pci 0000:00:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
Wow this update 
One device got corrupted - I kept settings when I was asked and it looked like update was success... Only when I started digging did I see my wifi was miss configured entirely - wrong channel selected , maximum output power reduced to 20mw and can't be increased ( yes , I did check and the country is set to correct location )
Sometimes it would lock me out of luci too... Kept saying wrong password when I tried connecting , had to close browser entirely and reset ssh tunnel ( page refresh didn't work )
The other device ended with broken luci... I thought it was a smart idea to NOT keep any settings , but it failed to clear settings properly during update...
Instead of router using default 192.168.1.1 for lan it was using 192.168.10.1 ( I set it to this on the previous version ) , but luci couldn't be reached at all on that address either ( Had to use reset button on the router )
Both devices are mt7621...
Same R7800
Two days ago I have updated two Archer C7 V5 without any problem. Everything is working without any issue so far. Thanks OpenWrt