Asus AIMesh Guest network issues

[HHawk]

Oops sorry. Was on my mobile and wanted to answer. Facepalm. But thanks will give it a go tomorrow. Thanks again.

 

[pinkgrae]

Dunno. But I cannot seem to find 386.45987 for AC86U. It only appears to be for the RT-AC68U?
The only current version I can find on the Asus website for my AC86U is: 3.0.0.4.386.45956.

Is that correct?

Router firmware has to be compiled specifically for the hardware, therefore each firmware version is unique to a particular router; over time this results in a large number of firmware versions. Asus's approach to managing this is a bit different to RMerlin's, in that they compile stock firmware for each router sequentially, using their latest coding, and give it a unique number. By contrast, @RMerlin releases a batch of asuswrt-merlin firmwares for all of the routers that he supports simultaneously using the same code base/s and under the same version number (e.g. 386.4), after which it is then up to individual users to download and install the firmware for their particular hardware.

Long story short, stock firmware version 386.45987 (released December 2021) is specific to the AC68U, while 386.45956 (released November 2021) is specific to the AC86U. However, the two firmwares were compiled within weeks of each other and will hopefully use similar Aimesh and guest network implementations. In addition, as @visortgw has separately reported this approach to work on various AX models and @tsanga has reported this working on his AC66U node with a firmware released in May 2021, I like your chances that switching to the latest stock firmware on your AC86U node will also work in your case - unless there is a separate issue unique to your setup or that particular hardware.

Anyway, the only way to find out if it works for you is to try, so let us know how you go!

 

[HHawk]

Thank you all guys! With the main router (RT-AC86U) on MerlinWRT 386.4 and the node (RT-AC86U) running on Asus 3.0.0.4.386_45956-g23134c9 I confirm it now works as it should!
Meaning I can connect to the guest network, without intranet access and still get an IP and use the internet without browsing the intranet!

Thank you all so much! Finally it's safe! ;-) #happy

 

[dbell]

Another data point.

AX86U router and a second AX86U as node, both running merlin 386.4. Directly connected Ethernet backhaul (no switches) on 2.5gbps ports. Guest network 1 @ 2.4ghz with IoT devices connecting just fine on both router and node and getting 101.x IP addresses.

I have experienced the issue of failing to connect to the guest network and get an IP (unless the allow intranet access was enabled) on some prior alpha (386.2 alpha 2) version and concluded the iptables entries had been hosed by one of those earlier firmware builds and was blocking the dhcp flow. There was a fix for broken firewall rules in 386.2 beta 2, so after updating I ended up completely resetting and re-configuring the router and node and guest network with intranet access disabled worked again.

Some comments on the topic here: http://www.snbforums.com/threads/new-ax86u-node-and-iot-devices.71002/post-671422. Notice this also occurred on my AC5300 that I was in the process of replacing with AX86U's so was not device specific but rather firmware.

 

[bukso]

Yes, I can confirm as well that running AiMesh node with Asus stock firmware 3.0.0.4.386_45987 fixed the issue with guest network for me.

Here is my setup:
main router RT-AC86U with Merlin 386.4 + node RT-AC68U with Asus stock firmware 3.0.0.4.386_45987 (ethernet backhaul without switch) + "Sync to AiMesh Node" = All + "Access Intranet" = Disable -> clients connected to guest network on RT-AC68U node get IP address and everything is OK.
However if I change the node firmware to Merlin 386.4, it stops working, guest clients do not get IP address when connecting to node (but they have no issue if they connect directly to main router).

 

[HKcow]

Another data point.

AX86U router and a second AX86U as node, both running merlin 386.4. Directly connected Ethernet backhaul (no switches) on 2.5gbps ports. Guest network 1 @ 2.4ghz with IoT devices connecting just fine on both router and node and getting 101.x IP addresses.

I have experienced the issue of failing to connect to the guest network and get an IP (unless the allow intranet access was enabled) on some prior alpha (386.2 alpha 2) version and concluded the iptables entries had been hosed by one of those earlier firmware builds and was blocking the dhcp flow. There was a fix for broken firewall rules in 386.2 beta 2, so after updating I ended up completely resetting and re-configuring the router and node and guest network with intranet access disabled worked again.

Some comments on the topic here: http://www.snbforums.com/threads/new-ax86u-node-and-iot-devices.71002/post-671422. Notice this also occurred on my AC5300 that I was in the process of replacing with AX86U's so was not device specific but rather firmware.

