IPv6 suffix is now limited to 8 characters which is wrong, it should allowed up to 16 characters. I used a 16 character hex suffix using DHCPv6 for my Debian servers and it worked fine until 23.05.0
Luci sysupgrade failing on two Linksys EA8500 with official 23.05.2 sysupgrade firmware image
At page /luci/admin/system/flash I click "Flash image..." button, pick the file, click "Upload" button...
I see the progress bar as it uploads, oddly slow on both APs, and then get error "XHR request timed out".
Neither AP ever displays the SHA256 checksum page after upload.
No new entries in the System log or Kernel log pages between attempts.
Any ideas? Anybody else?
Is it possible that it's a browser related issue?
I've only tested it on Chrome without any extensions or restrictions, and the sysupgrade seems to work for 23.05.2 via luci
As suggested by the error message, slow uploads can cause the upgrade to abort. Try improving your wireless connection, switch to a wired connection, or copy the sysupgrade file to the device and upgrade using the CLI.
This came from this commit, with no explanation for the change in accepted input format.
We should continue here for this issue Bug in IPv6-Suffix (hex) max 8 characters?
I referenced the wiki which is generally the source of truth.
As @jow wrote in 2020:
32 bits = 4 bytes = 8 (hex) characters FF-FF-FF-FF.
I used a 16 character suffix which is provided by DHCPv6 to my Debian server and it worked fine but now the suffix field is red now.
Please allow upto 16 hex characters.
Its not 32 bits now it is 64 bits.
Look at my old post What's with the 32-bit restriction with IPv6-Suffix for static leases?
Now it is 64 bits and it worked for me.
In 2021, the max hostid length was increased to 64 in odhcpd, which would be handling the IPv6 static leases.
I'm wondering how this is possible:
WNDR3800 (22.03.5 upgrade to 23.05.2): MemAvailable essentially unchanged.
Archer C7v2 (22.03.5 upgrade to 23.05.2): MemAvailable dropped from a longtime average around 60000 to around 40000, even after another reboot.
In each case, the configuration is the same as before because it was an upgrade and the subsequent package installation is scripted.
If v23 is just bigger than v22 (though that seems like an unrealistic amount), then why only one router? They're similar ath79 routers though of course not identical. Is it possible that the c7 family underwent a major change in v23 to account for this while the other didn't? If so, any idea what?
Hmm, I don't recall seeing my C7v4 do that. Only "extra" service I've got is
adblock (~70k domains) and it shows about 60M available. Hard to remember, as I wasn't much paying attention, but I thought it was about like this with 22.03, too. (I did use
auc to update, so as to minimize footprint on the packages.)
My C7 v5 (dumb AP on 23.05.2) only has the extra packages luci-app-attendedsysupgrade, auc and htop....
Seems a little bit on the low-side but am not sure.
On the c7v2 issue, I'm noticing that if I check very soon after reboot the memory is in the vicinity of what it used to be, if not quite as high, so a more plausible figure.
But what's happening is a slow, steady drop, so a leak of sorts (it's a very active router, but it always has been). I know the wireless driver can have a big effect, so I guess I'll try a different one. Right now I'm on the same one as I've been using for at least a year,
kmod-ath10k-ct-smallbuffers, which has been fine.
@a-z didn’t you encounter reduced memory in 23.05 giving rise to OOM situations with the otherwise exact same adblock settings?
Had over 200mbit x 20mbit when attempting to update but the wired connection helped. Ultimately installed the attended upgrade package for luci and that worked.
I skipped the initial release of 23.05, so this is my first experience with any v23.
No adblock in use, but I do have the same additional packages installed that I had on v22, though of course they would have been updated because they were installed anew post v23. It's possible that it's an issue with one of them that would have materialized on v22 with the same package version, but that would be pretty unlucky.
I don't know if it this issue ultimately leads to OOM.
Might be worth installing luci-app-statistics (and the depencies) to plot ram usage over time. If you store the rrd files on USB they will survive reboot.
Lot easier than trying to tell the trend by manually collecting values occasionally. Compare with an uptime graph to see what happens after reboots etc.
I have two TP-Link Archer A7 v5 routers. One acts as router and other just an AP. For both of them, I replaced the following packages:
ath10k-firmware-qca988x-ct ==>> ath10k-firmware-qca988x (non-ct)
kmod-ath10k-ct ==>> kmod-ath10k-smallbuffers (non-ct and uses small buffers for low RAM usage)
I had high RAM usage if I used the kmod-ath10k (without smallbuffers, irrespective of -ct and non-ct version). Switching to -smallbuffers kmod fixed the issue for me. I am not running adblock so cannot comment on that.
As of 23.05.2 (and also in SNAPSHOT), you can enable auto backup of the luci-app-statistics data on the rrdtool setup page.
See details at https://github.com/openwrt/luci/pull/6646 (jtkohl is
@atownlede in the forums, if you have questions about it).