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

[ColinTaylor]

@clovek1 I think you should set "Forward local domain queries to upstream DNS" on the LAN page to "No".

Everything else looks OK but personally I'd change the Domain Name from "WORKGROUP" to something more normal like "home.lan".

 

[mihei78]

I'll port them over for you to try and send you a PM.

Thank you very much, I will be very happy

 

[laracroftonline]

i'm now running merlin 380_70 on a rt-n66u is it beneficial to downgrade to this version?

 

[RMerlin]

i'm now running merlin 380_70 on a rt-n66u is it beneficial to downgrade to this version?

It's not a downgrade, it's a crossgrade. The version number might be lower, but it was developed in parallel to mine, so it's not going backward.

 

[john9527]

Not running this as a 'formal' beta, but for those who would like to try my latest development version...Have fun!

BETA/TEST RELEASE: Update-37B4 (based on 'E' Build stream)
6-November-2018
Merlin fork 374.43_37B4j9527
Download https://1drv.ms/f/s!Ainhp1nBLzMJghNQwAwWEq2LJxtd
============================

• Support for Double-NAT for DDNS (some additional tweaks from 37B1)
• Updated ca-bundle to 2018 October 17th version
• Applied some upstream commits for DoT getdns/stubby which should help reduce DNSSEC errors
• Updated dnsmasq to 2.80-122392e snapshot with some performance and DNSSEC fixes
• Misc OpenVPN and OpenSSL backports from Merlin
• Updated udpxy to build 23 and applied some parameter updates from Merlin builds - @mihei78

 

[phx28777]

Loaded your test release on my AC-68U
DoT with Cloudflare v4 and v6 servers

With DNSSEC enabled some sites return SERVFAIL

With DNSSEC off all sites resolve correctly

 

[john9527]

Loaded your test release on my AC-68U
DoT with Cloudflare v4 and v6 servers

With DNSSEC enabled some sites return SERVFAIL

With DNSSEC off all sites resolve correctly

Nothing more I can do there....I found this thread which I think is exactly the problem. (I traced the cloudflare test site failure and it is is-cf.cloudflareresolve.com/is-dot.cloudflareresovlve.com that is causing the test fail)
https://community.cloudflare.com/t/dnssec-validation-failures/28050

 

[phx28777]

Nothing more I can do there....I found this thread which I think is exactly the problem. (I traced the cloudflare test site failure and it is is-cf.cloudflareresolve.com/is-dot.cloudflareresovlve.com that is causing the test fail)
https://community.cloudflare.com/t/dnssec-validation-failures/28050

This is NOT the test site failure...this is a .com site that will not resolve. Never had this occur on previous versions of your firmware that I know of!

DNSSEC not enabled

; <<>> DiG 9.11.5 <<>> www.nrsforu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28530
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.nrsforu.com. IN A

;; ANSWER SECTION:
www.nrsforu.com. 251 IN CNAME nrsforu.com.
nrsforu.com. 251 IN CNAME imedia-e.nrsforu.com.
imedia-e.nrsforu.com. 251 IN A 155.188.80.113

;; Query time: 1 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Nov 07 09:46:17 US Mountain Standard Time 2018
;; MSG SIZE rcvd: 119


DNSSEC enabled

; <<>> DiG 9.11.5 <<>> www.nrsforu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41829
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.nrsforu.com. IN A

;; Query time: 280 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Nov 07 10:02:46 US Mountain Standard Time 2018
;; MSG SIZE rcvd: 33

 

[john9527]

This is NOT the test site failure...this is a .com site that will not resolve. Never had this occur on previous versions of your firmware that I know of!

Hmmm....works fine for me. Although this a CNAME case....

~ $ dig www.nrsforu.com

; <<>> DiG 9.9.5-3ubuntu0.18-Ubuntu <<>> www.nrsforu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22848
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;www.nrsforu.com.        IN    A

;; ANSWER SECTION:
www.nrsforu.com.    300    IN    CNAME    nrsforu.com.
nrsforu.com.        300    IN    CNAME    imedia-n.nrsforu.com.
imedia-n.nrsforu.com.    300    IN    A    155.188.186.113

;; Query time: 584 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Nov 07 12:19:12 MST 2018
;; MSG SIZE  rcvd: 165

~ $ dig +dnssec -t DS www.nrsforu.com

; <<>> DiG 9.9.5-3ubuntu0.18-Ubuntu <<>> +dnssec -t DS www.nrsforu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12389
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;www.nrsforu.com.        IN    DS

;; ANSWER SECTION:
www.nrsforu.com.    300    IN    CNAME    nrsforu.com.

