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:
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.
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.
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.
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.
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.
I upgraded to 22.03.4 on more than 10 devices and everything went well. I'll upgrade to 22.03.5 tomorrow if it's released. I don't know why and if a new release will come out that far, but for sure I know OpenWRT is really nice, and support is really good on this forum. Making Openwrt for such an impressive list of devices is for sure a difficult and time consuming process. I thank all the people working on Openwrt for their work. Thanks!!!
Consider this as "bad luck". There are several thousands of device supported, tens of targets. At each release, there is necessarly some bugs remaining that prevent some device(s) to run. Well this time it was EA/MR8300. Next time it will be another device. Before upgrading, consider reading release announcement and wiki ... you'll never known what can happened.
Furthermore, there is a lot (I mean a lot !) of files available for download that will never run, and sometimes can't even been flashed. I think of images for very old devices (4/32). There are more or less supported, and image builder continue to build theses images, even if they are not usable. It's up to the user to think about this.
While it is up to the user to think about this right now, I am sure it would be possible to somehow come up with a technical solution, at least for the 4/32 devices. Flash size is usually entered into the ToH, so could the firmware selector not cross-check its availability based on the toh?
Also, building all these images for devices that cannot even be flashed increases buildtime of image builders a lot, no?
As for devices that are buggy (like EA/MR8300), I am not sure how a automated mechanism could look like for disabling them in releases, but is it really that hard? Obviously, the easy, but lazy way out is to tell users to read release notes...
The solution is to manually build and remove some options. I was able to do this for an old device recently. It works beyond expectations.
They do. I have mixed feelings about this. As long as a device can be supported, it should be. But at some point it should be dropped. There is a minimum (8/64 for example) requirement for a release. When the device doesn't meet the requirement it should be skipped from image building. In fact some automatic generated images can't even be flashed. It should be up to the user to create its own build, assuming he understands that his device is outdated.
You may have forgotten the OpenWrt is not a commercial product. I quote the licence: "OpenWrt is free software, provided AS-IS and without any warranty." and "Support may be provided on a voluntary basis by developers and fellow users, but is not guaranteed.".