What's new

[Official Release] AiMesh Firmware v3.0.0.4.384.10007 for All Supported Products

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
So. Getting back to debugging. If we find bugs, what's the best way to let Asus know about them? Create a ticket? Or post in here? I have a few that I posted without any response.

For now, just post it in this thread. @arthurlien is monitoring it, if he needs additional info he will let you know.

Asus might not answer everyone's report, but that doesn't mean they didn't see it.
 
Sorry to ask what should be obvious, but is the point of AIMesh really supposed to be about seamless roaming? Is the switch between nodes supposed to be initiated by the client or the mesh system?

I believe it's initiated by mesh system. Here's a sample log entry from my aimesh setup.

Jan 30 06:54:35 roamast: discover candidate node [D8:50:E6:CF:84:E8](rssi: -55dbm) for weak signal strength client [2C:33:61:AE:7C:5A](rssi: -73dbm)
Jan 30 06:54:35 roamast: eth2: disconnect weak signal strength station [2c:33:61:ae:7c:5a]
Jan 30 06:54:35 roamast: eth2: remove client [2c:33:61:ae:7c:5a] from monitor list

84:E8 is my node and 7C:5A is the client. It would appear the environment understands there's better connectivity to the node so it actively disconnects the client from the router. Note this is not an enterprise solution where both the AP and client work together for a true seamless hand off. In this case it's a hard disconnect, with the idea being that the wireless client will attempt to reconnect to better signal available on the node.

At least that's how i understand it! :D

Hope that helps.
 
I'm having problems getting my AiMesh node to connect via wired backhaul. I have 2 86u's and I did a factory reset on both because my WAN speeds were only getting around 650-700 while wired direct and with my OnHub's I could get maxed out at 950-1000. Before the factory resets I had wired backhaul successfully working. Now, hooked up the same way, I can't get the backhaul to switch to wired even when I manually select Ethernet. Any hints or tips on either issue?
I, too, had issues after updating to the newly released .20287 with both WiFi stability and WAN throughput (30 Mbps up/7 Mbps down connection was lucky to see 1 or 2 Mbps down at times). I have an RT-AC68U as the primary router and three (3) RT-AC68U AiMesh nodes, all connected via wired backhaul through various TP-Link unmanaged switches. I discovered a couple of settings that appear to have resolved my issues once and for all (hopefully):
  1. Disable Airtime Fairness -- it has been historically reported to cause stability issues.
  2. Adjust Roaming Assistant setting. Initially, the 2.4 GHz value was set to 55 dB and 5 GHz to 70 dB. I was seeing a very high number of disconnects/reconnects in the log, primarily disconnecting from the 2.4 GHz network. I tweaked the values, and I have settled on 65 db/70 dB for 2.4 GHz/5 GHz, respectively, based upon the actual disconnect values in the log.
 
For now, just post it in this thread. @arthurlien is monitoring it, if he needs additional info he will let you know.

Asus might not answer everyone's report, but that doesn't mean they didn't see it.
Can you (or another mod) please create a new [Official Release] thread with sticky to specifically cover the new AiMesh 3.0.0.4.384.20287 firmware release? Unfortunately, release 384.10007 and 384.20287 comments are being co-mingled in this thread.
 
I, too, had issues after updating to the newly released .20287 with both WiFi stability and WAN throughput (30 Mbps up/7 Mbps down connection was lucky to see 1 or 2 Mbps down at times). I have an RT-AC68U as the primary router and three (3) RT-AC68U AiMesh nodes, all connected via wired backhaul through various TP-Link unmanaged switches. I discovered a couple of settings that appear to have resolved my issues once and for all (hopefully):
  1. Disable Airtime Fairness -- it has been historically reported to cause stability issues.
  2. Adjust Roaming Assistant setting. Initially, the 2.4 GHz value was set to 55 dB and 5 GHz to 70 dB. I was seeing a very high number of disconnects/reconnects in the log, primarily disconnecting from the 2.4 GHz network. I tweaked the values, and I have settled on 65 db/70 dB for 2.4 GHz/5 GHz, respectively, based upon the actual disconnect values in the log.

I usually go a step further and disable the usual suspects, the embedded devices seem to be much happier with them turned off:

yghozFf.png
 
Can you (or another mod) please create a new [Official Release] thread with sticky to specifically cover the new AiMesh 3.0.0.4.384.20287 firmware release? Unfortunately, release 384.10007 and 384.20287 comments are being co-mingled in this thread.

That will be up to Arthur.
 
