Asus XT-8 Internal Routing / Roaming Issue

[Pezzy]

Hi all,

Having a bizarre issue with my 2 Asus XT-8 devices.

My Setup:

- Firmware version:3.0.0.4.386_49873
- Wireless backhaul (5ghz-2)
- Operation mode: Wireless router
- Smart Connect: on
- Other relevant details: DHCP and DNS provided by another device on my LAN.

Description of issue: when a client device (e.g. mobile phone) roams from the secondary AiMesh node to the primary AiMesh node, it takes 2-3mins for it to be able to see any devices connected via the secondary node. This includes being unable to ping their IP. For the whole duration (before roam, immediately after roam), the roaming device is able to connect to the internet, and is able to connect to devices connected to the primary node without any noticeable interruption. The problem only applies for connectivity back to devices connected to the secondary node (wired and wireless). After 2-3mins, those devices can be pinged / connected to again.

Also, bizarrely, roaming in the "other" direction doesn't cause the same problem, only when roaming from secondary to primary. The closest thing I've found where someone else is having a similar issue is here: Asus ROGhttps://rog.asus.com › showthreadThread: Firmware bug? No route to wireless device after roaming away ...

Does anyone have any ideas what might be causing this (or what the solution might be)? Is anyone having similar issues? Unfortunately I can't test wired backhaul, but if anyone who uses wireless backhaul could confirm whether this happens for them too, that might be a start!

Thanks in advance.

 

[tgl]

Description of issue: when a client device (e.g. mobile phone) roams from the secondary AiMesh node to the primary AiMesh node, it takes 2-3mins for it to be able to see any devices connected via the secondary node. This includes being unable to ping their IP.

