Release ASUS RT-AX86U Pro Firmware version 3.0.0.6_102_34312 - 2024/05/09

[bbunge]

Are there any options for Guest Network Pro propagation to nodes or they work on the main router only in your Pro + non-Pro AiMesh?

I answered that before. Yes, you can choose which nodes get the Guest WIFI propagation and with multiple guest WIFI which of those go to which node. This is something I wanted when mesh first came out and I was managing the network in a not for profit. I had separate routers set up for main network, volunteer guest with captive portal and another for the guys who refurbished PC's. All with AP's scattered around the warehouse.

So far I do not believe VLAN can be set on node Ethernet ports. Just WIFI.

 

[OzarkEdge]

Are there any options for Guest Network Pro propagation to nodes or they work on the main router only in your Pro + non-Pro AiMesh?

I added a wired AX86U non-Pro node... the 5.0 signal takes awhile to appear. My GNP custom guest WLANs were not enabled by default for the new node. When enabled (for both bands or none), the 2.4 appeared as hoped... OE and OE Guest broadcasting across all 3 nodes. However, the 5.0 guest WLAN never appeared on the non-Pro node.

The LAN\VLAN tab only lists my two Pro nodes as posted earlier... the non-Pro node is not included... as I would expect.

I'd say go all-Pro 3.0.0.6 nodes to use the new VLANs as a 'system'.

OE

 

[Tech9]

However, the 5.0 Guest WLAN never appeared on the non-Pro node.

What I expected to happen. Thank you for testing it.

It has to be documented at some point with all the Asuswrt 4.0 and Asuswrt 5.0 mix of hardware options all claiming AiMesh compatibility.

 

[semigator]

I tried to upgrade to this new version on my RT-AX86U Pro and ran into an issue that I needed the previous guest network config to solve. I ended up downgrading until I can try again. I am running AiMesh with Ethernet backhaul to multiple nodes. I have some older IoT devices that will constantly disconnect WiFi and attempt to reconnect, including Honeywell thermostats. To solve this issue, many years ago on an older Asus model (probably RT-AC86U), I created a Guest Wifi Network that ran only on the main router and then pointed these troublesome IoT devices at that SSID. This method still works great up to 3.0.0.4.388_24199. When I tried the new Guest Network UI to create an SSID running only on the main router, I was getting constant disconnects and reconnect attempts with 4-way handshake error messages in the logs. I realize these are older devices, but I don't get what may have changed and how to resolve it. Any ideas are appreciated. Thanks.

 

[bbunge]

I tried to upgrade to this new version on my RT-AX86U Pro and ran into an issue that I needed the previous guest network config to solve. I ended up downgrading until I can try again. I am running AiMesh with Ethernet backhaul to multiple nodes. I have some older IoT devices that will constantly disconnect WiFi and attempt to reconnect, including Honeywell thermostats. To solve this issue, many years ago on an older Asus model (probably RT-AC86U), I created a Guest Wifi Network that ran only on the main router and then pointed these troublesome IoT devices at that SSID. This method still works great up to 3.0.0.4.388_24199. When I tried the new Guest Network UI to create an SSID running only on the main router, I was getting constant disconnects and reconnect attempts with 4-way handshake error messages in the logs. I realize these are older devices, but I don't get what may have changed and how to resolve it. Any ideas are appreciated. Thanks.

Best to do a factory reset and manual configuration. Set up your guest WIFI then add the nodes back in. You can elect to have the guest on the main router only or selected nodes. However, dual band guest WIFI may not work with older nodes. Still trying to sort out what works and what doesn't. I will not be able to test configuration for a couple of days as the wife is getting a new knee.

 

[bbunge]

Did a quick test today with the AX86U as an AiMesh node. Upgraded its firmware. Added the existing Guest-IoT to the AX86U (the Guest-IoT had both 2.5 and 5 GHz enabled and working on the router). The 2.4 GHz Guest-IoT made it to the node but the 5 GHz did not. I do not plan to use AiMesh as the router itself is working well. Did not try to do just a 5 GHz guest.

 

[OzarkEdge]

Same result here... again.

OE

 

[semigator]

Best to do a factory reset and manual configuration. Set up your guest WIFI then add the nodes back in. You can elect to have the guest on the main router only or selected nodes. However, dual band guest WIFI may not work with older nodes. Still trying to sort out what works and what doesn't. I will not be able to test configuration for a couple of days as the wife is getting a new knee.

So my Thermostat issue goes back many years. My goal is to update my main RT-AX86U Pro router and have a guest network run only on the main router (not the nodes), then have IoT devices connect to that SSID. With the new Guest Network Pro VLAN feature, if WPA2 shared key is causing the 4 way handshake issue, what are the thoughts on this idea: Enable an IoT SSID VLAN with less secure WPA for the old IoT devices to use, Disable Intranet access, and only let them IoT devices talk to the Internet?

 

[OzarkEdge]

I notice that my first VLAN 52 is listed as idx1 in the WLog when the client is connected to the main router. And likewise, my next VLAN 53 is listed as idx2. Clients connected to the node are not listed in the WLog. How many VLANs and idxs are permitted(?)

OE

 

[maxbraketorque]

When I was testing one of the 3.0.0.6 betas for the GT-AX6000 about a year ago, I found that changing the VLAN numerical ID from the suggested default caused the VLAN to not work. Has anyone experimented using their own preferred numerical ID?

 

[OzarkEdge]

Disable Intranet access, and only let them IoT devices talk to the Internet?

This is my default plan... no intranet access for untrusted clients. It remains to be seen how many of my future IoT clients, if any, will cooperate. Given they like to hairpin through their cloud servers these days when using their app locally, this approach may be sufficient.

