Wait, how did you do the upgrade? Did you use LuCI Attended Sysupgrade/cli auc, or just plain old sysupgrade with "keep config"? Sounds like the latter... I've been using auc on the command like for over a year now on a handful of different devices, and have been able to keep my installed packages, even when jumping between release and snapshots (and back -- I never jump too far, otherwise I'm sure I'd get bitten by things like fw3/fw4 diffs).
I did use LuCI standard release Sysupgrade from the downloaded openwrt-22.03.4-ramips-mt7621-totolink_x5000r-squashfs-sysupgrade.bin with keep config method to be sure, from the running system menu, under the impression that all of the individual made setup would remain like it would be with any other modern update made under any other OS available this days, be it M$, BSD, or Linux, which usually do nor require reinstalling any added software at all... well in most cases anyway 
+1 I've seen this on 2 disparate devices (Archer c7 v2 and Turris Omnia). I'm tempted to drop the Candela drivers, but I've got enough other problems with my network at the moment.
Oh, that's interesting, because while several have mentioned the ath10k_pci mac flush vdev errors, I didn't see mention of a correspondence with "disassociated / deauthenticated" events in the syslog.
I wonder if the previous reporters are are also seeing that event pairing?
Also, it's interesting that the prior report was about a TP-Link c2600, and you also mentioned another non-Archer. I was thinking this was an Archer issue, but maybe not. Maybe they all have something in common, like a chipset.
In my earlier post for Archer A7 you can see that I do get it preceded by a somewhat similar preceding event chain (essentially a jump from 2.4 to 5 GHz or vice versa, always of the same device actually) - but I also get many of those same band changes without the kernel info event
Also worth noting that I'm running non-standard kmod-ath10k-smallbuffers and ath10k-firmware-qca988x, so not related to -ct drivers (or not solely)
@aparcar:
Probably more UBI-using devices are affected. Not all seem to be easily recoverable without serial cable. Could be a good idea, to broaden the “known issues“ text, just for caution. And from what I was reading in the forum, the 21.02.6 kernel could also show similar issues, but the 21 announcement has no such known issue text so far:
3 Likes
Hmmm, I haven't looked into pairing correlation, but to the point of what these different devices have in common, yeah: ath10k is the 802.11 wireless driver for the Qualcom Atheros QCA988x family of chips.
EA3500
I am having the same issue with packet loss, throughput issues as reported in the Kirkwood testers.
Upgrading from 22.03.3 went without problems, no packet loss or throughput issues on my 100/10 connection from the previous service release 22.03.3.
Just reporting my experience with service release 22.03.4.
Regards
Why 22.03.5 Released so soon?
22.03.5 has NOT been released. A tag has been created in the repo, but until the devs tell you otherwise, DO NOT try to install it.
5 Likes
it is released
Index of /releases/22.03.5/ (openwrt.org)
Your text only tell, it takes 2 days until all versions are build. It not change anymore or change again.
Building new version not happen every time. I only ask, what is fatal fail why new version need release.
I’m sure all will be revealed when it is officially announced. Patience.
It’s very likely about the UBI regression.
4 Likes
It has not been released. The release will be officially announced with a thread much like this one. The build system is likely still running. Please read the thread linked by @efahl -- it is very relevant.
6 Likes
Are you running router on a stick? Meaning, are you using the single ethernet port on the rpi4 for lan and wan, by using vlans in a managed switch (r7800 in my case)? I get no errors when using a rtl8153 dongle for wan, but since my internet is only 300mbps, router on a stick is fine for me maxing out at 500mpbs without using the 8153 usb to ethernet dongle
From a relative novice, I've just done a sysupgrade to 22.03.4 on my Mochabin and spun up no issues. Working well with my backed up settings from 22.03.3. How come people are talking about 22.03.5 already, seems very quick going from 22.03.4 to 22.03.5? Is it because of some issues people are having above.
Out of interest as well, does anyone know when support for the following packages will be included in the stable build?
• kmod-ath11k
• kmod-ath11k-pci
• ath11k-firmware-qca6390
These are the ones I think I need for the wireless on Mochabin to work, but is currently only available in Snapshot which I struggle with.
Router on a stick was my first configuration with the rpi4b, but I gave it up in favour for the UE300 solution. For me the 2 ethernet port configuration has an important advantage:
My internet access is via LTE with a Zyxel LTE4506 router (operated in bridge mode). My ISP assigns a public IP address via DHCP, which is changed at least once a day.
When the LTE4506 gets a new IP address, it sets the signal "Link down" at its LAN port. If the LTE4506 is connected to a managed switch, the switch does not transfer this "Link down" signal to the rpi4b (owrt router). So the rpi4b operates with an invalid IP address until the lease time is over. Result: no internet access.
With an UE300 as the second ethernet port the "Link down" signal arrives at the rpi4b and triggers an "ifup wan" (including a DHCP discover). The change from old/invalid IP address to new/valid IP address is less than 60 seconds. During the night hours this delay doesn't matter. At least for me.
1 Like
I never do it myself, but there is two methods install openwrt.
Update to old firmware or empty all and install openwrt over router flash.
Common methond is update old firmware with new.
Latest update fix some overflash problems and give minor fixing to others.
If i understand wrong, some will advice right.
It seems like 22.03.5 will be released in the next few days.
I wasn't expecting that as 22.03.4 released just a few weeks ago.
Can confirm and couldn't agree more. This images should be removed from the download page.
Spent a hours worth of time a couple weeks ago trying to recover a EA8300 setup as a dumb access point. Only to discover a couple days later when finally being able to invest some time on researching and checking the forums of this issue. If it had been removed it would of saved time.
Very surprised it's still currently listed and downloadable for both MR8300 and EA8300 even as of this post reply.
2 Likes