Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

udotirol

New Around Here
I own 3 XT8/RT-AX95Q and after very mixed experiences with stock firmware, I decided to give the latest "official" RC8 version a try.

Unfortunately, things seem to have gotten from bad to worse for me. One of the major issues I have with those devices is that the third node randomly goes dark from time to time. The web UI shows it as disconnected and if you check on the device itself, the LED constantly flashes blue. What would help then is to turn of the node, press and hold the WPS button, turn it on and wait until the LED turns off and finally restart it again.

The distance between each nodes is about 3 meters and when the connection succeeds, the connection quality is usually marked as "great" in the UI.

Now after upgrading to the beta, the nodes initially saw each other and everything worked nicely, but after explicitly choosing a node as a "preferrable backhaul" in the node management section of the UI, my third node keeps on flashing blue forever. From time to time the UI lists the node as connected and I see the LED being white briefly, only to disconnect after a couple of seconds and start blinking blue again.

To rule out a hardware defect, I have even replaced my original nodes with new ones, but all to no avail.

Anyone else seeing problems like those with more than two XT8 nodes?

If it matters, my main node is in AP mode and I am using WPA2-Enterprise.
 

OzarkEdge

Part of the Furniture
I own 3 XT8/RT-AX95Q and after very mixed experiences with stock firmware, I decided to give the latest "official" RC8 version a try.

Unfortunately, things seem to have gotten from bad to worse for me. One of the major issues I have with those devices is that the third node randomly goes dark from time to time. The web UI shows it as disconnected and if you check on the device itself, the LED constantly flashes blue. What would help then is to turn of the node, press and hold the WPS button, turn it on and wait until the LED turns off and finally restart it again.

The distance between each nodes is about 3 meters and when the connection succeeds, the connection quality is usually marked as "great" in the UI.

Now after upgrading to the beta, the nodes initially saw each other and everything worked nicely, but after explicitly choosing a node as a "preferrable backhaul" in the node management section of the UI, my third node keeps on flashing blue forever. From time to time the UI lists the node as connected and I see the LED being white briefly, only to disconnect after a couple of seconds and start blinking blue again.

To rule out a hardware defect, I have even replaced my original nodes with new ones, but all to no avail.

Anyone else seeing problems like those with more than two XT8 nodes?

If it matters, my main node is in AP mode and I am using WPA2-Enterprise.
Really, 3 nodes/APs in 9 square meters?

OE
 

udotirol

New Around Here
Really, 3 nodes/APs in 9 square meters?

OE
It wasn't 3 meters from the beginning, don't you worry. I started the same way I had configured my old mesh system (AC1200): one node on every level of my house, but that didn't work out well with the XT8s:

From time to time where the node in the 2nd floor would not connect to the one on the 1st floor but instead to the one in the basement, leading to "bad" connection quality.

At least in the beta version, I can now force a node to be used as a backhaul, so that was one of the reasons why I was hopeful.
 

OzarkEdge

Part of the Furniture
It wasn't 3 meters from the beginning, don't you worry. I started the same way I had configured my old mesh system (AC1200): one node on every level of my house, but that didn't work out well with the XT8s:

From time to time where the node in the 2nd floor would not connect to the one on the 1st floor but instead to the one in the basement, leading to "bad" connection quality.

At least in the beta version, I can now force a node to be used as a backhaul, so that was one of the reasons why I was hopeful.
I'm not worried. Just wondering why noting that the nodes are not currently deployed at practical distances is relevant information.

If the system works normally in Router Mode and/or with WPA2-Personal, you might conclude that there is a firmware issue with AP Mode and/or WPA2-Enterprise.

Did you try the new System Optimization control to see if the backhauls settle logically on their own without having to force their topology?

OE
 

udotirol

New Around Here
I'm not worried. Just wondering why noting that the nodes are not currently deployed at practical distances is relevant information.

If the system works normally in Router Mode and/or with WPA2-Personal, you might conclude that there is a firmware issue with AP Mode and/or WPA2-Enterprise.

Did you try the new System Optimization control to see if the backhauls settle logically on their own without having to force their topology?

OE
yes, sorry, of course the distance is relevant - appreciate your help!

When I initially got the devices, I had them configured in the default way, that is router mode plus WPA2 personal, but that honestly didn't make much of a difference with regards to overall stability.

What I noticed however, and that's a bug both in the stock and the beta firmware, is that you cannot add nodes when you are in WPA2-Enterprise mode, because adding nodes apparently relies on WPS, which again is incompatible with WPA2-Enterprise.

And yes, I couldn't resist trying the "Optimization" button, unfortunately that led to both nodes only reporting a "weak" a 2.4GHz connection to the master node ... seems those devices and I wont become best friends :(
 
Last edited:

OzarkEdge

Part of the Furniture
yes, sorry, of course the distance is relevant - appreciate your help!

When I initially got the devices, I had them configured in the default way, that is router mode plus WPA2 personal, but that honestly didn't make much of a difference with regards to overall stability.

What I noticed however, and that's a bug both in the stock and the beta firmware, is that you cannot add nodes when you are in WPA2-Enterprise mode, because adding nodes apparently relies on WPS, which again is incompatible with WPA2-Enterprise.
By stability, I assume you mean the WiFi and/or wireless backhaul.

Have you surveyed WiFi in your area and set fixed, least congested, non-DFS channels to minimize interference (and auto channel disruption)?

WPA2-Personal ought to be sufficient if your needs are similar to the typical home user. I'd stick with that.