;; AUTHORITY SECTION:
ck0pojmg874ljref7efn8430qvit8bsm.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
ck0pojmg874ljref7efn8430qvit8bsm.com. 86400 IN RRSIG NSEC3 8 2 86400 20181112054214 20181105043214 37490 com. VtU+mR9c9/KMSBR8+8jD4tBuYVI02LgCM0l6ajfg0IFDAqgk4pvkQeeu PUolFBvqUhq/skdRtlUSE2SLBl7NqXFu2gzeW+BGQ7qeW/H/C3S2xQfY y+vrQvZXtTGTDRSQ7iKbs+p60HkpC6yW1yO5ZkbB53GLVRmjQDGCRm0i STM=
com.            900    IN    SOA    a.gtld-servers.net. nstld.verisign-grs.com. 1541618400 1800 900 604800 86400
com.            900    IN    RRSIG    SOA 8 1 900 20181114192000 20181107181000 37490 com. jSzI/uK13NMwvK+oKO6s1HTiEk/z7Ekn7hhKK07/dyx3xgzPjABMk2+R 0UU68oEpXHxv//c4P3gFxusbAgQEUttB2GVh/RrJAT3zsoekiWCEuExz Qlb6zOZ2IhDlu0oqzlqyNKQUeBrMeD1z0WyJUijTRimfu/tofJSmvUe5 Gtg=
91o9kmdbn23okh4q4kj01vmkvejamshq.com. 86400 IN NSEC3 1 1 0 - 91OD4LNA1CHHTL37HKSHJUUH6KBM9HKS NS DS RRSIG
91o9kmdbn23okh4q4kj01vmkvejamshq.com. 86400 IN RRSIG NSEC3 8 2 86400 20181114054559 20181107043559 37490 com. bJM/Mfgcye4WnDR1mdJ5lwD9jTEsOVrJ0fFE4g2eNzUTtYJL5F5sxy1P K/sTmgUDghSH+1G6m2hFnhYv1TE7Yhi38jSqmwzOs7hmFSSNdyUbgKPn zvucjFTi6nEGszQoaFKMh8D0Y8CT1IU7BP6Ix6ZrojTnafxZ7y/SaROR lVE=

;; Query time: 461 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Nov 07 12:20:17 MST 2018
;; MSG SIZE  rcvd: 892

 

[RMerlin]

This is NOT the test site failure...this is a .com site that will not resolve. Never had this occur on previous versions of your firmware that I know of!

DNSSEC not enabled

; <<>> DiG 9.11.5 <<>> www.nrsforu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28530
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.nrsforu.com. IN A

;; ANSWER SECTION:
www.nrsforu.com. 251 IN CNAME nrsforu.com.
nrsforu.com. 251 IN CNAME imedia-e.nrsforu.com.
imedia-e.nrsforu.com. 251 IN A 155.188.80.113

;; Query time: 1 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Nov 07 09:46:17 US Mountain Standard Time 2018
;; MSG SIZE rcvd: 119


DNSSEC enabled

; <<>> DiG 9.11.5 <<>> www.nrsforu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41829
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.nrsforu.com. IN A

;; Query time: 280 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Nov 07 10:02:46 US Mountain Standard Time 2018
;; MSG SIZE rcvd: 33

That domain does not have a valid DNSSEC configuration according to Verisign's DNSSEC analyzer:

https://dnssec-analyzer.verisignlabs.com/nrsforu.com

 

[john9527]

That domain does not have a valid DNSSEC configuration according to Verisign's DNSSEC analyzer:

https://dnssec-analyzer.verisignlabs.com/nrsforu.com

Also shows up as misconfigured at...
http://dnsviz.net/d/www.nrsforu.com/dnssec/

I'll need to reload to check, but I think this may be a case where it failed on the earlier code, and one of the upstream fixes bypasses the fail.

@phx28777Are you sure you loaded the B4 firmware?

 

[phx28777]

Also shows up as misconfigured at...
http://dnsviz.net/d/www.nrsforu.com/dnssec/

I'll need to reload to check, but I think this may be a case where it failed on the earlier code, and one of the upstream fixes bypasses the fail.

@phx28777Are you sure you loaded the B4 firmware?

Yes, loaded 37B4 and verified on router page, no issues with DNSSEC off

https://cloudflare-dns.com/help/#ey...lIjoiQ2xvdWRmbGFyZSIsImlzcEFzbiI6IjEzMzM1In0=

 

[MeDd]

Not running this as a 'formal' beta, but for those who would like to try my latest development version...Have fun!