I am running 2x RT-AX92U and experiencing issues on Guest Network with Intranet Disabled and Sync to Node. Earlier this week I had done a dirty firmware upgrade to version 3.0.0.4.386.46061 (released on 21Jan) and it did not fix the isssue. However after seeing your post it may due to broken firewall rules in earlier firmware versions. I will try to reset everything and hopefully this can fix the guest network issue.

 

[HKcow]

I am running 2x RT-AX92U and experiencing issues on Guest Network with Intranet Disabled and Sync to Node. Earlier this week I had done a dirty firmware upgrade to version 3.0.0.4.386.46061 (released on 21Jan) and it did not fix the isssue. However after seeing your post it may due to broken firewall rules in earlier firmware versions. I will try to reset everything and hopefully this can fix the guest network issue.

Guest Network was working as instended for a while but then it failed again. I am guessing it may because I am using non-standard ip (i.e. instead of 192.168.50.x) for the lan and this will confuse the guest network.

 

[tsanga]

Guest Network was working as instended for a while but then it failed again. I am guessing it may because I am using non-standard ip (i.e. instead of 192.168.50.x) for the lan and this will confuse the guest network.

For the LAN (not guest) I’m not using 192.168.50.x, but I’m using the 10.x.x.x range. And I have no issues with the guest network.

 

[natewin]

Similar situation, several devices on RT-AC88U node would not connect. Flashed to stock ASUS firmware on the node and things seem to be working now. Running latest Merlin on the main RT-AC86U.

Modem: Netgear CM1000
--1gbps ethernet connection--
Main: RT-AC86U, FW: Merlin 386.4
--1gbps Ethernet backhaul--
Node: RT-AC88U, FW: 3.0.0.4.386_46065

 

[HKcow]

From my testing, it seems that once I enabled Ethernet backhual on my RT-AX92U the Guest Network issue will kick-in. Guest cannot connect to node with Intranet Access disabled.

 

[pinkgrae]

From my testing, it seems that once I enabled Ethernet backhual on my RT-AX92U the Guest Network issue will kick-in. Guest cannot connect to node with Intranet Access disabled.

Yep - see post #74 above - the issue seems to arise from the following combination: (1) wired backhaul to node, (2) asuswrt-merlin firmware on node, and (3) intranet access disabled on guest 1. Which means you can (only) achieve working guest 1 via nodes, with intranet access disabled, in one of two ways:

• Wired backhaul: must run stock firmware on node; OR
• Wireless backhaul: can run either asuswrt-merlin or stock firmware on node.

 

[HKcow]

Yep - see post #74 above - the issue seems to arise from the following combination: (1) wired backhaul to node, (2) asuswrt-merlin firmware on node, and (3) intranet access disabled on guest 1. Which means you can (only) achieve working guest 1 via nodes, with intranet access disabled, in one of two ways:

• Wired backhaul: must run stock firmware on node; OR
• Wireless backhaul: can run either asuswrt-merlin or stock firmware on node.

Strange, my node is another RT-AX92U using stock firmware but still having issue. Will it because of the particular model (RT-AX92U) or because I am using Tri-band Smart Connect?

 

[pinkgrae]

Strange, my node is another RT-AX92U using stock firmware but still having issue. Will it because of the particular model (RT-AX92U) or because I am using Tri-band Smart Connect?

That's interesting - can't recall anyone reporting back on that particular model, though a number of other AX models have been reported working. Does guest 1 work for you via the node if you disable smart connect ?

 

[HKcow]

That's interesting - can't recall anyone reporting back on that particular model, though a number of other AX models have been reported working. Does guest 1 work for you via the node if you disable smart connect ?

I can try, because the smart connect maybe a bit different for RT-AX92U as it by default not share the 2nd 5G network for clients connection but reserve it as wireless backhaul. But sometimes enabling and disabling smart connect will break my AiMesh connection and requires reset, I will try it a bit later.

 

[tsanga]

Asus rolled stock FW 386.46065 on RT-AC68U. Interesting change list item:

Fixed AiMesh guest network issues.

Since this is on stock FW which works as the node, I haven’t tested what this is.

 

[pinkgrae]

Asus rolled stock FW 386.46065 on RT-AC68U. Interesting change list item:

Since this is on stock FW which works as the node, I haven’t tested what this is.

Hi @tsanga - I got excited and upgraded my AC68U node from 386.45987 to 386.46065 a few days ago. I haven't noticed any changes in network behaviour at all since then - neither good nor bad. Maybe whatever change has been made only affects the main router?

 

[Just_Karma]

