[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[john9527]

A maintainance update has been posted, 36EA

IMPORTANT:
This update fixes a security issue with OpenVPN server username/password authentication on the N66 and AC66 where non-authorized users may be allowed to connect.
If you use OpenVPN server on the MIPS based routers it is strongly recommended you update to this release.

LATEST RELEASE: Update-36EA/36LA
1-November-2018
Merlin fork 374.43_36EAj9527
Download http://bit.ly/1YdgUcP
============================

Changes:

• Fix unauthorized user logon to OpenVPN server on the N66 and AC66
• Using DNSSEC with DoT will now automatically use the DNSSEC validation built in to DoT (stubby) instead of dnsmasq DNSSEC
• Update miniupnpd to version 20180907, including a PCP fix and an Asuswrt change to allow forwarding to private/reserved networks
• Update nettle to version 3.4 (dnsmasq crypto)
• Update nano to version 3.1
• Fix orphan instances of udhcpc on WAN failure/recovery
• Fix broken lz4/lz4-v2 compression option in OpenVPN server
• Fix broken iptables-save (firewall rules) when using rules with a ROUTE target
• Fix broken Peanuthull DDNS support
• Fix to also move OpenVPN ca.key to/from jffs/nvram via move scripts

SHA256

(Default Build - All supported routers)
8a09b77d82c03efb47e617a650566f6fa21bfe92e4851d48237b3dee239bd70b  RT-N16_374.43_36EAj9527.trx
99576076245572a8a13bf59e6f14525f1a51b6bc3ba96e09e14f6ebb0917b9ca  RT-AC66U_374.43_36EAj9527.trx
df0543482938be3f53904bd3126b11d37856519b388a418163df994fdc740043  RT-N66U_374.43_36EAj9527.trx
7c5a72d6209e4e6a51a3f32f58462e115b98e314e41e68cc0b1a237ab60d90c9  RT-AC68U_374.43_36EAj9527.trx
aeecf8412283c6ce3b0efc7226872e6a0f522a7eaab52df3551af450ad376a84  RT-AC56U_374.43_36EAj9527.trx

(Legacy Only Builds)
bed83cca1f0dc0103d522d77e938f4d9d8654127b622909e7624c35e24fec556  RT-AC68U_3.0.0.4_374.43_2-36LAj9527.trx
ec75e1b18f282c0605a77c8e9888522669f43853c91bc9e44abac8f4d2aa853f  RT-AC56U_3.0.0.4_374.43_2-36LAj9527.trx
caf33f815a21cbf0a3560c194320c19289584a4f8418a114a69b455bd38ef4fa  RT-N16_3.0.0.4_374.43_2-36LAj9527.trx
a3ab575e81248b3ba918c30876116fd2458803d0658671b893bb72e23c99fe21  RT-AC66U_3.0.0.4_374.43_2-36LAj9527.trx
d382040dc9faa28a88595b5db912f6d48d7c78e24f3ae4af28d511e1cf902814  RT-N66U_3.0.0.4_374.43_2-36LAj9527.trx

 

[john9527]

Looking for some testers...

Update-37B1
https://1drv.ms/f/s!Ainhp1nBLzMJghNQwAwWEq2LJxtd

This adds support for DDNS when in a double-NAT configuration. This is currently NOT a backport from Merlin's inadyn (which is going to be a bit of work), but a functional extension to the current ez-ipupdate. To use it, go to the DDNS setup page and set Method to retrieve WAN IP to 'External'.

Let me know what works and what doesn't

 

[slobodan]

Looking for some testers...

Update-37B1
https://1drv.ms/f/s!Ainhp1nBLzMJghNQwAwWEq2LJxtd

This adds support for DDNS when in a double-NAT configuration. This is currently NOT a backport from Merlin's inadyn (which is going to be a bit of work), but a functional extension to the current ez-ipupdate. To use it, go to the DDNS setup page and set Method to retrieve WAN IP to 'External'.

Let me know what works and what doesn't

AC56U behind modem/router, it works with Dnsomatic.

 

[john9527]

AC56U behind modem/router, it works with Dnsomatic.

Thanks for the feedback....I'll add that I tested with NO-IP free and that worked for me (so that's two )

I'll should also note that I added an entry to the syslog that shows the ip address that it's setting along with a hostname confirmation.

Nov  2 09:19:03 ddns_update: ez-ipupdate: starting...
Nov  2 09:19:03 ddns_update: ddns host address 72.200.xxx.xxx
Nov  2 09:19:03 ddns_update: ddns host name xxxx.ddns.net
Nov  2 09:19:04 ddns_update: connected to dynupdate.no-ip.com (8.23.224.120) on port 443.
Nov  2 09:19:04 ddns_update: request successful
Nov  2 09:19:04 ddns_update: asusddns_update: 0

 

[Mr_Andy]

updated to version 36EA (Asus N66U) and tested OpenVPN, further to previous post I can confirm login is now working successfully from authorised username/password combination. previous problem is now fixed.

Thank you John !!!

 

[mymatenige]

• Fix broken lz4/lz4-v2 compression option in OpenVPN server

Now working fine. Thanks John!

 