OE

 

[OzarkEdge]

I use the 2.5G ports for a MoCA2.5 backhaul (the MoCA adapters have 2.5G ports). I posted above what LAN\VLAN looks like with no GNP profiles (normal default look). I now have GNP profiles and want to use one/Guest to secure the garage node LAN ports (less secure location)... and I notice the LAN\VLAN 2.5G ports are now a bit different... the node port is not configurable and has a note below it:

Router:

Node:

So, one side/port of the otherwise symetrical MoCA segment is treated differently here. I can configure the router 2.5G port; I can't change the node 2.5G port. Feel free to interpret this for us.

Is there a VLAN trick for completely disabling a physical port (given the settings available to us)?

OE

 

[bbunge]

I use the 2.5G ports for a MoCA2.5 backhaul (the MoCA adapters have 2.5G ports). I posted above what LAN\VLAN looks like with no GNP profiles (normal default look). I now have GNP profiles and want to use one/Guest to secure the garage node LAN ports (less secure location)... and I notice the LAN\VLAN 2.5G ports are now a bit different... the node port is not configurable and has a note below it:

Router:
View attachment 58766
Node:
View attachment 58767

So, one side/port of the otherwise symetrical MoCA segment is treated differently here. I can configure the router 2.5G port; I can't change the node 2.5G port. Feel free to interpret this for us.

Is there a VLAN trick for completely disabling a physical port (given the settings available to us)?

OE

By my uneducated view of Asus VLAN, it looks like you will need to:
1. Set up a guest network - custom maybe. Note the VLAN ID and SSID.
2. Under router LAN/VLAN Profile you should see the VLAN ID and SSID
3. For router Port 5 (2.5 Gbps) set Mode to Access and SDN to your SSID
If you do not want the Guest WIFI broadcasting at the router I believe you can turn it off.
Now you should be able to assign each LAN port, except 2.5 Gbps, on the node to the VLAN you created.

This is just a guess and I'll take credit if it works and deny blame if it doesn't. Just wish I had another pro router to try it!

 

[OzarkEdge]

I use the 2.5G ports for a MoCA2.5 backhaul (the MoCA adapters have 2.5G ports). I posted above what LAN\VLAN looks like with no GNP profiles (normal default look). I now have GNP profiles and want to use one/Guest to secure the garage node LAN ports (less secure location)... and I notice the LAN\VLAN 2.5G ports are now a bit different... the node port is not configurable and has a note below it:

Router:
View attachment 58766
Node:
View attachment 58767

So, one side/port of the otherwise symetrical MoCA segment is treated differently here. I can configure the router 2.5G port; I can't change the node 2.5G port. Feel free to interpret this for us.

Is there a VLAN trick for completely disabling a physical port (given the settings available to us)?

OE

I tried a half-hearted test (not enough rebooting and follow-up debugging... busy with other chores)... set node LAN1,2,3,4 ports to Access and my GNP guest WLAN profile. Affects:

o I could no longer browse to the OBi202 ATA connected to node LAN1 and the ATA could not register SIP with the ITSP.

o AiMesh tab reported the node offline. I did not touch the 2.5G backhaul ports (LAN5 on the node).

And the weird item I have not seen before... I have all LEDs OFF normally... the 5.0 LED came on steady on both nodes... I toggled the node LED ON/OFF to turn them all ON and then all OFF.

OE

 

[bbunge]

Well, 6 days 12 hours uptime since factory reset and manual configure. Very pleased with the new firmware version as it does what I want it to do. Guest-IoT set up with dual band WIFI and one LAN port on VLAN segregates "un-trusted-clients" on a separate network. Heck, I was given a couple of Wemo Smart Switches that I am finding use for. After watching the WIFI channels used for a couple of days I've locked 2.4 to Channel 6 at 20 MHz and the 5 GHz to channel 40 at 80 MHz. Works well! Wireguard, OpenVPN and Instantguard work well. The Network Map is still buggy but why am I not surprised!
Ho Hum - now to wait for the next upgrade...

 

[wisecoffee]

Hi there, just came here as I'm thinking of buying a RT-AX86U model. Is there already a workaround for the native IPv6 bug? Will a custom firewall rule help? Running the older firmware isn't an option at my place as I need VLAN support and for me the only options seems to be the new release, but it seems there are problems with IPv6. I want to replace my Fritzbox 4060 as I want to try out something new. Thanks for your replies in advance.

 

[OzarkEdge]

Hi there, just came here as I'm thinking of buying a RT-AX86U model. Is there already a workaround for the native IPv6 bug? Will a custom firewall rule help? Running the older firmware isn't an option at my place as I need VLAN support and for me the only options seems to be the new release, but it seems there are problems with IPv6. I want to replace my Fritzbox 4060 as I want to try out something new. Thanks for your replies in advance.

Presumably you mean the RT-AX86U Pro and this initial release of its new 3.0.0.6 ASUSWRT firmware, the subject of this thread. I would not replace your existing network with this yet. For instance, IPv6 is broken. At most, you might want to spend to learn more about making it your new network, and give ASUS time to fix such initial issues.

OE

 

[RMerlin]

There's no reliable way to fix it. Any iptables rule you added manually would disappear the moment the firewall is restarted (for instance on a WAN state change, or whenever changing various configuration settings). You have to use a previous version that works, or keep IPv6 disabled.

 

[wisecoffee]

Thanks for your quick reply. Sadly I can't do without IPv6 and VLANs are required as well. Hope, ASUS will fix it soon. Seems that I'll keep my Fritzbox a bit longer.

 

[L&LD]

Do not buy an RT-AX86U today. It has been indicated that that model will not be getting the 3.0.0.6.xxx level firmware ever.