Beta Asuswrt-Merlin 388.1 Beta is available for select models

[Treadler]

Same here, using the site you suggested.

I always have the IPv4 firewall enabled.
Its disabling the ”Enable IPv4 inbound firewall rules” that turned everything from ‘refused’ to ‘stealth’.

Now, for the first time ever, I’m seeing occasional dropped IPv6 packets in syslog.

 

[blackfireball5]

I just had the strangest thing happen. Out of nowhere a bunch of programs on my computer stopped being connected to the internet. However, I was still able to play the video game I was in (Overwatch 2). But programs like Chrome, Discord, Teamviewer, etc all stopped connecting to the internet. Then when I checked my phone, I noticed I wasn't connected to the wifi. I could see my SSID's, but when I tried to connect to them, nothing would happen. It wouldn't fail, or error, I would tap itm it would say connecting, then it would stop and nothing would happen.

I have never seen it where some programs on my ethernet wired computer could access the internet normally, but others completely couldn't.

I was able to access my router and modem fine. Ran diagnostics on modem (normal) and speed test from router (normal).

This was super unusual and I can't explain what caused it.

I rebooted the router from GUI and that fixed everything.

My log was just doing this over and over repeatedly during this time:

Nov 23 23:18:59 wlceventd: wlceventd_proc_event(469): eth10: Deauth_ind 2C:AA:8E:0C:26:C4, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Nov 23 23:18:59 wlceventd: wlceventd_proc_event(486): eth10: Disassoc 2C:AA:8E:0C:26:C4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Nov 23 23:18:59 hostapd: eth10: STA 2c:aa:8e:0c:26:c4 IEEE 802.11: disassociated
Nov 23 23:18:59 hostapd: eth10: STA 2c:aa:8e:0c:26:c4 IEEE 802.11: disassociated
Nov 23 23:19:10 wlceventd: wlceventd_proc_event(505): eth10: Auth 2C:AA:8E:0B:F0:5E, status: Successful (0)
Nov 23 23:19:10 wlceventd: wlceventd_proc_event(534): eth10: Assoc 2C:AA:8E:0B:F0:5E, status: Successful (0)
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0b:f0:5e IEEE 802.11: associated
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0b:f0:5e RADIUS: starting accounting session 3B932C2AC5C40033
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0b:f0:5e WPA: pairwise key handshake completed (RSN)
Nov 23 23:19:10 wlceventd: wlceventd_proc_event(505): eth10: Auth 2C:AA:8E:0C:26:C4, status: Successful (0)
Nov 23 23:19:10 wlceventd: wlceventd_proc_event(534): eth10: Assoc 2C:AA:8E:0C:26:C4, status: Successful (0)
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0c:26:c4 IEEE 802.11: associated
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0c:26:c4 RADIUS: starting accounting session 8F56A27A7EEA9D3D
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0c:26:c4 WPA: pairwise key handshake completed (RSN)
Nov 23 23:19:16 wlceventd: wlceventd_proc_event(469): eth10: Deauth_ind 2C:AA:8E:0C:2D:FD, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Nov 23 23:19:16 wlceventd: wlceventd_proc_event(486): eth10: Disassoc 2C:AA:8E:0C:2D:FD, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Nov 23 23:19:16 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd IEEE 802.11: disassociated
Nov 23 23:19:16 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd IEEE 802.11: disassociated
Nov 23 23:19:17 wlceventd: wlceventd_proc_event(469): eth10: Deauth_ind 2C:AA:8E:A7:10:77, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Nov 23 23:19:17 wlceventd: wlceventd_proc_event(486): eth10: Disassoc 2C:AA:8E:A7:10:77, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Nov 23 23:19:17 hostapd: eth10: STA 2c:aa:8e:a7:10:77 IEEE 802.11: disassociated
Nov 23 23:19:17 hostapd: eth10: STA 2c:aa:8e:a7:10:77 IEEE 802.11: disassociated
Nov 23 23:19:27 wlceventd: wlceventd_proc_event(505): eth10: Auth 2C:AA:8E:0C:2D:FD, status: Successful (0)
Nov 23 23:19:27 wlceventd: wlceventd_proc_event(534): eth10: Assoc 2C:AA:8E:0C:2D:FD, status: Successful (0)
Nov 23 23:19:27 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd IEEE 802.11: associated
Nov 23 23:19:27 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd RADIUS: starting accounting session ED06BDCCA22F3742
Nov 23 23:19:27 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd WPA: pairwise key handshake completed (RSN)
Nov 23 23:19:28 wlceventd: wlceventd_proc_event(505): eth10: Auth 2C:AA:8E:A7:10:77, status: Successful (0)
Nov 23 23:19:28 wlceventd: wlceventd_proc_event(534): eth10: Assoc 2C:AA:8E:A7:10:77, status: Successful (0)
Nov 23 23:19:28 hostapd: eth10: STA 2c:aa:8e:a7:10:77 IEEE 802.11: associated
Nov 23 23:19:28 hostapd: eth10: STA 2c:aa:8e:a7:10:77 RADIUS: starting accounting session 1A4B4A19F6167897
Nov 23 23:19:28 hostapd: eth10: STA 2c:aa:8e:a7:10:77 WPA: pairwise key handshake completed (RSN)

 