[phx28777]

Updated to 36EA and noticed DoT with Cloudflare was no longer working. I previously had DNSSEC enabled along with the disable strict enforcement checkmark. Disabled DNSSEC and DoT working as before.

Thanks for the great firmware! Have been using DoT since you implemented in your firmware and it has worked for me flawlessly.

 

[slobodan]

Spoke too soon:

OpenDNS details:
Errors requiring your attention
The IP Address you have supplied to DNS-O-Matic
differs from the IP Address that you are coming from.
OpenDNS does not allow you to update to an IP Address
that you don't actually own.
History

Nov 3 15:38:37 ddns_update: ez-ipupdate: starting...
Nov 3 15:38:37 ddns_update: ddns host address 192.168.180.11
Nov 3 15:38:37 ddns_update: ddns host name xxxxxxxxxxxxx
Nov 3 15:38:38 ddns_update: connected to updates.dnsomatic.com (67.215.92.215) on port 443.
Nov 3 15:38:39 ddns_update: invalid hostname: xxxxxxxxxxxxx
Nov 3 15:38:39 ddns_update: asusddns_update: 2

Got the reason: Method to retrieve WAN IP got changed to internal.

 

[john9527]

Spoke too soon:


Got the reason: Method to retrieve WAN IP got changed to internal.

Thanks...I'll run a few scenarios to see if I can figure out why it didn't save.

 

[bbunge]

Updated to 36EA and noticed DoT with Cloudflare was no longer working. I previously had DNSSEC enabled along with the disable strict enforcement checkmark. Disabled DNSSEC and DoT working as before.

Thanks for the great firmware! Have been using DoT since you implemented in your firmware and it has worked for me flawlessly.

If you are refering to the test at: https://cloudflare-dns.com/help/ enabling DNSSEC will cause this test page to "fail." We have not found a web site that validates the client operation of DNSSEC either with or without DoT enabled. There is a dig command that can check for the "ad" flag which indicates that DNSSEC is working. There is an iOS app for dig if you do not have Linux skills.

Edit: the ISC Dig IOS app does return the ad flag when tested to cloudflare-dns.com when Cloudflare resolvers are selected in DoT and DNSSEC enabled.
Thanks John!

 

[jsbeddow]

I for one will be happy when this "growing pains" period is over with regards to DoT/DoH/DNSSEC and Stubby vs. dnsmasq DNSSEC validation: even if I have been closely following the developments over in the Stubby install thread, I still find the whole thing to be a mess and can't wait for it to "settle down". The previous @john9527 builds (36E4 and 36E9) seemed more stable and would consistently connect to the Cloudflare test/help site with DoT showing as working (although at this point I can't recall if I had to turn off DNSSEC support entirely, or only the "Strict" checkbox).

Now on the current 36EA build, I definitely have to have DNSSEC support set to "off" (and there is no longer a "Strict" checkbox), for the Cloudflare test site to "work" and at least validate that DoT is working. The above post by @bbunge seems to indicate that I should trust that DNSSEC support should also be checked (unfortunately I have not set up dig, and don't have access to iOS devices for further verification), but by doing so, of course, the basic Cloudflare test/help site no longer validates any of this...and round and round we go.

However, on the current build, I did just notice that even though previous checks indicated that I was connecting to Cloudflare DNS servers, somehow (stubby?) had failed and moved over to some unknown DNS servers identified as "WoodyNet" on the AS name portion of the Cloudflare "help" site, and that DoT was no longer verifiable/active. What??? I only have Couldflare Primary and and Quad9 Secure Primary selected in the list of potential DoT DNS servers (in "Ordered" not "Round-Robin" configuration). See my screenshot...it was resolved by re-hitting "apply" on the this page, but for how long before it breaks again?

 

[bbunge]

I for one will be happy when this "growing pains" period is over with regards to DoT/DoH/DNSSEC and Stubby vs. dnsmasq DNSSEC validation: even if I have been closely following the developments over in the Stubby install thread, I still find the whole thing to be a mess and can't wait for it to "settle down". The previous @john9527 builds (36E4 and 36E9) seemed more stable and would consistently connect to the Cloudflare test/help site with DoT showing as working (although at this point I can't recall if I had to turn off DNSSEC support entirely, or only the "Strict" checkbox).

