Release [ 384.19_Alpha Build(s) ] Testing available build(s)

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Are you satisfied with title?

  • Yes

    Votes: 75 93.8%
  • No

    Votes: 5 6.3%

  • Total voters
    80
  • Poll closed .
Status
Not open for further replies.

LimJK

Senior Member
The Auto channel selection on 2.4Ghz & 5GHz seems to be now working with some intelligence of channel selection, relative to the WiFi surroundings.
nzwayne,
Thanks ... after reading your post,
I did Factory reset after flashing this Alpha on my AX88U, I left all my Wireless Settings to Merlin's default values after reset, I only turn off 160MHz as I do not have such devices and I do not want to use DFS channel as I am near large International Airport. I can confirm that leaving Channel Selection to "Auto" works correctly for me now.
 
Last edited:

FTC

Senior Member
Hi, I did test 384.19 alpha1 in my RT-AX88U today. I flashed it and it seemed to work OK. Then I did a full reset - to be sure I could report something reproduceable if anything failed - and redefined all my configuration and, did a configuration save (*) and ... I saw then CPU of the router going crazy.. so I rebooted and up on reboot... httpd hanged at any logon attempt. It did this from any client machine.
So I finally went back to 384.18 final and restored the newly created configuration save (*).. and 384.18 behaves correctly with it.

So the httpd hangs are *not* because of some navigator corruption in the client (happened with any client)
and are *not* because of a configuration corruption in the router... it was all just redefined after a reset, plus 384.18 runs happily with that configuration.
My guess is that there may be some definition or missing / wrong files in the 384.19 http deck of files and resources, that end up generating a loop in some cases loading the main 'network map' page.
 

gerardr

New Around Here
Just did a dirty upgrade on an RT-AX3000 from stock Asus 9354 to RT-AX58U_384.19_alpha1-g4e2197f3d2_cferom_pureubi.w (the 2020-07-06 build). At first, it said I needed to reboot the device manually, but the login page eventually came up. However, /jffs was not mounted then, so I wound up doing an additional reboot. Things came up then and have been running well since then.

Happy to know that my 'script_usbmount' definition works for both stock Asus firmware and AMNG. I'm not doing much fancy in /opt, just a socks proxy via openssh, and a common homepage with lighttpd. I did have to build and put fsck.ext4 and its required libs in /jffs, for the stock firmware, since ext4 is faster and easier to manage from my other systems.
 

bradbort

Senior Member
I've been running this 2nd alpha version on my AX88U. I have about 19 clients on it, ranging from 2.4 to 5 and two AX level clients. So far, no issues since I've done a dirty update. Stable. Fast. Fine.
 

Alaska99

Occasional Visitor
It's the best firmware for over 6 months !! I had major problems with updates on the Play Store on my Samsung S10+. Downloads still blocked before completion. Since this firmware all the problems are solved. I also had a laptop with an Intel AX-200 card that the driver constantly crashed. That too is finally settled.
 

Theliel

Regular Contributor
-Since I have my AX58u, finally, its the first build with AiProtection Working, at least blocking sites and Web/Apps Filtering, so perfect. Bidirectional IPS is not tested for now, but probably is working too. In the past builds, AiProtection was completly broken, so... thank Erik.

-QoS is working, but again, Upload limit dont work (adaptative), no matter what limit is imposed.
 

DelBierzo

Occasional Visitor
-Since I have my AX58u, finally, its the first build with AiProtection Working, at least blocking sites and Web/Apps Filtering, so perfect. Bidirectional IPS is not tested for now, but probably is working too. In the past builds, AiProtection was completly broken, so... thank Erik.

-QoS is working, but again, Upload limit dont work (adaptative), no matter what limit is imposed.
Totally agree with you. Everything correct, except the upload limit in the adaptative qos. With this issue resolved, it is a great firmware.
 

Cranium

Occasional Visitor
I am currently running 384.17 on my router (AX58U) and my node(AC3100).

Can I do a dirty install to this alpha version or should I first install 384.18?
 

L&LD

