[384.18_Alpha Builds] Testing all variants

[MDM]

@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.

 

[neil0311]

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.

 

[tarzan2000]

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)

 

[mbze430]

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

 

[ShelaMonster]

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.

 

[Adamm]

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.

 

[ShelaMonster]

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

Thanks Adamm!
At least now I know I'm not imagining things.

 

[octopus]

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

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)

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

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

Media-nod-ac56u 192.168.12.146 0.0.0.0 VPN
some-bypass 0.0.0.0 213.136.63.73 WAN

 

[RAH-66]

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.

 

[CaptainSTX]

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.

 

[faria]

@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]

@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.

 

[bbunge]

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.

 

[skeal]

@RMerlin Open Nat is available in AP mode. Should it be? On my AC68U it is, using this latest alpha.

So no word on this yet?

 

[jata]

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.

 

[RMerlin]

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.

 

[RMerlin]

So no word on this yet?

I'm still at the alpha stage of merging new Asus GPLs, not at the point of debugging new bugs they might have introduced in these new GPLs.

 

[raven-au]

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

 

[raven-au]

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.

 

[New2This]

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...