What's new

[Beta 380] Asuswrt-Merlin 380.69 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

RMerlin

Asuswrt-Merlin dev
Staff member
Asuswrt-Merlin 380.69 Beta is now available for all supported models.

This is a maintenance release for the legacy 380 branch. This branch will only provide minimal bugfixes from now on, as active development has been moved to the 382 branch. Development of the 380 branch will gradually get reduced, until all the actively supported models are migrated to the 382 codebase.

Highlight of changes since 380.68_4:

  • KRACK security fix for the RT-N66U and RT-AC66U. No other models in 380.69 are fixed. RT-AC88U and RT-AC3100 users should run 382.1_2 if they require the fix.
  • Updated odhcp6c, with improved support for some broken ISPs (patch by theMIROn)
  • Updated components: OpenSSL 1.0.2m, libogg 1.3.3, libforbis 1.3.5, tor 0.2.9.14.
  • wget updated to 1.19.2, fixing connectivity issues with some TLS 1.2 servers.
  • Security fixes for Samba backported from upstream (CVE-2017-15275, CVE-2017-12163 and CVE-2017-12150)
  • Fixed an httpd crash when accessing certain webui pages with no Ethernet clients connected
  • Fixes related to OpenVPN client (DNS priority, and rp_filtering settings not surviving a firewall restart)

Please review the changelog for complete details.

While the RT-AC88U and RT-AC3100 have already been transitionned to the 382 codebase, I decided to still provide new builds for these two models, for people who haven't decided to moveto 382 yet. There's no guarantee however I will keep providing 380 builds for these models in the future, as eventually they will be fully transitioned to 382.


Things that need particular testing:

  • OpenVPN clients, especially with Policy Rules enabled.
  • SMB file sharing, to ensure the security backports didn't introduce any new issue

Please keep this thread focused on this particular release.

Downloads are here.
Changelog is here.
 
Known issues:

  • Ethernet Port list not properly shown. Will be fixed in the final release.
 
RT-AC87U 380.69_beta1

Dec 9 12:04:55 miniupnpd[989]: Failed to convert hostname 'fe80::290:a9ff:fe40:f57c' to ip address
Dec 9 12:04:55 miniupnpd[989]: Failed to convert hostname 'fe80::290:a9ff:fe40:f57c' to ip address
Dec 9 12:04:55 miniupnpd[989]: Failed to convert hostname 'fe80::290:a9ff:fe40:f57c' to ip address
Dec 9 12:04:55 miniupnpd[989]: Failed to convert hostname 'fe80::290:a9ff:fe40:f57c' to ip address
Dec 9 12:04:55 miniupnpd[989]: Failed to convert hostname 'fe80::290:a9ff:fe40:f57c' to ip address
Dec 9 12:04:55 miniupnpd[989]: Failed to convert hostname 'fe80::290:a9ff:fe40:f57c' to ip address


This is normal 1000 rows ?
 
Looks more and more like I am going to have to replace my 87 because Asus is pulling an Apple. Forced obsolescence.
 
While the RT-AC88U and RT-AC3100 have already been transitionned to the 382 codebase, I decided to still provide new builds for these two models, for people who haven't decided to moveto 382 yet. There's no guarantee however I will keep providing 380 builds for these models in the future, as eventually they will be fully transitioned to 382.

I, for one, intend to stay with the 380 branch as long as possible. The amount of control that Merlin has to customize this branch exceeds that of the 382 branch, making it superior in several areas. Really glad to have at least one more 380 update for my RT-AC88U, and hope there will be more to come. Thank you!
 
Working fine on RT-AC1900P. VPN client running with no issues.
 
Just uploaded to my RT-AC5300 without any issues. The only issue I have seen so far, is as per Merlin, the Ethernet ports are not displaying.
 
I am seeing this error in my log for my RT-AC5300:
Dec 10 04:50:56 ddns_update: Asus update entry:: return: HTTP/1.1 299 |Invalid IP format| 192.168.1.3^M Date: Sat, 09 Dec 2017 20:50:56 GMT^M Server: Apache^M X-Powered-By: PHP/5.6.30^M Content-Type: text/html; charset=UTF-8^M Cache-Control: proxy-revalidate^M Content-Length: 0^M Connection: close^M ^M
Dec 10 04:50:56 ddns_update: retval= 1, ddns_return_code (,299)
Dec 10 04:50:56 ddns_update: asusddns_update: 1

