Release Asuswrt-Merlin 386.3 is now available

[ColinTaylor]

Would anyone here be willing to confirm please?

Working perfectly here.

 

[JohnD5000]

I found a bug I think.

Try entering any custom DNS in DNS Filter in custom 3, i.e. the third box. Assign it to a device. Observe that the custom set DNS is not applied.

Would anyone here be willing to confirm please?

This was happening to me. Toggle the "Enable DNS-based Filtering" to Off (Apply) then ON (apply) then it worked for me (I was using selections not custom though)

 

[Lynx]

Working perfectly here.

Sorry, I have tested further and it seems the issue that I experienced does not relate to the choice of Custom field in DNS filter, and is rather something more subtle. This is with a VPN client. If I set it to '1.1.1.1' then '1.1.1.1' gets used. If I set any of the custom fields to '8.8.8.8' then the VPN DNS gets used. There may be a reasonable explanation for this?

 

[jeff3820]

None of these are related to the 386.3 changes, since it's the exact same GPL code, exact same Broadcom SDK as 386.2_6.

When I upgraded two RT-AC86U units to 386.3 one was perfect. The other worked but exhibited a slight drop in download speed from ~330mbps to ~290mbps and the assignment of dhcp address was very slow. When plugging in a new wired device, nothing happened for ~10 seconds, then it got a 169.x APIPA address...about 2-3 seconds later it received a proper address but again, a slight drop in download speed. A day or so later I had the user power cycle the router and the strange dhcp behavior was gone and the download speed returned to normal.

 

[Wade Coxon]

and the assignment of dhcp address was very slow. W

I have been noticing some similarly slow dhcp assignment behaviour on my network as far back as 386.2. I haven't been able to pin down what is happening exactly, and it is only really upsetting a couple of my devices in that they don't get their addresses fast enough before a critical boot service starts and doesn't have a valid IP yet.

All I can see in the device logs is that the first dhcp request fails, and a second needs to be made.

 

[ColinTaylor]

I have been noticing some similarly slow dhcp assignment behaviour on my network as far back as 386.2. I haven't been able to pin down what is happening exactly, and it is only really upsetting a couple of my devices in that they don't get their addresses fast enough before a critical boot service starts and doesn't have a valid IP yet.

All I can see in the device logs is that the first dhcp request fails, and a second needs to be made.

I thought we had determined that this was expected behaviour from dnsmasq.

http://www.snbforums.com/threads/yazdhcp-feature-expansion-of-dhcp-assignments-increasing-limit-on-the-number-of-dhcp-reservations.69247/post-693769

 

[Wade Coxon]

I thought we had determined that this was expected behaviour from dnsmasq.

But there should be no delay for manually assigned addresses as your following post points out. My devices have been manually assigned.

I even tried disabling the dnsmasq ping test via settings , but that didn't seem to do much either.

I am yet to really dig deeper into this problem anyway. I had been meaning to check if perhaps rstp on my switch wasn't moving to a forwarding state fast enough after bringing the port up, or if there was something whacky going on with switch port flow control, or possibly any mesh-induced loops on my network.

 

[RMerlin]

Sorry, I have tested further and it seems the issue that I experienced does not relate to the choice of Custom field in DNS filter, and is rather something more subtle. This is with a VPN client. If I set it to '1.1.1.1' then '1.1.1.1' gets used. If I set any of the custom fields to '8.8.8.8' then the VPN DNS gets used. There may be a reasonable explanation for this?

How can you tell that the VPN DNS is used?

 

[SomeWhereOverTheRainBow]

How can you tell that the VPN DNS is used?

my thoughts would be trace route, just one method.

 

[RMerlin]

my thoughts would be trace route, just one method.

Traceroute does not tell you what DNS server is being used for DNS queries.

I have a feeling that his post is incorrect, that it does NOT use that DNS server. He's reporting a self-diagnosis rather than the actual symptoms...

 

[SomeWhereOverTheRainBow]

Traceroute does not tell you what DNS server is being used for DNS queries.

no but it shows you the route dns traffic is flowing, from a client perspective, you can see if your dns is passing through the vpn or if it is traveling via isp route.

 

[RMerlin]

