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.
Hi All, I just set up AiMesh with the following topology: AC86U (main AiMesh router) -> AC3100 (AiMesh node) -> AC68U (AiMesh node connects to AC3100 via Wifi). I can see all connected on AiMesh config. Clients can connect to both AC86U and AC3100, but not to AC68U. When clients connect to AC68U, they indicate "invalid SSID password". Is node-to-node setup supported in AiMesh?
From my understanding, you configure all nodes wirelessly in immediate proximity of the primary router. Once complete, you can move the nodes where appropriate, and the AiMesh network should automatically configure connectivity either to the router or another node using either WiFi or wired backhaul.
 
From my understanding, you configure all nodes wirelessly in immediate proximity of the primary router. Once complete, you can move the nodes where appropriate, and the AiMesh network should automatically configure connectivity either to the router or another node using either WiFi or wired backhaul.

Thanks for the quick rely. Yes, when I first set up the AiMesh, I had all three routers near each other. So, all nodes were connected to the main AiMesh router. I could connect to all nodes with no problem. But after I moved the nodes to current locations, then the 3rd node, which connects to the 2nd node, keeps giving me "invalid password for Wifi" error.
 
My client list stops updating after a day or so on an AC86U. A reboot fixes it, but then it dies again. I would guess that since this problem is one that has happened on other Asus routers I have had... that this is a bug? Anyone else seeing this issue? Funny part is that if I look in the app, it seems to get the latest client list (at least it appears to).
 
Thanks for the quick rely. Yes, when I first set up the AiMesh, I had all three routers near each other. So, all nodes were connected to the main AiMesh router. I could connect to all nodes with no problem. But after I moved the nodes to current locations, then the 3rd node, which connects to the 2nd node, keeps giving me "invalid password for Wifi" error.
If I were you, I would remove the 3rd node from AiMesh, perform a factory reset on it (while powered up fully, hold reset button until power light blinks), and re-add node.
 
I found that my AiMesh system will sometimes generate system dump in the syslog. And after the DUMP occurs, the AiMesh will start to work wield. The system log shows this:


Jan 24 04:08:22 kernel: DUMP CONSOLE:
Jan 24 04:08:22 kernel: DUMP CONSOLE: 042188.938 bcm_pack_xtlv_entry: no space tlv_buf: requested:260, available:236
Jan 24 04:08:22 kernel: DUMP CONSOLE: 042191.810 wl1.0: wlc_send_bar: seq 0x413 tid 0

I have attached the full log file for details.

Some further investigation show that once DUMP occurs, the AiMesh will break down and will not steer STA anymore, I also spot that the 5G eth2 devices cannot be accessed when I tried to use wlcscan. Rebooting the AiMesh AP can solved the problem and make it work again.
 

Attachments

  • syslog.log.txt
    108.4 KB · Views: 408
Last edited:
Just spot a strange problem when using 2 RT-AC88U for AiMesh, having running for a few days, I have spot a few problems:
1. It seems the AiMesh system did not propose the best connection in the mesh (I have tried RT-AC68U Router + RT-AC88U m=node which will propose better choice), just suspect if Smart Connect works properly with AiMesh? I will try to disable Smart Connect later and see if it can gives better result
2. The AiMesh did not choose an optimize channel in the WiFi jungle, I use some Wifi analyzer and figure out the channel chosen if the the best one, and it seems once the channel is chosen it will never rechoose another one if the environment changes, may I know when and how will the router evaluate the best channel and choose the best one?

I have tried to setup the AiMesh system (2 x RT-AC88U) with Smart Connect disabled. It seems the roaming and steering works properly again, it seems the SmartConnect and AiMesh is not quite compatible to each other. Can anybody from ASUS comments on this?
 
I have tried to setup the AiMesh system (2 x RT-AC88U) with Smart Connect disabled. It seems the roaming and steering works properly again, it seems the SmartConnect and AiMesh is not quite compatible to each other. Can anybody from ASUS comments on this?

If you want to disable "Roaming", please turn the Roaming assistant to disabled on "Wireless -> Profession"
 

Attachments

  • ScreenHunter_332 Jan. 24 11.14.jpg
    ScreenHunter_332 Jan. 24 11.14.jpg
    34.5 KB · Views: 447
If you want to disable "Roaming", please turn the Roaming assistant to disabled on "Wireless -> Profession"

I know this option. Not quite sure if roaming assistant still required with AiMesh on? I saw somebody reported roaming assistant will make the connection drops, and AiMesh can steer a STA to choose a strong alternative even without Roaming assistant, is this true?
 
