2 x AsusRT-AC68U in AiMesh becomes unavaliable regurarely

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Tobbis

New Around Here
I've got 2 x RT-AC68U, one as router, and the other one as an AiMesh node, with wireless/5Ghz backbone. ~8m , clear sight, between the two units. RSSI usually hoovers around -53 dBm between them. The two other units that hass been used when I'm getting my issue is a phone and a chromecast, both should be fairly close with very good connection to the AiMesh node, however I'm not sure which router they where connected to when the issue appeared (they should be able to reach both). Apart from these units there is probably around 10 other units on the Wifi (various phones, TV:s, computer e.t.c.)

My issue is, that sometimes when I watch something on the Chromecast, it suddenly stoppes. I then check my phone and see that I'm connected to Wifi, but I do not have any internet connection. After ~10 seconds the wifi drops completely and I cant find the SSID when I rescan. After another ~30sec I can find the SSID again, and after an additional ~30sec I can get internet access on the wifi. To me it feels like something is rebooting on either the main router, or the mesh node. I am not sure if the units where connected to the router or the mesh node, but eitherway I should reach both units when scanning SSID, so feels like both are down.

Romaing assist is turned on with a threshold at -63 (I had the same issue at -70). Airtime fairness and Beamforming is enabled. I've reseted both routers more than once and set up everything from scratch. Both running latest firmware.

Below is an extract from the syslog, which i guess is from the main router. The issue appeared around 21:07 (+- 1min).

Oct 10 20:07:06 roamast: eth1: remove client [Another, not mine, Phone MAC] from monitor list
Oct 10 20:07:08 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind [Another, not mine, Phone MAC], status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Oct 10 21:06:32 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth [Chromecast MAC], status: Successful (0)
Oct 10 21:06:32 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc[ Chromecast MAC], status: Successful (0)
Oct 10 21:06:49 roamast: determine candidate node [AiMesh node MAC](rssi: -39dbm) for client [Chromecast MAC](rssi: -68dbm) to roam
Oct 10 21:06:49 roamast: Roam a client [Chromecast MAC], status [0]
Oct 10 21:07:09 roamast: determine candidate node [AiMesh node MAC](rssi: -39dbm) for client [Chromecast MAC](rssi: -68dbm) to roam
Oct 10 21:07:09 roamast: Roam a client [Chromecast MAC], status [0]
Oct 10 21:07:30 kernel: SHN Release Version: 2.0.1 890c91d
Oct 10 21:07:30 kernel: UDB Core Version: 0.2.18
Oct 10 21:07:31 kernel: sizeof forward pkt param = 192
Oct 10 21:07:31 BWDPI: fun bitmap = 3
Oct 10 21:07:45 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Oct 10 21:17:49 roamast: determine candidate node [AiMesh node MAC](rssi: -40dbm) for client [Chromecast MAC](rssi: -70dbm) to roam
Oct 10 21:17:49 roamast: Roam a client [Chromecast MAC], status [0]
Oct 10 21:33:04 roamast: determine candidate node [AiMesh node MAC](rssi: -40dbm) for client [Chromecast MAC](rssi: -69dbm) to roam
Oct 10 21:33:04 roamast: Roam a client [Chromecast MAC], status [0]
Oct 10 21:49:59 roamast: determine candidate node [AiMesh node MAC](rssi: -40dbm) for client [Chromecast MAC](rssi: -70dbm) to roam
Oct 10 21:49:59 roamast: Roam a client [Chromecast MAC], status [0]
Oct 10 21:51:04 roamast: determine candidate node [AiMesh node MAC](rssi: -40dbm) for client [Chromecast MAC](rssi: -67dbm) to roam

So, a couple of questions:
  1. If I understand the log correct, the Chromecast has rssi of -39 to the Mesh Node, but current RSSI is -68, shouldn't this roam to the mesh node? Does not seem like it does...
  2. Why does the Kernel print the SHN and UDB version, is this an indication of that something rebooted?
  3. Can anbody spot something in the log that might help me troubleshoot the downtime I am experiensing (happens a couple of times each week).
  4. Can I get the syslog from the Mesh node as well?
 
Last edited:

OzarkEdge

Part of the Furniture
I've got 2 x RT-AC68U, one as router, and the other one as an AiMesh node, with wireless/5Ghz backbone. ~8m , clear sight, between the two units. RSSI usually hoovers around -53 dBm between them. The two other units that hass been used when I'm getting my issue is a phone and a chromecast, both should be fairly close with very good connection to the AiMesh node, however I'm not sure which router they where connected to when the issue appeared (they should be able to reach both). Apart from these units there is probably around 10 other units on the Wifi (various phones, TV:s, computer e.t.c.)

