What's new

[384.18_Alpha Builds] Testing all variants

  • 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!

@jata. Happend to me several times and it was always related to Firefox. Other browsers did just work. After resetting Firefox I could log-on normally again. I just think it has something to do with SSL en verifying certificates.
Yep, and no need to reset, just delete cert8.db and key3.db (or cert9.db and key4.db depending of the version) files in AppData\Roaming\Waterfox\Profiles\ and that should do it.
 
Updated to the latest Alpha for my AX88U and anecdotally the performance seems much better. Getting better throughout and much more consistent.

Was using .17 and it was always all over the place for me performance wise, and needed a reboot about once every few days.
 
For AC66_b1, which version of alpha can I use?
I have ac86u (ai mesh router) + ac66b1 (ai mesh node)

PS: Version RT-AC86U_384.18_alpha1-gb66d5282dd works fine in the pair Aimesh ac66u_b1 (384_17)
 
Last edited:
Full factory reset RT-AX88U
I still get same error i get on 384.17

Jun 14 10:43:28 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
I always did dirty flashing since 384.14 but I figured I give this a try and do full Factory reset, reformat my USB, and manually re-setup the router from scratch.
I get this message on 384.17 too
 
Just noticed on the latest Alpha for RT-AX88U that the OFDMA is now specified or corrected to "DL" only.
I wonder if this is for clarification that it was DL only previously but mislabeled, or some other reason.
If someone on an older (Non-Alpha) build can/would check, I don't -think- it was labeled specific to DL only.
Happy to be corrected if I'm wrong.

Decided to go check on the Professional settings and noticed it was set to Disabled, though I previously had it Enabled.
upload_2020-6-15_13-2-43.png
 
Just noticed on the latest Alpha for RT-AX88U that the OFDMA is now specified or corrected to "DL" only.
I wonder if this is for clarification that it was DL only previously but mislabeled, or some other reason.
If someone on an older (Non-Alpha) build can/would check, I don't -think- it was labeled specific to DL only.
Happy to be corrected if I'm wrong.

Decided to go check on the Professional settings and noticed it was set to Disabled, though I previously had it Enabled.
View attachment 24081

https://github.com/RMerl/asuswrt-merlin.ng/commit/e5da1db648f01b3a3fafed8bec686a52eca235af

webui: hide OFDMA UL/MIMO settings for RT-AX88U and RT-AX56U

These require updated SDKs/GPLs, we currently only have the
one for the RT-AX58U.
 
W.T.F happened with vpn client1 after reboot.........??? Seems a mess with routes. Policy Based routing rule not correspond routes. No other rules than default ones.

Routes
Code:
octopus@RT-AC68U-F2D8:/tmp/home/root# routes
Table 254
default via 158.174.xxx.1 dev eth0
Table 111
0.0.0.0/1 via 10.129.0.1 dev tun13   <<<=== here
128.0.0.0/1 via 10.129.0.1 dev tun13 <<<=== here
default via 10.128.0.1 dev tun11
Table 112
Table 113
0.0.0.0/1 via 10.129.0.1 dev tun13
128.0.0.0/1 via 10.129.0.1 dev tun13
default via 10.129.0.1 dev tun13
Table 114
Table 115

Ip route (seems to be fine)
Code:
octopus@RT-AC68U-F2D8:/tmp/home/root# ip route
185.86.xxx.xxx via 158.174.xxx.1 dev eth0
217.64.xxx.xx via 158.174.xxx.1 dev eth0
158.174.xxx.1 dev eth0  proto kernel  scope link
192.168.14.0/24 via 10.8.40.2 dev tun22
192.168.12.0/24 dev br0  proto kernel  scope link  src 192.168.12.1
10.8.40.0/24 dev tun22  proto kernel  scope link  src 10.8.40.1
158.174.xxx.0/22 dev eth0  proto kernel  scope link  src 158.174.xxx.xx
10.128.0.0/22 dev tun11  proto kernel  scope link  src 10.128.1.20  <<<=== here ok
10.129.0.0/22 dev tun13  proto kernel  scope link  src 10.129.1.10  <<<=== here ok
127.0.0.0/8 dev lo  scope link
default via 158.174.xxx.1 dev eth0

Vpnclient1 Policyroutes
Code:
computer-Pc 192.168.12.120 0.0.0.0 VPN
some-bypass 0.0.0.0 213.136.63.73 WAN
Stream-1 192.168.12.144 0.0.0.0 VPN
name-p30 192.168.12.128 0.0.0.0 VPN