For the security policy, the guest network shall be isolated with private network. (personal opinion)
I think it would be good to have several options. One a guest network where the devices only have internet access and can't communicate with any other device and another option where the guest devices can't access the non-guest network but they can communicate with other devices on the guest network. Any chance that we will ever get VLAN support?
 
I believe it's initiated by mesh system. Here's a sample log entry from my aimesh setup.

Jan 30 06:54:35 roamast: discover candidate node [D8:50:E6:CF:84:E8](rssi: -55dbm) for weak signal strength client [2C:33:61:AE:7C:5A](rssi: -73dbm)
Jan 30 06:54:35 roamast: eth2: disconnect weak signal strength station [2c:33:61:ae:7c:5a]
Jan 30 06:54:35 roamast: eth2: remove client [2c:33:61:ae:7c:5a] from monitor list

84:E8 is my node and 7C:5A is the client. It would appear the environment understands there's better connectivity to the node so it actively disconnects the client from the router. Note this is not an enterprise solution where both the AP and client work together for a true seamless hand off. In this case it's a hard disconnect, with the idea being that the wireless client will attempt to reconnect to better signal available on the node.

At least that's how i understand it! :D

Hope that helps.

Thanks, that's very helpful indeed. It sounds a bit like a built-in roaming assistant which could result in frequent disconnects/reconnects to a "smart" device like a cell phone. When I experimented with the Roaming Assistant I found that if my threshold was too high then the phone would be kicked off, only to try to reconnect to one of my other nodes, where it would be kicked off again. It would then try the first node and repeat the process. I think that the process needs to be made smarter where nodes are aware that they've kicked a client off a particular band and won't accept a reconnect for a certain "dwell" time, similar to Smart Connect.
I'm sure that Asus will think this all through as it moves forward with AIMesh.
 
I have an RT-AC68U and RT-AC68W setup with Aimesh using ethernet backhaul and the connection shows correctly from the main router (the RT-AC68W).

