What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

@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".
 
i'm now running merlin 380_70 on a rt-n66u is it beneficial to downgrade to this version?
 
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.
 
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
 
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
 
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
 
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
 
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....
Code:
~ $ 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
 
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
 
Last edited:
Last edited:
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 :)
 
Here's screenshot
 

Attachments

  • скрин.png
    скрин.png
    57.5 KB · Views: 530
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 ;)).
 
@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....

Code:
                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.
 
Last edited:
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
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....

Code:
                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
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top