[Release] Asuswrt-Merlin 384.11 is available

[Asad Ali]

Okay so I'm getting delay start issues on OpenVPN client, whenever I reboot the router or manually restart the OpenVPN client it takes approximately 5 minutes to connect and before that it just sits there doing nothing ( not even trying to connect )

I've found these lines in the log which might be helpful (Check the timestamps):

Jun 12 04:19:36 rc_service: httpds 885:notify_rc start_vpnclient1
Jun 12 04:19:36 rc_service: waitting "restart_vpnclient1;restart_dnsmasq" via httpds ...   ( Also looks like a typo in the code as well "waitting"
Jun 12 04:19:51 rc_service: skip the event: start_vpnclient1.
Jun 12 04:24:09 kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
Jun 12 04:25:19 ovpn-client1[6155]: OpenVPN 2.4.7 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 18 2019

Checked on two different providers so I dont believe its a service provider issue.

Important Information:
Asus RT-AC86U
Firmware Version:384.11_2
OpenVpn Providers tried: zpn.im and windscribe.com

@RMerlin Your educated insight on this?

 

[Martineau]

Updated ac86 to 11.2 and now vpn server doesn’t route to vpn client anymore. Any idea to fix this please?

Which VPN server/client?

Have you checked that the RPDB rule and iptables nat rule are still in place?

ip rule

iptables --line -t nat -nvL POSTROUTING

 

[RMerlin]

@RMerlin Your educated insight on this?

Pause at boot time is related to a deadlock between WAN coming up in multiple stages with some ISPs (mostly those with VLAN/IPTV), but the wait for NTP to be synced occurring in a too early stage. The issue was first reported a few months ago by a user, but I have never been able to reproduce it here.

384.12 is getting some work done to either reduce the wait period, or move the time-critical service out of the current wan setup loop. This is hard to address since I cannot reproduce the problem here, and the WAN code is a maze.

However failure to restart the client after the router has finished booting is unrelated. Make sure you don't have a script interfering with it, and also that you aren't messing with the clock, preventing the ntpd_ready flag from getting set by the ntpd daemon.

 

[Asad Ali]

However failure to restart the client after the router has finished booting is unrelated. Make sure you don't have a script interfering with it, and also that you aren't messing with the clock, preventing the ntpd_ready flag from getting set by the ntpd daemon.

Okay I did have openVPN up/down scripts and I tried again after disabling them and it seems to fix the issue. Now I need to diagnose what's wrong in the script because I'm using them from last 2+ years and they never gave any issues before.

 

[IT Guy]

Hi

Since updating, my router probes dns.msftncis.com.

Saw a post how to disable it, in old merlin fw. In current firmware I dont see the option on how to do it. Has it not been implemented?

 

[scjr]

Hi

Since updating, my router probes dns.msftncis.com.

Saw a post how to disable it, in old merlin fw. In current firmware I dont see the option on how to do it. Has it not been implemented?

Under Administration - System / Network Monitoring

 

[dave14305]

Hi

Since updating, my router probes dns.msftncis.com.

Saw a post how to disable it, in old merlin fw. In current firmware I dont see the option on how to do it. Has it not been implemented?

See the workaround in this thread to unset the nvram variable: Diversion - the Router Ad-Blocker

 

[John35]

I ran across something when testing DNS over TLS that might be of interest. I had quad9 set as my DNS for TLS. However using a DNS Leak Tester (e.g. http://dnsleak.com/ or https://dnsleaktest.com/ ) I got

• DNS IP: 66.185.124.244
• Hostname: res300.mad.rrdns.pch.net
• ISP: WoodyNet
• Country: United States

(where the 300 could be 100, 200)

As where the DNS queries go to. This initially looked very odd. However it turns out that Quad9 is an anycast DNS, which routes queries to the nearest server. Quad9 uses PCH (Packet Clearing House) to host DNS servers. PCH’s Director is Bill Woodcock aka Woody. So in summary, odd but okay...

 

[Deleted member 62857]

error

 

[RMerlin]

Hi Merlin,

Asus recently released a couple of security updates for the RT-AC87U in May 2019 - Version 3.0.0.4.382.51634

• Fixed DDoS vulnerability.
• - Fixed AiCloud vulnerability. Thanks for Matt Cundari's contribution.
• - Fixed command injection vulnerability. Thanks for S1mba Lu's contribution.
• - Fixed buffer overflow vulnerability. Thanks for Javier Aguinaga's contribution.
• - Fixed CVE-2018-20334
• - Fixed CVE-2018-20336
• - Fixed null pointer issue. Thanks for CodeBreaker of STARLabs’ contribution.
• - Fixed AiCloud buffer overflow vulnerability. Thanks for Resecurity International's contribution.

Would most of these security issues be already fixed in 384.11_2 which I currently use

I don't know since there are no details as to the exact issues that are resolved, so it's possible that some of these might either be already fixed, or not apply to my firmware. However they are certainly included in 384.12, which is based on the latest 384 code (released at the same time as 382_5163x).

 

[RMerlin]

I ran across something when testing DNS over TLS that might be of interest. I had quad9 set as my DNS for TLS. However using a DNS Leak Tester (e.g. http://dnsleak.com/ or https://dnsleaktest.com/ ) I got

• DNS IP: 66.185.124.244
• Hostname: res300.mad.rrdns.pch.net
• ISP: WoodyNet
• Country: United States

(where the 300 could be 100, 200)

As where the DNS queries go to. This initially looked very odd. However it turns out that Quad9 is an anycast DNS, which routes queries to the nearest server. Quad9 uses PCH (Packet Clearing House) to host DNS servers. PCH’s Director is Bill Woodcock aka Woody. So in summary, odd but okay...

pch.net = Quad9.

 

[Deleted member 62857]

error

 

[JohnSmith]

RT-AX88U with V384.11_2 Final has been up for over 23 days straight, and still running strong, with over 30 devices attached, downloads, streaming, etc., all working as expected.

Thanks RMerlin!!

 

[Ditch]

Which VPN server/client?

Have you checked that the RPDB rule and iptables nat rule are still in place?

ip rule

iptables --line -t nat -nvL POSTROUTING

Both OVPN
this is the output

@RT-AC86U-8DB8:/tmp/home/root# ip rule

0:    from all lookup local

10001:    from 192.168.1.116 lookup main

10002:    from 192.168.1.250 lookup main

10003:    from 192.168.1.248 lookup main

10004:    from 192.168.1.126 lookup main

10005:    from 192.168.1.35 lookup main

10006:    from 192.168.1.179 lookup main

10007:    from 192.168.1.232 lookup main

10008:    from 192.168.1.194 lookup main

10009:    from 192.168.1.181 lookup main

10010:    from 192.168.1.176 lookup main

10101:    from 192.168.1.0/24 lookup ovpnc1

10102:    from 10.8.0.0/24 lookup ovpnc1

32766:    from all lookup main

32767:    from all lookup default

@RT-AC86U-8DB8:/tmp/home/root# iptables --line -t nat -nvL POSTROUTING

Chain POSTROUTING (policy ACCEPT 97964 packets, 7449K bytes)

num   pkts bytes target     prot opt in     out     source               destination        

1    97921 9617K MASQUERADE  all  --  *      tun11   192.168.1.0/24       0.0.0.0/0          

2        4   256 MASQUERADE  all  --  *      tun1+   10.8.0.0/24          0.0.0.0/0          

3        0     0 ACCEPT     all  --  *      *       192.168.1.0/24       0.0.0.0/0            policy match dir out pol ipsec

4    58901 3848K PUPNP      all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0          

5    53352 3460K MASQUERADE  all  --  *      ppp0   !213.xx.xx.xx        0.0.0.0/0          

6        0     0 MASQUERADE  all  --  *      eth0   !192.168.0.2          0.0.0.0/0          

7     2803  366K MASQUERADE  all  --  *      br0     192.168.1.0/24       192.168.1.0/24