Couple questions:
  • A wifi scanner shows both devices using the same channel (161) - Can I configure them to (and don't I want them to) use different channels?
  • The Device List for the device listed as the node appears to update very slowly (like minutes after a client connects). Is this normal?
  • Is there a way to completely disable the 2.4GHz radios?
  • Whats the best way to verify that as I walk from the front of the house to the back that the handoff between them is actually happening?
Thanks in advance!
 
Sorry to ask what should be obvious, but is the point of AIMesh really supposed to be about seamless roaming? Is the switch between nodes supposed to be initiated by the client or the mesh system?
Base on my own experience any mesh system, no matter how it do the roaming in the backend, should give the device a seamless roaming, depends on how it implement a little packet lost is acceptable in some case. Back in the day when there are no wifi roaming standing vendors build their own mesh system, it is nothing new to add a software/controller on exist wifi equipment to implement roaming function. Asus may be the first one provide this function on exist home user grade router without additional cost.

Depends on how you implement the roaming, most of the time it will be a job of the wifi AP/controller as you can't expect a client will give you the action you need for roaming, except using those IEEE standard such as 802.11r

Lastly mesh is not about centralized, and centralized management does not means just copy the same config to all device. Centralized management help you to control a brunch of equipment in groups, which can be groups of difference device, different config. For example you work in a ISP with 10000+network switch all over the city, how you allow some user have higher priority in some specific area? You just can't setup them one by one, and you can't have all the switch have the same setup. Back to the wifi mesh, it always need to have individual tx pwr for each AP, for example a wifi mesh system in a hospital need to lower the tx pwr of those AP near some kind of medical equipment, most of time we do it by put the AP far away from them but you can't do this all time. There are software to calculate how should the AP placed and how much tx power they need.

Sorry for long post (and bad English), but no potato.
 
I usually go a step further and disable the usual suspects, the embedded devices seem to be much happier with them turned off:

yghozFf.png


I have done this.

Also:

I still have an issue with wireless scheduling working intermittently.
I have configured wireless to turn off each night.
Sometimes it does, sometimes not!

Any ideas anyone?
 
Posting in this thread so it gets seen by Asus:
RT-AC86u main router 10007 firmware
RT-AC1900p 20287 firmware as AiMesh node

Playing a game on my Android 7 tablet in my den, about halfway between main and node. Sitting in one place.

Tablet keeps switching back and forth between main and node. Getting kicked out of game or losing connection to game.

Confirms using WiFi Manager that when I lose connectivity, it's the tablet switching between nodes. Or. The nodes switching the tablet.

Signal level to both points is about -38-42 dbm.

Is there some way to stick to one wireless connection? It seems like AiMesh should keep you on one node unless the signal drops below a certain amount or the difference between signal is a big difference.

Is there a setting I can use to cause this not to happen so often or at all?

Btw the tablet I am using is 2.4Ghz only. I have Smart Connect enabled. Is it possible that a combination of Smart Connect and AiMesh causes this to happen? I disabled AiMesh and left Smart Connect enabled and the issue went away.
 
Last edited:
Posting in this thread so it gets seen by Asus:
RT-AC86u main router 10007 firmware
RT-AC1900p 20287 firmware as AiMesh node

Playing a game on my Android 7 tablet in my den, about halfway between main and node. Sitting in one place.

Tablet keeps switching back and forth between main and node. Getting kicked out of game or losing connection to game.

Confirms using WiFi Manager that when I lose connectivity, it's the tablet switching between nodes. Or. The nodes switching the tablet.

Signal level to both points is about -38-42 dbm.

Is there some way to stick to one wireless connection? It seems like AiMesh should keep you on one node unless the signal drops below a certain amount or the difference between signal is a big difference.

Is there a setting I can use to cause this not to happen so often or at all?

Btw the tablet I am using is 2.4Ghz only. I have Smart Connect enabled. Is it possible that a combination of Smart Connect and AiMesh causes this to happen? I disabled AiMesh and left Smart Connect enabled and the issue went away.
Option 1: disabled roaming assistant
Option 2: adjust threshold from -50 to others.

我從使用 Tapatalk 的 ASUS_Z012DA 發送
 
I have an RT-AC68U and RT-AC68W setup with Aimesh using ethernet backhaul and the connection shows correctly from the main router (the RT-AC68W).

Couple questions:
  • A wifi scanner shows both devices using the same channel (161) - Can I configure them to (and don't I want them to) use different channels?
  • The Device List for the device listed as the node appears to update very slowly (like minutes after a client connects). Is this normal?
  • Is there a way to completely disable the 2.4GHz radios?
  • Whats the best way to verify that as I walk from the front of the house to the back that the handoff between them is actually happening?
Thanks in advance!
Follow the log file on the router.
 
I have done this.

Also:

I still have an issue with wireless scheduling working intermittently.
I have configured wireless to turn off each night.
Sometimes it does, sometimes not!

Any ideas anyone?

May i known the issue happen in Main Router or Node ?
 
Bug or Feature Request:

There seems to be a limit of ~1000 characters for the nvram variable custom_clientlist. If you have a lot of devices it's easy to go over this number.

Just wondering if anyone else has run into this? It seems like if you're near the limit, you can't save any icon / name changes, either via ssh or the UI.


RT-AC86U on 3.0.0.4.384_10007-g8e859e9 (router)

RT-AC68U on 3.0.0.4.384_20287-g51c2770 (node)
 
Was on 384_20287 and i am back to 382.18XXx ( ac68u)
I will flash it again and retry .

Edit: I am now back to .20287 on my Ac68,but this time i erased Nvram, not just a factory reset before fresh config. Brb with news
Edit : Issue with mediabridge mode seem fixed. Probably something from 10007 was still in
 
@arthurlien I’m running 20287 now. I changed my 5GHz channel from 44 to 48 and what I posted below was in my log.

What I highlighted in bold, I didn’t see when changing channels with 10007 or maybe it was there and I didn’t notice the message? Normally when changing a channel, I see the message below minus what’s in bold.

My setup hasn’t changed. I was making the change on my laptop, which is connected via router Ethernet port 1. Everything else in home is wireless. No AiMesh.

Wireless is working fine after changing channel. Do you know what this message means?

Thanks.

Jan 30 19:47:00 lldpd[292]: unable to send packet on real device for eth1: Network is down
Jan 30 19:47:00 lldpd[292]: unable to send packet on real device for eth2: No such device or address


Code:
Jan 30 19:46:59 rc_service: cfg_server 26946:notify_rc restart_wireless
Jan 30 19:47:00 lldpd[292]: unable to send packet on real device for eth1: Network is down
Jan 30 19:47:00 lldpd[292]: unable to send packet on real device for eth2: No such device or address
Jan 30 19:47:02 kernel: wl_module_init: passivemode set to 0x0
Jan 30 19:47:02 kernel: wl_module_init: igs set to 0x0
Jan 30 19:47:02 kernel: wl_module_init: txworkq set to 0x0
Jan 30 19:47:02 kernel: eth1: Broadcom BCM4360 802.11 Wireless Controller 6.37.14.126 (r561982)
Jan 30 19:47:02 kernel: eth2: Broadcom BCM4360 802.11 Wireless Controller 6.37.14.126 (r561982)
 
Last edited:
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top