OpenWrt 21.02.1 First service release

I don't recall noticing this from 18 to 19, but when comparing 19 to 21, how can the Archer be so different than the comparable one I mentioned, for example? Shouldn't they both have dropped similarly, relative to what they had each been, instead of what happened? The fact that one was extremely different makes me think something went wrong on the upgrade, despite it working, particularly in light of the weirdness I show in the screenshot.

It would be interesting to know if anyone else with a C7v2 has a Devices tab looking like that.

My C7V2: only Accesspoint, no luci (webservice) running
# uptime
18:20:09 up 9 days, 23:27, load average: 0.00, 0.00, 0.0

# free
total used free shared buff/cache available
Mem: 123400 51248 55136 240 17016 38952

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' :dizzy_face:?:
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