I know this option. Not quite sure if roaming assistant still required with AiMesh on? I saw somebody reported roaming assistant will make the connection drops, and AiMesh can steer a STA to choose a strong alternative even without Roaming assistant, is this true?

I am not sure what happened to make somebody reported that. If you disabled Roaming Assistant, the AiMesh Router/Node will not handle the STA handoff in each Router/Node.
 
I am not sure what happened to make somebody reported that. If you disabled Roaming Assistant, the AiMesh Router/Node will not handle the STA handoff in each Router/Node.

So it seems roaming assistant is part of a must settings for AiMesh to work properly, right?

How about SmartConnect? I observed when SmartConnect is enabled it is a bit wield that the best channel will never be chosen.
 
So it seems roaming assistant is part of a must settings for AiMesh to work properly, right?

How about SmartConnect? I observed when SmartConnect is enabled it is a bit wield that the best channel will never be chosen.

SmartConnect is help STA to steering with different band(2G/5G) in same router/node. We call "Band (2G to 5G, 5G to 2G) Steering"
Roaming is help STA to steering with different router/node. We call "APs (Node to Node) Steering"
Auto Channel Selection : When you setting the Control Channel to Auto in Wireless -> General, the AP will select a working channel by itself.
 
I found that my AiMesh system will sometimes generate system dump in the syslog. And after the DUMP occurs, the AiMesh will start to work wield. The system log shows this:


Jan 24 04:08:22 kernel: DUMP CONSOLE:
Jan 24 04:08:22 kernel: DUMP CONSOLE: 042188.938 bcm_pack_xtlv_entry: no space tlv_buf: requested:260, available:236
Jan 24 04:08:22 kernel: DUMP CONSOLE: 042191.810 wl1.0: wlc_send_bar: seq 0x413 tid 0

I have attached the full log file for details.

Some further investigation show that once DUMP occurs, the AiMesh will break down and will not steer STA anymore, I also spot that the 5G eth2 devices cannot be accessed when I tried to use wlcscan. Rebooting the AiMesh AP can solved the problem and make it work again.

Investigating ...
 
Previously I had two rt-ac68U's both in AP mode, one in the basement and one on the first floor. They were both ethernet connected to the router via a patch panel and switch.
The router was the one provided by the ISP.
I was getting speeds on both Asus routers of around 350Mbps.
I've just installed rt-ac86U in the basement and put the ISP router into modem mode so that the 86U is doing the routing.
I've turned on iamesh and configured one of the 68U's as a node to the 86U, the 68U on the first floor and is connected via ethernet. I've removed the second 68U from the network.
In the basement I'm getting speeds of 350Mbps as before.
But on the first floor the speed is now 100Mbps.
Does this mean that the ethernet is simply a backhaul and the mesh network only utilises radio to radio connections to create the seamless transitions when moving around the house?
i.e. the degradation in the signal on the first floor is because of the weakness of the wireless signal between the router and node? And the strength of the ethernet connection is not broadcast from the node as it is when in AP mode?
I'm assuming there is no way to force a handoff to the node as I believe my devices are maintaining a connection to the 86U even when I'm standing right beside the 68U on the first floor.
And does all this mean that a mesh network is a convenience in terms of managing transitions between router and nodes at the cost of speed when compared to using the 68U's as AP's?
 
Previously I had two rt-ac68U's both in AP mode, one in the basement and one on the first floor. They were both ethernet connected to the router via a patch panel and switch.
The router was the one provided by the ISP.
I was getting speeds on both Asus routers of around 350Mbps.
I've just installed rt-ac86U in the basement and put the ISP router into modem mode so that the 86U is doing the routing.
I've turned on iamesh and configured one of the 68U's as a node to the 86U, the 68U on the first floor and is connected via ethernet. I've removed the second 68U from the network.
In the basement I'm getting speeds of 350Mbps as before.
But on the first floor the speed is now 100Mbps.
Does this mean that the ethernet is simply a backhaul and the mesh network only utilises radio to radio connections to create the seamless transitions when moving around the house?
i.e. the degradation in the signal on the first floor is because of the weakness of the wireless signal between the router and node? And the strength of the ethernet connection is not broadcast from the node as it is when in AP mode?
I'm assuming there is no way to force a handoff to the node as I believe my devices are maintaining a connection to the 86U even when I'm standing right beside the 68U on the first floor.
And does all this mean that a mesh network is a convenience in terms of managing transitions between router and nodes at the cost of speed when compared to using the 68U's as AP's?

Could you send feedback with system log, wifi log, setting file by Feedback function ?
 
