Fixed - Very poorly balanced RT-AX88U AiMesh running Merlin (w/ hardwired backhaul)

[mswlogo]

TL;DR - The power up sequence of ASUS AiMesh is what F*k's things up

My setup & Issue:​

• I run with a hardwired Backhaul (this is required for the work around unfortunately)
• I have about 50 clients with two AX88U's running Merlin
• I do run with split SSID's (2.4Ghz and 5.0Ghz)
  • All the problems exist with "Smart Connect" on or off (one SSID for both)
• I'd have situations where I'd see clients on absolutely the wrong node
• It's mainly due to boot up order
  • The main AX88U comes up first
  • A whole bunch of clients end up on that router
  • then the Slave AiMesh node comes up a few minutes later
• So I end up with like 45 devices on Main AX88U and 5 on the Slave AX88U
• The smarter devices (e.g. phones and computers) will migrate quickly to the best node, but a lot of dumb devices will stick to the wrong node.
• So next day it might be, 40 on primary and 10 on slave, still very lopsided
• I have, lot's of smart devices, smart appliances, echo shows, 4 macs and many other iDevices, and a boat load of phones (I'm a mobile developer)
• Oh and a Tesla that needs good wifi in the garage which is what started this whole mess
• I hardwire as much as I can
• Router locations:
  • AX88U is in the cellar in the ceiling in the corner closest to the Garage
  • AX88U is on main floor in a closet almost on the extreme the end of the house about 45 ft away (away from the garage)

Experimenting​

• For grins, I turned off Hardwired Backhaul and instantly everything was like 20 devices on Primary and 30 on slave (as they should be) and all the closest clients were on the correct node.
• OMG, the back haul is broken. So I turn it back on, and every thing was still good
• So it's not the hardwire Backhaul, it "Fixed it" from flipping the switch, that causes it to drop all wifi clients and let everything reconnect with both nodes fully up
  • That's the trick we want to automate
  • Easy peasy
  • It's really not hard, I'm just being very detailed

Unrelated learnings​

• Binding works like SH*T (it just stops things from rebalancing)
  • I didn't retry binding after I came up with the work around below
• If you do use binding and want to move a client to another node, ignore the low power warning message, which is bogus
• Optimize seemed useless too
  • If you ran Optimize (hardwired backhaul off) it ran a lot like a fresh boot that everything would connect to the primary first.
• Flipping the hardwired backhaul switch was the best "Optimization" I could do
• Pretty disappointed that ASUS does this and I may look elsewhere next time around

Solution​

How can I automate simulating flipping that hardwired backhaul switch?

Note: This may require Merlin, you need a custom boot script

Summary​

• Setup a boot script that does /sbin/service restart_wireless a couple minutes after router boots
• It needs to be done TWICE, it partially optimizes the first time, but the 2nd time it seems to be fully optimized
• So there are two scripts, one to restart wireless twice and another to run that script 2 minutes after boot and set up a cron job to run that script once a day
• The cron job might be overkill, but won't hurt
  • I have another option at the bottom to only do it on boot
• Scheduled Reboot will NOT solve this
  • If anything it will make it worse and make you regularly unbalanced (i.e. unoptimized)
  • Because Primary boots up first and everything tries to connect to it and some stay on a weak slow connection
• You can manually test this out first see below

Detailed Steps​

• In Administration (not sure if these are available on OEM ASUS firmware)
  • Enable jffs
  • Enabled ssh
• In a terminal (user name and IP address may differ)
  • ssh [email protected]
  • <router password>
• Now you are in a terminal in the router
• Copy everything between the ===== lines and paste it in the terminal in the router
• That will create a file /jffs/scripts/services-start
• If you screw anything up or want to change it, you can redo the paste (cat command)
  • It will overwrite the file
  • This is easier than learning vi

==============
cat << 'EOF' > /jffs/scripts/services-start
#!/bin/sh
# --- Schedule nightly WiFi reset at 3:00 AM ---
cru a WiFiReset "0 3 * * * /jffs/scripts/wifi_reset.sh"
# --- Run once 2 minutes after boot ---
(
sleep 120
/jffs/scripts/wifi_reset.sh
) &
EOF
==============

• Now we need to make the file runnable
• Enter next line in the terminal
  • chmod 755 /jffs/scripts/services-start
• Now we need to make another file
• Do the same thing

==============
cat << 'EOF' > /jffs/scripts/wifi_reset.sh
#!/bin/sh
logger -t wifi_reset "Starting WiFi reset sequence"
logger -t wifi_reset "Restart #1 initiated"
/sbin/service restart_wireless
sleep 60
logger -t wifi_reset "Restart #2 initiated"
/sbin/service restart_wireless
logger -t wifi_reset "WiFi reset sequence complete"
EOF
==============

