I have discovered a problem with an AiMesh setup, where I can’t reach a wireless device after it has roamed from a wireless AiMesh node back to the main router.
This happens with two RT-AC67U (running latest firmware 184.108.40.206.384_5329) as well as with an RT-AX88U (running latest firmware, 220.127.116.11.384_5329) paired with one of the RT-AC67U routers (or all three together).
To reproduce follow these steps:
- Set up an AiMesh config with any two of those devices where the mesh node is only connected via WLAN (instead of an ethernet cable), with default config using the config wizard on both devices.
- Connect a device via WLAN with the main router.
- Right now, any device connected to either the main router or the mesh node using WLAN or LAN can find a route to that device (ping, traceroute).
- Move the wireless device closer to the mesh node, making the wireless device roam to the mesh node (forced by roaming assist as per default config).
- Again, any device connected to either the main router or the mesh node using WLAN or LAN can find a route to that device (ping, traceroute).
- Move the wireless device closer to the main router, making the wireless device roam back to the main router (forced by roaming assist as per default config).
- Right now, no device can find a route to the wireless device. It doesn’t matter, if the device from which you are trying to find a route to said wireless device is connected to the main router or the mesh node, via WLAN or cable.
- Moving closer to the mesh node connected via WLAN making it roam back to that node, it is reachable again immediately, and so on.
After a few minutes the device can be reached again. It looks, like some entry is getting some sort of timeout.
I’ve already checked routing tables, arp tables, and the mac table of the bridges br0 on both routers (brctl showmacs). Editing that entries or timeout values didn’t seem to have any effects.
I didn’t have time to investigate further, so I don’t know where the route breaks. Maybe the arp requests get stuck or the arp responses get dropped somewhere.
All this only applies to mesh nodes which are connected vie WLAN to the main router. As soon as the backhaul is done by ethernet, everything works fine. Maybe it’s the wireless interface of one of the bridges (br0), which isn’t accepting packets that have the wrong originating mac and need to be fooled with mac spoofing via ebtables, or something like that.
I have discovered this issue when I was trying to use an Apple HomeKit compatible wifi smart plug with my Asus AiMesh. I had one smart plug connected to the main router and a second smart plug connected to the WLAN connected mesh node. When I was moving with the iPhone near the wireless mesh node, I could only reach the smart plug connected to that router, moving near the main router I could only control the other smart plug, which was connected to the main router.
This issue might very well be related to the general issue of dropping mesh nodes, as well.
When I set the three mentioned routers up as a mesh with two of them being connected via LAN cable and one via WLAN, the node with the WLAN connection was dropped sporadically and was listed as “offline”. It did never recover from that status until the affected node got rebooted.
I would appreciate if you could offer a solution to this issue.
Thanks a lot in advance.