Beta Asuswrt-Merlin 386.1 Beta (stage 2) is now available

[ugandy]

on my ax88 and with a 1Gb connection i get about 850 on the router. but i have qos/trend micro off
on my PC with an intel ax200 card i get close to 850 too
the att gateway is reporting about 900
sym·met·ri·cal

 

[beerglass007]

I've now RMA my router and will stay off the beta when it comes back. Real shame but cant risk it again but thanks for all the work going on with this ....great work

I'll be back when things progress

Thanks again everyone and Eric

 

[AntonK]

If you are using the router speed test feature, I would take the result with a grain of salt. While its cool to have the speed test, these routers don't alway have the HP to fully assess internet speeds. With my AC86U at low CPU usage and a gigabit internet connection, if I run the b4b built-in speed test, I get about 580 mbps. If I run the Ookla speedtest app from my wired desktop, I get the usual 930 mbps. And that's on an AC86U which is among the more powerful AC ASUS routers.

For those who think they are having internet speed issues with b4b, I'd be curious to see what results they get with a wired computer running the Ookla app and not using a web browser (which is also unable to show full speed on higher bandwidth connections).

Here are screen caps of my tests: One from my router's speed test, and the other from my Ookla desktop app (Win10). My ISP is Comcast Cable, 200/5 (provisioned slightly higher than that at 230/6)

 

[maxbraketorque]

@Merlin, there is some wierdness happening with OVPN. For a site-to-site bi-dir setup between two AC86Us with the server running 384.19 and the client running 386.1.b4b, I am getting the following three warnings that I did not have before updating the client to 386.1.b4b.

Jan 15 23:51:23 ovpn-server1[10467]: ... WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1549', remote='link-mtu 1541'
Jan 15 23:51:23 ovpn-server1[10467]: ... WARNING: 'cipher' is present in local config but missing in remote config, local='cipher AES-128-GCM'
Jan 15 23:51:23 ovpn-server1[10467]: ... WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA1'

I have no idea why the link-mtu values are not the same, I have nothing in my configs about MTU settings. I have verified this by ssh'ing into the routers and reviewing the config files installed on the routers in /etc/openvpn.

I also have no idea what the auth values are inconsistent. Both the server and the client are set to use SHA1, and I have verified this in the config files.

I kind of have some understanding of the cipher issue. If I enable ncp with fallback on the server, I get the error I show above. However, if I disable fallback to get rid of the "cipher" warning, then the server and client both complain about using an insecure cipher and the link will not complete.

What is especially odd about this situation is that I have another site-to-site setup using the same client running 386.1.b4b, but the server is an AC68U running 384.19, and for that setup with identical configurations, I am getting none of these warnings.

 

[clvk07]

running 386.1 b4 on AX86U, with QOS enabled I get full speeds (500/50) with my old AC86U used to get 300/50. Is because AX86U is more powerful or because QOS is not fully implemented in the beta?

 

[Calkulin]

Anyone else notice Roaming Block List doesn't work anymore? I have clients that are on that list and still connect to the node and I didn't notice that behaviour on 384 firmwares. I'm sure it's something Asus needs to fix but I'm wondering if anyone noticed it also.

Also @RMerlin, in the wireless log page, most clients display the custom name I entered for them but some display the original name for some reason. Not sure if that is a bug or not in your code or Asus's being that page is custom to your firmware but I have noticed that for a while now and even in the 384 firmwares if I remember correctly.

 

[RMerlin]

Also @RMerlin, in the wireless log page, most clients display the custom name I entered for them but some display the original name for some reason. Not sure if that is a bug or not in your code or Asus's being that page is custom to your firmware but I have noticed that for a while now and even in the 384 firmwares if I remember correctly.

The Wireless Log page shows the actual hostname, not whatever label you might define on the Network Map.

 

[RMerlin]

@Merlin, there is some wierdness happening with OVPN. For a site-to-site bi-dir setup between two AC86Us with the server running 384.19 and the client running 386.1.b4b, I am getting the following three warnings that I did not have before updating the client to 386.1.b4b.

This is a configuration/OpenVPN issue, which has nothing to do with the firmware. As the log indicates, the negotiated parameters don't all match what is actually present in the config files, hence the warnings.

 

[MNoisy]

After upgrade Instant Guard seems to be having issues. Log shows

Jan 16 12:38:40 00[DMN] Starting IKE charon daemon (strongSwan 5.7.2, Linux 2.6.36.4brcmarm, armv7l) Jan 16 12:38:40 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts' Jan 16 12:38:40 00[LIB] file coded in unknown format, discarded Jan 16 12:38:40 00[LIB] building CRED_CERTIFICATE - X509 failed, tried 4 builders Jan 16 12:38:40 00[CFG] loading ca certificate from '/etc/ipsec.d/cacerts/asusCert.pem' failed Jan 16 12:38:40 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts' Jan 16 12:38:40 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts' Jan 16 12:38:40 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts' Jan 16 12:38:40 00[CFG] loading crls from '/etc/ipsec.d/crls' Jan 16 12:38:40 00[CFG] loading secrets from '/etc/ipsec.secrets' Jan 16 12:38:40 00[LIB] loaded plugins: charon aes des rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf curve25519 agent xcbc cmac hmac attr kernel-netlink resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-tls eap-peap xauth-generic counters Jan 16 12:38:40 00[JOB] spawning 8 worker threads Jan 16 12:38:40 06[CFG] received stroke: add connection 'Host-to-Netv2' Jan 16 12:38:40 06[CFG] adding virtual IP address pool 10.10.10.0/24 Jan 16 12:38:40 06[LIB] file coded in unknown format, discarded Jan 16 12:38:40 06[LIB] building CRED_CERTIFICATE - ANY failed, tried 1 builders Jan 16 12:38:40 06[CFG] loading certificate from 'svrCert.pem' failed Jan 16 12:38:40 06[CFG] added configuration 'Host-to-Netv2'

 