• Now we need to make the file runnable
• Enter next line in the terminal
  • chmod 755 /jffs/scripts/wifi_reset.sh
• Now check it
• Enter next line in terminal
  • ls -la /jffs/scripts/
• It should look like this

admin@RT-AC88U-CB70:/tmp/home/root# ls -la /jffs/scripts/
drwxr-xr-x 2 admin root 0 Nov 13 22:50 .
drwxr-xr-x 19 admin root 0 Nov 15 00:22 ..
-rwxr-xr-x 1 admin root 206 Nov 13 23:11 services-start
-rwxr-xr-x 1 admin root 279 Nov 13 23:02 wifi_reset.sh

• Reboot your router
• Monitor the clients in each node
• Watch what happens around 3 minutes after boot
• Then notice where each client connected

This is an alternative to the above two scripts​

• If you don't want the cron job, and just want this on boot, then
• Just do this and create this one boot script file

=============
cat << 'EOF' > /jffs/scripts/services-start
#!/bin/sh
# Run everything inside a background subshell
(
# Wait 2 minutes after boot
sleep 120
logger -t wifi_reset "Starting WiFi reset sequence"
# First wireless restart
logger -t wifi_reset "Restart #1 initiated"
/sbin/service restart_wireless
# Wait 60 seconds
sleep 60
# Second wireless restart
logger -t wifi_reset "Restart #2 initiated"
/sbin/service restart_wireless
logger -t wifi_reset "WiFi reset sequence complete"
) &
EOF
===============

• and set it runnable
  • chmod 755 /jffs/scripts/services-start

Removal​

• ssh in and run these two commands
  • rm -f /jffs/scripts/services-start
  • rm -f /jffs/scripts/wifi_reset.sh
• reboot router

Try before you buy​

• If you have a hardwired backhaul
  • reboot, observe how messed up things are
  • then flip the hardwired backhaul switch off/on
  • then observe again clients and which nodes they are on

Or (no hardwired backhaul)​

• reboot router
  • observe how messed up things are
• In Administration
  • Enabled ssh
• In a terminal
  • ssh [email protected]
  • <router password>
• Enter the following command
  • /sbin/service restart_wireless
• <Physically wait 1 min>
• Enter the following command again
  • /sbin/service restart_wireless
• Then observe clients and which nodes they are on

Conclusion​

• Absolutely everything is connected where it should be
  • Near immediately after every reboot
• This is just poor design on ASUS's it should be doing something like this
  • Or offer as an option, like the daily reboot
  • This just restarted wifi, while all nodes up so everything gets a clean shot at once.
    • That's all this does
• Some nodes will eventually migrate, some just won't, some take forever

Before (5 min after boot WITHOUT work around)

After (5 min after boot WITH work around)

 

[jksmurf]

I've been fighting with my AiMesh for quite a while with clients not on the optimal AiMesh node

Liked your post not for the solution, if ASUS was working properly you shouldn’t need to implement a script, but for the thought process trying to address issues a number of us have experienced at various stages. Well done you .

 

[Tech9]

make you regularly unbalanced

What makes you "unbalanced" is the fact both routers run on full power by default. Unfortunately, AiMesh doesn't have per device Tx power control and your band-aid solution will be always temporary. Router + AP Mode configuration will give you more control, but you'll lose Guest Network propagation to "nodes". Get Omada or UniFi on your next upgrade.

 

[mswlogo]

What makes you "unbalanced" is the fact both routers run on full power by default. Unfortunately, AiMesh doesn't have per device Tx power control and your solution will be always temporary. Router + AP Mode configuration will give you more control, but you lose Guest Network propagation to "nodes". Get Omada or UniFi on your next upgrade.

No way. That's a band-aide and would defeat the purpose of having a Mesh in the first place. That's what ChatGPT suggested.

You want overlap. You're saying turn down the power on the primary so far 1/2 the house won't see it, at all.
So that they will wait for the node that is closer to come up.
Now the primary Node will run like sh$t and not reach the garage or much of anything.

This would not work well with Mesh or AP
I didn't see you said power tweaking with AP only, but even if you could on Mesh it's not good.

I want full power on two extreme ends of the house. One end to reach the garage and the other to reach blink cameras way out in the yard

The problems is sequencing, and the solution was to let devices pick the strongest (at the same point in time). Many devices are too dumb to reevaluate later.

I'll update my post with router locations