Yeah, I was having that same issue with a pair of XT8s a year ago. (My notes suggest that it happened after roaming in either direction not just one way, but I'm not 100% sure about that anymore.) I was running mine in AP mode, so router vs. AP mode isn't the trigger, and the bug considerably pre-dates F/W 49873 too -- it was present at least since 42095. I didn't ever find a solution, except to give up on the XT8s as my house network. Before I was driven to the point of buying some other APs, I worked around it for awhile by binding the roaming device to just one of the XT8s -- depending on your physical layout, maybe that's a possibility for you?

I will not be buying any more ASUS wireless gear -- a year of reading these forums has provided sufficient proof that ASUS' software team are utterly incompetent.

 

[Pezzy]

Yeah, I was having that same issue with a pair of XT8s a year ago. (My notes suggest that it happened after roaming in either direction not just one way, but I'm not 100% sure about that anymore.) I was running mine in AP mode, so router vs. AP mode isn't the trigger, and the bug considerably pre-dates F/W 49873 too -- it was present at least since 42095. I didn't ever find a solution, except to give up on the XT8s as my house network. Before I was driven to the point of buying some other APs, I worked around it for awhile by binding the roaming device to just one of the XT8s -- depending on your physical layout, maybe that's a possibility for you?

I will not be buying any more ASUS wireless gear -- a year of reading these forums has provided sufficient proof that ASUS' software team are utterly incompetent.

Thanks for the response - good to know it's not just me, but a bit worrying if this has been going unaddressed for a while. Did you / anyone report the bug?

 

[tgl]

Did you / anyone report the bug?

I have not. By all reports, interacting with ASUS customer support will accomplish exactly nothing beyond raising one's blood pressure.

 

[drinkingbird]

Hi all,

Having a bizarre issue with my 2 Asus XT-8 devices.

My Setup:

- Firmware version:3.0.0.4.386_49873
- Wireless backhaul (5ghz-2)
- Operation mode: Wireless router
- Smart Connect: on
- Other relevant details: DHCP and DNS provided by another device on my LAN.

Description of issue: when a client device (e.g. mobile phone) roams from the secondary AiMesh node to the primary AiMesh node, it takes 2-3mins for it to be able to see any devices connected via the secondary node. This includes being unable to ping their IP. For the whole duration (before roam, immediately after roam), the roaming device is able to connect to the internet, and is able to connect to devices connected to the primary node without any noticeable interruption. The problem only applies for connectivity back to devices connected to the secondary node (wired and wireless). After 2-3mins, those devices can be pinged / connected to again.

Also, bizarrely, roaming in the "other" direction doesn't cause the same problem, only when roaming from secondary to primary. The closest thing I've found where someone else is having a similar issue is here: Asus ROGhttps://rog.asus.com › showthreadThread: Firmware bug? No route to wireless device after roaming away ...

Does anyone have any ideas what might be causing this (or what the solution might be)? Is anyone having similar issues? Unfortunately I can't test wired backhaul, but if anyone who uses wireless backhaul could confirm whether this happens for them too, that might be a start!

Thanks in advance.

My guess is the mac address table is not properly updating, the node is sending replies out the local wireless instead of the backhaul, until the entry expires, at which point it learns it from the backhaul. Not sure if these routers have any way of viewing/clearing the L2 tables or not, that would be the only way to confirm. Maybe since the primary node is in router mode the ARP packet causes the MAC table to update, all just guesswork though.

 

[tgl]

My guess is the mac address table is not properly updating, the node is sending replies out the local wireless instead of the backhaul, until the entry expires, at which point it learns it from the backhaul.

Yeah, that was the impression I had as well. The primary node seems to manage to clear cached ARP data for devices connected to it, but the satellite node not so much, so you have to wait for the ARP cache entries to time-out. If I were responsible for actually debugging this, I might try watching wireshark data to see what addresses appeared in ping and ping-response packets on the LAN behind the satellite. But I'm not, and even if I knew exactly what was wrong I doubt I could push the information through ASUS customer support to their developers.

 

[drinkingbird]

Yeah, that was the impression I had as well. The primary node seems to manage to clear cached ARP data for devices connected to it, but the satellite node not so much, so you have to wait for the ARP cache entries to time-out. If I were responsible for actually debugging this, I might try watching wireshark data to see what addresses appeared in ping and ping-response packets on the LAN behind the satellite. But I'm not, and even if I knew exactly what was wrong I doubt I could push the information through ASUS customer support to their developers.

In theory the node (assuming it is an AP/L2 device) should not know any ARP at all for a client just passing through it (that isn't accessing its management interface etc) which is why I'd figure it is probably at L2/MAC Table. On the main device, that will be aware of ARPs and perhaps the process of the ARP broadcast somehow triggers the main node/router to update the MAC table too. Who knows. Not really a fan of mesh systems, but if the node isn't removing a MAC table entry when the client disconnects from it, it probably wouldn't work right even if it was just a standalone AP.

There were flavors of seamless roaming where APs would have the same MAC address and even ones where they would sort of tunnel traffic through one AP back to the other spoofing MACs and stuff. They were pretty problematic. I don't think Asus is doing any of that though.

 

[Smokey613]

Have you tried updating to the latest firmware?

 

[Pezzy]

Have you tried updating to the latest firmware?

I haven't (yet). The latest one looks reasonably stable so I may give that a try - wanted to see whether others also experienced this issue first. Perhaps someone already on the latest firmware could confirm?

The scenario is easy enough to reproduce:

- using mobile device connected to secondary node, ping / connect to stationary device connected to secondary node.
- move mobile device so that it connects to primary node, then immediately try again to ping / connect to the same stationary device which is connected to secondary node.

 

[martinjh]

Thanks for this post and the problem description!
I have the exact same issue with a ZenWiFi XT9 as primary and two ZenWiFi AX devices as secondary nodes. Ping fails when moving around with my mobile phone if the target device is connected to one of the secondary nodes. There are no issues if the device is connected to the primary. Wired or wireless makes no difference. I can reproduce this as well, even with the latest firmware. I tried various different settings and setups but with no success.

Did anybody ever find solution to this problem? (Apart from throwing away the ZenWiFi routers.)