[Beta] Asuswrt-Merlin 380.67 Beta is now available

[bluepoint]

Yes, gone through all posts, all mentioned disabled, fixed channel ...
Never before expirienced issues with 5GHz until .67 beta and flashed every beta and final from .65.

Not complaining but just giving feedback.

There were posts that says changing to 40 MHz bandwidth works after experiencing unstable 5GHz band. Have you tried that?

 

[RMerlin]

380.67 Beta 2 has been uploaded. Notable additions is support for FTP TLS, which can be enabled on the FTP configuration page. Also note that due to this, persistent certificates have been moved to /jffs/ssl/ and will be named as follow:

cert.pem and key.pem: webui
ftp.cert and ftp.key: vsftpd

List of changes since Beta 1:

03e93bc sshd: disable the new 20 mins timeout by default as dropbear's keep-alive support seems broken
3b3bf31 nano: Updated to 2.8.5 (closes #1393)
2b1d74d Updated documentation
642258a webui: restart httpd if the persistent https certificate setting was changed
80316dc vsftpd: implement TLS support
db0eebd openssl: make gencert.sh handle either httpd or ftp certs
2132943 httpd: moved stored SSL certs to /jffs/ssl/, as we have other certs to store
72cdf4d openvpn: better handle misconfigurations where we're missing a route_vpn_gateway
514d1b7 openvpn: put redirect-gateway def1 into the custom area if found in an imported ovpn
1ed8353 Updated documentation
b3fa0bd kernel-mips, kernel-sdk7.x: merge GPL 7743 changes to ppp
8c34035 Merge with GPL 7743 binary blobs for RT-AC66U and RT-AC3200 (minus missing wifi driver); updated kludges
60db666 webui: update SSL persistent certificate location in the tooltip
8216384 Merge pull request #1382 from rmk40/master
fd2de3b upnp: external and internal port arguments are swapped in miniupnpd's config file
23ba41b Bumped revision to beta 2
ddc7959 wpa_supplicant: Support for PEAP/MSCHAPv2 via 802.1x

 

[MacG32]

Add "auth no-cache" to your configuration. I don't know yet if it's a bug with OpenVPN or PIA (or could be an OpenVPN bug but PIA hasn't updated yet). That's the solution that PIA came up with when I talked to them about it.

380.67b1: It seems no matter what variables I use in the configuration, when the VPN client times out, it can't re-authenticate. I've opened a support ticket with PIA. We'll see what happens. I'm betting it's a bug/change in OpenVPN though. Testing 380.67b2 now.

 

[Icemanz]

380.67b1: It seems no matter what variables I use in the configuration, when the VPN client times out, it can't re-authenticate. I've opened a support ticket with PIA. We'll see what happens. I'm betting it's a bug/change in OpenVPN though. Testing 380.67b2 now.

Not a big specific to this fw. I've had this PIA > time out > bogus auth fail on reconnect on the xxx.64 versions.

 

[RMerlin]

380.67b1: It seems no matter what variables I use in the configuration, when the VPN client times out, it can't re-authenticate. I've opened a support ticket with PIA. We'll see what happens. I'm betting it's a bug/change in OpenVPN though. Testing 380.67b2 now.

I've had PIA succesfully re-authenticate for over 24 hours here using auth-nocache.

 

[Goran]

I'm trying again but with beta 2.
Testing 5GHz and on trafic analyzer getting some weird graph numbers after few minutes:

 

[Laszlo Ladanyi]

AC87U: slow pppoe wan performance (320/200Mbit) with this beta.
Flashed back latest stable and measured 950 Mbit download/200Mbit upload which is fine.
I did this flash cycle again with same results.
Ps: all were dirty flash without factory reset.

380.67 beta2 also has limited pppoe wan speed. It stucks at ~300-320Mbit/s as beta1.
380.66.6 works fine with 900+ Mbit/s. Something is wrong with beta. I think I'm not alone, because other guys complain about this issue in another forum.
(model: ASUS AC87U)

 

[stambeccuccio]

This is the issue I have been experiencing and described in an earlier post on this thread - post #54 on page 3. There is nothing that will fix it other than setting 5Ghz bandwidth to 40 Mhz. You can not use 80Mhz or 20/40/80 Mhz settings. Factory resets, clearing NVRAM, reloading firmware, doing fresh configurations, etc all have been tried by many people and do not work. Only using 40 Mhz channel widths (regardless of channel number chosen) fixes the issue.

I wish either Asus or Broadcom would acknowledge this fault and hopefully produce a version of firmware that fixes it. The older Asus 3941 code seems to be the only original Asus firmware that has stable 5Ghz WiFi but it is not Merlin code and he doesn't have a version directly based on this code. I know people on the boards have tried Merlin 380.62, 380.63, 380.64, 380.65, and 380.66 and all still have this 5Ghz problem. I too have used all of them to no avail. I have been using 380.67 Alphas and now the 380.67 Beta code and the problem still persists. I have my router on 40Mhz channel width and all is fine as it was with all other previous Merlin builds.

Thanks. Apparently I solved it changing "Control Channel" to channel 36 instead auto.

 

[XIII]

Upgraded from Beta 1 to Beta 2 on my AC66U.

Personally generated SSL certificate and key were overwritten by router ones instead of reused, while "Generate a new certificate" is set to "No".

Is this because of the move to new storage location?

 

[RMerlin]

Upgraded from Beta 1 to Beta 2 on my AC66U.

Personally generated SSL certificate and key were overwritten by router ones instead of reused, while "Generate a new certificate" is set to "No".

Is this because of the move to new storage location?

Yes, new ones were generated as the existing ones aren't moved to the new location.

Sent from my P027 using Tapatalk

 

[JGrana]

AC88U, running Beta 1 - everything good

I do want to say Happy Canada Day Merlin!

 

[deathnite]

380.67 beta2 also has limited pppoe wan speed. It stucks at ~300-320Mbit/s as beta1.
380.66.6 works fine with 900+ Mbit/s. Something is wrong with beta. I think I'm not alone, because other guys complain about this issue in another forum.
(model: ASUS AC87U)

Same here with AC56U and a PPPoE connection, feels like hardware NAT is not working, even though it says CTF is enabled.
This started with 380.67 alpha 3 when GPL code 380_7743 was merged. Flashed back to alpha 2 and speed is back.

Confirmed with ASUS FW. https://www.snbforums.com/threads/asus-rt-ac68u-firmware-version-3-0-0-4-380-7743.39689/#post-330845

This is a huge issue, ASUS should remove 380.7743 until it's fixed.

 

[Theliel]

Thank Erik,

good to view TLS support on FTP, working fine (together with HTTPS cert).

 

[Stuey3D]

Out of curiosity did the 5GHz driver get updated with this release on the RT-AC87U? The reason I ask is that it appears MU-MIMO is now out of beta as it no longer has the disclaimer next to it its just a standard toggle now.

 

[NoSync]

Just confirming that, as several other users experienced, HW acceleration with PPPoE seems to be somewhat broken with the new Asus code. I'm running on gigabit FTTH (RT-AC68U A2 rev) and I usually get around 900 mbit/sec download with Ethernet, whereas with 380.67 I get only 200 mbit/sec. Same with 802.11ac. Upstream is capped at 200 mbit/sec by my provider, and since with both releases I get full bandwidth I can't confirm whether this bug involves upload as well.

Anyhow, t's a problem with the stock firmware, so I guess there's not much to be done except for waiting for it to be fixed upstream.

 

[RMerlin]

Out of curiosity did the 5GHz driver get updated with this release on the RT-AC87U? The reason I ask is that it appears MU-MIMO is now out of beta as it no longer has the disclaimer next to it its just a standard toggle now.

No driver change in a long time for the RT-AC87U.

Asus merely removed the "beta" and "alpha" labels from the webui.

 

[Stuey3D]

No driver change in a long time for the RT-AC87U.

Asus merely removed the "beta" and "alpha" labels from the webui.

Damnit I wish they would update the 5Ghz driver I am having a nightmare with it.

 

[netware5]

Successfully installed 380.67-beta, no issues so far except a minor one with Samba. I decided to enable SMB2 support in the firmware in order to disable SMB1 on my Windows 10 clients. Unfortunately that change resulted in unavailability of the router's samba share. It is not visible if the windows client is configured without SMB1 support. So seems to be that despite I've enabled SMB2 support in the firmware it continues to use SMB1. Returning back the SMB1 support in the windows client makes router's samba share visible again.

 

[john9527]

So seems to be that despite I've enabled SMB2 support in the firmware it continues to use SMB1. Returning back the SMB1 support in the windows client makes router's samba share visible again.

Other way around....windows network discovery depends on SMB1 and won't work if you disable the windows SMB1 client. You can still connect manually with it disabled by specifying the unc name.

 

[Trebuin]

I would love to see the roaming assist in the wifi allow signals as weak as -60dbi. The best we have now is -70 & that causes devices that are literally right next to my extender to reach through two walls & connect to the master router. -60 would kick them off of that.