[Thread-1] [ 386.1_Alpha Build(s) ] Testing available build(s)

[stalker780]

Updated my AX86U and AX58U to today's (13 Nov 20) alpha build.
No problems in upgrading, but after the upgrade, I had no internet to any client, wired or wireless. I could ping any site from the Tools- Network Analysis, I could do nslookup and ping sites from my PC or any other device. None could reach any website.

Rolled back to factory (without a factory reset) and all clients are fully connected.

You need to open WAN tab and set WAN MTU value, perhaps to 1500.

Running this firmware on AX86U for about 2 hours. Looks stable so far.

 

[bbunge]

Dirty upgrade to alpha 3 from alpha 2. No issues so far. Log entries look "normal."

 

[Mutzli]

Updated to alpha 3 and the 5Ghz radio still takes 2-3 minutes before it's functional. This is on channel 44 with 160MHz and Wi-Fi Agile Multiband enabled. Not really complaining, just wondering if that is normal? Once it's up and running I have a connection link speed of 2.4Gb/s which I never had on the 384 versions.

 

[mtlhus]

I can't install entware on ax86u alpha 3. it seems /opt is read only.

 

[Deleted member 22229]

Just installed 386.1 A3, RT-AX58U. Factory reset and reconfigure. So far working good. Thanks Merlin.

 

[JWoo]

Loaded the 386.1 Alpha 3 build on my RT-AX58U (clean install). As with @Mutzli , I also observed that the 5Ghz radio takes 2-3 minutes before it's functional. Some of the 2.4Ghz devices would not connect at all (keep in mind folks that MANY security devices such as doorbells, cameras and light bulbs are primarily 2.4Ghz still). I was exploring what is in the new GUI and while navigating the GUI, the router took a spontaneous restart, a bug which may or may not be reproducible. For now, I went back to 384.17.

 

[Deleted member 22229]

Loaded the 386.1 Alpha 3 build on my RT-AX58U (clean install). As with @Mutzli , I also observed that the 5Ghz radio takes 2-3 minutes before it's functional. Some of the 2.4Ghz devices would not connect at all (keep in mind folks that MANY security devices such as doorbells, cameras and light bulbs are primarily 2.4Ghz still). I was exploring what is in the new GUI and while navigating the GUI, the router took a spontaneous restart, a bug which may or may not be reproducible. For now, I went back to 384.17.

Interesting not noticing any issues here working good at least so far.

 

[John Fitzgerald]

Loaded the 386.1 Alpha 3 build on my RT-AX58U (clean install). As with @Mutzli , I also observed that the 5Ghz radio takes 2-3 minutes before it's functional. Some of the 2.4Ghz devices would not connect at all (keep in mind folks that MANY security devices such as doorbells, cameras and light bulbs are primarily 2.4Ghz still). I was exploring what is in the new GUI and while navigating the GUI, the router took a spontaneous restart, a bug which may or may not be reproducible. For now, I went back to 384.17.

Why are you on 384.17 vs 384.19?

 

[Calkulin]

There are no public indications that Merlin has received any GPL source from Asus newer than 40577. So believe the changelog and Github and assume it’s still based on 40577.

I don't know why I didn't think about just checking the source code in Github, must of been tired but thanks for the suggestion. A bunch of folder descriptions still say 40577, so it does look like it's still using the old code, so I'll skip this new Alpha till new code gets merged in

Loaded the 386.1 Alpha 3 build on my RT-AX58U (clean install). As with @Mutzli , I also observed that the 5Ghz radio takes 2-3 minutes before it's functional. Some of the 2.4Ghz devices would not connect at all (keep in mind folks that MANY security devices such as doorbells, cameras and light bulbs are primarily 2.4Ghz still). I was exploring what is in the new GUI and while navigating the GUI, the router took a spontaneous restart, a bug which may or may not be reproducible. For now, I went back to 384.17.