[maxbraketorque]

This is a configuration/OpenVPN issue, which has nothing to do with the firmware. As the log indicates, the negotiated parameters don't all match what is actually present in the config files, hence the warnings.

The exact same config files didn't cause these warnings before moving the client to 386.1.b4b, so perhaps there is something different about the new version of OVPN in b4b. Or maybe something to do with how you implement OVPN? I did manage to excise all the warnings just a few minutes ago by tinkering with the configurations. I had to make the following changes:

Server side
- Cipher Negotiation: Enable with Fallback. Set fallback to "AES-128-GCM". This was the same as before except that I previously had the Fallback set to "AES-128-CBC".

Client side
- I manually added "cipher AES-128-GCM" to the config.

Everything else in the configs was set the same as before. It seems that there is some sort of mismatch associated with the initial attempt at cipher selection between OVPN 2.4.9 on the server side and OVPN 2.5.0 on the client side. I would update the server to 386.1.b4b, but I don't want to attempt a remote update with no one around to manually reboot it if needed. I guess I'm wondering whether there is something about how you implement OVPN that could cause this too.

 

[Gifyku]

Is there any known issue with dnsmasq.conf.add in beta 4? i did a factory restore to make sure but none of my entries seem to be taking hold. Neither did my x3mrouting attempts. To be fair, first time I am trying x3mrouting but I have been using dnsmasq.conf.add regularly on 384 (i moved from 384 because my chromecast devices would frequently disappear from the network)

 

[Lotta Cox]

Still LOVING 384.19b2!
Would have been about 120 days, except I rebooted the router UN-necessarily during an area cable outage 63 days ago.

​

Uptime	63 days 21 hour(s) 48 minute(s) 35 seconds
Temperatures	2.4 GHz: 52°C - 5 GHz: 57°C - CPU: 71°C

 

[FeRReTTi]

@RMerlin, I'm on beta 4 on my AC5300, any idea how to fix this? Also did WTFast get removed? I can't find the gaming section anymore. Btw, the reception stat is correct, but obviously the transmission one isn't haha. (Reception = the new COD lol) It gave proper stats for both transmission and reception in beta 2 so I'm wondering what changed. The other spike was from beta 1 btw,

 

[cvee]

Who knows how to interpret router logs.
I have an issue (that i don't think is specific to the latest beta software) where RANDOMLY my primary router 5300 will drop all wifi connections.
On the front of the router.. ALL white led's are lit solid except for the internet light which flashes.

I've had to power cycle my router 3 times today.
Sometimes it'll only happen once a day.

Been happening MORE since i started using AIMESH.
Previous to AIMESH (which is only recent - running it for 7 days) i used to run the 68U in media bridge mode... and the hangs would only happen 2-3 times a week.

Anyone else seeing issues like that?

I stand corrected.
I decided to go back to Beta 3.... and the primary router 5300 and has been better. No manual reboots required as yet.
So NOT sure what's different... but i'll stay on Beta 3 for now until next update is released.
The aimesh node router is still on Beta 4 and running fine.

 

[Calkulin]

The Wireless Log page shows the actual hostname, not whatever label you might define on the Network Map.

That's weird, almost everything listed in this screenshot of my wireless log page is a custom name with the exception of the HS200 and the MyQ. Some of those originally were named HS220 and some were HS200s but most are showing my custom name now, only a few are showing the original name.

Maybe it's because there were multiple with the same name and only 1 shows the original name and the rest the custom? Even my TVs are like that, 1 shows the original and 1 the custom but both had the same original name,

 

[Psu2ski32]

Power dropped out for roughly 5 seconds and now seem to be having a problem with WiFi on AC5300 running 386 beta4. Tried resetting twice. Any thoughts? Doubt it’s beta4 related but figured I’d pool the experts here.

 

[SubElement]

Okay, so after a few days of stability with no amtm scripts enabled, I replaced the SSD I was using and setup the scripts again. A little over 12 hours later and my router has already crashed and restarted.

So pretty sure it's not the drive, but one of the scripts or even just having any script enabled. This is on an RT-AX86U with Beta 4. I know there are plenty of others with the same router and firmware with no issues, so I have to wonder what is different on my end. Some regional difference in hardware? Some other way I've setup my router?

 

[geoleonsh]

when will you finish the final 386.1 version?

 

[roboots21]

when will you finish the final 386.1 version?

... When it's ready. It's not the best practice to ask for an ETA for something that someone is doing for the community as a free service. When it's ready for primetime, the final release it'll be out.

 

[agfac]

I've installed beta 4b on my ax88u (with factory reset after). I've installed diversion, skynet and scribe also. But now I'm noticing some weird behaviors: sometimes some URLs take a lot to be opened (about ~10 seconds) and sometimes not (sometimes it works normally). Sometimes also accessing the webgui delays. Besides, sometimes also accessing through SSH delays (about 10 seconds to get the prompt). Some minutes ago, I called 'Diversion' through SSH and it took about 10s to open but now it's working normally (the response is instantaneous).