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

[Richard Li]

@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

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)

I have submitted this before and after some observation, this may due to wireless reconfiguration which makes the packets failed to send when the wireless device are down during reconfiguration.

 

[Richard Li]

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!

Hope that helps.

This is only one of the strategy applied in the mesh, I have study a lot about Mesh system and seems most of them are not standardized yet. Although there are IEEE standards out there, many devices including phones, pads, routers, etc. are not conform to the standard yet. So even though the routers implemented these standards, it is not guaranteed to work properly.

 

[scjr]

I have submitted this before and after some observation, this may due to wireless reconfiguration which makes the packets failed to send when the wireless device are down during reconfiguration.

Thank you for your reply, Richard.

I didn’t see that entry before 10007, so I thought it may be a bug. The channel change takes place fine and everything works as it should.

Appreciate your explanation. Thanks again!

 

[mogulman]

Option 1: disabled roaming assistant
Option 2: adjust threshold from -50 to others.

我從使用 Tapatalk 的 ASUS_Z012DA 發送

Ok. Changed roaming threshold on 2.4ghz from -55 to -65. This seems to have fixed it. I didn't think that would work because my device seemed to have a strong signal.

 

[Treadler]

May i known the issue happen in Main Router or Node ?

Router only. I am not using Aimesh, just the single router.

(Many thanks for your attention Arthur).

 

[Neil62]

I have just noticed that ASUS have now officially released AIMESH firmware for RT-AC5300

https://www.asus.com/AiMesh/

 

[Sendil K Krishna]

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!

Hope that helps.

how do you enable more logging?

I see mostly "add client" logs:-
sendilk@RT-AC68U:/tmp/home/root# tail -f /tmp/syslog.log
Jan 30 22:24:01 roamast: eth2: add client [f4:f5:d8:a9:39:24] to monitor list
Jan 30 22:39:11 roamast: eth2: add client [cc:08:8d:53:a5:fe] to monitor list
Jan 30 22:51:01 roamast: eth1: add client [d0:73:d5:14:33:ce] to monitor list
Jan 30 23:04:21 roamast: eth2: add client [f4:f5:d8:a9:39:24] to monitor list
Jan 30 23:16:46 roamast: eth1: add client [b0:ea:bc:66:20:35] to monitor list
Jan 30 23:20:36 roamast: eth2: add client [cc:08:8d:53:a5:fe] to monitor list
Jan 30 23:21:16 roamast: eth2: add client [cc:08:8d:19:15:81] to monitor list
Jan 30 23:24:16 roamast: eth2: add client [cc:08:8d:53:a5:fe] to monitor list
Jan 30 23:28:16 roamast: eth2: add client [f4:f5:d8:a9:39:24] to monitor list

 

[arthurlien]

@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

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)

We used lldpd to do some communication between Nodes. these kind of message will not impact anything....

 

[Richard Li]

how do you enable more logging?

I see mostly "add client" logs:-
sendilk@RT-AC68U:/tmp/home/root# tail -f /tmp/syslog.log
Jan 30 22:24:01 roamast: eth2: add client [f4:f5:d8:a9:39:24] to monitor list
Jan 30 22:39:11 roamast: eth2: add client [cc:08:8d:53:a5:fe] to monitor list
Jan 30 22:51:01 roamast: eth1: add client [d0:73:d5:14:33:ce] to monitor list
Jan 30 23:04:21 roamast: eth2: add client [f4:f5:d8:a9:39:24] to monitor list
Jan 30 23:16:46 roamast: eth1: add client [b0:ea:bc:66:20:35] to monitor list
Jan 30 23:20:36 roamast: eth2: add client [cc:08:8d:53:a5:fe] to monitor list
Jan 30 23:21:16 roamast: eth2: add client [cc:08:8d:19:15:81] to monitor list
Jan 30 23:24:16 roamast: eth2: add client [cc:08:8d:53:a5:fe] to monitor list
Jan 30 23:28:16 roamast: eth2: add client [f4:f5:d8:a9:39:24] to monitor list

