[Release] Asuswrt-Merlin 380.65 is now available

[Naftali Oziel]

Asuswrt-Merlin 380.65 is now available for all supported models.

This release introduces a number of important changes, which is why it went through a longer development cycle than usual (in addition to the issues involved with testing the GPL 4180 code, which had to be reverted).

• Upgraded to OpenVPN 2.4.0, and implemented support for various new features introduced with this major release. Asuswrt-Merlin fully supports the new GCM ciphers, negotiated ciphers, tls-crypt and more. This probably makes Asuswrt-Merlin one of the first to implement support for it
• Numerous issues related to OpenVPN were resolved.
• Updated Busybox to 1.25.1. This component provides a lot of the tools used by the router's shell environment.
• Other component updates include openssl, tor and nano which were updated to their latest versions.
• Some portions of Asus's 380_4180 GPL were merged. The rest wasn't, due to numerous issues introduced in this GPL release.
• Fix to IPv6 for newer router models, which were using an invalid MAC when requesting for a prefix.
• Various fixes to the Network Services Firewall
• Fixed rendering under Chrome 56
• Many other fixes and changes, please read the changelog for the complete list

Update - March 30th:
380.65_4 was uploaded, fixing two bugs.

   - FIXED: Various LAN/WAN issues with the RT-AC3200 due to
            incorrect GMAC state checks (Asus bug) (patch
            by john9527)
   - FIXED: Some models would sometime randomly fail to start one
            of their wifi radio, possibly due to a hardware design
            issue.  Partly revert the 380.65 changes that removed
            the automatic reboot if one radio was disabled at boot
            time, but reduced the maximum number of reboots to 1.

Update - March 10th:
380.65_2 was uploaded, fixing two CVE security issues and two minor webui bugs.

   - FIXED: CVE-2017-6549 (implemented temporary workaround,
            until a proper fix from Asus)
   - FIXED: CVE-2017-6548 (backport from GPL 7266)
   - FIXED: WOL page fails to load if adding a client with a
            quote in its name.
   - FIXED: Couldn't add a DHCP reservation client if its name
            contained a quote

More info on OpenVPN 2.4.0:

OpenVPN 2.4.0 is a major update over 2.3.x. The new GCM ciphers should in theory be a bit more efficient, by reducing the overhead of individual packets.

The new negotiation protocol (NCP) allow you to specify a list of supported ciphers, and both ends will communicate together to select the best matching cipher. If one of the two ends is still using an older version of OpenVPN, then the 2.4.0 end will fallback to using the former "cipher" parameter. This automatic fallback behaviour can be enabled/disabled through the webui.

Note that having a mixture of 2.3 and 2.4 endpoints, or using the legacy fallback might cause some warnings about inconsistent settings to show in your log, as your server will try to establish whether to use NCP or the old cipher operand. These warnings can safely be ignored.

2.4.0 also adds support for LZ4 compression, which should be more efficient than LZ0. This requires that both ends run 2.4.x.

tls-crypt is a new security layer that will allow OpenVPN to encrypt the content of the TLS control channel, helping in further obfuscating the protocol (potentially allowing it to go through firewalls blocking OpenVPN usage). The encryption is done using a static key, just like static authentication. Use the Static Key field to paste the key, which must be generated by OpenVPN itself (not by OpenSSL/easy-rsa.) Please consult the OpenVPN manual for more information on how to generate your own key.

If you enable server settings that are incompatible with a 2.4.0 client, you will be warned. In general you shouldn't need to re-export a new config file for your older clients provided you do not change your existing configuration.

A few parameters have been deprecated/removed in 2.4.0, so you might need to adjust any existing "custom" settings. Please refer to the OpenVPN manual.