I was having issue with this and still have issues. I am running with a guest network 1 on 2.4G radio and access intranet set to disable.

Running an XT8 as main router with 3.0.0.4.386.46061 and three Aimesh nodes. I have 2 XT4 nodes also running 3.0.0.4.386.46061 and finally an RT-AC86U running 3.0.0.4.386.46061. All nodes are connected via ethernet backhaul and connect via a switch.

I am seeing two different behaviours the RT-AC86U works correctly and device can connect successfully. However on the XD4 nodes they fail. When a guest device tries to connect just goes round in a loop of trying to get an assigned addressed and fails.

I have also ran wireshark on various ports to see what is being passed. I can confirm my other network devices switch etc. do not appear to be causing an issues and passing an relevant VLAN information. I know from RT_1 that Aimesh works by using VLAN 501 for 2.4G and 502 for 5G. Looking at my wireshark trace I can see a lot of spanning tree for bridges STP from my RT-AC86U node and I can see VLAN 501 and 502 on these ethernet frames.

However looking at spanning tree for bridges STP ethernet frames from my XD4 nodes they do not have any VLAN ID/tags on them. Looks like Asus has not correctly implemented the fix for XD4 devices.

Has anyone managed to get guest networks with intranet access disabled working on and a device attached to an XD4 Aimesh node?

Posting to hopefully help some of the people on this thread, I have AIMesh, with Guest Isolation, Wired backhaul, Main router AX58 and 2 nodes AX55 and AC68, everything works.

The likely issue for at least some people with a similar setup is that if your backhaul goes through a switch, you will have the issue of no IP being assigned unless the switch is managed, supports VLANs and is set up correctly.

The Guest Networks, when isolation is turned on, creates VLANs with IDs of 501 for 2.4GHz (the 192.168.101.XXX sub net) and 502 for the 5GHz (192.168.102.XXX sub net). No VLANs are created or needed when isolation is off.

I have my nodes each going through 2 switches (1 Netgear, one TP-Link) but they are both managed and support 802.1Q-based VLAN's and once those were correctly set up the nodes both worked correctly.

 

[Just_Karma]

So I finally have a working configuration this is based on completely 100% ethernet backhaul and using:

• Asus XT8, running 3.0.0.4.386.46061 - Primary Router
• Asus XD4, running 3.0.0.4.386.46061 - Aimesh Node 1 and 2
• Asus RT-AC86U, running 3.0.0.4.386.45956 - Aimesh Node 3

All the Aimesh nodes are networked together with a TP-Link TL-SG1005P 5port gigabit PoE switch. This PoE switch powers all my Aimesh nodes as well via PoE splitters and has a cable connected from port 5 into my Asus XT8 Primary Router.

The above is a good and working configuration for me. Guest network 1 (2.4G and 5G radios) are available at all Aimesh nodes and is set to Access Intranet as Disable. All guest are attaching and functioning as expected. That is devices on this network only have access to the internet and nothing else.

Once you know you have good working Asus hardware and firmware, be very careful how you network the backhaul. If you have any network devices that can/could potentially mess with the VLAN ids of the ethernet frames it will stop the mesh functioning correctly for Guest Network 1 when Access Internet = Disabled is required. I think best to plug Aimesh nodes straight into your Asus Router with no devices in between first to prove your Asus hardware and firmware is a working configuration before adding in additional network hardware.

---

My previous issue was with how VLANs are handled and required by the Asus Router and Asus Aimesh Nodes. Prior to the working configuration above I had my PoE switch with the Aimesh nodes, connected into my Tp-link TL-SG108E 8port gigabit easysmart switch. And this is where my problems were. Whilst the TL-SG108E was helpful with diagnosing the problem, it was also the problem for me.

With this configuration instead of the connecting the PoE switch up to the Asus XT8 router, the Poe switch connected into the TL-SG108E switch. And then the TL-SG108E connected up to the router.

With this configuration I was able to mirror the PoE connecting port on the TL-SG108E onto another port on the TL-SG108E and log/trace with wireshark running on a Raspberry Pi. This would let me look for ethernet frames and check for the VLAN id tags in wireshirk. And whilst I could see some 501, 502 and 503 tags the behaviour was not consistent. Sometimes when a client connected to any of the guest networks with this network configuration it would get stuck in the DHCP handshaking phase. Other times it would work. I found out that if I restarted the TL-SG108E switch or changed the VLAN options of the TL-SG108E and changed it back it would all of a suddenly start passing VLAN traffic again and the Aimesh nodes would allow clients to attach. Then after about 30 minutes the problem would return. For me I have found the TL-SG108E quite unreliable. And therefore my Aimesh nodes no longer go through this. Fortunately the TL-SG108E PoE switch appears reliable and quite stable and is passing ethernet frames and leaving the VLAN ids intact and it all works as it should, FINALLY!