use command line, set log level to 7, original is 6, and reboot the node/router using reboot:

nvram set log_level=7
nvram commit
reboot

 

[Richard Li]

We used lldpd to do some communication between Nodes. these kind of message will be impacted anything....

You mean will NOT impact anything?

 

[arthurlien]

You mean will NOT impact anything?

Yes... typo...

 

[scjr]

We used lldpd to do some communication between Nodes. these kind of message will not impact anything....

Thank you!

 

[Quad80]

I'm seeing multiple entries for some devices on app , and devices that are connected showing as offline , but working okay.

I've had this since I had my router, not just since AiMesh started. The client list was always buggy, showing things connected that weren't, etc. It has gotten better, but my WiFi camera, which is hardwired, shows twice on the client list (and it's not because one is WiFi and one is LAN; wifi is disabled on the camera and it shows the same IP address twice). Additionally, this same camera should be requesting a static IP based on MAC. Funny thing, it works on both IPs (the assigned, static, and the random assigned that shows twice). Everything works fine, but there's definitely a bug here.

 

[scjr]

We used lldpd to do some communication between Nodes. these kind of message will not impact anything....

@arthurlien I changed channels a couple of times this morning and no lldpd messages in the log this time. Firmware must have recognized I don’t have AiMesh nodes. Pretty neat.

 

[mogulman]

Turning off AIMesh fixed this. I tried the scenario multiple times with AiMesh turned off and didn't have the issue.
Added AiMesh RT-AC1900p back to the RT-AC86U and started happening again. I didn't see anything unusual in the syslog but here is the chain of events. Also, this only seems to be happening when "sleeping PC2" via RDP, rather than the power button. It only seems to happen when AiMesh is on and it seems to make the AiMesh node offline when it happens.

*** Resume from Sleep PC2 by pressing power button
Jan 29 09:41:41 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link UP 1000 mbps full duplex
*** Connected to PC2 from PC1 over RDP.
Jan 29 09:41:49 kernel: net_ratelimit: 6187 callbacks suppressed
Jan 29 09:41:54 kernel: net_ratelimit: 14881 callbacks suppressed
*** Sleep PC2 from PC1 over RDP
Jan 29 09:42:27 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link DOWN.
*** No network access on PC1 (Lan or WAN)
Jan 29 09:42:27 kernel: net_ratelimit: 885 callbacks suppressed
Jan 29 09:42:32 kernel: net_ratelimit: 20287 callbacks suppressed
Jan 29 09:42:37 kernel: net_ratelimit: 11681 callbacks suppressed
Jan 29 09:42:42 kernel: net_ratelimit: 8476 callbacks suppressed
Jan 29 09:42:47 kernel: net_ratelimit: 7898 callbacks suppressed
Jan 29 09:42:52 kernel: net_ratelimit: 6483 callbacks suppressed
Jan 29 09:42:57 kernel: net_ratelimit: 6433 callbacks suppressed
Jan 29 09:43:02 kernel: net_ratelimit: 4979 callbacks suppressed
Jan 29 09:43:07 kernel: net_ratelimit: 5137 callbacks suppressed
*** Resume from Sleep PC2 by pressing Power button
Jan 29 09:43:10 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link UP 1000 mbps full duplex
*** PC1 now has network access
Jan 29 09:43:12 kernel: net_ratelimit: 6162 callbacks suppressed
*** Sleep PC2 using power button
Jan 29 09:43:38 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link DOWN.
*** PC1 continues to have network access.
Jan 29 09:43:38 kernel: net_ratelimit: 499 callbacks suppressed
Jan 29 09:43:43 kernel: net_ratelimit: 14365 callbacks suppressed
Jan 29 09:43:48 kernel: net_ratelimit: 10137 callbacks suppressed

@arthurlien Anything else I can do to help debug this? The feedback option in my router RT-AC86u doesn't seem to work. It tells me that it can't connect and to copy and paste text into an email.

This happened to me today again...

• PC1 already booted up
• PC2 press power button to resume from sleep
• RDP into PC2 into PC1.
• Remembered the issue above, so instead, closed RDP Session and worked on PC2 directly.
• Pressed the power button on PC2 to suspend/sleep.
• PC1's connection to the network stopped.
  
• Powered on PC2 and PC1 started working again.
• Later on, Powered off PC2 and PC1 was fine.

I know this could be related to my computers, but this never happens without AiMesh and never happened when I had just the RT-AC1900p alone. FYI..These are both wired GB Ethernet to the main router.

 

[scope666]

Does anyone know which service is responsible for updating the list of clients in "View List" ? Mine keeps getting stuck, showing old data for the clients and their signal levels. I'd like to find an alternative to rebooting if at all possible.

I've already tried service restart_lltdc and service restart_networkmap (and clicking the "Refresh" button in the UI)



RT-AC86U - 3.0.0.4.384_10007

 

[GrinningShark]

Does anyone know which service is responsible for updating the list of clients in "View List" ? Mine keeps getting stuck, showing old data for the clients and their signal levels. I'd like to find an alternative to rebooting if at all possible.

I've already tried service restart_lltdc and service restart_networkmap (and clicking the "Refresh" button in the UI)

I am having the same problem. This has been an issue for some time.

 

[arthurlien]

I've had this since I had my router, not just since AiMesh started. The client list was always buggy, showing things connected that weren't, etc. It has gotten better, but my WiFi camera, which is hardwired, shows twice on the client list (and it's not because one is WiFi and one is LAN; wifi is disabled on the camera and it shows the same IP address twice). Additionally, this same camera should be requesting a static IP based on MAC. Funny thing, it works on both IPs (the assigned, static, and the random assigned that shows twice). Everything works fine, but there's definitely a bug here.

Could you capture a UI picture ?

我從使用 Tapatalk 的 ASUS_Z012DA 發送

 

[Ronald Schwerer]

Does anyone know which service is responsible for updating the list of clients in "View List" ? Mine keeps getting stuck, showing old data for the clients and their signal levels. I'd like to find an alternative to rebooting if at all possible.

I've already tried service restart_lltdc and service restart_networkmap (and clicking the "Refresh" button in the UI)



RT-AC86U - 3.0.0.4.384_10007

I am having the same problem. This has been an issue for some time.

I suspect there's a problem in your NVRAM. Maybe a corruption or it is full. First backup your settings in the Web gui. Then delete the current list using ssh commands:

nvram set custom_clientlist= ""
nvram commit
reboot​

After the reboot finishes, login to the webgui and check the clientlist. You'll loose all you custom names but at least you should be able to edit them. If you've got a lot of clients on your LAN, try keeping those names short - the nvram space is finite.
I'd seriously consider just biting the bullet and doing a factory reset on the router. There may be other issues you haven't noticed.

 

[GrinningShark]

I suspect there's a problem in your NVRAM. Maybe a corruption or it is full. First backup your settings in the Web gui. Then delete the current list using ssh commands:

nvram set custom_clientlist= ""
nvram commit
reboot​

After the reboot finishes, login to the webgui and check the clientlist. You'll loose all you custom names but at least you should be able to edit them. If you've got a lot of clients on your LAN, try keeping those names short - the nvram space is finite.
I'd seriously consider just biting the bullet and doing a factory reset on the router. There may be other issues you haven't noticed.

I did a full factory reset (pressing the button) after installing the latest firmware on my 86U. Also did that after I had this problem and it still did not help. I did not try reseting the client list, figured a full reset and configure would do that (since my customizations were zapped by the reset). Only thing I have not tried was a reset and not doing anything to the client list. That might be an interesting experiment.