[blackfireball5]

From what I can tell, all the mac addresses listed that are being repeatedly deauthenticated are Wyze cams / smart outlets connected to my 2.4ghz network.

 

[Martineau]

Did you actually test it?
I tried again with different ssh client and still showing off.View attachment 45716

IIRC, commands

service start_wgc

service stop_wgc

will alter the state of any Wireguard peer where its nvram enabled variable is set to "1"

e.g 'client' peers

nvram dump 2>/dev/null | grep -E wgc[1-5]_en

wgc1_enable=0
wgc2_enable=1
wgc3_enable=0

so if the above variables are set as shown, then commands service start_wgc/service stop_wgc will be applied to ONLY 'client' peer wgc2

 

[brummygit]

I've been running Asuswrt-Merlin 388 on my RT-AX88U since the Alpha, and have seen the issue being reported by others that my RT-AX86U nodes show in AIMesh as disconnected when running on the beta firmware. I initially thought this was cosmetic but started to get reports of very poor call quality when people use WiFi Calling on their iPhones. I've also seen some patchy performance of my Ring cameras which could be linked. I switched the nodes to stock 388 and the display of mesh node connection status returned and I initially thought all was good.

I've continued to get reports of multiple iPhones having wifi calling issues and so went back to stock 386 on my nodes. This made no improvement. I also tried disabling IPV6 and Smart Connect without any improvement.

Finally I've regressed to 386.8 on my RT-AX88U with 3.0.0.4.386_49599 on my RT-AX86U nodes and so far this seems to have improved the situation. I'm a long term user of for QoS and never usually see any issues with it, and indeed rely on it to help with my relatively modest speeds.

I'm wondering if anyone else has seen similar problems?

 

[Unisoft]

I've been running Asuswrt-Merlin 388 on my RT-AX88U since the Alpha, and have seen the issue being reported by others that my RT-AX86U nodes show in AIMesh as disconnected when running on the beta firmware. I initially thought this was cosmetic but started to get reports of very poor call quality when people use WiFi Calling on their iPhones. I've also seen some patchy performance of my Ring cameras which could be linked. I switched the nodes to stock 388 and the display of mesh node connection status returned and I initially thought all was good.

I've continued to get reports of multiple iPhones having wifi calling issues and so went back to stock 386 on my nodes. This made no improvement. I also tried disabling IPV6 and Smart Connect without any improvement.

Finally I've regressed to 386.8 on my RT-AX88U with 3.0.0.4.386_49599 on my RT-AX86U nodes and so far this seems to have improved the situation. I'm a long term user of for QoS and never usually see any issues with it, and indeed rely on it to help with my relatively modest speeds.

I'm wondering if anyone else has seen similar problems?

I agree.

Never had a problem with Adaptive QOS before on 386 builds and below on RT-AX86U (I have THREE units available for testing), and I reset router settings by hand every couple of releases.

This .388 branch, when QOS is enabled, and even if only 1 machine connected, I get all sorts of weird speedtest results nowhere near my 1gbps connection speed. If I turn off QOS, the speeds return. An internet speed test direct from router to cable modem is always around 1100mbps+ so I know it is not my ISP at fault. I was doing all sorts of tests thinking it was my Realtek 8125B 2.5gbps network adapter/drivers/Windows TCP settings. It wasn't. It is clearly Adaptive QOS. The upload and download speeds are set to Manual (because historic bug spoken about on here with Automatic setting) - and this on 386 builds gave A+ on Buffer Bloat tests.

I've disabled QOS now, and the speed returned. I like to have QOS enabled though, as it manages more limited upstream bandwidth.

 

[skeal]

I agree.

Never had a problem with Adaptive QOS before on 386 builds and below on RT-AX86U (I have THREE units available for testing), and I reset router settings by hand every couple of releases.