One potential new issue seem to be specific to MIPS models (RT-N66U/RT-AC66U) and their older kernel. Starting with 2.4.0, OpenVPN expects the tun interface to support IPv6. That doesn't seem the case on this older kernel, so VPN servers that push back an ifconfig-ipv6 or route-ipv6 parameters might fail to connect. I haven't been able to test it myself (as I don't have a tunnel provider account), but I'd suggest trying to add these to your custom configuration if your client fail to connect with thhe system log reporting a failure on an "ip -6" command:

pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"

This is another sign that it might be time to retire these older models...


As usual, please try to keep posts in this thread specifically to this version. I strongly suggest starting a new thread if you have a configuration question.

Downloads are here.
Changelog is here.

Running the 380.65_4 AP mode AC68U. Noticed the following error messages in my log, below. Do you know what this means?

May 4 19:28:53 ots[440]: Error Packets: 3 0 0

 

[RMerlin]

Running the 380.65_4 AP mode AC68U. Noticed the following error messages in my log, below. Do you know what this means?

May 4 19:28:53 ots[440]: Error Packets: 3 0 0

I believe OTS is tied to WPS/EZSetup. Could be an invalid attempt at connecting a client with your router.

 

[Naftali Oziel]

I believe OTS is tied to WPS/EZSetup. Could be an invalid attempt at connecting a client with your router.

Thank you

 

[Nigel Jones]

@RMerlin - in an earlier post you mentioned the RT-3200 uses an earlier version of the SDK than 7114 - I searched after seeing the release notes on the RT-3200 build.
Do you think this is likely to continue with asus moving forward? Do you think it implies asus may not support the 3200 as well moving forward? Or that it would be more difficult for you to do so?
Or is it just likely a point in time thing

Interested in your views
(Why? I don't need 5 Ghz-2, still in 30 day return window to switch to AC-68u)

 

[RMerlin]

Do you think this is likely to continue with asus moving forward?

Asus does not tend to upgrade SDKs for specific models, unless there's a very good reason for it. So don't expect the RT-AC3200 to be moved to SDK7114, or they would have done so by now.

No idea how well or for now long Asus will support this model.

 

[zamar29]

Security related question. As known, all routers out of the box with factory firmware come with default login & password to Web UI (like admin & admin or such), and also factory login & password (for law enforcement, service, or provider login, at times stored on a separate chip) for UI, Telnet, SSH connections etc. These "factory passwords" for some routers and modems are found on the web, and at times abused.

Question is, whether Merlin FW blocks or erases these factory passwords, so if a user changes default login & password, it won't be possible to use "secret factory login" to remotely login into the router via a bridged modem or directly from the web using router Web UI, telnet, SSH or other methods?

 

[joegreat]

1) First there is no default login/PW on Asus routers - since very long time! After a factory reset you enter your private login and PW.

2) Why you post into the thread of the old firmware version with a question NOT related to this version? Please open a new thread with such general questions!

 

[zamar29]

@joegreat

The reason I posted the question here was explained in it: to find out if Merlin FW (including this version) is different from factory firmware when it comes to "back doors" mandated by US legislation for network devices approved for sale in the US. Do you know the answer? If "yes", and you can reference it with some source, pls share instead of giving unrelated instructions. Note, there is a big difference btw "default login" and "back door login".

 

[ColinTaylor]

is different from factory firmware when it comes to "back doors" mandated by US legislation for network devices approved for sale in the US.

I don't believe there is any current US legislation that mandates back doors. In fact I thought recent US senate committees discussed this and despite the desire of the NSA and FBI they have not approved such things. Can you provide links to support your statement.

 

[RMerlin]

There are no backdoors, period. The only password the router accepts is the one you configured. The only way to revert back to the original default password is to do a factory default reset, which erases your entire configuration.

 

[zamar29]

Can you provide links to support your statement.

You marked UK as your location, but claim to know a lot about US laws and "debates", while they are not the same thing. All info is on the web, a few random links for your further research: Act (more), CMTS, Arris, How to, Data, go on... As reported in media, the problems arise when such techniques and backdoor passwords are commonly leaked to web, and then used by criminals and on commercial and private info market.

As to router backdoors - huge variety, including ASUS, and more: "The post describes how to install a backdoor in the expansion ROM of a PCI card (or any board), which during the boot process patches the BIOS to patch grub to patch the kernel to give the controller remote root access."