Any idea's on what it means?
 
Last edited:
In addition while going through the System Log for my RT-AC5300 I also noticed that the events are not being sorted by date, is there any reason for this?
 
I am seeing this error in my log for my RT-AC5300:
Dec 10 04:50:56 ddns_update: Asus update entry:: return: HTTP/1.1 299 |Invalid IP format| 192.168.1.3^M Date: Sat, 09 Dec 2017 20:50:56 GMT^M Server: Apache^M X-Powered-By: PHP/5.6.30^M Content-Type: text/html; charset=UTF-8^M Cache-Control: proxy-revalidate^M Content-Length: 0^M Connection: close^M ^M
Dec 10 04:50:56 ddns_update: retval= 1, ddns_return_code (,299)
Dec 10 04:50:56 ddns_update: asusddns_update: 1

Any idea's on what it means?

Your WAN IP isn't public (192.168.1.3).
In addition while going through the System Log for my RT-AC5300 I also noticed that the events are not being sorted by date, is there any reason for this?

Syslog is a flat file, it's not a database. Therefore, it lists events in the order in which they are added to the logfile, regardless of the date used by the logging application.
 
Your WAN IP isn't public (192.168.1.3).


Syslog is a flat file, it's not a database. Therefore, it lists events in the order in which they are added to the logfile, regardless of the date used by the logging application.
Ok, thanks for the reply
 
Just an update, I am 12 hours into applying the beta to my RT-AC5300 and all still good. Not a single problem with 26 clients connected. Kind of boringly great...Great work Merlin....
 
Hello, RMerlin!
Are You have plans to implement OpenVPN 2.4.4 in 380.69?
Thanx!

Not at this time, as there are no important fixes in 2.4.4, and the 380 branch will only receive critical fixes from now on. Development focus is on the 382 branch.
 
RT-AC68U Bug?

Two concurrent active VPN clients 1 & 2 both with 'Accept DNS Configuration=Exclusive'

Code:
iptables -nvL --line -t nat

Chain PREROUTING (policy ACCEPT 26 packets, 3341 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:1194
2        2   120 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
3        4   184 VSERVER    all  --  *      *       0.0.0.0/0            WAN.xxx.xxx.xxx     
4        1    62 DNSVPN2    udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
5        1    60 DNSVPN2    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
6        1    62 DNSVPN1    udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
7        1    60 DNSVPN1    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53

Chain DNSFILTER (0 references)
num   pkts bytes target     prot opt in     out     source               destination        

Chain DNSVPN1 (2 references)
num   pkts bytes target     prot opt in     out     source               destination        
1        0     0 DNAT       all  --  *      *       172.16.1.1           0.0.0.0/0            to:104.223.91.210

Chain DNSVPN2 (2 references)
num   pkts bytes target     prot opt in     out     source               destination        
1        0     0 DNAT       all  --  *      *       172.16.2.2           0.0.0.0/0            to:100.120.0.1
Add single arbitrary LAN device to use DNSFILTER=OpenDNS
Code:
iptables -nvL --line -t nat

Chain PREROUTING (policy ACCEPT 6 packets, 628 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:1194
2        8   517 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
3        0     0 VSERVER    all  --  *      *       0.0.0.0/0            WAN.xxx.xxx.xxx     
4       11   696 DNSFILTER  udp  --  *      *       10.88.8.0/24         0.0.0.0/0            udp dpt:53
5        0     0 DNSFILTER  tcp  --  *      *       10.88.8.0/24         0.0.0.0/0            tcp dpt:53
6        4   265 DNSVPN2    udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
7        0     0 DNSVPN2    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53

Chain DNSFILTER (2 references)
num   pkts bytes target     prot opt in     out     source               destination        
1        7   431 DNAT       all  --  *      *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX to:208.67.222.222

Chain DNSVPN2 (2 references)
num   pkts bytes target     prot opt in     out     source               destination        
1        0     0 DNAT       all  --  *      *       172.16.2.2           0.0.0.0/0            to:100.120.0.1

and VPN Client 1 table DNSVPN1 has been OBLITERATED ?????
 
I suspect only the currently active VPN client had its firewall rules re-applied after you made the DNSFilter changes. I'll see if I can reproduce it.
 
Looks like the System Status - Ethernet Ports has stop working on 380.69_beta1 on the RT-AC5300

wbVIZ4P.png
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top