Almost every device in the house could connect to either router and run ok. It was really reaching the garage with one and the blink cameras on the other.
And no, I don't want to run an AP in the garage, been there done that, electronic don't like it when it's 0F out.

And running AP Mode I did consider, but it's a lot less work to use a Mesh if you can get it work. And that would be harder to get every device on the optimal node.
The wifi restart comes up in unison on both nodes so devices can easily pick the best node every time.

I don't have to do anything now, everything optimally connects and don't have to mess with non overlapping channels from two routers and neighbors or play with power.
And I get max reach on both ends of the house.

 

[Tech9]

That's what ChatGPT suggested.

Follow ChatGPT advice then. No problem.

 

[Tech9]

Almost every device in the house could connect to either router and run ok.

Yes, the reason for your imbalance. You have too much overlap between the two APs and your devices just connect to the first seen. This is not a Mesh. This is a Mess. I have 4x APs in my home and don't need to restart anything. ChatGPT will help you further. Good luck!

 

[mswlogo]

Follow ChatGPT advice then. No problem.

I ignored ChatGPT advice, because it was giving me the same advice you just suggested

I do appreciate your sharing ideas, but using AP mode and messing with power with be a total time suck and terrible results.

One router is just barely reaching the garage on one end and the other is barely reaching the furthest blinks. And reduction in power on either and I'll lose them, period.

I could lock clients down using two SSID's on two routers, but that would be a ton of work.

 

[mswlogo]

Yes, the reason for your imbalance. You have too much overlap between the two APs and your devices just connect to the first seen. This is not a Mesh. This is a Mess. I have 4x APs in my home and don't need to restart anything. ChatGPT will help you further. Good luck!

It's working perfect now. And I only need two nodes. I guess that's why you need 4 AP to fill in the gaps you made by turning down the power.

It's a bug in ASUS that it just doesn't do this in the first place or give an option to do it. You want the nodes to come up simultaneously so dumb devices pick the best one.
It does have a really stupid mode "Roaming Assistant" of doing something like this per node, but it's almost as dumb as turning down the power on AP nodes.
If power drops below threshold then roam. That would be a nightmare using that.

It should just periodically renegotiate any node, by time [off hours], when all nodes are UP. Which is WHAT I DID. Because it may find a better node, and does.

Don't need the ChatGPT digs, really. Because ChatGPT gave that same advice you did and I ignored it as it was really terrible advice.
But if it works for you, tweaking power on every AP to get 50 devices connecting where you want, and messing with all the channel clash, enjoy.

If I did what you suggest I'd have to put an AP in the garage and way out in the yard.
Because we don't want them too strong or something in the house might connect to them. Can't have any overlap, right. That's insane.

So in the extreme, why not have an AP for every client device with the lowest power possible? If 4 is good, 16 has to be better, right?
That's exactly the way you're thinking. And in the extreme yeah, it would work.

If I could double the power on one, and run no mesh, I would.

Sorry if my script was overwhelming for you. It's pretty damn simple and works great.

The main problem is not power, it's that it comes up sequentially, script solves the sequential problem.

Everybody, reconnect, when all mesh nodes are up. That's all it does.

I'm using the least nodes to get the two extremes of coverage I need and I should not care what overlaps (clients should find the best one, and they can, and now they do, when shown all the options at the same point in time)

 

[Tech9]

The main problem is, not power, it's that it comes up sequentially, this solves the sequential problem.

Well... if constant rebooting is your choice - continue doing it. I have some doubts many people will be very pleased with such a fix. If you want permanent fix advice, let me know. I can only give you a hint - router/AP too close with signal too strong is seen as less preferable connection by your devices. Your routers depending on the region use up to 1000mW power per radio. I use 40mW on 2.4GHz band and 100mW on 5GHz band and my devices roam between the APs perfectly. I never reboot anything unless software update requires it. Tuning a system needs some understanding of how Wi-Fi works. High power AP 30dBm to low power client 12-14dBm at distance and through walls is not a good Wi-Fi.

If I could double the power on one, and run no mesh, I would.

No. You'll only create disbalanced links. You don't change the power of the client. Wi-Fi is 2-way communication. If you stopped here to learn something - good. If you stopped here to advertise your rebooting as a solution - bad. There is no sequential power up problem. Your devices will be messed up again on next re-connect. You know it, but don't know why it happens.

 

[jksmurf]

It's mainly due to boot up order, that the main AX88U comes up first, a whole bunch of clients end up on that router then the Slave AiMesh node comes up a couple minutes later
So I end up with like 45 devices on Main AX88U and 5 on the Slave AX88U