Hey, John!
I just updated FW of my ASUS RT AC66U from 3.0.0.4.382_50470 to your 374.43_36EAj9527 and now I've got one problem.
There's no AC type of connection in 5Ghz inlay. How could I fix that? What happens?
P.S. This is my first custom FW for router

 

[MeDd]

Here's screenshot

 

[john9527]

There's no AC type of connection in 5Ghz inlay. How could I fix that? What happens?

On this fork, you use 'Auto' to use AC connections.

 

[MeDd]

On this fork, you use 'Auto' to use AC connections.

Ok, great thx! It just was surprise for me! Appreciate that!

 

[jsbeddow]

Hi @john9527, just wondering if you have had any further insights into the issue that @phx28777 was having with DNSSEC on this new "unofficial" beta 37B4 build? In other words, are you still considering his case to be a rare/edge case scenario with that site's CNAME record in a non-standard format? I want to try this out, but am a little nervous if this is going to cause frequent DNS resolution errors (the family will not take well to that ).

 

[john9527]

@phx28777
I had been bewildered as to why I wasn't seeing the same failure you were on nrsforu.com, so spent the day experimenting. Finally was able to recreate a fail.

My normal operating mode with stubby is Cloudflare Primary and Cloudflare secondary in roundrobin, dnssec and ipv6 servers included. What I found is that switching to 'Ordered' mode creates the failure. It seems as if there is a bug that some failures are not retried correctly in ordered mode. Can you confirm you are using ordered mode? The bug also shows up if only one DoT server is selected in either roundrobin or ordered mode.

So until the next release of getdns/stubby, my recommendations for DoT use are:

• Do NOT use ordered mode, only roundrobin
• Always select at least two servers from the server pulldown

@jsbeddow
With the DoT settings I've listed I haven't seen any failures in my normal browsing or streaming activity (the only fail I've been able to consistently reproduce is the cloudflare test site). If you did encounter any problems, you can always fall back to not using DoT (normal servers with or without dnssec) which hasn't changed.

@Xentrk
Just a callout FYI.

EDIT: Now I'm confused again. I decided to run one more set of tests comparing dnsmasq dnssec with stubby dnssec. So we have the following for the nrsforu.com....

                stubby dnssec              dnsmasq dnssec
Roundrobin      NOERROR                    SERVFAIL
Ordered         SERVFAIL                   SERVFAIL

So it appears as if stubby dnssec/roundrobin is the outlier, allowing a misconfigured site to pass.

 

[Mr_Andy]

N66U version V36EA

I'm using DoT with Quad9, don't have DNSSEC enabled but I am using Ordered mode to Quad9 Secure Primary and Secondary. I've not noticed any DNS problems but if there is a bug should I also be using RoundRobin in this setup ??

 

[phx28777]

@phx28777
I had been bewildered as to why I wasn't seeing the same failure you were on nrsforu.com, so spent the day experimenting. Finally was able to recreate a fail.

My normal operating mode with stubby is Cloudflare Primary and Cloudflare secondary in roundrobin, dnssec and ipv6 servers included. What I found is that switching to 'Ordered' mode creates the failure. It seems as if there is a bug that some failures are not retried correctly in ordered mode. Can you confirm you are using ordered mode? The bug also shows up if only one DoT server is selected in either roundrobin or ordered mode.

So until the next release of getdns/stubby, my recommendations for DoT use are:

• Do NOT use ordered mode, only roundrobin
• Always select at least two servers from the server pulldown

@jsbeddow
With the DoT settings I've listed I haven't seen any failures in my normal browsing or streaming activity (the only fail I've been able to consistently reproduce is the cloudflare test site). If you did encounter any problems, you can always fall back to not using DoT (normal servers with or without dnssec) which hasn't changed.

@Xentrk
Just a callout FYI.

EDIT: Now I'm confused again. I decided to run one more set of tests comparing dnsmasq dnssec with stubby dnssec. So we have the following for the nrsforu.com....

                stubby dnssec              dnsmasq dnssec
Roundrobin      NOERROR                    SERVFAIL
Ordered         SERVFAIL                   SERVFAIL

So it appears as if stubby dnssec/roundrobin is the outlier, allowing a misconfigured site to pass.

@john9527

Yes, I have always used ordered mode for DoT servers
with Cloudlflare

I thought I would try a different set of DoT servers
Using Quad 9 Secure Primary and Secondary in ordered mode

nrsforu.com resolves correctly

Changing back to Cloudflare ordered

nrsforu.com gives SERVFAIL

Changing to Cloudflare roundrobin

nrsforu.com resolves correctly
I believe my testing confirms a problem with ordered mode using Cloudflare

I will continue to use DoT round robin with Cloudflare and will let you know if I see any other failures