Now on the current 36EA build, I definitely have to have DNSSEC support set to "off" (and there is no longer a "Strict" checkbox), for the Cloudflare test site to "work" and at least validate that DoT is working. The above post by @bbunge seems to indicate that I should trust that DNSSEC support should also be checked (unfortunately I have not set up dig, and don't have access to iOS devices for further verification), but by doing so, of course, the basic Cloudflare test/help site no longer validates any of this...and round and round we go.

However, on the current build, I did just notice that even though previous checks indicated that I was connecting to Cloudflare DNS servers, somehow (stubby?) had failed and moved over to some unknown DNS servers identified as "WoodyNet" on the AS name portion of the Cloudflare "help" site, and that DoT was no longer verifiable/active. What??? I only have Couldflare Primary and and Quad9 Secure Primary selected in the list of potential DoT DNS servers (in "Ordered" not "Round-Robin" configuration). See my screenshot...it was resolved by re-hitting "apply" on the this page, but for how long before it breaks again?

Since Cloudflare is an unicast address you can be routed to several data centers. I use ORD which is in Chicago USA. Do not know where Woody is located.
Not a good idea to use Cloudflare and Quad9. Use one or the other and the alternate. I find using Cloudflare in round robin to be faster. From home I have connection issues with quad9 but my routers in a business application on Comcast work fine with Quad9.
Don't worry about the test results to Cloudflare. They do not test client, your router, operation. While there are some unanswered questions about stubby enough of us have been banging away at it for weeks and feel confident that it does work!

Sent from my SM-T380 using Tapatalk

 

[john9527]

@jsbeddow

In no particular order

• WoodyNet == Quad9 (has to do with the history of Quad9)
• Back before the switch to using stubby dnssec, the recommendation was to always use the dnsmasq 'strict' dnssec mode (unchecking that box essentially made it like disabling dnssec). I had originally put the option in before strict became the default, to make a fully functional dnssec.
• It may help to understand how the 'ordered' option works. With ordered it will start using the first selected server until a severe error occurs (without an error, it would never touch any other servers). If the first server encounters an severe error, it will start using the next server and sit on that server until the next severe error, when it switches again. It will be interesting to see changes in the next stubby release as there have been a lot of suggestions for the developers.
• Regarding Cloudflare, their internal servers are using an uncommon encryption which they have 'optimized'. It's my belief at this time that this has some compatibility problems with the standard crypto libraries, and is causing false errors. Best advice right now is if you are having problems with specific sites with stubby/dnssec/Cloudflare, is to use a different server.

 

[jsbeddow]

@jsbeddow

In no particular order

• WoodyNet == Quad9 (has to do with the history of Quad9)
• Back before the switch to using stubby dnssec, the recommendation was to always use the dnsmasq 'strict' dnssec mode (unchecking that box essentially made it like disabling dnssec). I had originally put the option in before strict became the default, to make a fully functional dnssec.
• It may help to understand how the 'ordered' option works. With ordered it will start using the first selected server until a severe error occurs (without an error, it would never touch any other servers). If the first server encounters an severe error, it will start using the next server and sit on that server until the next severe error, when it switches again. It will be interesting to see changes in the next stubby release as there have been a lot of suggestions for the developers.
• Regarding Cloudflare, their internal servers are using an uncommon encryption which they have 'optimized'. It's my belief at this time that this has some compatibility problems with the standard crypto libraries, and is causing false errors. Best advice right now is if you are having problems with specific sites with stubby/dnssec/Cloudflare, is to use a different server.

Thank you to both @john9527 and @bbunge. Some of this I knew already (Ordered vs. Round-Robin, and the uncommon encryption of Cloudflare, for example) but not all of these items, particularly the "WoodyNet==Quad9 detail.....that one is a bit of a relief, as it just verifies that the ordered structure that I specified works as expected, and was not a truly random DNS server resolving addresses .

 

[zboq]

Hello again guys
I've been trying to find out why my N66U restarts it self with no particular reason. Someone suggested that my wall charger is dying, so I've changed that and still the same. Also did some test with remote loge server but it came up with nothing.
So, I've updated to the latest available fimware 36EA and still experiencing reboots, at least one per day. Did a factory reset and reinstalled a fimware from restoration utility. All of them started to happen right after switching from rmerlin to this fork from john9527.
As a last resort i'm planing to switch back to rmerlin, just to see if the reboots are still there.

And the last thing. My kid noticed that many of the reboots are happening when I come home from work. So I laughed at him when he told me that, but then it turned out to be true. It actually is like that. When i get in a range of my wifi and my phone connects to it, router restarts and if I go away from my wifi or turn wifi off on my phone and few minutes later connect again, nothing happens. It's like I would have to be away for few hours for it to happen.
So if anyone have an idea what i could do to fix this, I would be gratefull.

 

[oso2276]

And the last thing. My kid noticed that many of the reboots are happening when I come home from work. So I laughed at him when he told me that, but then it turned out to be true. It actually is like that. When i get in a range of my wifi and my phone connects to it, router restarts and if I go away from my wifi or turn wifi off on my phone and few minutes later connect again, nothing happens. It's like I would have to be away for few hours for it to happen.

Is that an iPhone?

Enviado desde mi Moto Z2 Play mediante Tapatalk

 

[zboq]

Is that an iPhone?

Enviado desde mi Moto Z2 Play mediante Tapatalk

No, It's 1+6

 

[ColinTaylor]

No, It's 1+6

I notice that the OnePlus 6 supports 5GHz using AC. Are you connecting to the 5GHz band? The N66U doesn't support AC connections, only B/G/N so maybe that's confusing it. Try connecting to the 2.4GHz band only and seeing if that makes a difference.

 

[zboq]

Was thinking about something similar and disabled 5GHz band completely but reboots where still there.

 

[john9527]

@zboq
Some variants of Android 8 cause what what is essentially a DoS attack...See this thread.
https://www.snbforums.com/threads/phone-keeps-killing-my-ac66-wifi.49586/#post-441272