Just a data point on this statement btw, as I have observed similar behaviour, but if I let it settle, the mostly IoT 2.4Ghz clients gravitate to the closest node and eventually find what I consider to be a reasonable balance.

I use AiMesh, Smart Connect and it seems to work pretty well on my local system. The remote system is all wired backhaul so has different parameters.

There’s so many variables though, with everyone’s systems and conditions, it must be really, really difficult for the system designers to work out configurations that will bracket the greater proportion of users needs.

 

[Tech9]

really difficult for the system designers to work out configurations

It's super easy if you have the control options. The reason I recommended upgrade to system with everything needed out of the box. AiMesh is mostly testing your luck. Some other home "mesh" systems do the tuning automatically. At least make an attempt.

 

[mswlogo]

Just a data point on this statement btw, I have o served the same behaviour, but if I let it settle, the mostly IoT 2.4Ghz clients gravitate to the closest node and eventually find what I consider to be a reasonable balance.

I use AiMesh, Smart Connect and it seems to work pretty well on my local system. The remote system is all wired bsckhaul so has different parameters. There’s so many variables though, with everyone’s systems and conditions, it must be really, really difficult for the system designers to work out configurations that will bracket the greater proportion of users needs.

There were some that were just not moving. Some, it didn't really matter all that much, they would run fine on either. Some would move, and some that did move would take a long long time move. This way, if I get a power glitch, or I do want to reset things, I'm fully optimized in 3 minutes.
And like I said the, Tesla is what started this, and it was stuck on the wrong node, and I had to reboot the car to get it move if it landed on the wrong node.

I updated the OP, with a simpler alternate, just do it on boot only. That's when it's the worst. And for folks that do daily reboot to resolve other issues, this is a must.
And I also added manual steps to test it before adding any scripts, to just see if it's worth it. Try it.

I always thought it was resolving itself. But it wasn't when I looked closer and part of that resolution was some clients eventually rebooted or maybe they eventually do renegotiate.
But it was always always heavily lopsided with way to many devices connecting to the worse placed node, the primary, (but it's the best place for the garage and needs max power)

Oh, and now when I reboot just the primary, everything is perfect too. It's win win. So simple.

I've always run split SSID's I had a few odd devices over the years that just refused to connect. Like a furnace that had older tech and was 2.4Ghz but if it was joined it just wouldn't connect at all. Anything I know needs speed, I put on 5Ghz (regardless if it's weak). Anything that needs range and doesn't need bandwidth I put on 2.4Ghz.
Having that control has been really helpful. Letting devices decide and bounce between, not helpful.

For the most part, only the phones, AppleTV, Echo Shows's are on 5Ghz. All computers are wired and most everything else is on 2.4Ghz.

 

[mswlogo]

Well... if constant rebooting is your choice - continue doing it. I have some doubts many people will be very pleased with such a fix. If you want permanent fix advice, let me know. I can only give you a hint - router/AP too close with signal too strong is seen as less preferable connection by your devices. Your routers depending on the region use up to 1000mW power per radio. I use 40mW on 2.4GHz band and 100mW on 5GHz band and my devices roam between the APs perfectly. I never reboot anything unless software update requires it. Tuning a system needs some understanding of how Wi-Fi works. High power AP 30dBm to low power client 12-14dBm at distance and through walls is not a good Wi-Fi.



No. You'll only create disbalanced links. You don't change the power of the client. Wi-Fi is 2-way communication. If you stopped here to learn something - good. If you stopped here to advertise your rebooting as a solution - bad. There is no sequential power up problem. Your devices will be messed up again on next re-connect. You know it, but don't know why it happens.

You didn't read my post

All you need is this on boot, that's it, and you do need to do it twice

sleep 120
/sbin/service restart_wireless
sleep 60
/sbin/service restart_wireless

Since I had bothered to add a boot script, I figured it won't hurt to add 1 more line for a cron job. There are other bugs in ASUS routers, really.
I have seen a few other issues, that I just lived with and that nightly wifi restart might clear those up too, it's totally harmless.

I have very little doubt, most would be overjoyed with this and makes the ASUS AiMesh work so much better it's not funny.
I was thinking of replacing it before I found this work around
It's why I took the time to share it

Yes, it is absolutely, beyond a doubt, a sequential power up problem.

 

[bbunge]

The best settings for AiMesh are the defaults. Enabling Ethernet Backhaul has been shown, for some time now, to cause connection issues. Forcing the higher WIFI bandwidth can acerbate the problems. AiMesh needs time to settle into its settings. Rebooting or doing network restarts only prolongs the confusion.
And you really believe ChatGPT??? If so I have some prime land to sell you in southern Florida!

 

[mswlogo]

