Release Asuswrt-Merlin 386.9 is now available for AC models

[visortgw]

I tried everything except direct wired connection, and it didn't work. However, what did work was performing the update over 2.4 GHz wifi instead of 5 GHz. That's actually really weird, but I guess all's well that ends well.

Not really. 2.4 GHz has longer range, giving it a much larger usable footprint.

 

[bennor]

I've been going through the nvram list on an AC68U running 386.9, and by far the majority of space used is taken up by nvram variable names rather than nvram variable values. I've manually pruned out all the old stuff that is known to be no longer stored in nvram, I've deleted almost all of the entries in the custom_clientlist, and I've trimmed the length of entries such as the ciphers used for the 5 VPN clients, and my AC68U is still at 651xx bytes. <snip for readability>

Some other suggestions for dealing with high NVRAM usage were discussed in the following thread:

Solved - High nvram usage

I was playing with my RT-AC56U running RMerlin 384.5 and I noticed by accident that the nvram usage is a bit high: NVRAM usage: 65545 / 65536 bytes It seems I am 9 bytes over the limit and yet the router *appears* to be running fine. I do use long wifi passwords, have 30+ static dhcp bindings...

www.snbforums.com

Among them are moving one's manual DHCP reservations to /jffs/configs/dnsmasq.conf.add and another is running the following to clean out unused NVRAM entries (as always use at your own risk).

for line in `nvram show | grep =$ `; do var=${line%*=}; nvram unset $var; done; nvram commit

Or

for line in `nvram show | grep ^[^=]*=$ `; do var=${line%*=}; nvram unset $var; done; nvram commit

 

[heysoundude]

Feel free to correct my likely-incorrect understanding, but wasn't YazDHCP intended to make DHCP reservations more space-efficient?
Most folk use it to increase the number of static addresses, but wouldn't the reverse also hold true: fewer reservations make for more available nvram, like a restaurant's tables?

 

[teo1966]

I have an AC88U here with 2 x AC68U in mesh
I have 4 ports connected
I've already done a reboot
on port 5 indicates that something is connected but it is not

 

[capncybo]

@teo1966 Does indeed look wrong but I need to ask... Have you've already tried a browser refresh (Ctrl+F5 Key-Combo)?

 

[heysoundude]

Or try using ports 2, 4, 6, 8...
(because 1, 3, 5, 7 may be problematic...)

 

[heywire]

Stable after 2 days of running in an active network with 20-30 clients and:
1. AC86U main 386.9 firmware. Previously 386.7_2
2. 3 Aimesh nodes: AC66UB1 (wired), AC68U (wireless), AX52 repeater (wireless) - all running stock firmware.

Operationally, the network is running smooth - no disconnections etc. So I recommend updating.

But the long-standing problems with Client List and Wireless Log being completely unreliable persist, tho; a number of clients is lacking, especially in the wireless Log, and new clients don't appear even in the Client List until I do a reboot (doesn't cure the Wireless Log tho, only marginally improves is). This makes monitoring the network difficult, and I wish some effort could be put into improving this. I don't know if the official AsusWRT is better than Merlin in this respect.

Another problem I experienced was when I tried "binding" a client (nintendo switch) to an Aimesh node in the iOS Asus Router app (because it suddenly connected to the closest Aimesh node instead of the closest). Now it seems stuck; "unbinding it in the app doesn't unbind it (I click "unbind", dialogie appears asking: "are you sure you want to...", I click "Yes", but it it still "binded in the client list with a RJ45 adapter icon on the right instead of the correct wireless/5ghz icon).

 

[Sonyrolfy]

I wonder if dnsmasq 2.88. changed this below or did I do something or something else?


Old. RT-AC86U_386.7_2 (routing table)
ISP. DNS * 255.255.254.0 U 0 0 0 WAN

New. RT-AC86U_386.9_0 (routing table)
ISP.DNS * 255.255.255.0 U 0 0 0 WAN

Above is an copy/paste from System Log - Routing Table

 

[teo1966]

@teo1966 Does indeed look wrong but I need to ask... Have you've already tried a browser refresh (Ctrl+F5 Key-Combo)?

yes with firefox and edge

 

[RMerlin]

a number of clients is lacking, especially in the wireless Log,

The Wireless Log will always reliably display all connected clients since it directly queries the radio for that list. If a client does not show there, then that client is not connected to that router, and must be either disconnected, or connected to your mesh node.

I wonder if dnsmasq 2.88.

dnsmasq is unrelated to routing.

 

[Natty]

After reading the useful tips above from @bennor I decided to do the factory restore/reset on my RT-AC66U B1. After many hours of bad language and grumpiness, especially after enabling HTTPS login near what I thought would be the end of the process then getting locked out due to a certificate issue, so having to go through it all a second time, it is back to functioning as it was. Guess who forgot to save a backup .cfg before enabling HTTPS?! I am reminded of why I was so reluctant to do that factory restore.

I pruned the DHCP reservation list from 32 entries to 19. That combined with the assumed efficiency saving of removing accumulated redundant crud dating back to 384.18 reduced my NVRAM usage from 65545 to 61198 bytes. It seems to be working ok, and the low NVRAM warning has gone away, so I guess the factory restore was worth the pain.

 

