Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

[KingBravery]

with 4x4 160Mhz it should be 4.8 Gbps, no?

yes, if you put node next to main.. if only using ax200 wifi or phone, you can get max 2400Mbps for now as they run 2x2.

 

[sanke1]

Are you complaining about the betaware being tested in this thread?

OE

I am complaining about each and every firmware irrespective of being beta or stable being unable to fix port forwarding issue.

Quick description of the problem:
After few days (or sometimes even after few hrs), none of the port forwards work. I have just 7-8 port forwards so it's not a huge list I got there. I can even replicate the issue reliably these days. If everything is working well for 2 days, I just need to log into router and do any trivial thing like clear log and BAM! Port forward stops working within few minutes. None of the CCTV cameras work and even Remote Desktop connectivity is lost. I have to use Chrome Remote Desktop or Teamviewer to remote login to one of my work PCs, go to router homepage and reboot the router. Then repeat this till next hang. There is nothing in log as well... that is the moment port forwards stop working, there is zero entry about anything in the log.

I replaced the RT-AX88U with cheap $20 TP-Link router to make sure nothing in my network was causing any issue. To my surpirse, that cheap TP-Link held on it's own for 1 month straight without any port forwarding issues untill I finally removed it and put back RT-AX88U just to see if this 386 solves it. But it's just the same. I have sent 4-5 reports through GUI. At the moment I really don't know what to do with this unreliable overpriced router.

 

[karma]

yes, if you put node next to main.. if only using ax200 wifi or phone, you can get max 2400Mbps for now as they run 2x2.

which brings me back to my original point that i'm surprised wireless backhaul isn't faster. surely AX, 4 spacial streams at 80Mhz which my wireless backhaul is running at, not located too far away, should be faster than 1.4Gbps.

 

[OzarkEdge]

I am complaining about each and every firmware irrespective of being beta or stable being unable to fix port forwarding issue.

Quick description of the problem:
After few days (or sometimes even after few hrs), none of the port forwards work. I have just 7-8 port forwards so it's not a huge list I got there. I can even replicate the issue reliably these days. If everything is working well for 2 days, I just need to log into router and do any trivial thing like clear log and BAM! Port forward stops working within few minutes. None of the CCTV cameras work and even Remote Desktop connectivity is lost. I have to use Chrome Remote Desktop or Teamviewer to remote login to one of my work PCs, go to router homepage and reboot the router. Then repeat this till next hang. There is nothing in log as well... that is the moment port forwards stop working, there is zero entry about anything in the log.

I replaced the RT-AX88U with cheap $20 TP-Link router to make sure nothing in my network was causing any issue. To my surpirse, that cheap TP-Link held on it's own for 1 month straight without any port forwarding issues untill I finally removed it and put back RT-AX88U just to see if this 386 solves it. But it's just the same. I have sent 4-5 reports through GUI. At the moment I really don't know what to do with this unreliable overpriced router.

Thanks for clarifying.

Sell it to someone who doesn't use port forwarding.

OE

 

[LimJK]

The BW field was added around the time of the RT-AX88U if I remember correctly.

I still think Asus should redesign this whole page IMHO. This is how it looks in my firmware, for example.

View attachment 26024

RMerlin,
You have an excellent Wireless Log ,

• However, for an AiMesh Network, this particular Wireless log page on both Stock and your Firmware only shows the AiMesh Router's Wireless log. If it can include those of the AiMesh Nodes that will be excellent.
• Considering the new AiMesh 2.0 GUI design, I was hoping they can at include all the info you show for each wireless client (Rx/TX & RSSI, Connect Time, Streams, Flags). For a start, I thought it will be good if ASUS can consider to include the Bandwidth info in the new GUI for the each Wireless client. I see a lot of people raised concerns here that their 5GHz WiFi throughput degraded without knowing that the AiMesh Node bandwidth has dropped from 80MHz to 20MHz in the earlier RCs Firmware.

 

[ligeza]

Will Lyra Trio also get AiMesh 2 support?
After adding Lyra as AiMesh node I'm getting info that Ethernet Backhaul is not supported, but it's working in this mode.

 

[Stuey3D]

The BW field was added around the time of the RT-AX88U if I remember correctly.

I still think Asus should redesign this whole page IMHO. This is how it looks in my firmware, for example.