This .388 branch, when QOS is enabled, and even if only 1 machine connected, I get all sorts of weird speedtest results nowhere near my 1gbps connection speed. If I turn off QOS, the speeds return. An internet speed test direct from router to cable modem is always around 1100mbps+ so I know it is not my ISP at fault. I was doing all sorts of tests thinking it was my Realtek 8125B 2.5gbps network adapter/drivers/Windows TCP settings. It wasn't. It is clearly Adaptive QOS. The upload and download speeds are set to Manual (because historic bug spoken about on here with Automatic setting) - and this on 386 builds gave A+ on Buffer Bloat tests.

I've disabled QOS now, and the speed returned. I like to have QOS enabled though, as it manages more limited upstream bandwidth.

With your connection speed, QOS is not advised. Although QOS does in fact govern upload as well as download, upload is very seldom anyone's issue. IMHO. If you don't need it don't use it.

 

[skeal]

Speed test results and QOS performance have an inverse relationship. If you want speed test results don't use QOS, if you want proper bandwidth management use QOS, it's really that simple. If Upload bandwidth is an issue then traditional QOS gives you more granular control, but with speed test results dropping as a result. WiFi calling doesn't use much bandwidth to be honest.

 

[Unisoft]

Speed test results and QOS performance have an inverse relationship. If you want speed test results don't use QOS, if you want proper bandwidth management use QOS, it's really that simple. If Upload bandwidth is an issue then traditional QOS gives you more granular control, but with speed test results dropping as a result. WiFi calling doesn't use much bandwidth to be honest.

It's always been accurate though with speed test providers on 386 codebase with Adaptive QOS (manual) and throughout history. This 388 build is wild and anywhere from 280-660mbps.

On my 1gbps connection, it only has a 52mbps upstream used for Emby streaming so that's why I like QOS normally My cable tv broadband provider is likely to go 100-120mbps at some point, and I have a symmetric 1gbps FTTP connection coming as another provider is currently putting the infrastructure in.

 

[hancox]

Most with the AX86U have experienced poor QOS performance long before 388.1 - flow cache is simply broken on this router, from the looks of it.

For downstream <= ~ 300Mb/s, you can cheat and disable fc to restore performance, but this won't work well with higher bandwidth connections.

 

[dave14305]

Although QOS does in fact govern upload as well as download, upload is very seldom anyone's issue.

With the popularity of asymmetric down/up bandwidth, upload is almost always the issue to prevent bufferbloat upstream. Upload is the only direction you can really control from your router. Once you receive a download packet, it doesn’t do much good to try to subject it to QoS. The ISP bandwidth to receive it has already been consumed.

 

[skeal]

With the popularity of asymmetric down/up bandwidth, upload is almost always the issue to prevent bufferbloat upstream. Upload is the only direction you can really control from your router. Once you receive a download packet, it doesn’t do much good to try to subject it to QoS. The ISP bandwidth to receive it has already been consumed.

So is traditional QOS still the best then?

 

[sndude]

The onedrive test builds download folder is empty??

 

[Deleted member 22229]

The onedrive test builds download folder is empty??

Yes. We are in the Beta phase now check the main download page and look under beta for your model.

 

[dave14305]

So is traditional QOS still the best then?

No, but it’s probably more important to control upload first before fretting over download.

 

[Damit1]

Well, AX88U run for 2 days no issues at all. Beta3

Ax56U after 2 days, crashed 30mins ago.

Not sure why, logs not showing any specific indications for it . Beta3 as well.
Beta2 ran for 9 days straight

Hope nothing has changed in between that relate...

 

[Olivier]

Beta 3 running smooth with as router GT-AX11000 pro & 4 * XT12.
Tx for this work!

 

[Rhialto]

Beta 3 running smooth with as router GT-AX11000 pro

Where are you from? Europe maybe? Can't find it online in North America. Anyway maybe overkill/overpriced for us so I'm more looking at RT-AX86U Pro which have yet to show online also here in NA.

 

[abir1909]

IIRC, commands

service start_wgc

service stop_wgc

will alter the state of any Wireguard peer where its nvram enabled variable is set to "1"

e.g 'client' peers

nvram dump 2>/dev/null | grep -E wgc[1-5]_en

wgc1_enable=0
wgc2_enable=1
wgc3_enable=0

so if the above variables are set as shown, then commands service start_wgc/service stop_wgc will be applied to ONLY 'client' peer wgc2

Now I got. In other words the client need to be enabled first (connected) and once you execute the command it will stop the client but it won’t disable it.
Not like open VPN when it actually disable and enables it. Thanks

 

[BreakingDad]

I just had the strangest thing happen. Out of nowhere a bunch of programs on my computer stopped being connected to the internet. However, I was still able to play the video game I was in (Overwatch 2). But programs like Chrome, Discord, Teamviewer, etc all stopped connecting to the internet. Then when I checked my phone, I noticed I wasn't connected to the wifi. I could see my SSID's, but when I tried to connect to them, nothing would happen. It wouldn't fail, or error, I would tap itm it would say connecting, then it would stop and nothing would happen.

