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

[Smokey613]

I am staying with 384.19 for now. It is very stable and just works.

 

[raven-au]

Loaded alpha3 with factory reset.
Without any other configuration changes started adding my reserved IPs.

Added them all (about 43) and hit apply to be met with an empty list on return.
Started adding them again applying after every few addresses and noticed the host name setting wasn't saved.
Continued and after entering around 30 the apply hung the router.
Powered off and back on to be met with an empty list.

I can't use the build if I can't define my reserved IPs.

 

[raven-au]

Loaded alpha3 with factory reset.
Without any other configuration changes started adding my reserved IPs.

This is on my AX88U.

 

[paul0363]

This is on my AX88U.

Can't replicate this on my RT-AX88U. I've got 24 reserved IP's and they all "stuck" with no problems (including specifying a DNS server on three). Running 386.1-alpha3.

 

[uwish]

Running the new 386 A3 code on all my devices. So far so good, including the AX86U...

 

[bbunge]

AC68U AiMesh testing with alpha 3
Flashed the alpha 3 over Asus 386-40453. Noted the /jffs was not mounted. Factory reset via WPS button and tried to add to AiMesh with my AC86U. Was able to add to mesh over Ethernet. Reset AC68U again and tried to butt to mesh over WIFI, failed. Set up AC68U minimally and set /jffs to format at next boot then rebooted. Logged in and reset to factory without initializing all settings. Add mesh node over WIFI worked this time. Logged into node via SSH and the /jffs was active. Was even able to start AMTM on the node. Mesh node seems stable.
Can the /jffs issue be fixed?

 

[nanochip]

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.

The two 160 MHz channels in the 5Ghz band use DFS. The lower 160 MHz channel use channels 36-64, but channels 52-64 are DFS. The upper 160 MHz channel uses channels 100-128, all of which are DFS. Channels 120-128 are the weather band, and you’re likely gonna get kicked out due to radar detection, if the router is close enough to weather radar.

Per FCC and other regulations around the world, routers in DFS mode must sense the medium for at least 60 seconds for radar before they can transmit. This, delay, unfortunately, is normal. 6GHz (Wi-Fi 6E) operation should change this, I hope.

 

[octopus]

Can the /jffs issue be fixed?

Please respect this:

This is a new model, support is still being gradually implemented, it's a work-in-progress.
Early development, I have not uniformized build profiles yet.

Folks, I cannot stress this enough. These are ALPHA builds. That means work in progress, a lot of things are still being actively implemented. So yes, expect things to not be done yet, this is normal. Until it reaches official beta stage, expect things to NOT fully be implemented yet.

 

[bbunge]

Please respect this:

I was not pushing but simply asking a question. Actually, the wife needed me to do something for her and I hurriedly finished the post. Just failed to choose better words.
I really do know the foibles of "new" software having been doing testing and documentation since the days of DOS and WIndows 3.1. And before the days when a firewall was necessary. Yup, really "Old Dog"

 

[octopus]

I was not pushing but simply asking a question. Actually, the wife needed me to do something for her and I hurriedly finished the post. Just failed to choose better words.
I really do know the foibles of "new" software having been doing testing and documentation since the days of DOS and WIndows 3.1. And before the days when a firewall was necessary. Yup, really "Old Dog"

If you have read chagelog you should know.

384.19 (14-Aug-2020)
- NOTE: Due to flash partitioning changes done by Asus, it is
strongly recommended to make a backup of your JFFS
partition before upgrading the RT-AC86U, and restoring
that backup afterward. If you run into issues,
reformat your JFFS partition and reboot.

 

[rlj2]

The aimesh 2.0 stuff sure seems great (working good here so far). I cant believe how screwed up my aimesh stuff was until I was able to look at it all. nodes connecting to a node 50' past the main router, clients refusing to connect to a router 5' from it and barely connecting to one 150' away...
Being able to bind all that seems to have made a huge difference in some clients.

 

[Deleted member 22229]

If you have read chagelog you should know.

Problem is it's misleading. It's not just the AC86 that's effected its possibly all the models. I know for sure my AC3100 and AX58U always shows unmounted after updating. Reformatting is required.

 

[octopus]

Problem is it's misleading. It's not just the AC86 that's effected its possibly all the models. I know for sure my AC3100 and AX58U always shows unmounted after updating. Reformatting is required.

Yes probably since all fw grows and can take /jffs space.

 

[bbunge]

If you have read chagelog you should know.

384.19 (14-Aug-2020)
- NOTE: Due to flash partitioning changes done by Asus, it is
strongly recommended to make a backup of your JFFS
partition before upgrading the RT-AC86U, and restoring
that backup afterward. If you run into issues,
reformat your JFFS partition and reboot.

Ah yes, but if you would have read I was referring to an AC68U.

 

[octopus]

Ah yes, but if you would have read I was referring to an AC68U.

Ok, my bad. Looked at your signature.
I remember when I switched to 386 I have to reset and format /jffs because I run into all kind of trouble. Working fine after that.

 

[swejuggalo]

I havn't tested everything yet... But up an running on AX88 with Skynet with a3.
Asus probably broke auto channel feature again though. 5Ghz acting strange with it on. So back on manual channels.

 

[heysoundude]

Went from latest stable to alpha 3 on my two RT-AC68U. Cleared NVRAM on both after flash and rebooted a 2nd time on both so JFFS would mount. Set up AiMesh with ethernet backhaul without any problems.

QoS seems broken - using Adaptive QoS sites won't load all the way, or if they do they take forever. Traditional QoS also seems to be poorly performing, with Core 1 hitting 99% load and only able to get 200mbps on speed test (normally my connection tops out at 360mbps). With QoS off I get my 360mbps (though core 1 still shows 99% usage). This is on wired connection -> aimesh node -> wired backhaul -> main router -> cable modem. Only other setting I changed is using my own DNS servers and enabling DNS over TLS.

Edit: QoS issue doesn't seem to be present in the latest ASUS AiMesh2 RC firmware. Then again, it's not quite an Apples to Apples comparison. On the firmware from ASUS, the version number seems higher and there are no DNS over TLS options for me to turn on.

allow me to introduce you to Cake-QoS

 

[Wallace_n_Gromit]

...
I really do know the foibles of "new" software having been doing testing and documentation since the days of DOS and WIndows 3.1. And before the days when a firewall was necessary. Yup, really "Old Dog"

Do you remember the days (around 1999ish) when Zone Labs developed a Internet Activity Monitor which became the first software firewall ZoneAlarm. I remember following that development at grc.com. Used it for years. Those were simpler times.

 

[Linux_Chemist]

Do you remember the days (around 1999ish) when Zone Labs developed a Internet Activity Monitor which became the first software firewall ZoneAlarm. I remember following that development at grc.com. Used it for years. Those were simpler times.

Shieldsup! Too right!

 

[dragon31337]

Updated to alpha 3 my 88u and there are a few issues:
In logs I see constant
kernel: TCP: time wait bucket table overflow
1 CPU core is on high load and there are no WIFI clients reported on the network map.