My first observation: my s23u still doesn't trigger the 160MHz. Only when I connect a laptop with an Intel WLAN card to WLAN does the router switch to 160MHz. I don't see any difference to 388.2 at the moment.388.2_1 Alpha, is out for a few hours, and 160MHz looks better now
160Mhz for S23 ultra, linkspeed is attached.
Zero SDK or wireless change between 388.2 and the 388.2_1 test builds...388.2_1 Alpha, is out for a few hours, and 160MHz looks better now
Zero SDK or wireless change between 388.2 and the 388.2_1 test builds...
I’ve been running 388.2 withI am not able to test it right now, but I saw that AMTM and Diversion were not "up to date".
I will update all the packages, let them run a little bit on 388.1 and will upgrade to 388.2.
Will post the result of my tests in the following days.
I’ve been running 388.2 with
1) Skynet enabled and Diversion disabled: no problems
2) skynet enabled and diversion enabled: problems
When I switch diversion off via the web interface, instantly the devices can reconnect again.
@RMerlin is right, it’s the new dnsmasq with diversion.
@thelonelycoder is this something that can be fixed?
It's called counter information ... you've decided to just blame Diversion and updated dmasq, I'm providing another point of usage.That's wonderful news for you. Unfortunately some of us do not, you've to read the thread not just react to one remark.
First, don't say that I am rude, if you experienced something as rude. I wasn't. Second, I don't "blame" Diversion, I love it, it has been working flawlessly. Rmerlin suggested/suspected that it could be dnsmasq and I said that I would test (so did someone else) and report back, so I did. Third, you didn't need to reply to my post, you could just report that everything was going well for you.It's called counter information ... you've decided to just blame Diversion and updated dmasq, I'm providing another point of usage.
Don't be rude. You didn't need to respond to me at all if the information isn't relevant to your setup.
Your router was rebooted. That means it may be using a different channel from before, for example.Not sure why, but 100% something has changed.
What??? The 388.2_2 will be drop tonight.The 388.2_1 Alpha Changelog contents for those that are curious:
Asuswrt-Merlin Changelog
==================
388.2_2 (xx-xxx-2023)
- UPDATED: Merged GPL 388_22668 for the XT12 (only)
- UPDATED: OpenVPN to 2.6.3.
- FIXED: QoS Status page wouldn't display Upload stats
if the WAN interface was set to a secondary
2.5G/10G port instead of the default WAN port.
- FIXED: dnsmasq may crash if no DNS server is configured
(fix backported from dnsmasq upstream)
- FIXED: Missing GPY211 driver for the XT12 and for certain
hardware revisions of other HND 5.04 models.
EDIT: As unusual, I can't resist an upgrade. Dropped the Alpha on my APs only. Router stays on stable. No issues observed at this point. Will monitor.
Your router was rebooted. That means it may be using a different channel from before, for example.
388.2_1 only contains an Ethernet driver fix for 5.04 models (specifically for the XT12), OpenVPN updated to 2.6.3 (largely Windows-related fixes), a dnsmasq backport, and an httpd fix related to QoS stats.
I cannot wait either for 388.2_2, so existedEDIT: As usual, I can't resist an upgrade. Dropped the Alpha on my APs only. Router stays on stable. No issues observed at this point. Will monitor.
I have GT-AX6000 as well running 388.2 and I had mem usage that high same as you. A temporary workaround I did, not really a fix, is to run diversion update twice a week which will drop the cache a bit to free some mem. I think i have seen it drop to about 53-54% after this. BUT a few hours later it will rise up.EDIT 2: The only observation I have just now is with my router (388.2 Release) and noticed the memory usage was at 95% - never seen it that high before on any release. Uptime was ~35days... so gave it a bounce and back to 48%. Strange...
free && sync && echo 3 > /proc/sys/vm/drop_caches && free
crontab -l
cru a FreeMem "0 */6 * * * sync && echo 3 > /proc/sys/vm/drop_caches"
cru a FreeMem "0 */12 * * * sync && echo 3 > /proc/sys/vm/drop_caches"
#!/bin/sh
### Cron job to clear mem cache every 6hrs
cru a FreeMem "0 */6 * * * sync && echo 3 > /proc/sys/vm/drop_caches"
Almost 30h now, 36/160 is running.Thank you like always for your through answer.
Actually, my router uptime already 3 times was reset, since 388.2 was installed.
Like its crashing, internally...
Not sure why, or what made it crash (no power outages occured, so its gotta be something else).
I also hard reset my units when 388.2 (Alpha/Beta/RC) was out, because it was started all weird from Alpha stages.
Had 160Mhz issue to keep maintaining, Ch 36.
Same ch worked perfectly on 80Mhz.
Thought because it is because I am on flight route.
Did not put much attention to it, just downgraded 160Mhz to 80, and 36 ch was fixed.
After router reboot, when I played with that on 160Mhz - 5 to 10m and the bandwidth would collapse from 160Mhz to 80 because it allegadly find a radar- and, allegadly made sense.
So just fixed on 80Mhz made it work just fine.
DOnt fix what aint broken, they say.
Another weird issue, was, after router reboot ir took roughly 5m to allocate Aimesh nodes.
I indeed acknowledge the fact you did not actively change anything that should help me resolve those issues, but gladly, something was changed that helped to resolve all of these.
Now, 24h that 160Mhz is running no issues whatsoever.
Not enough time to conclude any conclutions, but, I have a beginning here to start with.
So, again, thank you @RMerlin, for all your effort, even if you mistakenly managed to resolve me any issue
My main router is the same yours - the RT-AX88U - and it runs the same FW release 388.2. I also run Skynet on it and have not found any problems at all.I’ve been running 388.2 with
1) Skynet enabled and Diversion disabled: no problems
2) skynet enabled and diversion enabled: problems
When I switch diversion off via the web interface, instantly the devices can reconnect again.
@RMerlin is right, it’s the new dnsmasq with diversion.
@thelonelycoder is this something that can be fixed?
Skynet runs without a hitch. It’s when I have Diversion enabled that devices can’t reconnect, until I restart Diversion. Suspicion is that it has something to do with dnsmasq and/or DHCP — the guest network doesn’t seem to have this problem.My main router is the same yours - the RT-AX88U - and it runs the same FW release 388.2. I also run Skynet on it and have not found any problems at all.
Sure thing, though what’s relevant? I’ve been going through the log files and couldn’t find anything that jumps out.Can you post relevant Syslog messages you may have?
This might have something to do with Skynet taking a while loading whitelist entries.Skynet runs without a hitch. It’s when I have Diversion enabled that devices can’t reconnect, until I restart Diversion. Suspicion is that it has something to do with dnsmasq and/or DHCP — the guest network doesn’t seem to have this problem.
Sure thing, though what’s relevant? I’ve been going through the log files and couldn’t find anything that jumps out.
Thanks
So disable Skynet, yet enable Diversion? Ok, I’ll test it (but it takes a day or two for me to report back as it doesn’t happen immediately, but after 24h.This might have something to do with Skynet taking a while loading whitelist entries.
What if you disable Skynet only and reboot?
If it takes 24 hours to become a problem have both Skynet and Diversion on and wait till it happens again. In the terminal run top and post the output.So disable Skynet, yet enable Diversion? Ok, I’ll test it (but it takes a day or two for me to report back as it doesn’t happen immediately, but after 24h.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!