My issue is, that sometimes when I watch something on the Chromecast, it suddenly stoppes. I then check my phone and see that I'm connected to Wifi, but I do not have any internet connection. After ~10 seconds the wifi drops completely and I cant find the SSID when I rescan. After another ~30sec I can find the SSID again, and after an additional ~30sec I can get internet access on the wifi. To me it feels like something is rebooting on either the main router, or the mesh node. I am not sure if the units where connected to the router or the mesh node, but eitherway I should reach both units when scanning SSID, so feels like both are down.

Romaing assist is turned on with a threshold at -63 (I had the same issue at -70). Airtime fairness and Beamforming is enabled. I've reseted both routers more than once and set up everything from scratch. Both running latest firmware.

Below is an extract from the syslog, which i guess is from the main router. The issue appeared around 21:07 (+- 1min).

Oct 10 20:07:06 roamast: eth1: remove client [Another, not mine, Phone MAC] from monitor list
Oct 10 20:07:08 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind [Another, not mine, Phone MAC], status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Oct 10 21:06:32 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth [Chromecast MAC], status: Successful (0)
Oct 10 21:06:32 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc[ Chromecast MAC], status: Successful (0)
Oct 10 21:06:49 roamast: determine candidate node [AiMesh node MAC](rssi: -39dbm) for client [Chromecast MAC](rssi: -68dbm) to roam
Oct 10 21:06:49 roamast: Roam a client [Chromecast MAC], status [0]
Oct 10 21:07:09 roamast: determine candidate node [AiMesh node MAC](rssi: -39dbm) for client [Chromecast MAC](rssi: -68dbm) to roam
Oct 10 21:07:09 roamast: Roam a client [Chromecast MAC], status [0]
Oct 10 21:07:30 kernel: SHN Release Version: 2.0.1 890c91d
Oct 10 21:07:30 kernel: UDB Core Version: 0.2.18
Oct 10 21:07:31 kernel: sizeof forward pkt param = 192
Oct 10 21:07:31 BWDPI: fun bitmap = 3
Oct 10 21:07:45 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Oct 10 21:17:49 roamast: determine candidate node [AiMesh node MAC](rssi: -40dbm) for client [Chromecast MAC](rssi: -70dbm) to roam
Oct 10 21:17:49 roamast: Roam a client [Chromecast MAC], status [0]
Oct 10 21:33:04 roamast: determine candidate node [AiMesh node MAC](rssi: -40dbm) for client [Chromecast MAC](rssi: -69dbm) to roam
Oct 10 21:33:04 roamast: Roam a client [Chromecast MAC], status [0]
Oct 10 21:49:59 roamast: determine candidate node [AiMesh node MAC](rssi: -40dbm) for client [Chromecast MAC](rssi: -70dbm) to roam
Oct 10 21:49:59 roamast: Roam a client [Chromecast MAC], status [0]
Oct 10 21:51:04 roamast: determine candidate node [AiMesh node MAC](rssi: -40dbm) for client [Chromecast MAC](rssi: -67dbm) to roam

So, a couple of questions:
  1. If I understand the log correct, the Chromecast has rssi of -39 to the Mesh Node, but current RSSI is -68, shouldn't this roam to the mesh node? Does not seem like it does...
  2. Why does the Kernel print the SHN and UDB version, is this an indication of that something rebooted?
  3. Can anbody spot something in the log that might help me troubleshoot the downtime I am experiensing (happens a couple of times each week).
  4. Can I get the syslog from the Mesh node as well?
Roaming seems to occur at the noted time... when it shouldn't(?). Not sure what the kernel entries are about. 24 feet apart is not very far so the signal overlap may be significant.

I would disable Airtime Fairness and Universal Beamforming.

The less negative the RSSI, the stronger the signal and the less need to roam. I would go back to the defaults for Roaming Assistant... and spread the routers some, if possible. The Chromecast at -39 should stay put... that's a good signal... if it gets to -70 at a farther distance, it should try to roam to a closer node/stronger signal.

Can you observe the Wifi signals with an analyzer app to be sure they are stable and roughly what power they are at the Chromecast devices?

OE
 

Tobbis

New Around Here
Roaming seems to occur at the noted time... when it shouldn't(?). Not sure what the kernel entries are about. 24 feet apart is not very far so the signal overlap may be significant.

I would disable Airtime Fairness and Universal Beamforming.

The less negative the RSSI, the stronger the signal and the less need to roam. I would go back to the defaults for Roaming Assistant... and spread the routers some, if possible. The Chromecast at -39 should stay put... that's a good signal... if it gets to -70 at a farther distance, it should try to roam to a closer node/stronger signal.

Can you observe the Wifi signals with an analyzer app to be sure they are stable and roughly what power they are at the Chromecast devices?