View attachment 26024

This is my favourite page of your firmware, this is one of the most useful additions over the stock firmware for my usage.

 

[OzarkEdge]

Will Lyra Trio also get AiMesh 2 support?
After adding Lyra as AiMesh node I'm getting info that Ethernet Backhaul is not supported, but it's working in this mode.


View attachment 26046

It's all kind of amazing... Asus trying to mesh its various standalone routers. I'm curious to know how this will pan out in the long term, in the market, in our homes. I would like to know more about how and why they chose this product development direction. Plus Asuswrt-Merlin goes along for the ride... who would have thought it would go mesh and overnight.

A background discussion here is, 'how mesh is AiMesh?'.

/off-topic

OE

 

[JohnD5000]

If I install this AiMesh 2 firmware to try out, will I still be able to run scripts (AMTM,Skynet, etc?)

 

[bbunge]

If I install this AiMesh 2 firmware to try out, will I still be able to run scripts (AMTM,Skynet, etc?)

Not easily.

 

[JChris]

I’m having trouble trying to make IGMP work in AP mode. I tried with the beta firmware 9.0.0.4.386_39485, but it seems the issue persists, findings below.

Model: ZenWifi XT8 2-PACK (Europe)

ISP FTTH with 1 “all-in-one” device working as ONT, router, wireless router, switch and RFTV. Wireless router functionality was disabled by me because I want everything wifi coming from ZenWifi. I also have 1 ISP IPTV STB with wired and wireless capabilities

I want the ZenWifis working as “dumb” APs, because wired backhaul is not possible with the cabling layout I have in my house and wireless backhaul is a waste because I want 4x4 5G for my devices. I have the following structure:

ISP Router

LAN1: ZenWifi #1 <- the one I need IGMP working​

LAN2: TV​

LAN3: ISP STB​

LAN2: ZenWifi #2​

LAN2: TV​

LAN3: console​

For all attempts below I used this configuration:

View attachment 26025

Attempt #1
XT8 with 3.0.0.4.386_25524 on AP mode: IPTV STB works and got IP from ISP Router DHCP, but everything else connected to ZenWifi won’t even get an IP address.
WAN: cable from ISP router
LAN3: IPTV STB

Attempt #2
XT8 with 3.0.0.4.386_25524 on AP mode: not working. IPTV STB won’t even detect network
LAN1: cable from ISP router
LAN3: IPTV STB

Attempt #3
XT8 with 3.0.0.4.386_25524 on Wireless Router mode: working, no freezing
WAN: cable from ISP router
LAN3: IPTV STB

I intentionally moved the IPTV STB from LAN3 to LAN2 and the freezing started, as expected. I moved it back to LAN3 and all good, no freezing.

The problem with this setup is that I would end up with 2 networks, one for each router and to manage them I would have to connect to each, which is terrible. I’d rather have then as APs and access, let’s say, 192.168.0.10 and .11 to manage them.

Attempt #4
XT8 with 3.0.0.4.386_25524 on Wireless Router mode: not working. IPTV STB won’t even detect network. Other devices connected via wifi or wired can access the Internet. I’m not able to access the ZenWifi admin page
LAN1: cable from ISP router
LAN3: IPTV STB

Attempt #5
XT8 with 9.0.0.4.386_39485 on AP mode: IPTV STB works and got IP from ISP Router DHCP, but everything else connected to ZenWifi won’t even get an IP address.
WAN: cable from ISP router
LAN3: IPTV STB

Attempt #6
XT8 with 9.0.0.4.386_39485 on AP mode: not working. IPTV STB won’t even detect network
LAN1: cable from ISP router
LAN3: IPTV STB

Attempt #7
XT8 with 9.0.0.4.386_39485 on Wireless Router mode: working, no freezing
WAN: cable from ISP router
LAN3: IPTV STB

Same problem as attempt #3, creates a different network.

Attempt #8
XT8 with 9.0.0.4.386_39485 on Wireless Router mode: not working. IPTV STB won’t even detect network. Other devices connected via wifi or wired can access the Internet. I’m not able to access the ZenWifi admin page
LAN1: cable from ISP router
LAN3: IPTV STB

---

To sum it all, I can’t get IGMP working when the XT8 in is AP mode, only when in Router mode.

