My C7 v2 Devices tab looks the same.
And...nothing wrong with the install...it does have less available memory.
FWIW, I have a C7 v2, but used as a AP only. I'm seeing if anything a bit less memory usage. I used to normally get 50ish free to 30-40ish used. Currently on 21.02.1, I'm seeing about 60 free to 45ish used.
Again, that's dumb AP use, disabling a few services and interfaces, not regular router/AP use.
Sadly, I'm seeing wifi issues, more than before (still troubleshooting to see if it's something non-firmware) and on 5ghz as well as 2.4ghz. 5ghz used to be very solid, with 2.4ghz has been very problematic for some years now. Changed from the -ct drivers to the non -ct, problems worse.
CT drivers seemed to increase memory usage for me (AP/router).
I solved the frequent wireless disconnects I was getting by upping the value in Station inactivity limit
Have you tried kmod-ath10k-ct-smallbuffers instead of kmod-ath10k-ct ? That may help bring down the memory usage.
wifi down
opkg update
opkg remove kmod-ath10k-ct
opkg install kmod-ath10k-ct-smallbuffers
reboot
1 Like
For context, on the C7v2 I mentioned above that went from about 70000 free with 19.07 to 35000-40000 now, I was using non-ct in both cases. That definitely helped with memory use in 19.07, so I assume it's doing the same now and things would be even worse using ct.
So. in summary, this is what I see as installed when searching on ath:
Yep...looks like my results.
What's interesting is the difference in LuCI (with htop running) vs. htop (with LuCI running).
Currently, LuCI is showing 64 MB used.
htop is showing 46 MB used.
Uhhh... that's interesting. I'm seeing (somewhat) the exact opposite.
LUCI - 58Mb free, 46Mb used (w/o top running, and don't have htop on this one now)
top - 47Mb used, 78Mb free
Really, a little bit of memory this way and that isn't a big deal, it's whether you ever run out. If you go from 50Mb free to 30Mb free it shouldn't make any difference. Maybe try one of the logging packages (connecd?) to try and monitor if for some reason you have events of huge memory use?
Not running out of memory...doing fine here.
Just an observation (as well as others) that there has been a marked decrease in Total Available (according to LuCI) since 19.07.8.
No issues with non-CT drivers so far.
1 Like
Everything I quoted above was LUCI, but now that I run top I see that Used, Cached and buff basically agree with LUCI.
Whereas top's Free is about 20MB higher than LUCI.
Are they somehow both correct but stating the answer differently (i.e. one is taking something else into account and the other isn't)? I find it hard to believe that LUCI is inaccurate.
htop's free was approx. 18 MB higher than LuCI.
Did anyone read this article '14 New Security Flaws Found in BusyBox Linux Utility for Embedded Devices' 
?:
Article: https://thehackernews.com/2021/11/14-new-security-flaws-found-in-busybox.html
Hope a new version of OpenWRT will be released soon!
It says Busybox is fixed since August 19 with 1.34, my RPi4 is running 1.33-6 under 21.02.1 released on
October 25...
It seems all issues are triggered via cli, but shouldn't this be a priority fix ?
We're almost 3 months later, anyone able to get fix expedited into release ?
This should indeed be a priority.
Hope it will be fixed soon!
Busybox was updated in snapshot to 1.34 on Sep 4, 2021 and to 1.34.1 on Oct 5, 2021. If having assurance these issues are addressed is an immediate concern, snapshot is an option.
1 Like
Snapshot introduces another set of other issues, that's why it's imperative release gets these security bugs fixed.
1 Like
Of course it does, but it nonetheless remains an option if there is a concern with prior busybox versions of man, awk, lzma, unlzma, ash, awk and hush being nefariously executed from the OpenWrt command line.
I can't imagine how that could happen for my use case, but if I could and was worried about it, snapshot is an option I would look into until a future release of 21.02 updates busybox.
2 Likes
Curious if anyone here (particularly, but not limited to, cable users) who previously had a WAN IP that basically never changed short of you doing something like changing the WAN MAC, now get a new WAN IP on almost every router reboot.
This issue, while not of paramount importance in my case, has me stumped beyond words, since it never happened before going to 21.02 and then immediately started. It's almost as if OpenWRT is sometimes presenting a random MAC to the ISP on boot during the DHCP process, prompting the ISP to issue a fresh IP, but that's pretty unlikely. Someone elsewhere speculated that the router could be NAK'g the first offer, or simply not responding, for whatever reason, also then prompting the ISP to issue a fresh IP.
If you don't reboot, all is well: DHCP renegotiates with the ISP every 24 hours in my case. Same IP ad infinitum.
I get a new WAN IP on every reboot.
1 Like
Fiber, but no new IP address on any 21.02 device (three devices). The IP address has only changed one time per device since OpenWRT 18.06 for me no matter of power grid outage or if I reboot and that was because of maintenance work at the ISP.
A new IP address would break my VPN tunnel (without DDNS) so that won’t happen unnoticed!
The only time I have ever got a new IP because of me is when changing the device so the physical MAC gets changed. Then the IP address is changed.
But isn’t the mac presented in overview or ARP table so you should be able to see if the mac is changed?
1 Like
Yes, the MAC is shown there, and it's the correct one that agrees with what's on the Network page. But is that the one the router is actually consistently using when needed? I would think so but really have no idea. Someone would have to conduct a trace of some kind on boot to see what's happening in terms of the conversation with the ISP.
So far, I have heard from several who say it does happen but only one cable user who says it doesn't. Perhaps the ISP is key. Whatever the issue is seems to manifest with certain ones. It's interesting that you don't see it on fiber, and there's probably a good reason for that.
1 Like