Vpnclient3 Policyroutes

Code:
Media-nod-ac56u 192.168.12.146 0.0.0.0 VPN
some-bypass 0.0.0.0 213.136.63.73 WAN
 
Last edited:
webui: hide OFDMA UL/MIMO settings for RT-AX88U and RT-AX56U

These require updated SDKs/GPLs, we currently only have the
one for the RT-AX58U.

Last GPL of ASUS RT-AX88U for firmware 3.0.0.4.384.9107 have it.
 
After twenty four hours on 18-Alpha I reverted to 17.

I could tolerate the perpetual spinning wheel in the VPN server 1, but my IoT devices not appearing in the network map was more annoyance than I wanted to deal with. I could force them to appear for a short period of time with a router reboot or switching the 5 Ghz radio off/on.

If someone wants to see if they can replicate the problem here was my setup:

Router AC86

8 Wifi devices from various manufactures that all can and do connect to the router's 5 Ghz radio.

The guest WiFi was setup as the third 5 Ghz guest network. Only one 5 Ghz guest networks is being used and turned on.

All devices have static IPs assigned by the router and are outside the DHCP pool.

Even though the devices didn't show up in the network map they do show up correctly in the wireless log and all devices have their assigned IPs and were fully functional.

7 of the devices were routed through the WAN and 1 was through a VPN tunnel on VPN client 1.

Other devices connecting to the 5 Ghz radio (non guest ) show up in the network map.

If you test give it some time as the missing devices appear at first then eventually disappear from the network map but continue to function.

Upon reverting to V 17 everything works fine.
 
@CaptainSTX The exact same is happening with my iots on a 2.4 Ghz guest network.Same router Too.
Since I only set up my iots last week i thought it was normal
 
@CaptainSTX The exact same is happening with my iots on a 2.4 Ghz guest network.Same router Too.
Since I only set up my iots last week i thought it was normal

I have no issues with the four IoT devices that connect on 2.4 Ghz guest network. They however do use the first guest network and only one 2.4 Ghz guest network is up and running. I use different SSIDs on the 2.4 Ghz & 5 Ghz radios to keep the IoT devices that can use the 5 Ghz using it.
 
No issues so far with 384.18 alpha. Using Dual Band SmartConnect, roaming assistant and one guest 2.4 for iot. All clients shown on network map.
 
Yep, and no need to reset, just delete cert8.db and key3.db (or cert9.db and key4.db depending of the version) files in AppData\Roaming\Waterfox\Profiles\ and that should do it.

Thanks all for input/feedback on this issue. I don't use firefox at all so not related to this browser.

When I have this issue, I can't connect to the router GUI from any device or browser (chrome, safari, ios safari, ios asus app). I connect via http (not https).

So I will see if it happens again and report back if it does.
 
I could tolerate the perpetual spinning wheel in the VPN server 1,

Works fine here. That issue was fixed back on May 28th, so double check what build you flashed - you most likely flashed an old build.
 
Full factory reset RT-AX88U
I still get same error i get on 384.17

Jun 14 10:43:28 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
I always did dirty flashing since 384.14 but I figured I give this a try and do full Factory reset, reformat my USB, and manually re-setup the router from scratch.

I'd be interested to know how you go.
I hadn't noticed this in rev 17 but I have now seen it in the 18 alpha.
And I'm not able to pair my two ZenWiFi XT8 nodes with 18 alpha or rev 17.

Ian
 
I'd be interested to know how you go.
I hadn't noticed this in rev 17 but I have now seen it in the 18 alpha.
And I'm not able to pair my two ZenWiFi XT8 nodes with 18 alpha or rev 17.

I had started with a factory default reset on the previous alpha, didn't work then.
Perhaps it's a wireless high band setting mismatch between the my Merlin AX88U and the ZenWiFi XT8 needed for initial pairing but, since others are seeing this, it might not be related to the AiMesh at all.
 
Just noticed on the latest Alpha for RT-AX88U that the OFDMA is now specified or corrected to "DL" only.
I wonder if this is for clarification that it was DL only previously but mislabeled, or some other reason.
If someone on an older (Non-Alpha) build can/would check, I don't -think- it was labeled specific to DL only.
Happy to be corrected if I'm wrong.

Decided to go check on the Professional settings and noticed it was set to Disabled, though I previously had it Enabled.
View attachment 24081

Ive enable this also, one thing Ive noticed on my 11 Pro max, its really chewing up my battery...
 

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