Worked out great here with AUC, yay!
Did an Archer C7v2 and X86
Both my R7800 upgraded and running fine. Thanks to everyone involved !
That's helpful. All I can add is that it also seems to happen with the two recent 21.02 updates (C7 v2), though in that case there's only light usage (so relatively infrequent instances of the recurring events, explaining why I didn't notice it) and it's not my home router so I can't really tell if it's manifesting in any problematic way as it seems to do in your case.
But maybe there's a clue in the fact that both sets of maintenance releases show this. That does make some sense, since both the v21 and v22 updates had overlap in terms of changes.
Interesting... I haven't seen this error much, if at all, before updating to the 22.03.4 release. I was fooling around with non stock settings as well, (WPA2/3, different timeouts for rekey and dissasociate, longer beacon and DTIM time) but have reverted to stock and just WPA2... with the errors still appearing.
After doing that last night... with a bit of time on it, it's looking like it's settled down to the pattern I've been seeing. I have my rekey set back to 3600 (1hr) and the dissasociate time to 900 (15min). What I'm seeing is every connected station rekeys on the hour, and many times, there's a lazy one that fails, and gets dissasociated. Thats when this error shows up. Though, not every time, not the same device, and it varies on getting disconnected, just disassociated, etc. I need to get familiar with the stages of connecting and verifying, and what that looks like in log entries... But overall, its happening pretty much after the end of the global rekey.
Haven't done the upgrade yet, though I agree that due to the (apparent) lack of changes in the wifi or ath10k areas would suggest that it doesn't change things. We'll see.
I also feel that we should get a specialized thread going for this in one of the other sections, and get this off the service release thread. A few reports are appropriate, but I don't want to dig as deep here, as I'd want to...
I have succesfully upgraded with the help of "auc":
- Netgear WAX202
- TP-Link EAP615-Wall v1
Done. So all discussion of it can go there now. I hope you and others can fill in some of the gaps.
EA3500 issues still persisted from 22.03.4 onto 22.03.5 but I may have found the problem with ipv6, wan6 having it enabled caused packet loss, wan throughput dropping.
After disabling both ipv6, wan6 my internet connection returned to normal, ping loss disappeared.
Enabling both packet loss, wan throughput was dropping.
Do I need to open a new thread with logs for further discussion etc?
Edited: The problem maybe my isp at the moment.
I had some time to do more testing on some speed test sites with ipv6 enabled and found no problem as described in my previous post.
I don't really need to run IPv6 over my network but I do enable it from time to time to check if it is working after upgrading.
I can now check the beta testers for kirkwood again and perhaps I will see the same results.
Regards
Update from;
Raspberry Pi 4 Model B Rev 1.2
ARMv8 Processor rev 3
bcm27xx/bcm2711
|OpenWrt 22.03.4 r20123-38ccc47687 / LuCI openwrt-22.03 branch git-23.093.57104-ce20b4a
to; (with imagebuilder as always)
22.03.5
Wifi devices are gone (just my WAN backup)
dns-https-proxy luci page not loading.
So back to 22.03.4 trying to fix this later. Any suggestions in the meantime are welcome of course.
Cudy WR2100 and Archer C7 v2 succesfully upgraded.
not stable for tl-wr841n v13
Hello friends I upgraded my TP-LINK TL-WR841N V13 router to the latest stable version of Openwrt v22.03.5. !!!Unfortunately, it is not good at all!!! It works very hard and the boot time of the device has increased a lot, and worst of all, it automatically reboots when saving the router settings, while this was not the case in any of the previous versions!
!!! And when Wi-Fi is restarted, the LAN connection will be disconnected for a long time!!!
And the installation space is much less and unused Dear developers, please think about making it heavier and rebooting this version in the next builds. I have flashed the router many times and unfortunately it rebooted when I did Wi-Fi settings and the devices tab. I hope you solve this problem in the next builds
TP-LINK TL-WR841N V13 https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wr841n_v13
This router only provides 8 MB flash and 64 MB RAM. Please read more about this here: https://openwrt.org/supported_devices/openwrt_on_864_devices
Today's popular routers are in the range of 128 or 256 MB flash and 512 MB RAM. Examples:
- Linksys E8450/Belkin RT3200 https://openwrt.org/toh/linksys/e8450
- Netgear XR500 as successor to the popular R7800 https://openwrt.org/toh/hwdata/netgear/netgear_xr500
- Dynalink DL-WRX36 even has 1024 MB RAM: https://openwrt.org/toh/dynalink/dl-wrx36
So, yes, sooner or later 8 MB flash and 64 MB RAM devices will run out of resources and it will be time to upgrade to run recent OpenWrt releases.
Insufficient RAM for stable operation
- 32 MB RAM is already deprecated. You will run into issues with an up to date OpenWrt version.
- 64 MB RAM may have some issues with stability, depending on your hardware and use cases, although it is enough for basic usage
- 128 MB RAM or more is recommended if software past basic router/AP functionality is to be used
Raspberry Pi 4 does not work after updating from 22.03.4 to 22.03.5 via Attended Sysupdate
as well. The reason is unknown and I still kept the SD card separately for the late investigation. Luckily I could restore the back to the new SD card and continue. Have anyone run into the same issue?
Happened to me as well, I thought I had done something wrong up until your post.
RPi 4B, attended sysupdate from 22.03.4 to 22.03.5 and 22.03.3 to 22.03.4 resulted in a non working system.
Attended Sysupdate worked fine for updates before 22.03.4.
Already flashed the SD card with build with custom packages from https://firmware-selector.openwrt.org/?version=22.03.5&target=bcm27xx%2Fbcm2711&id=rpi-4
22.03.5 works fine with that one!
Meanwhile half of us are still using v19 because you wont fix compatability issues and just blame it on the manufacturer
Who is "us"?
Nobody should use OpenWrt 19.07 for more than network isolated test or learning setups today. OpenWrt 19.07 is unmaintained end of life and does not receive security vulnerabilty patches.
If you like to maintain OpenWrt 19.07 branch forever the community will be thankful. Please do so.
In January 2024 Linux kernel 4.14 series of OpenWrt 19.07 will be upstream end of life and you will then have to maintain this kernel for yourself. Good luck.
TP-LINK TD-W8970 (dumb AP) successfully updated.
Many thanks to all the devs.
Wifi is working (just did the imagebuilding again, don't know why it didn't work the first time, there where no errors)
there is apparently no package for dns-https-proxy for 22.03.5...
root@Router:~# opkg list | grep dns-https-proxy
root@Router:~#
Is luci-app-https-dns-proxy
and https-dns-proxy
what you are looking for?
luci-app-https-dns-proxy - 2022-10-15-11 - Provides Web UI for DNS Over HTTPS Proxy
https-dns-proxy - 2022-10-15-11 - Light-weight DNS-over-HTTPS, non-caching translation proxy for the RFC 8484 DoH standard. It receives regular (UDP) DNS requests and resolves them via DoH resolver. Please see https://docs.openwrt.melmac.net/https-dns-proxy/ for more information.
Yes, I spelled it wrong ;-). But the problem is that from version .4 to .5 it's not working for some reason.
I'll check it out when I find the time.
Remember to do opkg update before attempting to search for or install a package. :-)