[Release] Asuswrt-Merlin 384.18 and 384.13_10 is now available

[FLA_NL]

On my 86U the openVPN seems to freeze showing this message:

Initialinzing the settings of OpenVPN server now, please wait a few minutes to let the server to setup completed before VPN clients establish the connection.

This message does not go away unless I reboot my router.

If you still can connect with the vpn server then it is probably the same issue than in this thread:
https://www.snbforums.com/index.php?posts/595052

 

[prosperot]

If you still can connect with the vpn server then it is probably the same issue than in this thread:
https://www.snbforums.com/index.php?posts/595052

Yes it is. Thanks for putting me on track to that thread. Obviously a bug that isn't solved in the .18 final .. Coming from Asus stock, where I did not have this issue, I guess it is something in the Merlin implementation of open VPN?

 

[Wadadli]

Same old...
This morning I received the following in the logs:

Jul 10 07:55:50 kernel: eth0 (Int switch port: 3) (Logical Port: 3) (phyId: c) Link DOWN.
Jul 10 07:55:52 WAN_Connection: ISP's DHCP did not function properly.
Jul 10 07:55:57 WAN_Connection: Ethernet link down.

I was unable to get on the internet, even though the internet LED was flashing white. This told me that the hardware was ok. (the flashing is arp traffic from my isp)
The firmware thought for some reason that the link was down when in reality the hardware connection was ok.
RT-AX88U / asus-merlin-384-18

 

[Mike S]

Yesterday, I upgraded my RT-AC88U from 384.17 to 384.18. Everything seemed to work fine. My router is configured to automatically reboot every morning at 3AM, which it apparently did this morning.

However, after the reboot, it ran into an error connecting to an OpenVPN server on another Asus router at a remote location. The router also wouldn't accept an incoming OpenVPN from a 3rd Asus router.

I managed to connect to the RT-AC88U's GUI remotely, and discovered some very strange stuff in the log file immediately after the auto reboot this morning (I have attached the log file). I then rebooted the router, and everything started working fine.