If you are using AP mode, is your non-AiMesh router broadcasting WiFi?

OE
 

udotirol

New Around Here
By stability, I assume you mean the WiFi and/or wireless backhaul.

Have you surveyed WiFi in your area and set fixed, least congested, non-DFS channels to minimize interference (and auto channel disruption)?

WPA2-Personal ought to be sufficient if your needs are similar to the typical home user. I'd stick with that.

If you are using AP mode, is your non-AiMesh router broadcasting WiFi?

OE
What has been happening ever since I got the devices in August is that the most remote node on the 2nd floor would lose connection from time to time, even before I had them setup for WPA2-Enterprise. Sometimes the connection speed would also drop from "great" to "ok" to "weak". I tried all sorts of workaround, like configuring time triggered reboots, but all not no avail.

Most of the time I could add the node the way I described it in my post above, other times I had to completely reset all three nodes in order to "see" each other again. It has really been a bumpy ride so far ... If there hadn't been weeks where everything worked flawlessly and if the devices wouldn't deliver excellent speed and coverage, I would long have given up.

Frequency congestion is no issue here, I'm living in quite a rural area and in order to find the ideal spots for the nodes (as well as my pervious ones) I have used a Wifi analyzer.

Unfortunately, WPA2-Personal is no option.

My main node's upstream is ethernet, no other WiFi nearby.
 

TimoBlurt

New Around Here
Yesterday I gave the latest RC2 beta firmware a try (9.0.0.4_386_40947), I was happy with more options to fiddle with in the web gui.
However the node went from Great to Weak wireless backhaul with the main router. It was solved by simply reverting back to the latest official stable firmware 3.0.0.4.386_25790
 

VANT

Very Senior Member
RC-8 for RT-AC86U. After some days AIProtection stop raporting and emailing when was blocking suspicious websites. I tried maually test with wicar.org, and sites was blocked but no affect to statistic and no email notofications.
 

Morpheus2020

New Around Here
AX86U.
QOS off or Adaptive QOS ON.
From 3.0.0.4.384.9318 to the latest beta firmware, besides 9.0.0.4_386_41034-ge2d15cc(Alpha?) , Bandwith monitor doesn't work. The bandwidth value is very low, which is obviously wrong.

Traditional QoS or Bandwidth Limiter.
Bandwith monitor works.

By the way, in 3.0.0.4.384.9298, Bandwith monitor works when any QOS ON or QOS OFF. But in this firmware, many entries like "kernel: invalid dirty_p detected: ffffffc000000000 valid=[ffffffc03ccbbb40 ffffffc03ccbbc80]" appear in the syslog, when there are data transmission and reception in 5G WiFi, if I switch Adaptive QOS ON or just in the bandwidth monitor interface. The upload speed of 5G WiFi is very low, if I switch Adaptive QOS or Aiprotection ON. These issues are resolved in 9.0.0.4_386_41034-ge2d15cc. But value in Bandwith monitor is wrong in 9.0.0.4_386_41034-ge2d15cc.

In addition, does Adaptive QOS or Aiprotection in AX86U really have any effect? In my test, they have no effect.

It can be said that Adaptive QOS, Aiprotection and Bandwith monitor never works perfectly in ANY Downloadable Firmware of AX86U. But these functions can be found in “https://www.asus.com/us/Networking/RT-AX86U/specifications/” and the website where I bought it. AX86U has been on sale for more than half a year, but these bugs are still not completely fixed.
As a consumer, I feel very sad.
 

Morpheus2020

New Around Here
In 9.0.0.4_386_41034-ge2d15cc, these entries often appear in the syslog.

Nov 28 19:44:58 kernel: CONSOLE: 168712.922 wl1: wlc_recv: dropping a frame with invalid src mac addressc5:a5:c7:7a:01:82
Nov 28 19:44:58 kernel: CONSOLE: 168712.922 Unexpected RX reason 22 {if=wl1 fc=0040 seq=f9e0 A1=ff:ff:ff:ff:ff:ff A2=c5:a5:c7:7a:01:82}
Nov 28 19:44:58 kernel: CONSOLE: 168712.942 wl1: wlc_recv: dropping a frame with invalid src mac addressc5:a5:c7:7a:01:82
Nov 28 19:44:58 kernel: CONSOLE: 168712.942 Unexpected RX reason 22 {if=wl1 fc=0040 seq=f9f0 A1=ff:ff:ff:ff:ff:ff A2=c5:a5:c7:7a:01:82}
Nov 28 19:45:02 kernel: CONSOLE: 168717.762 wl1: wlc_recv: dropping a frame with invalid src mac address2f:77:ea:75:5e:c8
Nov 28 19:45:02 kernel: CONSOLE: 168717.762 Unexpected RX reason 22 {if=wl1 fc=0040 seq=0590 A1=ff:ff:ff:ff:ff:ff A2=2f:77:ea:75:5e:c8}
Nov 28 19:45:03 kernel: CONSOLE: 168717.781 wl1: wlc_recv: dropping a frame with invalid src mac address2f:77:ea:75:5e:c8
Nov 28 19:45:03 kernel: CONSOLE: 168717.781 Unexpected RX reason 22 {if=wl1 fc=0040 seq=05a0 A1=ff:ff:ff:ff:ff:ff A2=2f:77:ea:75:5e:c8}

These mac addresses do not belong to my device.

I don’t know if this information is useful. I don’t know if these entries in the syslog are normal.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top