Release Asuswrt-Merlin 388.2 is now available for select models

[Damit1]

388.2_1 Alpha, is out for a few hours, and 160MHz looks better now
160Mhz for S23 ultra, linkspeed is attached.
Remains to be checked further on if something was changed actually

 

[Dedel66]

388.2_1 Alpha, is out for a few hours, and 160MHz looks better now
160Mhz for S23 ultra, linkspeed is attached.

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.

However, when I look at the changelog, that's not to be expected.

 

[RMerlin]

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...

 

[Damit1]

Zero SDK or wireless change between 388.2 and the 388.2_1 test builds...

Not sure why, but 100% something has changed.
My all setup has connected way smoother, nothing has changed by my side.

I do know to tell that on 388.2,
during its all course the setup connection, it was slower and 160Mhz just dropped.

Not sure why/what changed.

 

[Bogey]

I 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?

 

[5stringdeath]

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?

I've been running 388.2 since it was released, amtm 3.6 and Diversion 4.3.3

Having zero problems.

 

[5stringdeath]

That's wonderful news for you. Unfortunately some of us do not, you've to read the thread not just react to one remark.

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.

 

[Bogey]

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.

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.

 

[RMerlin]

Not sure why, but 100% something has changed.

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.

 

[shabbs]

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 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.

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...

 

[bluepoint]

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.

What??? The 388.2_2 will be drop tonight.

 

[Damit1]

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.

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

 

[snapieee]

EDIT: 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 cannot wait either for 388.2_2, so existed

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...

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.

I found out also this handy dandy cmd after searching this forum, which will drop the cache manually and free some mem. Again, this is not a fix.

free && sync && echo 3 > /proc/sys/vm/drop_caches && free

sync && echo 3 > /proc/sys/vm/drop_caches : is the actual cmd to free the mem
free: display mem utilization before and after

I though of why not automate this but I didn't know how. So, I googled and googled and googled until I read something about cron jobs. I am by no means a linux expert but I have a good grasp of a few things in it. Next job was to create the cron job and save it in crontab with all the other scheduled tasks. With some help from this forum and google of course, lol, I was able to create the cron job successfully and confirmed by running the following command to see it is actually in crontab:

crontab -l

The way that I actually did it was to edit init-start in /jffs/scripts and add the following: (NOTE: I didn't have init-start so I had to create it manually using nano).

cru a FreeMem "0 */6 * * * sync && echo 3 > /proc/sys/vm/drop_caches"

Now, this particular cron task will run every 6 hrs. I had it set to run every 12 hrs, but the mem utilization was showing high more frequently. So, I decided 6 hrs is the sweet spot.

the following is what I used before for every 12 hrs:

cru a FreeMem "0 */12 * * * sync && echo 3 > /proc/sys/vm/drop_caches"

I am not really sure if running this cron task, or clear the cache manually frequently will exhaust or cause any harm to the router in the long term.

This is the contents of my init-start script I used: "I believe the default permission is 755, or i had to use chmod to change it...don't remember, loll"

#!/bin/sh

### Cron job to clear mem cache every 6hrs
cru a FreeMem "0 */6 * * * sync && echo 3 > /proc/sys/vm/drop_caches"

From what I read here, the cron job needed to be in init-start to make sure it will be added back to crontab when the router reboots.

 

[violetenergy]

Hello @RMerlin ,

Thank for your work.

Feedback about low priority issue ; "Reboot cancel setting LED"

• I have two AX-86U on 388.2 Merlin with really basic config, I disable LED on my routers and I have weekly reboot planned
• I use following setting for LED ; "Aimesh/%SelectRouter%/Management/LED"
  • After each reboot, LED is again on , on web interface I see off , I need to Set On and Set Off again for see LED really OFF
• Settings on "Administration/System/Disable LED" have only effect on main router. (Same with firmware asus)

I don't have this "reboot issue" on Asus Official firmware.
Can be great if a fix can be implemented on next release, I don't see something wrong on Log After reboot.

Available if you need anything for help.

Thank you so much !

 

[Damit1]

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

Almost 30h now, 36/160 is running.
Bunch of airplanes flew over me within just few meters, no issues.
System is way more stable here.
Cannot indicate or point which change (of the changelog) did this, but eventually- fixed some issues for me.

Even the AiMesh Wireless backhaul is stabler now for 30h, got to 2G/2G (never passed 1.9Gb/s previously).

Anyway, that way or another- good job @RMerlin , glad I donated 2nd time, you are way better than a stock in the term of good investment

Thank you!

 

[thelonelycoder]

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?

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.
Can you post relevant Syslog messages you may have?

 

[Bogey]

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.

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.

Can you post relevant Syslog messages you may have?

Sure thing, though what’s relevant? I’ve been going through the log files and couldn’t find anything that jumps out.

Thanks

 

[thelonelycoder]

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

This might have something to do with Skynet taking a while loading whitelist entries.
What if you disable Skynet only and reboot?

 

[Bogey]

This might have something to do with Skynet taking a while loading whitelist entries.
What if you disable Skynet only and reboot?

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.

 

[thelonelycoder]

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.

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.