Thank you to all the contributors of this thread. I would not have known where to look or figured out the solution. Thank you all.

 

[HKcow]

So I finally have a working configuration this is based on completely 100% ethernet backhaul and using:

• Asus XT8, running 3.0.0.4.386.46061 - Primary Router
• Asus XD4, running 3.0.0.4.386.46061 - Aimesh Node 1 and 2
• Asus RT-AC86U, running 3.0.0.4.386.45956 - Aimesh Node 3

All the Aimesh nodes are networked together with a TP-Link TL-SG1005P 5port gigabit PoE switch. This PoE switch powers all my Aimesh nodes as well via PoE splitters and has a cable connected from port 5 into my Asus XT8 Primary Router.

The above is a good and working configuration for me. Guest network 1 (2.4G and 5G radios) are available at all Aimesh nodes and is set to Access Intranet as Disable. All guest are attaching and functioning as expected. That is devices on this network only have access to the internet and nothing else.

Once you know you have good working Asus hardware and firmware, be very careful how you network the backhaul. If you have any network devices that can/could potentially mess with the VLAN ids of the ethernet frames it will stop the mesh functioning correctly for Guest Network 1 when Access Internet = Disabled is required. I think best to plug Aimesh nodes straight into your Asus Router with no devices in between first to prove your Asus hardware and firmware is a working configuration before adding in additional network hardware.

---

My previous issue was with how VLANs are handled and required by the Asus Router and Asus Aimesh Nodes. Prior to the working configuration above I had my PoE switch with the Aimesh nodes, connected into my Tp-link TL-SG108E 8port gigabit easysmart switch. And this is where my problems were. Whilst the TL-SG108E was helpful with diagnosing the problem, it was also the problem for me.

With this configuration instead of the connecting the PoE switch up to the Asus XT8 router, the Poe switch connected into the TL-SG108E switch. And then the TL-SG108E connected up to the router.

With this configuration I was able to mirror the PoE connecting port on the TL-SG108E onto another port on the TL-SG108E and log/trace with wireshark running on a Raspberry Pi. This would let me look for ethernet frames and check for the VLAN id tags in wireshirk. And whilst I could see some 501, 502 and 503 tags the behaviour was not consistent. Sometimes when a client connected to any of the guest networks with this network configuration it would get stuck in the DHCP handshaking phase. Other times it would work. I found out that if I restarted the TL-SG108E switch or changed the VLAN options of the TL-SG108E and changed it back it would all of a suddenly start passing VLAN traffic again and the Aimesh nodes would allow clients to attach. Then after about 30 minutes the problem would return. For me I have found the TL-SG108E quite unreliable. And therefore my Aimesh nodes no longer go through this. Fortunately the TL-SG108E PoE switch appears reliable and quite stable and is passing ethernet frames and leaving the VLAN ids intact and it all works as it should, FINALLY!

Thank you to all the contributors of this thread. I would not have known where to look or figured out the solution. Thank you all.

I am connecting two RT-AX92U with a QNAP QSW-M408-4C managed switch. I am not able to isolate if the AiMesh Guest Network issue is related to this. Do you know if there is any option I can play around in the swtich have potential to solve the issue?

To add on this, I am also using link aggregation such that my main RT-AX92U is using 2 1G wire to connect to the switch. This may also complicate the problem since I can see link aggregation is closely related to VLAN tagging. Apologize that I am not a network expertise and not having the SME knowledge.

 

[HKcow]

I am connecting two RT-AX92U with a QNAP QSW-M408-4C managed switch. I am not able to isolate if the AiMesh Guest Network issue is related to this. Do you know if there is any option I can play around in the swtich have potential to solve the issue?

To add on this, I am also using link aggregation such that my main RT-AX92U is using 2 1G wire to connect to the switch. This may also complicate the problem since I can see link aggregation is closely related to VLAN tagging. Apologize that I am not a network expertise and not having the SME knowledge.

Tried to using the same switch, but disabled link aggregation in the switch and my main router. The same AiMesh Guest Network issue still occur. I also tried to tag all the ports in the QNAP swtich into a new VLAN ID (before that all the prots are untagged), this also not solving the guest network issue. Anyhow I still can't get an IP if the device is connecting to Guest Network through the AiMesh Node.