On my RT-AC68U the LED button don't work if I am in a intranet, once I connect back to internet the button work again, sometime reboot it will fix the problem.
 
After six days of stable AiMesh (with just a few basic settings) it stopped working.
When I connect to the Web gui, I don't see AiMesh anymore as an option. This is wat I saw happening in my system log (full log attached):

Jan 24 20:04:43 roamast: discover candidate node [B0:6E:BF:3E:92:78](rssi: -68dbm) for weak signal strength client [AC:D1:B8:48:B1:23](rssi: -85dbm)
Jan 24 20:04:43 roamast: eth1: disconnect weak signal strength station [ac:d1:b8:48:b1:23]
Jan 24 20:04:43 roamast: eth1: remove client [ac:d1:b8:48:b1:23] from monitor list
Jan 24 20:05:45 roamast: eth1: add client [00:22:aa:0f:da:42] to monitor list
Jan 24 20:11:30 kernel: DUMP CONSOLE: :fa:3e:61:00:d3 link is already gone !!??
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555398.487 flow_create : bitmap_size=512 maxitems=512
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555398.494 wl0.0: wlc_send_bar: seq 0x1 tid 0
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555406.457 wl0: Proxy STA 5e:fa:3e:61:00:d3 link is already gone !!??
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555410.232 flow_create : bitmap_size=512 maxitems=512
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555410.818 wl0.0: wlc_send_bar: seq 0xade tid 0
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555412.496 flow_create : bitmap_size=512 maxitems=512
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555412.502 wl0.0: wlc_send_bar: seq 0x1 tid 0
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555418.261 wl0: Proxy STA 00:22:aa:0f:da:42 link is already gone !!??
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555422.381 wl0: Proxy STA 5e:fa:3e:61:00:d3 link is already gone !!??
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555428.514 flow_create : bitmap_size=512 maxitems=512
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555428.523 wl0.0: wlc_send_bar: seq 0x1 tid 0
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555428.812 wl0.0: wlc_send_bar: seq 0xb23 tid 0
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555436.488 wl0: Proxy STA 5e:fa:3e:61:00:d3 link is already gone !!??
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555442.531 flow_create : bitmap_size=512 maxitems=512
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555442.537 wl0.0: wlc_send_bar: seq 0x1 tid 0
Jan 24 20:11:30 kernel: DUMP CONSOLE: 555450.496 wl0: Proxy STA 5e:fa:3e:61:00:d3 link is already gone !!??
Jan 24 20:11:30 kernel: dhdpcie_checkdied: msgtrace address : 0x00000000
Jan 24 20:11:30 kernel: console address : 0x003FFCF0
Jan 24 20:11:30 kernel: Assrt not built in dongle
Jan 24 20:11:30 kernel: TRAP type 0x4 @ epc 0x2657a8, cpsr 0x80000193, spsr 0x80000033, sp 0x2ac7c4, lp 0x24f789, rpc 0x2657a8
Jan 24 20:11:30 kernel: Trap offset 0x2ac76c, r0 0x3e4678, r1 0x95030104, r2 0x88c7, r3 0x33b048, r4 0xd1f01c10, r5 0x886c, r6 0x3b9828, r7 0x2ac880
Jan 24 20:11:32 rc_service: restart_wireles 8721:notify_rc stop_amas_wlcconnect
Jan 24 20:11:32 rc_service: restart_wireles 8721:notify_rc stop_amas_bhctrl
Jan 24 20:11:32 rc_service: waitting "stop_amas_wlcconnect" via restart_wireles ...
Jan 24 20:12:00 miniupnpd[348]: upnp_event_process_notify: connect(192.168.1.212:2869): Connection timed out
Jan 24 20:12:07 miniupnpd[348]: upnp_event_process_notify: connect(192.168.1.212:2869): Connection timed out
Jan 24 20:12:45 kernel: Register interface [wds1.1] MAC: 1c:b7:2c:76:37:d4
Jan 24 20:12:56 kernel: Register interface [wds1.1] MAC: 1c:b7:2c:76:37:d4
Jan 24 20:13:01 lldpd[408]: unable to send packet on real device for eth1: No buffer space available
Jan 24 20:13:02 lldpd[408]: unable to send packet on real device for wds0.3: No buffer space available
Jan 24 20:13:11 lldpd[408]: unable to send packet on real device for eth1: No buffer space available
Jan 24 20:13:12 lldpd[408]: unable to send packet on real device for wds0.3: No buffer space available
 

Attachments

  • syslog (1).txt
    329 KB · Views: 430
Status
Not open for further replies.

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