Part of the Furniture
@Cranium whether flashing the .18 final or the .19 Alpha, be ready to do a full reset if needed. Having said that, the Alpha is what I would be running in your shoes. :)
 

Trent Hubbert

Occasional Visitor
I recommend a full reset. Please note that this is an Alpha version. It has been running great for myself and one of the better firm wares so far.
 

Vexira

Part of the Furniture
So my question is does the QoS upload limiting bug affect the ax 88u or is it only on the ax56u?
 

S.claus

Regular Contributor
So my question is does the QoS upload limiting bug affect the ax 88u or is it only on the ax56u?
My AX88U limits both upload and download on the latest alpha
 

RAH-66

Regular Contributor
we wait
384.19 (xx-xxx-2020)
- NEW: Added support for static routes for PPTP/L2TP VPN
clients, on the Static Route page (themiron)
- NEW: Added notification when jffs free space drops
below 3 MB.
- UPDATED: Merged GPL 384_9354 for AX models.
- UPDATED: Merged GPL 384_81992 for mainline models.
- UPDATED: Merged SDK + binary blobs 384_9354 for RT-AX58U.
- UPDATED: Merged SDK + binary blobs 384_9107 for RT_AX88U.
- UPDATED: Merged binary blobs + SDK 384_81981 for RT_AC5300.
- UPDATED: Merged binary blobs + SDK 384_81992 for RT-AC86U.
- UPDATED: Merged bwdpi components from 385_20630 firmware
image for RT-AC68U.
- CHANGED: Improved mechanism for providing an available
mount point for addon API scripters (dave14305)
- CHANGED: Harmonized the various SSL certificate modes with
upstream.
0-None - will be self-generated
1-Imported - lets you upload your own (no longer
self generated unless you don't
upload one)
2-Let's Encrypt (unchanged)
Self-generated cert will be stored to /jffs/cert.tgz,
just like upstream.
- FIXED: Broken French webui on AX models (fixed with
Asus's GPL update)
- FIXED: Chacha20 wasn't prioritized for bcm675x models which
lacked AES acceleration (RT-AX56U and RT-AX58U)
 

brummygit

Senior Member
I've been running the second Alpha build for the RT-AX88U and for the last couple of days I've been having major problems with low speed and high latency. Yesterday my dual-wan was failing over to 4G due to lost pings to 1.1.1.1 but searching social media etc, I couldn't find many reports of major issues anywhere. Up to this point the alpha has been fantastic on my router with it running the best ever.

This morning I re-enabled wifi on my ISP router (I have to run a dual-nat setup due to ISP restrictions) and discovered that I get my expected speeds (45/8) at the ISP router but only 9/1.3 at my Asus. I have been swapping between cake-qos and FlexQoS a few times for testing, and I've also been running dual-wan which has been cutting over last week due to now fixed ISP cable issues so may not be directly related to the alpha, but I wanted to log the issue in case anyone else experiences similar.

Time for a nuclear reset.
 

brummygit

Senior Member
Many LTE operators ban 1.1.1.1 when you try to bypass their dns servers. Try 8.8.8.8, it may work, but it is unlikely.
My ISP doesn't block 1.1.1.1 or 8.8.8.8 but connectivity yesterday was very intermittent. I'm not sure if I've had the perfect storm of a recent fault on my service to my home (fixed in the last couple of days), wider ISP or internet routing issues, and some quirks with my AX88U or just problems with my router but I think a full reset is a good starting point to get back to a known baseline.
 

brummygit

Senior Member
After doing a full reset to defaults in firmware and rebuilding my network today I spotted the following in the syslog

Code:
Jul 14 17:49:29 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
I'm running AiMesh with 2 x AX56U as nodes and have Smart Connect turned on but AX mode disabled.

EDIT: With google I found a tweet by RMerlin saying that this is just a debugging message
 
Last edited:

jsbeddow

Senior Member
Nice find....a preview of the builds that are coming for the rest of the models and what Asus versions they will be based on.
 
Status
Not open for further replies.

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