So... no one here uses IGMP on their router in AP mode?

 

[L&LD]

@JChris I make a point not to.

(Hope someone sees this bump for you).

 

[karma]

aaalrighty, i'm reverting my XT8s to the latest non beta which was working well enough for me since I need my guest network to work and it doesn't in AP mode. Maybe I'll try the next beta when it's released if guest is fixed.

 

[KingBravery]

aaalrighty, i'm reverting my XT8s to the latest non beta which was working well enough for me since I need my guest network to work and it doesn't in AP mode. Maybe I'll try the next beta when it's released if guest is fixed.

Have you try first version of RC2 firmware?

 

[JChris]

I'm seeing lots of Auth/Deuth events in the same second, is that normal?

Below is just a tiny fraction of the log. I have a 1000 sqft house with 2x XT8 in AP mode (firmware 9.0.0.4.386_39485) and there is a lot of signal overlap when both are configure as Tx power adjustment Performance, so I had to configure Tx power adjustment Power Saving in both APs. Basically each AP covers 50% of the house. This way when someone moves they are disconnected from one AP and connect into the other AP. I also configured Roaming assistant as -60dbm.

Sep  7 19:24:32 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  7 19:24:32 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  7 19:25:51 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:25:51 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  7 19:25:51 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  7 19:26:15 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:26:15 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  7 19:26:15 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:26:15 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  7 19:26:15 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:26:15 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  7 19:26:15 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:26:15 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  7 19:26:15 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  7 19:26:15 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  7 19:26:15 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)

Sep  8 19:49:40 acsd: acs_set_chspec: 0x1002 (2) for reason APCS_CSTIMER
Sep  8 19:49:41 acsd: eth4: selected_chspec is 1002 (2)
Sep  8 19:49:41 acsd: eth4: Adjusted channel spec: 0x1002 (2)
Sep  8 19:49:41 acsd: eth4: selected channel spec: 0x1002 (2)
Sep  8 19:49:41 acsd: eth4: txop channel select: Performing CSA on chspec 0x1002
Sep  8 19:49:42 acsd: eth4: selected_chspec is 1002 (2)
Sep  8 19:49:42 acsd: eth4: Adjusted channel spec: 0x1002 (2)
Sep  8 19:49:42 acsd: eth4: selected channel spec: 0x1002 (2)
Sep  8 19:49:42 acsd: eth4: txop channel select: Performing CSA on chspec 0x1002
Sep  8 19:49:43 acsd: eth4: selected_chspec is 1002 (2)
Sep  8 19:49:43 acsd: eth4: Adjusted channel spec: 0x1002 (2)
Sep  8 19:49:43 acsd: eth4: selected channel spec: 0x1002 (2)
Sep  8 19:49:43 acsd: eth4: txop channel select: Performing CSA on chspec 0x1002
Sep  8 19:54:10 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 19:54:10 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 19:54:24 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  8 19:54:24 wlceventd: wlceventd_proc_event(515): eth6: ReAssoc 08:74:02:7F:01:2A, status: Successful (0)
Sep  8 19:55:56 wlceventd: wlceventd_proc_event(505): eth6: Auth A4:38:CC:2B:91:CB, status: Successful (0)
Sep  8 19:55:56 wlceventd: wlceventd_proc_event(534): eth6: Assoc A4:38:CC:2B:91:CB, status: Successful (0)
Sep  8 19:55:57 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 19:55:57 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 19:56:02 wlceventd: wlceventd_proc_event(486): eth6: Disassoc A4:38:CC:2B:91:CB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 19:56:02 wlceventd: wlceventd_proc_event(486): eth6: Disassoc A4:38:CC:2B:91:CB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 19:56:36 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  8 19:56:36 wlceventd: wlceventd_proc_event(515): eth6: ReAssoc 08:74:02:7F:01:2A, status: Successful (0)
Sep  8 19:57:08 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 19:57:08 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 19:59:49 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  8 19:59:49 wlceventd: wlceventd_proc_event(515): eth6: ReAssoc 08:74:02:7F:01:2A, status: Successful (0)
Sep  8 20:00:52 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 20:00:52 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 20:01:26 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  8 20:01:26 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 08:74:02:7F:01:2A, status: 0, reason: Unspecified reason (1)
Sep  8 20:01:26 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  8 20:01:26 wlceventd: wlceventd_proc_event(515): eth6: ReAssoc 08:74:02:7F:01:2A, status: Successful (0)
Sep  8 20:02:15 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 20:02:15 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 20:02:56 wlceventd: wlceventd_proc_event(505): eth6: Auth 08:74:02:7F:01:2A, status: Successful (0)
Sep  8 20:02:56 wlceventd: wlceventd_proc_event(515): eth6: ReAssoc 08:74:02:7F:01:2A, status: Successful (0)
Sep  8 20:06:47 wlceventd: wlceventd_proc_event(505): eth6: Auth D0:E1:40:90:FC:76, status: Successful (0)
Sep  8 20:06:47 wlceventd: wlceventd_proc_event(534): eth6: Assoc D0:E1:40:90:FC:76, status: Successful (0)
Sep  8 20:07:20 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 20:07:20 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 08:74:02:7F:01:2A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 20:22:02 wlceventd: wlceventd_proc_event(505): eth6: Auth A4:38:CC:2B:91:CB, status: Successful (0)
Sep  8 20:22:02 wlceventd: wlceventd_proc_event(534): eth6: Assoc A4:38:CC:2B:91:CB, status: Successful (0)
Sep  8 20:22:07 wlceventd: wlceventd_proc_event(486): eth6: Disassoc A4:38:CC:2B:91:CB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep  8 20:22:07 wlceventd: wlceventd_proc_event(486): eth6: Disassoc A4:38:CC:2B:91:CB, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

 