[Wistuplu]

Dear,

No mesh here, just one AC-86U. Installed 386.9 approx. 4 days ago. All good. Thank you very much RMerlin and testers.

FYI
386.9 seems to work better with my wifi clients than 386.7.x (mostly for an Android 9 client in a "remote" location that sometimes failed to reconnect after airplane-mode).
In some past release(s), the Ookla speedtest sometimes failed. With 386.9, it seems to always work, from the webui, and from the Asus app on Android.

Thank you again, and best wishes all for 2023

 

[bennor]

+I pruned the DHCP reservation list from 32 entries to 19.

You could try moving the DHCP reservations to either YazDHCP or to the /jffs/configs/dnsmasq.conf.add file. That might free up a little bit more. If moving to the dnsmasq.conf.add file you'll need to properly format each reservation. (See this post) Note: there may be certain tradeoff's to using YazDHCP or dnsmasq.conf.add file, like loosing the custom icons.

 

[Natty]

Thanks @bennor I'll keep that in mind. Users report no issues with their devices routed via 386.9. NVRAM went up by 1 byte after the nightly reboot. System log has several entries such as this:

Jan 14 14:25:48 kernel: nvram: consolidating space!

I was looking for the "regularly flush caches" setting as I had set this without researching what it does, and I now want to turn it off as I believe it has no effect on NVRAM. I can't find it anywhere. After crawling around every tab of every function it has disappeared, at least to my eyes. Was it removed? (not mentioned in changelog) If not, where am I missing it?

Crawling around every page of the webui without changing anything increased NVRAM use from 61199 to 61357 bytes, so something is being logged or cached in NVRAM, possibly related to visiting pages. What might that be? Will it just keep growing even if I don't change any settings?

 

[ColinTaylor]

I was looking for the "regularly flush caches" setting as I had set this without researching what it does, and I now want to turn it off as I believe it has no effect on NVRAM. I can't find it anywhere. After crawling around every tab of every function it has disappeared, at least to my eyes. Was it removed? (not mentioned in changelog) If not, where am I missing it?

Yes it was removed (perhaps only for HND models?). It used to be at Tools - Other Settings > Advanced Tweaks and Hacks

Crawling around every page of the webui without changing anything increased NVRAM use from 61199 to 61357 bytes, so something is being logged or cached in NVRAM, possibly related to visiting pages. What might that be? Will it just keep growing even if I don't change any settings?

Navigating to certain pages will create "working copies" of some of the variables used by that page. Nothing is being logged or cached. So once you have visited these pages for the first time the nvram use should stabilise.

 

[Sonyrolfy]

The Wireless Log will always reliably display all connected clients since it directly queries the radio for that list. If a client does not show there, then that client is not connected to that router, and must be either disconnected, or connected to your mesh node.


dnsmasq is unrelated to routing.

Got it, br0 vs eth0. Subnets clearly not for me

 

[dickensr4lf]

RT-AC86U: Dirty upgrade from 386.7_2, so far stable. Running for about 40 min.

 

[PaulRuby]

Possible bug in 386.9: Upgraded my RT-AC5300 from 386.7_2 to 386.9 but this caused a problem. I have an AiMesh network with two RP-AC1900 extenders, each connected by wired ethernet for backhaul. After the upgrade, these would lose connection back to the router every few minutes for maybe 10 seconds at a time. I can see the dropped connection from the router AiMesh network page and all the devices connected to the AC1900 lose connection. Both AC1900 are on the newest FW (3.0.0.4.386_49703). I reverted my RT-AC5300 to 386.7_2 and everything is fine again.

 

[heywire]

Possible bug in 386.9: Upgraded my RT-AC5300 from 386.7_2 to 386.9 but this caused a problem. I have an AiMesh network with two RP-AC1900 extenders, each connected by wired ethernet for backhaul. After the upgrade, these would lose connection back to the router every few minutes for maybe 10 seconds at a time. I can see the dropped connection from the router AiMesh network page and all the devices connected to the AC1900 lose connection. Both AC1900 are on the newest FW (3.0.0.4.386_49703). I reverted my RT-AC5300 to 386.7_2 and everything is fine again.

What does the log say when the disconnection occurs?
I had problems with a wired AC66U-B1 Aimesh node routinely dropping both clients and an AC68U wireless Aimesh node that connected to it at short, reoccurring intervals at one point running 386.7_2.
Solution: WPS reset the AC66U-B1 and then set it up as an Aimesh node again. The problems stopped, and has not reoccurred after upgrading to 386.9 either.

 

[PaulRuby]

What does the log say when the disconnection occurs?
I had problems with a wired AC66U-B1 Aimesh node routinely dropping both clients and an AC68U wireless Aimesh node that connected to it at short, reoccurring intervals at one point running 386.7_2.
Solution: WPS reset the AC66U-B1 and then set it up as an Aimesh node again. The problems stopped, and has not reoccurred after upgrading to 386.9 either.

Looks like the log was killed when I reverted FW. I only have new log entries. I'll have to repeat the process and see...