The waiting for 5GHz to turn on is not new to this firmware, my RT-AX58U has done it since day 1 on stock 384 firmware. I initially thought it was related to the router having 2 chipsets but what Octopus said a few pages back makes sense and explains why I didn't see that behaviour when I had a RT-AX56U, as it only had 80MHz and I set it to use non DFS channels(the RT-AX58U is my first 160MHz router). 40577 code was buggy on my RT-AX58U but 40947 seems to have fixed a bunch of issues I noticed on it, so I've been running the stock beta till Merlin gets around to using that code

Yes, If you use DFS channels it must scan first for radar then turn 5ghz ON.

 

[nzwayne]

Dirty upgrade from Alpha 2 to 3 on RT-AX88U, and also the AiMesh backhauled two RT-AC86U's & RT-AX56U. Logs look calm. The missing tabs of "Unbound, connmon, ntpMerlin, scMerlin" now back on the AddOns tab. Will give it an hour...then the mandatory power off (for at least a few minutes) then on again as final install checkpoint.

 

[lucluke]

Dirty upgrade from 389.19 on RT-AX58U, all looks fine, thanks!

Router crashes and restarts when opening USB applications -> Servers Center.
Using only diversion.
Don't see the speedtest in Adaptive QoS https://www.snbforums.com/threads/t...s-testing-available-build-s.67101/post-631095

 

[Deleted member 22229]

@Merlin Any idea why Asus did not include the speed test for the AX58U ?

 

[JWoo]

Why are you on 384.17 vs 384.19?

384.19 was buggy when I used it. I tried it a long while back, so I'd probably have to reinstall it to remember why I reverted. 384.17 is very stable: meaning no restarts, WIFI connections are stable, functions I use work well. There were others that also experienced issues with 384.19 (and some with 384.18 also) if you search the threads. 386 is the future, so that is where my energy will be.

 

[JWoo]

I don't know why I didn't think about just checking the source code in Github, must of been tired but thanks for the suggestion. A bunch of folder descriptions still say 40577, so it does look like it's still using the old code, so I'll skip this new Alpha till new code gets merged in




The waiting for 5GHz to turn on is not new to this firmware, my RT-AX58U has done it since day 1 on stock 384 firmware. I initially thought it was related to the router having 2 chipsets but what Octopus said a few pages back makes sense and explains why I didn't see that behaviour when I had a RT-AX56U, as it only had 80MHz and I set it to use non DFS channels(the RT-AX58U is my first 160MHz router). 40577 code was buggy on my RT-AX58U but 40947 seems to have fixed a bunch of issues I noticed on it, so I've been running the stock beta till Merlin gets around to using that code

Agree with you. I also tried the 40947 code base as rc-8 and it is much better than 40577. Additionally, Asus appears to have aligned all the routers on the same 40947 code base which in theory should make it easier to maintain SW for all these models.

 

[y-y]

I'm using RT-AC5300 (main) and RT-AC68U (node). Just tried alpha-3 (also tested beta 7 and 8). All three firmwares have the same issue on the RT-AC5300 -- Received the WAN internet IP address, alpha 3 web admin interface showed the internet status was connected (beta 7 and 8 showed the internet was disconnected). WiFi client were able to connect to the internet for a very short period (like a minute) after the router reboot. After that, clients were not able to connect to the internet.

Tried setting WAN MTU to 1500. Still not working.

Any RT-AC5300 testers? Any suggestions? Thanks.

 

[Hawk]

Eric, do these build include trend micro components, I remember they are not included in normal GPL, but asus gave you special method to add it.

 

[L&LD]

@Hawk, yes, they do.

 

[Hawk]

@Hawk, yes, they do.

Thanks for confirming

 

[maghuro]

I have this log message both on alpha2 and 3.
I performed a full reset when upgrading to alpha 3 and the log message still persists

It's appearing every second which is very spammy.

Anyone facing this issue?

 

[RMerlin]

Updated to alpha 3 and the 5Ghz radio still takes 2-3 minutes before it's functional. This is on channel 44 with 160MHz

This is normal. Check the Wireless Log status page, it will tell you it's currently doing DFS scanning.