no but it shows you the route dns traffic is flowing, from a client perspective, you can see if your dns is passing through the vpn or if it is traveling via isp route.

Routing != using the wrong DNS server. His post says that the VPN's DNS server is used instead of 8.8.8.8.

 

[Lynx]

How can you tell that the VPN DNS is used?

Just simply using:

DNS leak test

www.dnsleaktest.com

That creates unique lookup requiring the ultimate DNS server to resolve right? In any case, I have tested a few times and the behaviour seems consistent.

 

[SomeWhereOverTheRainBow]

Just simply using:

DNS leak test

www.dnsleaktest.com

That creates unique lookup requiring the ultimate DNS server to resolve right? In any case, I have tested a few times and the behaviour seems consistent.

What is your vpn tunnel set to as far as dns is concerned? What about lan dns? And what about wan dns? As well as what dns does it say you are using when dns filter is turned off?

 

[RMerlin]

Just simply using:

DNS leak test

www.dnsleaktest.com

That creates unique lookup requiring the ultimate DNS server to resolve right? In any case, I have tested a few times and the behaviour seems consistent.

If that client is set to use the VPN and you have DNS mode set to Exclusive, then this is working as intended.

 

[edreams]

Hi Everybody,

Just updated my RT-AC5300 to 386.3 and I have a big issue with OpenVPN. I changed nothing to my openvpn configuration and it refuses now to connect with a "error check configuration" error...

Somebody had the same issue here ? I really don't know how to fix this issue

Thanks

 

[ColinTaylor]

@edreams Look for errors in System Log > General Log when you enable the VPN client.

 

[edreams]

@edreams Look for errors in System Log > General Log when you enable the VPN client.

Thank you @ColinTaylor !!! Here is the log, but I'm a kiddie and can't understand where's the problem

May 5 07:36:53 ovpn-client3[2296]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
May 5 07:36:53 ovpn-client3[2296]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
May 5 07:36:53 ovpn-client3[2296]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
May 5 07:36:53 ovpn-client3[2296]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
May 5 07:36:53 ovpn-client3[2296]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
May 5 07:36:53 ovpn-client3[2296]: TCP/UDP: Preserving recently used remote address: [AF_INET]217.138.211.68:4443
May 5 07:36:53 ovpn-client3[2296]: Socket Buffers: R=[122880->122880] S=[122880->122880]
May 5 07:36:53 ovpn-client3[2296]: UDP link local: (not bound)
May 5 07:36:53 ovpn-client3[2296]: UDP link remote: [AF_INET]217.138.211.68:4443
May 5 07:36:53 ovpn-client3[2296]: TLS: Initial packet from [AF_INET]217.138.211.68:4443, sid=9f3616a8 260e4fee
May 5 07:36:53 ovpn-client3[2296]: VERIFY OK: depth=1, C=KY, O=FastestVPN, CN=FastestVPN Root CA
May 5 07:36:53 ovpn-client3[2296]: VERIFY ERROR: depth=0, error=certificate is not yet valid: C=KY, O=FastestVPN, CN=FastestVPN, serial=9645471466874494827573622408934548685209409612
May 5 07:36:53 ovpn-client3[2296]: OpenSSL: error:1416F086:lib(20):func(367):reason(134)
May 5 07:36:53 ovpn-client3[2296]: TLS_ERROR: BIO read tls_read_plaintext error
May 5 07:36:53 ovpn-client3[2296]: TLS Error: TLS object -> incoming plaintext read error
May 5 07:36:53 ovpn-client3[2296]: TLS Error: TLS handshake failed
May 5 07:36:53 ovpn-client3[2296]: SIGUSR1[soft,tls-error] received, process restarting
May 5 07:36:53 ovpn-client3[2296]: Restart pause, 300 second(s)

 

[RMerlin]

Thank you @ColinTaylor !!! Here is the log, but I'm a kiddie and can't understand where's the problem

Your router's clock isn't set. Double check NTP and DNS settings.

 

[edreams]

@edreams Look for errors in System Log > General Log when you enable the VPN client.

@ColinTaylor

thanks to your suggestion to look at the logs I realized that for some reason that I cannot explain the date of the router was not good, it believed to be in 2018 !!! After setting the time everything works again.

A very big thank you to you!