OE
The way I interpreted "roamast: determine candidate node [AiMesh node MAC](rssi: -39dbm) for client [Chromecast MAC](rssi: -68dbm) to roam " was that the Chromecast is connected to the main router, at -68dbm, but the mesh node is a candidate since it can connect with -39dbm. And since -68 is below the threshold, it shold roam to the mesh node, but it does not since this log entry keeps repeating. Is this a wrong interpretion?

The reason I changed the raoming threshold to -63 (instead of -70) is that some mobile devices (such as phones) would stay on a too weak signal. After changing the threshold to -63 this works much better. And I do not see how a low roaming threshold should affect "stationary" devices since they should stay put on the "best" node. I can not realy spread the routers more, they are somewhat positioned in a "T" with the main router at the bottom, mesh node in the crossing, and Chromecast at the far left. So moving the mesh-node to the left will get too much big walls between it and the main router leading to very unstable connection. This also means that there should not bee too much overlap.

I've checked with an analyzer app, and the position of the Chromecast has very good and stable power to the mesh node (-60dbm and less negative).

I will disable Airtime Fairness and Universal Beamforming and see if that helps.

Honestly I do not think this is a bad signal/overlaping/interference-issue. The Wifi completely dies, for multiple units that have 5-10m free sight to the mesh node, and then magically comes back alive again (and no wireless phone/microwave e.t.c. was used in between if that should matter).
 

OzarkEdge

Part of the Furniture
The way I interpreted "roamast: determine candidate node [AiMesh node MAC](rssi: -39dbm) for client [Chromecast MAC](rssi: -68dbm) to roam " was that the Chromecast is connected to the main router, at -68dbm, but the mesh node is a candidate since it can connect with -39dbm. And since -68 is below the threshold, it shold roam to the mesh node, but it does not since this log entry keeps repeating. Is this a wrong interpretion?

The reason I changed the raoming threshold to -63 (instead of -70) is that some mobile devices (such as phones) would stay on a too weak signal. After changing the threshold to -63 this works much better. And I do not see how a low roaming threshold should affect "stationary" devices since they should stay put on the "best" node. I can not realy spread the routers more, they are somewhat positioned in a "T" with the main router at the bottom, mesh node in the crossing, and Chromecast at the far left. So moving the mesh-node to the left will get too much big walls between it and the main router leading to very unstable connection. This also means that there should not bee too much overlap.

I've checked with an analyzer app, and the position of the Chromecast has very good and stable power to the mesh node (-60dbm and less negative).

I will disable Airtime Fairness and Universal Beamforming and see if that helps.

Honestly I do not think this is a bad signal/overlaping/interference-issue. The Wifi completely dies, for multiple units that have 5-10m free sight to the mesh node, and then magically comes back alive again (and no wireless phone/microwave e.t.c. was used in between if that should matter).
What you say makes sense.

Observe the WiFi signals in the app over time to see if they drop unexpectedly.

Are you using fixed channels (not Auto) and different SSIDs for each band?

OE
 

Tobbis

New Around Here
What you say makes sense.

Observe the WiFi signals in the app over time to see if they drop unexpectedly.

Are you using fixed channels (not Auto) and different SSIDs for each band?

OE
Different SSIDs for each band, however I am not sure about the channel, I might have forgotten to change to fixed after the last reset. Will check that next time together with observing the WiFi signal over time in the app. However this is at my parents place to it might be a week or two before I can check that.

Anyways, thanks for the help so far, I appreciate it. Any ideas are welcome :)
 

NealJohnsonUK

New Around Here
Interesting problem. I'm afraid I can't offer a solution, but as a fresh pair of eyes I would say something is up with your RT-AC68U that is unrelated to your mobiles or Chromecast. Especially if the WiFi signal suddenly drops for multiple, or all devices.

I am having a more basic problem with my Chromecast device. I have an aimesh with a RT-AC88U as the router adn 2 x RT-AC68U nodes. The Chromecast device only connects to the AC88U Router which has RSSI -83 dBM to -78 dBM which is weak and it periodically pauses adn buffers! There is an RT-68U node which is closer and the Amazon FireStick on the same TV connects to the RT68U mesh node at -43 dBm. I know they are different devices, but the difference in signal strength is so vast between the two devices I have to believe the Chromecast would be better off connecting to the RT68U. Is there any way I can force or manipulate this? All devices have the latest firmware and I have left the roaming threshold at the factory default (disconnect clients less than -55 dBm) - mainly because this setting works with the 30+ devices all over the house and I am reluctant to play with this for the sake of 1 device! It just seems a shame that the Chromecast won't connect to the node with the obviously better signal. I have Smartconnect on, and use only 1 SSID. The Chromecast always connects over 5G. Any suggestions??
 

Sign Up For SNBForums Daily Digest

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