[SBSTNGRSS]

I am running 2 nodes AiMesh both RT-AC88U with RC4 (9.0.0.4.386_39485-ge699ff3) and my LAN seemed to have a hickup today:

Sep 8 22:36:01 kernel: rtk_port_linkStatus_get() fail, err: 10
Sep 8 22:36:05 kernel: rtk_port_linkStatus_get() fail, err: 10
Sep 8 22:36:05 rtl_fail: rtkswitch fail access, restart.
Sep 8 22:36:07 kernel: rtl8365mbrtl8365mb initialized(0)(retry:0)
Sep 8 22:36:08 kernel: rtk port_phyEnableAll ok
Sep 8 22:36:09 kernel: txDelay_user: 1
Sep 8 22:36:09 kernel: # txDelay - TX delay value, 1 for delay 2ns and 0 for no-delay
Sep 8 22:36:09 kernel: EXT_PORT:16 new txDelay: 1, rxDelay: 1
Sep 8 22:36:09 kernel: current EXT_PORT:16 txDelay: 1, rxDelay: 1
Sep 8 22:36:09 kernel: rxDelay_user: 4
Sep 8 22:36:09 kernel: # rxDelay - RX delay value, 0~7 for delay setupEXT_PORT:16 new txDelay: 1, rxDelay: 4
Sep 8 22:36:09 kernel: current EXT_PORT:16 txDelay: 1, rxDelay: 4
Sep 8 22:44:40 kernel: htb: htb qdisc 10: is non-work-conserving?

The effect on my end was a reported LAN cable disconnect. Not sure whether this is new or not.

Thanks, Sebastian

 

[karma]

XT8 - AP Mode - Guest
i'm back to running the latest stable release and it turns out that the guest is not at all isolated. that's really not good. for those not in AP mode with a working guest is it isolated in the beta?

 

[OzarkEdge]

XT8 - AP Mode - Guest
i'm back to running the latest stable release and it turns out that the guest is not at all isolated. that's really not good. for those not in AP mode with a working guest is it isolated in the beta?

Guests on APs/AiMesh 1.0 APs are not isolated... that's been an issue.

Guests on AiMesh 2.0 RC2 are suppose to be isolated, and are reported to even be isolated from each other within the same WLAN.

OE

 

[karma]

Guests on APs/AiMesh 1.0 APs are not isolated... that's been an issue.

Guests on AiMesh 2.0 RC2 are suppose to be isolated, and are reported to even be isolated from each other within the same WLAN.

OE

ah ok. thanks for the info!

 

[JokerPower]

Hi

Any ideas when the final build will be released?

How is the latest version?

I'm using RT-AX92U (2-pack) with latest stable build

Thanks