Any ideas on what is going on? Note: This is the same router that I have been having issues with the GUI not being visible while running 384.17 (see https://www.snbforums.com/threads/cant-login-to-gui.64631/page-2#post-601272)

 

[FLA_NL]

Yes it is. Thanks for putting me on track to that thread. Obviously a bug that isn't solved in the .18 final .. Coming from Asus stock, where I did not have this issue, I guess it is something in the Merlin implementation of open VPN?

Merlin firmware probably has a newer version of OpenVPN then in the stock firmware.

 

[gattaca]

Which ASUS router would you recommend to substitute the RT-AC87U in terms of capabilities and size (and important parameter for me)?

I agree -> keep it until you have a good performance, support or cost $ reason to update. Today, if I were buying a new front-door router: RT-AC86U or RT-AX88U (more cpus) I think those are the top recommendations around here.

I do not understand ASUS's "GT-xxx" gaming routers, so someone else will have to chime in there. Seem like there's a bit of flash/shine/polish on those which are upsales.

 

[CW1]

I cannot agree at all.

I have been using my RT-AC87U from more than 5 years ago and I am totally happy with it. I have had no problems at all with the family using it 24/7, and with RMerlin firmware it has been even better (by the way, this model has a lot of dowloads of his firmware).

Anyway, I agree with grifo that I expected to have from ASUS, at least, a similar support to the older and cheaper AC68U ...

My intention is to use it until it dies ...

I'm likely going to do the same. My 87U was a replacement from Asus for a RT-AC68W that went bad under warranty. That was 3 years ago, and this 87U has been rock solid running Asus-Merlin FW.

 

[Xentrk]

DoT does not work on my RT-AC88U. Unable to resolve host names. I tried cloudflare, quad9 and google DoT servers from the list. I had the same issue in 384.17. I may do a factory reset to debug as the system log messages have not provided any clues as to what could be the cause. But wanted to first check with other RT-AC88U owners to confirm it is working for them.

 

[MysticGold04]

After 8+ days of uptime on beta1, I updated to 384.18. Been up 30 min so far, no issues. Thanks @RMerlin!!

Update: 7+ days of steady uptime. This is a great release, @RMerlin - Thank you !!!

 

[AntonK]

DoT does not work on my RT-AC88U. I tried cloudflare, quad9 and google DoT servers from the list. I had the same issue in 384.17. I may do a factory reset to debug as the system log messages have not provided any clues as to what could be the cause. But wanted to first check with other RT-AC88U owners to confirm it is working for them.

What do you mean, it "doesn't work"? I've been using DoT with the DNS servers you name for months, if not a year or more without issue. How could it not work?

 

[dave14305]

DoT does not work on my RT-AC88U. I tried cloudflare, quad9 and google DoT servers from the list. I had the same issue in 384.17. I may do a factory reset to debug as the system log messages have not provided any clues as to what could be the cause. But wanted to first check with other RT-AC88U owners to confirm it is working for them.

There was a guy who wrote a blog post and a script to install stubby on routers a while back, with many documented commands to confirm it works. Check it out. His name was @Xentrk.

 

[Treadler]

Network Tools > Netstat > TCP Sockets > Diagnose
& look for stuff ending in “:853”.

DoT runs over port 853?

 

[Xentrk]

What do you mean, it "doesn't work"? I've been using DoT with the DNS servers you name for months, if not a year or more without issue. How could it not work?

View attachment 24652

I updated my post. Unable to resolve hostnames is the issue. Can't browse a page. VPN Clients are unable to resolve host names to the VPN server. If I recall correctly, in one of the earlier DoT builds, there was an issue with DoT has it was compiled using an older openssl version for the RT-AC88U. My inquiry is to see if the issue I have is a model specific issue based on the previous issue with the RT-AC88U.

 

[RAH-66]

DoT runs over port 853?

only https://github.com/RMerl/asuswrt-merlin.ng/wiki/DNS-Privacy
you can monitoring, install tcpdump

opkg install tcpdump

and run

tcpdump -i eth0 -p port 853 or 53 -n

in the settings of the DNS Server1 and DNS Server2, fields leave blank

 

[Xentrk]

There was a guy who wrote a blog post and a script to install stubby on routers a while back, with many documented commands to confirm it works. Check it out. His name was @Xentrk.

That seems like a long time ago now. It does look like a cipher issue which gives me something to go on now. I'll do some more analysis.

stubby -l
[05:47:16.044321] STUBBY: Stubby version: Stubby 0.3.0
[05:47:16.155987] STUBBY: Read config from file /etc/stubby/stubby.yml
[05:47:16.156548] STUBBY: DNSSEC Validation is ON
[05:47:16.156655] STUBBY: Transport list is:
[05:47:16.156738] STUBBY:   - TLS
[05:47:16.156822] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[05:47:16.156907] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[05:47:16.156985] STUBBY: Starting DAEMON....
[05:47:16.888432] STUBBY: --- SETUP(TLS): : This version of OpenSSL does not support configuring cipher suites
Could not schedule query: The library did not have the requested API feature implemented.
<snip>

 

[dave14305]

That seems like a long time ago now. It does look like a cipher issue which gives me something to go on now. I'll do some more analysis.

stubby -l
[05:47:16.044321] STUBBY: Stubby version: Stubby 0.3.0
[05:47:16.155987] STUBBY: Read config from file /etc/stubby/stubby.yml
[05:47:16.156548] STUBBY: DNSSEC Validation is ON
[05:47:16.156655] STUBBY: Transport list is:
[05:47:16.156738] STUBBY:   - TLS
[05:47:16.156822] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[05:47:16.156907] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[05:47:16.156985] STUBBY: Starting DAEMON....
[05:47:16.888432] STUBBY: --- SETUP(TLS): : This version of OpenSSL does not support configuring cipher suites
Could not schedule query: The library did not have the requested API feature implemented.
<snip>

Verify what libssl version is linked with stubby:

ldd /usr/sbin/stubby

 

[bbunge]

That seems like a long time ago now. It does look like a cipher issue which gives me something to go on now. I'll do some more analysis.

stubby -l
[05:47:16.044321] STUBBY: Stubby version: Stubby 0.3.0
[05:47:16.155987] STUBBY: Read config from file /etc/stubby/stubby.yml
[05:47:16.156548] STUBBY: DNSSEC Validation is ON
[05:47:16.156655] STUBBY: Transport list is:
[05:47:16.156738] STUBBY:   - TLS
[05:47:16.156822] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[05:47:16.156907] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[05:47:16.156985] STUBBY: Starting DAEMON....
[05:47:16.888432] STUBBY: --- SETUP(TLS): : This version of OpenSSL does not support configuring cipher suites
Could not schedule query: The library did not have the requested API feature implemented.
<snip>

Might try to disable DNSSEC in Stubby to see if that helps. The only two mods I use in Stubby is round_robin and DNSSEC. Other settings for Stubby at Merlin defaults.

 

[DAVIZINHO]

Hello,
I install the version 384.18 in a ac88u the last week. I reset all the config to setup as new (some years withou a full reset and its time to play!)
all works fin whit a lot of setups but i have a problem with the 2.4ghz wifi settings and i dont know which is the problem
All mi leagcy devices connect to the 2.4ghz (xiaomi smart devices, power switches, logitech harmony hub, etc...).
After a some hours working, the 2.4ghz devices disconect the wifi and stop working.
Any idea which is the problem? is a bug o a config problem in my side?

thanks a lot

 

[Xentrk]

Verify what libssl version is linked with stubby:

ldd /usr/sbin/stubby

Appears to look okay.

ldd /usr/sbin/stubby

        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2ac98000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x2abc7000)
        libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x2abe1000)
        libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x2acaa000)
        libc.so.0 => /lib/libc.so.0 (0x2ae8e000)
        libdl.so.0 => /lib/libdl.so.0 (0x2ac46000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2ab0b000)

 

[dave14305]

Appears to look okay.

ldd /usr/sbin/stubby

        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2ac98000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x2abc7000)
        libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x2abe1000)
        libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x2acaa000)
        libc.so.0 => /lib/libc.so.0 (0x2ae8e000)
        libdl.so.0 => /lib/libdl.so.0 (0x2ac46000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2ab0b000)

What’s in your stubby.yml?

The message come from here: https://github.com/RMerl/asuswrt-me...ease/src/router/getdns/src/openssl/tls.c#L482