Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

[bitsbytes]

is anyone having problems on 5Ghz on the nodes? i can connect to it but there's no internet access.

edit: and now it's completely down.

 

[JagoUK]

I checked my ac68u, there is no `DFS status` at all.

SSID: "X"
RSSI: 0 dBm    SNR: 0 dB    noise: -79 dBm    Channel: 2
BSSID: X    Capability: ESS ShortSlot RRM
Supported Rates: [ 1(b) 2(b) 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ]
VHT Capable:
    Chanspec: 2.4GHz channel 2 20MHz (0x1002)
    Primary channel: 2
    HT Capabilities:
    Supported HT MCS : 0-23
    VHT Capabilities:
    Supported VHT (tx) Rates:
        NSS: 1 MCS: 0-9
        NSS: 2 MCS: 0-9
        NSS: 3 MCS: 0-9
    Supported VHT (rx) Rates:
        NSS: 1 MCS: 0-9
        NSS: 2 MCS: 0-9
        NSS: 3 MCS: 0-9

Interference Level: Acceptable
Mode    : AP Only

Stations List                         
----------------------------------------
idx MAC               Associated Authorized    RSSI PHY PSM SGI STBC Tx rate Rx rate Connect Time
    X Yes        Yes         -52dBm n   No  Yes Yes    72.2M   72.2M 26:29:29
    X Yes        Yes         -69dBm n   No  Yes Yes    58.5M     13M 343:22:42

SSID: "X"
RSSI: 0 dBm    SNR: 0 dB    noise: -92 dBm    Channel: 100/80
BSSID: X    Capability: ESS RRM
Supported Rates: [ 6(b) 9 12(b) 18 24(b) 36 48 54 ]
VHT Capable:
    Chanspec: 5GHz channel 106 80MHz (0xe06a)
    Primary channel: 100
    HT Capabilities:
    Supported HT MCS : 0-23
    VHT Capabilities:
    Supported VHT (tx) Rates:
        NSS: 1 MCS: 0-9
        NSS: 2 MCS: 0-9
        NSS: 3 MCS: 0-9
    Supported VHT (rx) Rates:
        NSS: 1 MCS: 0-9
        NSS: 2 MCS: 0-9
        NSS: 3 MCS: 0-9

Interference Level: Acceptable
Mode    : AP Only

Stations List                         
----------------------------------------
idx MAC               Associated Authorized    RSSI PHY PSM SGI STBC Tx rate Rx rate Connect Time
    X Yes        Yes         -46dBm ac  Yes Yes No    866.7M    390M 01:58:22
    X Yes        Yes         -51dBm ac  Yes Yes No    866.7M     24M 07:59:26

A Radar detect will look like this in your system log. But it doesn't always list it which I think is a bug.

Aug 4 04:30:53 wlceventd: wlceventd_proc_event(632): eth6: Radar detected

 

[KrispiL]