The best settings for AiMesh are the defaults. Enabling Ethernet Backhaul has been shown, for some time now, to cause connection issues. Forcing the higher WIFI bandwidth can acerbate the problems. AiMesh needs time to settle into its settings. Rebooting or doing network restarts only prolongs the confusion.
And you really believe ChatGPT??? If so I have some prime land to sell you in southern Florida!

You folks really don’t get my ChatGPT comment, do you. I IGNORED that one bit of bad advice from ChatGPT. It wanted me to switch to AP and Fk with power. So some here are agreeing with that ChatGPT advice. It’s probably here is where it got it from, LOL.

I totally bumbled into this thinking Hardwired backhaul was the problem. Turned out it wasn’t.

You also didn’t read. This has absolutely nothing to do with running hardwired Backhaul or not. It was flipping the Hardwired switch (in EITHER DIRECTION) I noticed it did a WiFi reset without dropping the mesh nodes. But the cable was in place.

So that allowed everything to reconnect with all mesh nodes still up. And the closest clients all connected to closest nodes. This was a side affect I wanted to take advantage of.

Sorry this is so challenging for some to grasp.

Hardwired backhaul is also working fine. I could share tips on that but I’m finding this way to exhausting and time consuming to share my experiences. If I do see problem with it on I’ll shut it off or find different hardware.

But you got me thinking, sorry for that. This probably does require a hardwired backhaul to work. I didn’t try this with it unplugged. Only with the switch off or on. With it unplugged it may go back to the sequential startup because it will lose access to the mesh nodes. With hardwire connected it doesn’t. I need to double check that so I don’t mislead people that don’t have hardwire.

And for the record if you think AI (including ChatGPT), in general, is a useless stupid tool, good luck in the future. That helps me know which folks to ignore.

AI tools are extremely powerful tools, Claud Code being my favorite. My job depends on making productive use out of AI. And if I don’t, I will lose my job and I totally agree with them I should. Because I’d be a really bad engineer if I had the same attitude towards AI (including ChatGPT) I’ve seen here.

If you don’t know how to leverage AI, good luck.

 

[bbunge]

Because I’d be a really bad engineer

Two weeks ago I couldn't even spell engineer. Today I are one!

And, Merlin firmware is not recommended for AiMesh nodes.

 

[mswlogo]

Two weeks ago I couldn't even spell engineer. Today I are one!

And, Merlin firmware is not recommended for AiMesh nodes.

Slave nodes or everything? Do you have a reference or details of why?

I really have not had much issue with it. Been running Merlin with AiMesh for a couple years.
The poorly / slowly optimized mesh was not really a huge problem until I realized why the car was having issues on connectivity, which needed a reboot to resolve.
That's when I noticed the implementation was dumber than I thought.

BTW it does need a hardwired backhaul connected for my work around to work (switch can be in either direction, but the connection needs to be there)
I think it needs hardwire to get past the sequential nature. Which I don't think OEM firmware can get around.

 

[degrub]

i think if you search for Merlin's threads about using Merlin firmware on nodes, he said something to the effect that his firmware does not add anything to the node function. The AiMesh firmware is in the ASUS part of the firmware and his addition does not touch it. His firmware additions are intended for the main router.

 

[bennor]

With respect to Asus-Merlin and AiMesh nodes. Note the Asus-Merlin Wiki entry on AiMesh. It is dated (last updated 2019), but it does indicate the following:

AiMesh

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

While Merlin-based nodes seem to work fine so far (aside from the above limitation), there is generally little benefit in running it on a node, so it's generally recommended to leave your nodes on the stock Asus firmware.

Note that AiMesh can sometimes be less stable than using a plain router + access point or repeater configuration due to the increased complexity of sharing configuration between the main router and its node(s). AiMesh implementation being closed source, there is nothing that can be changed about AiMesh's functionality by the developers of this project. This also means that there are zero chances of adding support to unsupported models such as the RT-AC87U or RT-AC3200, or enhancing/implementing additional features specific to AiMesh. Only Asus can technically do that, since any change has to be made within components for which only they have access to the source code.

 

[mswlogo]

i think if you search for Merlin's threads about using Merlin firmware on nodes, he said something to the effect that his firmware does not add anything to the node function. The AiMesh firmware is in the ASUS part of the firmware and his addition does not touch it. His firmware additions are intended for the main router.

Yes I found that. I prefer run all the same, so everything is on the same vintage. If you don't, you might be running different vintage closed drivers on the main node vs the slave nodes and I don't care to keep track or risk issues with that. If I just run all the same I don't need to think about it. I only have one slave node and I do manual updates on main node any way.