I have never seen it where some programs on my ethernet wired computer could access the internet normally, but others completely couldn't.

I was able to access my router and modem fine. Ran diagnostics on modem (normal) and speed test from router (normal).

This was super unusual and I can't explain what caused it.

I rebooted the router from GUI and that fixed everything.

My log was just doing this over and over repeatedly during this time:

Nov 23 23:18:59 wlceventd: wlceventd_proc_event(469): eth10: Deauth_ind 2C:AA:8E:0C:26:C4, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Nov 23 23:18:59 wlceventd: wlceventd_proc_event(486): eth10: Disassoc 2C:AA:8E:0C:26:C4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Nov 23 23:18:59 hostapd: eth10: STA 2c:aa:8e:0c:26:c4 IEEE 802.11: disassociated
Nov 23 23:18:59 hostapd: eth10: STA 2c:aa:8e:0c:26:c4 IEEE 802.11: disassociated
Nov 23 23:19:10 wlceventd: wlceventd_proc_event(505): eth10: Auth 2C:AA:8E:0B:F0:5E, status: Successful (0)
Nov 23 23:19:10 wlceventd: wlceventd_proc_event(534): eth10: Assoc 2C:AA:8E:0B:F0:5E, status: Successful (0)
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0b:f0:5e IEEE 802.11: associated
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0b:f0:5e RADIUS: starting accounting session 3B932C2AC5C40033
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0b:f0:5e WPA: pairwise key handshake completed (RSN)
Nov 23 23:19:10 wlceventd: wlceventd_proc_event(505): eth10: Auth 2C:AA:8E:0C:26:C4, status: Successful (0)
Nov 23 23:19:10 wlceventd: wlceventd_proc_event(534): eth10: Assoc 2C:AA:8E:0C:26:C4, status: Successful (0)
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0c:26:c4 IEEE 802.11: associated
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0c:26:c4 RADIUS: starting accounting session 8F56A27A7EEA9D3D
Nov 23 23:19:10 hostapd: eth10: STA 2c:aa:8e:0c:26:c4 WPA: pairwise key handshake completed (RSN)
Nov 23 23:19:16 wlceventd: wlceventd_proc_event(469): eth10: Deauth_ind 2C:AA:8E:0C:2D:FD, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Nov 23 23:19:16 wlceventd: wlceventd_proc_event(486): eth10: Disassoc 2C:AA:8E:0C:2D:FD, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Nov 23 23:19:16 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd IEEE 802.11: disassociated
Nov 23 23:19:16 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd IEEE 802.11: disassociated
Nov 23 23:19:17 wlceventd: wlceventd_proc_event(469): eth10: Deauth_ind 2C:AA:8E:A7:10:77, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Nov 23 23:19:17 wlceventd: wlceventd_proc_event(486): eth10: Disassoc 2C:AA:8E:A7:10:77, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Nov 23 23:19:17 hostapd: eth10: STA 2c:aa:8e:a7:10:77 IEEE 802.11: disassociated
Nov 23 23:19:17 hostapd: eth10: STA 2c:aa:8e:a7:10:77 IEEE 802.11: disassociated
Nov 23 23:19:27 wlceventd: wlceventd_proc_event(505): eth10: Auth 2C:AA:8E:0C:2D:FD, status: Successful (0)
Nov 23 23:19:27 wlceventd: wlceventd_proc_event(534): eth10: Assoc 2C:AA:8E:0C:2D:FD, status: Successful (0)
Nov 23 23:19:27 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd IEEE 802.11: associated
Nov 23 23:19:27 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd RADIUS: starting accounting session ED06BDCCA22F3742
Nov 23 23:19:27 hostapd: eth10: STA 2c:aa:8e:0c:2d:fd WPA: pairwise key handshake completed (RSN)
Nov 23 23:19:28 wlceventd: wlceventd_proc_event(505): eth10: Auth 2C:AA:8E:A7:10:77, status: Successful (0)
Nov 23 23:19:28 wlceventd: wlceventd_proc_event(534): eth10: Assoc 2C:AA:8E:A7:10:77, status: Successful (0)
Nov 23 23:19:28 hostapd: eth10: STA 2c:aa:8e:a7:10:77 IEEE 802.11: associated
Nov 23 23:19:28 hostapd: eth10: STA 2c:aa:8e:a7:10:77 RADIUS: starting accounting session 1A4B4A19F6167897
Nov 23 23:19:28 hostapd: eth10: STA 2c:aa:8e:a7:10:77 WPA: pairwise key handshake completed (RSN)

what's your overwatch2 rank?