I have the same problem as on the last RC (39485), on the primary network using the 5Ghz for the backhaul, I have intermittent packet loss, there are still errors in the log like this:
Sep 11 17:23:50 kernel: ^[[0;33;41m[ERROR vlan] vlanIoctl ,652: Failed to delete VLAN device wds0.0.1.501^[[0m
Sep 11 17:23:50 kernel: ^[[0;33;41m[ERROR vlan] vlanIoctl ,652: Failed to delete VLAN device wds0.0.1.0^[[0m
Sep 11 17:23:50 kernel: ^[[0;33;41m[ERROR vlan] vlanIoctl ,652: Failed to delete VLAN device wds0.0.1.502^[[0m
Sep 11 17:23:50 kernel: ^[[0;33;41m[ERROR vlan] vlanIoctl ,652: Failed to delete VLAN device wds0.0.1.0^[[0m

Thats with a RT-AX88U on 40024 and an AiMesh RT-AC68U node on 40024 connected to the primary network over 5Ghz with a 2.4Ghz and 5Ghz network with intranet isolation enabled. The guest network works fine it's just the primary network which suffers from connectivity issues. I think there's some kind of routing issue.

 

[bitsbytes]

ok, i'm back on the last official firmware and wifi is stable on the node. the RC 5 release is a bust for me.

 

[OzarkEdge]

Clean installed RC2-5 on 2xRT-AC86U wireless AiMesh per my install notes. Seems to be working ok here for the first time.

I have OE-24 and OE-24 Guest on ch 11 at 20 MHz and OE-50 and OE-50 Guest on ch 157 at 20/40/80 MHz. All sync'd to all nodes and appear to hold up with dBm values as good as they get.

An Android tablet connects at typical n 150 Mbps on both nodes. A laptop connects at typical ac 866 Mbps on both nodes. Laptop link rate holds steady during repeated browser speed tests, measuring ISP nominal 115/12 on both nodes while streaming HDHomerun TV tuner wired to root node. If I stream TV on both devices on remote node, the speed test down would dip into the 90s.

Initial roaming around outside with a streaming mobile on OE-24 was trouble free.

Router DHCP is set for 192.168.1.x. OE-* Guest clients report IPs 192.168.101.x. But I notice that a Wyze Cam on OE-24 Guest with client IP 192.168.101.43 is listed in the router client lists with IP 192.168.1.217. So, two different IP addresses are in play for the same one guest WLAN client.

From my root node wired desktop, I can ping root node OE-24 Guest 192.168.101.43...

Pinging 192.168.101.43 with 32 bytes of data:
Reply from 192.168.101.43: bytes=32 time=6ms TTL=63
Reply from 192.168.101.43: bytes=32 time=1ms TTL=63
Reply from 192.168.101.43: bytes=32 time=4ms TTL=63
Reply from 192.168.101.43: bytes=32 time=1ms TTL=63

Ping statistics for 192.168.101.43:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 6ms, Average = 3ms

but not same client 192.168.1.217...

Pinging 192.168.1.217 with 32 bytes of data:
Reply from 192.168.1.34: Destination host unreachable.
Reply from 192.168.1.34: Destination host unreachable.
Reply from 192.168.1.34: Destination host unreachable.
Reply from 192.168.1.34: Destination host unreachable.

Ping statistics for 192.168.1.217:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
no more ping data here

From my root node wired desktop, I cannot ping remote node OE-24 Guest 192.168.101.43 nor same client 192.168.1.217...

Pinging 192.168.101.43 with 32 bytes of data:
Reply from 192.168.1.1: Destination host unreachable.
Reply from 192.168.1.1: Destination host unreachable.
Reply from 192.168.1.1: Destination host unreachable.
Reply from 192.168.1.1: Destination host unreachable.

Ping statistics for 192.168.101.43:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Pinging 192.168.1.217 with 32 bytes of data:
Reply from 192.168.1.34: Destination host unreachable.
Reply from 192.168.1.34: Destination host unreachable.
Reply from 192.168.1.34: Destination host unreachable.
Reply from 192.168.1.34: Destination host unreachable.

Ping statistics for 192.168.1.217:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Notice the various Reply IP addresses above.

So, the root node LAN client can ping the root node guest WLAN client, but not the remote node guest WLAN client. So, maybe an issue here.

The same Wyze cam Android app on root node OE-50 can stream video from the cam on either OE-24 Guest WLAN, so I suspect the cam stream is by way of the Internet connection available to all networks. So, ok... and my only IoT device, the Wyze cam, is now a bit more isolated on a remote node guest WLAN.

The HDHomerun TV Android app on root node OE-50 Guest cannot stream video from the root node wired TV tuner. So, OK.

Finally, upon setting up the guest WLANs, the Log recorded a flurry of entries, but has since been relatively normal. See attached Log.txt file.

OE

 

[LimJK]

The devices on the guest never showed up on my device list. As for isolation I'm sure it was working in the previous RC firmware because the ips assigned were not on the same subnet and devices on guest couldn't be seen by other devices on the Network. Devices on the guest couldn't see each other as well if I remember correctly.

When I'm back home I'll chech the ip address for devices on guest.

bitsbyte,
I did a bit more investigation. I check with Net Analyzer on my iPhone that is using Guest Wifi, it is indeed using a different subnet and is isolated from my Primary Home Network. The bug is in the Network Map -> View list -> which is showing the IP address assigned in my DHCPlist and not the actual IP address assigned by Guest Wifi as shown below:

 

[Neil62]

@ASUSWRT_2020

The client lists which are displayed in the new AiMesh, for nodes and main router/s, can they please be sorted, using an IP address for each of the client names? Right now, it looks like there is no sorting at all occurring of attached clients, at least nothing obvious, I can see. The old client list display sort can be changed by clicking on column titles. The new client listing for AiMesh has no ability to change the display sorting of connected clients. I am suggesting to use an IP address sort for the displaying of connected clients at a minimum on original display. Which then equals/corresponds to/for current old/initial client display listing.

 

[Neil62]

@ASUSWRT_2020

I also noticed this on setting up my reboot schedule under the Administration tab, incorrect wording is still there:

Date to reboot highlighted in yellow, should/please, be changed/modified, to "Day(s) to Reboot" , as there is not a "date" association with the reboot schedule.

 

[YCY]

RT-AX86U, RT-AX82U, RT-AX3000, RT-AX58U will upgrade to 386 rc2.
The status is similar to RT-AX89X. There are new SDK for these four models and it takes time to do lots of tests to ensure the stability of the new SDK.

Do I see the RT-AX3000 model, including the TUF-AX3000? I noticed that these two are actually the same product, but there are differences in firmware. Thanks.

 

[Neil62]

@ASUSWRT_2020

Using the "Internet Speed" tab from the the Adaptive QoS menu, is there a way to pick up and or change the date display format? e.g DD/MM/YYYY and or match system time format. Not sure where it is picking up that format from and or its a bug (maybe). It also does not match my locale setting. Not a big deal as I think the date format is comming from the Ookla server to which you are attached to for the testing. Can you confirm this please?

Its displaying a different format from my system time even.

 

[Neil62]

@ASUSWRT_2020

I have also noticed that from the AiMesh menu and selecting "System Settings", if I then click on the "System Reboot" option, I am then unable to get back into the system gui login, on completion of reboot, without powering off and on the main router. Has anyone else had this problem and or, even tried this option, as according to the warning screen, it is supposed to reboot both main and nodes, simultaneously?

I also have the identical problem as above, if clicking on and using the "Optimization" button.

Nothing in the log file that I could see worthy of mention.

Note: I only use WIFI as a backhaul connection and current RC version was reset and rebuilt manually. Setup as per my signature.

 

[JoWa]

@ASUSWRT_2020

Using the "Internet Speed" tab from the the Adaptive QoS menu, is there a way to pick up and or change the date display format? e.g DD/MM/YYYY and or match system time format. Not sure where it is picking up that format from and or its a bug (maybe). It also does not match my locale setting.

Its displaying a different format from my system time even.

View attachment 26163

View attachment 26164

mine shows the same time and date as system..

 

[Neil62]

@ASUSWRT_2020

What does the orange dot indicate after the client number?

 

[Neil62]

mine shows the same time and date as system..

So you see a different date format on the internet speed tab?

 

[JoWa]

So you see a different date format on the internet speed tab?

yes

 

[JoWa]

my logg is beeing filled up with this error message...it just keep on going. Using the new RC2-5 build.

 

[Neil62]

yes

Really, so I wonder where it gets that date format from. I Just checked again, cleared browser cache, restarted the router and still I see this format: Anyone?

I believe the date format is coming from the server/current connecton, to which Ookla is using for the speed test. At a guess. Anyways not a deal breaker...

 

[Neil62]

my logg is beeing filled up with this error message...it just keep on going. Using the new RC2-5 build.

Have you tried a reboot of the main router or even a power off and on? Did you factory reset the router after the loading of the new firmware? A reset and manual rebuild should be a must with each new RC release.

 

[KingBravery]

my logg is beeing filled up with this error message...it just keep on going. Using the new RC2-5 build.

You need to factory reset using small reset button below unit if not yet

 

[karma]

@ASUSWRT_2020

What does the orange dot indicate after the client number?
View attachment 26165

From what I could gather it means there's a client on that node which isn't connected to it's preferred/bound node.