What's new

Beta Asuswrt-Merlin 388.1 Beta is available for select models

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Did you actually test it?
I tried again with different ssh client and still showing off.View attachment 45716
IIRC, commands
Code:
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
Code:
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
 
Last edited:
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'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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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?
 
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...
 
Beta 3 running smooth with as router GT-AX11000 pro & 4 * XT12.
Tx for this work!
 
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.
 
IIRC, commands
Code:
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
Code:
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
 
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?
 
So I upgraded to 388.1 beta 3 on my AXE16000, using the ROG styled firmware, and have run into an unexpected issue. The router keeps redirecting me to router.asus.com when I have it set not to in System settings page. I've tried toggling it off and on but it just keeps redirecting me...pretty annoying. Any ideas on how to fix this?

Update: Flashed the non-ROG styled 388.1 beta 3 firmware and apparently it's fixed? Don't see how that could've fixed it but hey...will keep poking around it though.
 
Last edited:
what's your overwatch2 rank?
I had the same situation last night. Since upgraded my family says internet not stable, their phones getting no internet from time to time while other things still working. It happened to me last night also, I turned off WiFi on my phone and turned it back on. Once reconnected internet worked.

See attached log. Has anything looks strange?
 

Attachments

  • B0FE65F3-17A4-4170-A007-8D1894D6304A.jpeg
    B0FE65F3-17A4-4170-A007-8D1894D6304A.jpeg
    123.6 KB · Views: 137
Status
Not open for further replies.

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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