I wonder, if its possible to add Intrusion Detection feature to Merlin Firewall?

 

[ColinTaylor]

You marked UK as your location, but claim to know a lot about US laws and "debates", while they are not the same thing. All info is on the web, a few random links for your further research: Act (more), CMTS, Arris, How to, Data, go on... As reported in media, the problems arise when such techniques and backdoor passwords are commonly leaked to web, and then used by criminals and on commercial and private info market.

I didn't claim "know a lot" about US Laws, merely that it was my understanding. Even though I'm in the UK I still read what's happening in the US as it has a knock-on effect for the rest of the world, hence my request for more information.

The links you provided don't show any evidence of backdoor user accounts being mandated for home network equipment (like routers). Your first link is to the old wire-tapping law. That law applies to telecoms providers, their equipment and the state's ability to "intercept" the traffic. The CMTS document is well known and again applies to service providers and traffic interception. The other links you provided refer to the government's desire/ability to hack into consumer devices. If there were already government backdoors in these devices they wouldn't need to hack them.

So at the moment I'm still not aware of any legal requirement for Asus, Netgear, etc. to provide a secret "government-only" user account in their products.

 

[zamar29]

If that gives you piece of mind - I'm happy for you.

 

[ColinTaylor]

If that gives you piece of mind - I'm happy for you.

Well I hope your mind has been put at rest also. As Merlin said, "There are no backdoors, period.".

 

[zamar29]

Not really, the developer may not know that with regards to all board chipsets and the default bootloader, even less about existing vulnerabilities. Did you read my entire above post, or only half?

I don't suspect RMerlin in anything along these lines for sure, and greatly appreciate his interest and long dedication to the subject. That's why I kindly ask him to add basic Intrusion Detection system to Merlin Firewall.

 

[RMerlin]

As to router backdoors - huge variety, including ASUS, and more:

That's not a backdoor and it has nothing to do with the NSA or the FBI. Infosvr is used during manufacturing to test and configure routers (that's why they ship with different MACs, different regions, etc...). There was a bug in infosvr where the authentication scheme wasn't working as intended. That issue has been fixed three years ago.

 

[RMerlin]

That's why I kindly ask him to add basic Intrusion Detection system to Merlin Firewall.

If the router is the device you mistrust, then adding IDS to the router itself would be pointless, as it would be easily bypassed. The IDS would have to be run on a separate device.

 

[amplatfus]

Another possibility (I can't test it) as a temporary fix for the AC3200 on 65_2.....

nvram set stop_gmac3=1
nvram commit

then reboot

Testing now, haven't seen any bad ARP requests over the last hour and ICMP to the router now appears stable (after connecting/disconnecting multiple wifi devices). Will continue to check for the next 24 hours.

Just to confirm, the workaround appears to have fixed the issue ICMP connectivity to the AP has been solid and there have been no more bad ARP entries logged by pfSense (on the 65_2 release).

Hi,

Could you please share what is influence in performance and in product lifetime or any other details for this command, as a permanent fix for blocking the access to router GUI like here:
https://www.snbforums.com/threads/option-to-disable-wirless-login.47786/page-3#post-418812

nvram set stop_gmac3=1

Or somebody else could tell, I will appreciate. Thank you in advance!

BR

 

[john9527]

Could you please share what is influence in performance and in product lifetime or any other details for this command

Sorry, but nobody knows. Most of the effect is buried in closed source code and proprietary hardware specs.
IIRC the original workaround you referenced was based on a code bug where the firmware was incorrectly setting a mac address to null that was input to gmac3.

What I can see is that gmac3 changes the internal switch configuration and CPU communication port/VLAN definitions. My best guess would be that it's at least part of performance optimization, but where and how a potential performance bottleneck would show up is anybody's guess.

 

[RMerlin]

From what I've been told, gmac3 allows wifi traffic to bypass something at the networking stack level (not unlike how CTF works with NAT traffic) to reduce CPU usage when routing wifi traffic to the rest of the network.