I have dealt with this issue in the past and confirmed it's not caused by a damaged cable nor any hardware issue. I replaced them just in case with brand new cables and the same issue was happening.
Previously it was only resolved by upgrading to a different OpenWRT version, now it seems like the very same issue is back. I'm not sure if it reappered in 23.05, could've reappeared in any version between 22.03rc and 23.05.0-rc3 as I hadn't updated it until now.
I documented the whole issue in the past in this thread Internet speed capped at 100mbps by the router
I also see there's a related bug report on github, other people are reporting it too https://github.com/openwrt/openwrt/issues/9069
1 Like
i think the wifi issue appears for those who use anything other than wpad-basic (mbedtls). last good build for be was r23429.
1 Like
Thanks for the tip. It's working in the latest SNAPSHOT r23995-ce7209bd21
2 Likes
There are two ways of looking at this.
Openwrt releases tend to take 6 or 7 months for the first stable release to materialise.
The next release candidate or stable will be based on the latest SNAPSHOT. So there is no harm in changing to snapshot as if there is a wifi issue, it does need reporting and auc upgrading packages on an existing release is not recommended.
I am hoping to see 23.05 stable by the end of the year, as long as there are no major bugs found.
1 Like
I've installed 23.05.0-rc3 as a VM in Proxmox and having a very strange problem with the WiFi.
The WiFi works well as part of the LAN, so I can use the WiFi to access the OpenWRT.
However, when I configure the WAN, devices in the WiFi can't access the WAN. The same device connected to a LAN port, works well, so it doesn't look a firewall config problem or anything similar with the network configuration.
Any hints?
Yes that is true. But... Attended Sysupgrade is going to provide all the updated packages to someone that downloads rc3 today. IE the rc3 download I just downloaded tonight is not the same rc3 I downloaded a month ago.
I went back to SNAPSHOT now that dnscrypt-proxy2 has been fixed.
Just for the heck of it tonight I decided using the Firmware Selector (for Linksys WRT3200ACM) to download rc3 and added my extra packages under " Customize installed packages and/or first boot script"
I flashed it and kept my settings. Then checked Luci for software updates. There were none to be had.
So it's my opinion that Attended Sysupgrade is safe to use. Now with that said...if there is a bug in a new package that will always be a problem until it gets fixed. In that case reboot back to the working partition.
As far as the broken WiFi... Linksys WRT router's WiFi has been broken for several years. I'm using a WAX620 WiFi adapter plugged into a LAN port and moved on.
1 Like
OpenWrt 23.05.0-rc3 - wpad-basic-mbedtls 2023-09-08-e5ccbfc6-3
Beeline SmartBox TURBO+ (mt7621) DO NOT update - WI-FI disappears, only rollback helps 2023-06-22-599d00be-1.2
1 Like
I don't know how, but it started working, I didn't changed anything ...
It took a long enough to confirm something wrong is with mt76 on my mt7981 based Cudy WR3000
using 23.05.0-rc3 . On random events wifi 2.4Ghz and 5Ghz (independently) drop adapter rate to below 12Mbps but do not drop client . I have graph of below events . Also log / dmesg stays clear until radio is restarted .
2.4Ghz is more visible as there are few constantly connected devices .Devices stays associated but there was no transfer . As seen below I've tried even disable collectd to see if that's help . And did not.
Now I'm rolled back to RC2 and trouble free
edit: seems there is more than this . RC2 had similar issues . Snapshot as well but ending up with reboot instead wifi lock . Now on RC4 got reboot as well.
Culprit is DAWN controller stop and disable made this issues disappear .
2 Likes
Our EA8300 is on 28 days of uptime, rc3.
No problems at all that I can detect.
I have these odhcpd segfault messages in logread on x86. I'm not sure what the impact is.
Sun Sep 24 21:04:39 2023 kern.info kernel: [165046.733802] br-lan: port 1(eth2) entered forwarding state
Sun Sep 24 21:04:39 2023 kern.info kernel: [165046.740741] odhcpd[29748]: segfault at 4 ip 00007f71c8931a5d sp 00007ffcf27a1388 error 6 in libubox.so.20230523[7f71c8930000+5000]
Sun Sep 24 21:04:39 2023 kern.info kernel: [165046.753664] Code: 4d 39 d1 74 16 49 8d 79 20 4c 89 de e8 30 fc ff ff 48 85 c0 7f 05 4d 8b 09 eb e5 49 8b 41 08 4d 89 41 08 4d 89 08 49 89 40 08 <4c> 89 00 31 c0 41 c6 40 10 01 c3 83 c8 ff 80 7f 10 00 74 1d 48 8b
Ouch, will they ever fully fix vlans for mvebu on a release build? I'm still using 19.07.10 because of vlans! 
2 Likes
that's about rc3 not SNAPSHOT though, it's been filed incorrectly as SNAPSHOT.
Hello Community, now, I have a problem, with X86 running inside Proxmox, wanted to add a USB 3 SSD extern, and suddenly I see strange behaviour of Block info command and also of Luci Mount Point menu, please, if someone knows, what I can do, to fix it, here my Terminal output:
root@vm-lede:~# block info
Error loading shared library libubus.so.20220615: No such file or directory (needed by /sbin/block)
Error relocating /sbin/block: ubus_free: symbol not found
Error relocating /sbin/block: ubus_lookup_id: symbol not found
Error relocating /sbin/block: ubus_connect: symbol not found
Error relocating /sbin/block: ubus_invoke_fd: symbol not found
I checked, /sbin/block is present, but have no clue, how I can fix that problem, would be thankfull indeed. Im using RC3 and also sadly found out, qosify I cant also not install anymore... what is very sad, as it performed better here, then SQM ..but I can live with that, just want again my USB Mount points work again...is my only wish... Thanks for reading, and hope, someoen can give me a hint what to do..
The key is in this message:
There is an issue with that library in your device.
2 Likes
strange, Thanks for reply, I already checks for this libubus.so ... its installed, so Im wondering, why this happens... will remove and re install, and see.. if it helps...
It is not installed...
20220615 != 20230605
You have a different (newer) version...
It has been updated in 23.05 seven days ago by @nbd, probably in preparation of the next rc.
But that may cause dependency trouble with some packages, as some 23.05.0-rc3 packages still expect the old version.
5 Likes
hnyman, Thanks so much ... my eyes are not the best anymore with my 60 years.... I apologize, is there a way, to fix this... downgrade ? or just let is so, till next RC version or final release comes? ...and do you know, if now not working (cant isntall) qosify again? It was so damn good my my environment, very low bufferbloat.. better...then SQM... in my case...
by the way, used Firmwarebuilder website chooosed x86/64 with some packages added... just like 2 days ago.. so imagebuilder loaded this new libubus lib... that causes the problem when I choosed rc3...
my fault, I had a image, where everything worked well, from before this new release you mentioned came out... but stupidly, I deleted it... so cant go back anymore... will learn from this, and store images build by (Firmwareselector) imagebuilder, that work... seperatly and keep them... now, its kinda f***ed up... cause imagebuilder builds with this incompatible libubus library... that causes problems, or am I wrong?
Sure, it is always important to keep the flashed image that works, so that if something goes wrong with the next one, you have the working one archived.
Might be.
I never use the imagebuilder, fimrwareselector, auc, whatever... as there is the risk of this kind of incoherency due to some packages being locked through ABI versioning and some getting updated. Major problems are rare and usually temporary, but can happen (like apparently now). (Certain core packages like ubus and libiwinfo are the most difficult.)
Two simple choices:
- download and install the official 23.05.0.rc3 image and do not install additional packages
- compile from sources with the full toolchain (like I do), and you will get a coherent image. Always.
Third option is to wait for 23.05.0-rc4 or final release, when everything is again coherent.
Ps.
the problem with ubus ABI versioning was discussed two years ago:
- https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg58946.html
- https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg58951.html
- https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg59257.html
But in the end the devs decided to avoid my proposed mitigating solution.
The solution was actually first merged as https://github.com/openwrt/openwrt/commit/72cc44958ef4e0df1a152178514c92899d6a957a but then reverted a bit later with https://github.com/openwrt/openwrt/commit/8307da3dbdaff13d5ce99f8aefa32f5b7a2e18e6 as that approach causes different kind of dependency problems.
2 Likes