Things I learned about my RT-BE88U AiMesh routers

[vlanvlan]

Currently I run a setup with a RT-AX86U and RT-AX88U router in AP mode, with a hacked together VLAN setup as described here. I had some stability issues, mainly with the RT-AX86U, so when I saw the RT-BE88U's with their native VLAN support I figured lets upgrade to two of the same devices, then things should be running smoother, right? RIGHT? Yea, nah, nothing of that.

In my quest of getting things to work the way I intended to, I am learning quite a bit on the inner workings of these devices. I figured lets make a thread and dump some information in there, maybe it'll come handy to other users. If anyone has additional information, corrections, or clarifications, please post them and I'll update the main thread.

My goal is simple: Run the two RT-BE88U's in AP mode with AiMesh, with an upstream firewall providing the layer 3 connectivity. The uplink to the firewall is a trunk (dot1q) connection with no configuration on the untagged (native) VLAN. In my previous setup I managed to connect the two nodes to the firewall and have my trunk and AiMesh work on the same link connecting the individual device to my firewall. On my new setup I've not yet managed to get it to work. Currently I am running it as such: Firewall -> dot1q trunk -> AP1 -> AiMesh link via 10G LAN -> AP2.

[General things to know about the device]

• You cannot assign a VLAN to the default SSID's in the GUI (I'll post the scripts for this later)
• The 10G interfaces (RJ45+SFP) are one and the same interface, cannot be used both

[Unknowns]
Some things I've ran in to that I haven't figured out yet what they are used for.

• eth9 exist but unsure which interface this refers to
• On the 2.4Ghz radio a default subinterface wl0.4 exists allocated to the br0 bridge (brctl show), haven't figured out yet what this sub interface does. On the AiMesh node this interface is called wl0.5.
• The nvram shows 3 default configured VLANs with subnets that I have no idea about why they exist: 501>192.168.101.1/24, 502>192.168.102.1/24, 503>192.168.103.1/24

[Miscellaneous]

• In order to be able to run scripts on the AP you need to set 'nvram set jffs2_scripts=1'. According to the Wiki This needs to be set on AiMesh nodes, however it also needs to be set on AP mode when it is not yet part of AiMesh.
• Removing VLANs from the standard GUI secretly does not really remove them. You can still find your removed VLANs in the nvram, also after a reboot: nvram show all | grep -i vlan
• Removing VLANs does not always remove the created sub interfaces and those interfaces will magically get stuck inside a bridge of another VLAN
• In certain conditions STP (Spanning-tree protocol) does not work (or never works?), causing a broadcast storm when wired as a ring topology
• Each VLAN will get radio sub interfaces assigned, regardless of using them or not (option in the GUI to not assign an SSID and radios to them)
• Bizarrely when creating a MLO network it put one radio in one VLAN, and the other radio in another VLAN

[AiMesh]

• Although you can select that a node should be an AiMesh node during the initial setup of the device, don't bother doing this, as it'll just cause it not to be detected on the main node. Just make sure the device has had a config reset and you should be good to go
• DHCP needs to be available in the untagged network during AiMesh setup time, it won't accept having a static IP set and then be added to an AiMesh setup
• Ethernet backhaul mode needs to be enabled, otherwise the newly joined wired AiMesh node won't connect to the main node.
• Running in AiMesh mode, sometimes when adding a new SSID+VLAN assigned to the SSID, it won't start broadcasting the SSID on the AiMesh node until it is rebooted
• When rebooting the main node, a reboot is also required on the AiMesh node, otherwise it stops passing traffic, even after the main node has come back online
• MLO appears not to be working on the AiMesh node. It's configured, the bridge is there, but it's simply not broadcasting the SSID from that node

[Interfaces]
Physical interface layout:

• eth0 -> 10G wan/lan (RJ45+SFP)
• eth1 -> LAN1
• eth2 -> LAN2
• eth3 -> LAN3
• eth4 -> LAN4
• eth5 -> LAN5
• eth6 -> LAN6
• eth7 -> LAN7
• eth8 -> LAN8
• eth9 -> ???

Wireless interface layout:

• wl0 -> 2.4Ghz radio (default part of br0, removing it from br0 doesn't seem to be having any effect on anything)
• wl1 -> 5Ghz radio (default part of br0, removing it from br0 doesn't seem to be having any effect on anything
• wl0.0 -> This sub interface is created after adding the first custom vlan/SSID and is added to br0, not sure why, possibly IOT network, not tested
• wl0.1.0 -> This sub interface is created on the AiMesh node after adding the first custom vlan/SSID and is added to br0, not sure why, possibly IOT network, not tested
• wl1.0 -> This sub interface is created after adding the first custom vlan/SSID and is added to br0, not sure why, possibly IOT network, not tested
• wl1.1.0 -> This sub interface is created on the AiMesh node after adding the first custom vlan/SSID and is added to br0, not sure why, possibly IOT network, not tested
• wl0.1 -> Default (main) SSID 2.4Ghz
• wl0.2 -> Default (main) SSID 2.4Ghz on AiMesh node
• wl1.1 -> Default (main) SSID 5Ghz
• wl1.2 -> Default (main) SSID 5Ghz on AiMesh node
• wl0.4 -> This default exists, no idea why.
• wl0.5 -> This default exists on AiMesh node, no idea why.

There is this weird thing going on that I don't really understand yet. When creating VLANs it is generating mac addresses for the bridge interfaces. Weirdly on some bridges it has generated the exact same mac address, and on the AiMesh node side it uses some of the same mac addresses, but not always on the same bridge. Not sure if its relevant to anything either, although it does seem like weird behavior. See the following list of current addresses and bridges:

Bridge             Main AP                          AiMesh node
br0             8000.60cf8401e930             8000.60cf8401e370
br2             8000.8c8742f70000             8000.8c1715f70000
br3             8000.8c8742f70000             8000.8c1715f70000
br4             8000.7acf8401e932             8000.9acf8401e374
br5             8000.7acf8401e933             8000.8c1715f70000

[VLANs]

• When adding a VLAN a corresponding bridge interface is created (brctl show). The br interface will have the same ID as the VLAN ID. If a VLAN ID is changed, the bridge ID will also update. For example if you tag a vlan with ID 2, your br (bridge) interface will be named 'br2', if you assign a new ID to the VLAN, for example 6, the bridge ID will be renamed to 'br6'.
• The above is also true for the sub interfaces created. Things will however go super wonky when creating VLAN4 because of the unknown wl0.4 sub interface that exists by default. If you create VLAN 4, the sub interface for the 2.4Ghz radio will become wl0.5, and this will get confusing if you keep numbering upwards. If you can help it, avoid using VLAN 4 all together.

To be continued...

 

[vlanvlan]

A note: The above are experiences running the current 3006.102.3 firmware release.

 

[Tech9]

What about 2x routers in AP Mode to your upstream firewall without AiMesh between them?

 

[vlanvlan]

What about 2x routers in AP Mode to your upstream firewall without AiMesh between them?

This is possible, but I want roaming to work. I have an odd situation where I live in an apartment that should really be sufficient to have one router in it, however there is one massive thick wall screwing up my signal requiring me to set up two APs. They are however too close to each other to manually deal with tuning values to having my devices jump from one AP to the other correctly.

 

[Tech9]

but I want roaming to work

It will work the same way. Roaming is client decision. Play with the home routers and see what you can achieve with the current firmware, but perhaps 2x SMB APs with full VLAN support are the better and easier way to go in your specific situation.

 

[vlanvlan]

It will work the same way. Roaming is client decision. Play with the home routers and see what you can achieve with the current firmware, but perhaps 2x SMB APs with full VLAN support are the better and easier way to go in your specific situation.

Not sure what I am missing, but I cannot get my devices to jump to the strongest signal if i don't run them in AiMesh mode. I've looked at SMB APs but I cannot find anything that satisfies me, mainly due to the antenna setups of the devices, or simply because it's from a vendor I don't want to use.

Regardless, I'll get this to work the way I want too, just requires some fiddling. The lessons of which I'm dumping in this thread in case it contains any info someone else can use when messing with their setups.

 

[Tech9]

You have to reduce Tx power significantly. Asus routers on default Performance setting blast up to 1000mW per radio. AiMesh doesn't help in roaming except Roaming Assistant tool... in case it works. It's available in AP Mode as well. You know already the term AiMesh is marketing created, nothing AI there and no real mesh with wired devices. The vendor you don't want to use is perhaps the one way ahead of many others with client movement tracking and dynamic AP power adjustment to encourage roaming. Something like this may help a lot in challenging environment.