Stubby-Installer-Asuswrt-Merlin

[Marin]

after applying this line...

 stubby.yml configuration file created by Xentrk
# version 1.0.0
tls_ca_file: "/opt/etc/ssl/certs/ca-certificates.crt"
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 0
idle_timeout: 2000
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
appdata_dir: "/opt/var/cache/stubby"
listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453

and restarting Stubby...

@RT-AC86U-99A8:/rom/etc/ssl/certs# /opt/etc/init.d/S61stubby resta
rt
 Shutting down stubby...              done.
 Starting stubby...              done.

then after running this ... I get this:

@RT-AC86U-99A8:/rom/etc/ssl/certs# echo | openssl s_client -verify
 on -CApath /rom/etc/ssl/certs -connect 1.1.1.1:853
verify depth is 0
CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify error:num=20:unable to get local issuer certificate
4143998160:error:14090086:SSL routines:ssl3_get_server_certificate:certificate v
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 2529 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: DD0C9B7C5512B72918B64C215E4ACCCD8BA1FDC87E43CB17B72C27348392160E
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1545188580
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

 

[Xentrk]

I have been getting these in under my IPS section of the AiProtection. I'm thinking they are Stubby-related and nothing serious but proof that AiProtection is doing its job. Am I correct or not?

I'll check to see if I have the same entries when I return home tomorrow.

 

[Xentrk]

after applying this line...

 stubby.yml configuration file created by Xentrk
# version 1.0.0
tls_ca_file: "/opt/etc/ssl/certs/ca-certificates.crt"
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 0
idle_timeout: 2000
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
appdata_dir: "/opt/var/cache/stubby"
listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453

and restarting Stubby...

@RT-AC86U-99A8:/rom/etc/ssl/certs# /opt/etc/init.d/S61stubby resta
rt
 Shutting down stubby...              done.
 Starting stubby...              done.

then after running this ... I get this:

@RT-AC86U-99A8:/rom/etc/ssl/certs# echo | openssl s_client -verify
 on -CApath /rom/etc/ssl/certs -connect 1.1.1.1:853
verify depth is 0
CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify error:num=20:unable to get local issuer certificate
4143998160:error:14090086:SSL routines:ssl3_get_server_certificate:certificate v
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 2529 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: DD0C9B7C5512B72918B64C215E4ACCCD8BA1FDC87E43CB17B72C27348392160E
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1545188580
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

I see the problem, you changed stubby to use certificate from entware rather than rom. But the command references the rom location.

Do these steps

1. echo | openssl s_client -connect '1.1.1.1:853'

Check the last few lines of the output from the echo | openssl s_client -connect '1.1.1.1:853' command. If you see the message

Verify return code: 20 (unable to get local issuer certificate)

in the last few lines, enter the following command to validate the certificate path which will fix the error:

echo | openssl s_client -verify on -CApath /opt/etc/ssl/certs -connect 1.1.1.1:853

 

[Marin]

 0150 - 34 dd 8e a3 d2 7e 6f 8a-b3 48 9c 85 b3 a6 40 30   4....~o..H....@0
    0160 - 96 7d 93 38 db 61                                 .}.8.a

    Start Time: 1545189696
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)

then.....YEEESSSS!!!

@RT-AC86U-99A8:/tmp/home/root# echo | openssl s_client -verify on
-CApath /opt/etc/ssl/certs -connect 1.1.1.1:853
verify depth is 0
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=Cloudflare, Inc./CN=cloudflare-dns.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFuzCCBUKgAwIBAgIQC8tbG6nCVEnHtUFDDVILSzAKBggqhkjOPQQDAjBMMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp
Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xODExMDIwMDAwMDBaFw0yMDEx
MDYxMjAwMDBaMHIxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYw
FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMu
MRswGQYDVQQDExJjbG91ZGZsYXJlLWRucy5jb20wWTATBgcqhkjOPQIBBggqhkjO

Thank you as always @Xentrk!!!!

 

[dave14305]

I suggest to avoid future consternation over the OpenSSL test, you amend the github readme to use this command instead:

echo | openssl s_client -verify on -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853

The rom ssl directory won’t contain the expected hashes that CApath requires. Better to explicitly reference the bundle in rom and not need the Entware CA packages.

 

[john9527]

Just for anyone using my fork that reads this thread.....the cert location on my fork for the OpenSSL test is
/rom/ca-bundle.crt

 

[dave14305]

Just for anyone using my fork that reads this thread.....the cert location on my fork for the OpenSSL test is
/rom/ca-bundle.crt

We “forkers” are interlopers here in this thread since we have Stubby baked in.

 

[Jack Yaz]

Perhaps the firmware cert is in a different directory location on the AC86U? @Jack Yaz can you confirm?

admin@RT-AC86U:/tmp/home/root# l s -la /rom/etc/ssl/certs/ca-certificates.crt 
-rw-rw-r--    1 admin    root        209309 Nov 16 20:00 /rom/etc/ssl/certs/ca-certificates.crt

 

[Xentrk]

 0150 - 34 dd 8e a3 d2 7e 6f 8a-b3 48 9c 85 b3 a6 40 30   4....~o..H....@0
    0160 - 96 7d 93 38 db 61                                 .}.8.a

    Start Time: 1545189696
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)

then.....YEEESSSS!!!

@RT-AC86U-99A8:/tmp/home/root# echo | openssl s_client -verify on
-CApath /opt/etc/ssl/certs -connect 1.1.1.1:853
verify depth is 0
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=Cloudflare, Inc./CN=cloudflare-dns.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFuzCCBUKgAwIBAgIQC8tbG6nCVEnHtUFDDVILSzAKBggqhkjOPQQDAjBMMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp
Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xODExMDIwMDAwMDBaFw0yMDEx
MDYxMjAwMDBaMHIxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYw
FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMu
MRswGQYDVQQDExJjbG91ZGZsYXJlLWRucy5jb20wWTATBgcqhkjOPQIBBggqhkjO

Thank you as always @Xentrk!!!!

Great! If you want leave it like that for now, go ahead. I'd like to work with you to understand why you had the error message when using the certificate.crt file stored in /rom/etc/ssl/certs/.

When you have time, try and revert back to the rom certficate and try @dave14305 suggestion:

echo | openssl s_client -verify on -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853

Remember to restart Stubby after making the change to stubby.yml.

 

[Xentrk]

I suggest to avoid future consternation over the OpenSSL test, you amend the github readme to use this command instead:

echo | openssl s_client -verify on -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853

The rom ssl directory won’t contain the expected hashes that CApath requires. Better to explicitly reference the bundle in rom and not need the Entware CA packages.

Change made. Thank you for the suggestion and collaboration!

 

[Marin]

Great! If you want leave it like that for now, go ahead. I'd like to work with you to understand why you had the error message when using the certificate.crt file stored in /rom/etc/ssl/certs/.

When you have time, try and revert back to the rom certficate and try @dave14305 suggestion:

echo | openssl s_client -verify on -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853

Remember to restart Stubby after making the change to stubby.yml.

Sounds good! Thank you again!!


Sent from my iPhone using Tapatalk

 

[bbunge]

We “forkers” are interlopers here in this thread since we have Stubby baked in.

It is good to share the knowledge as some of us use both the baked in version of Stubby as well as the Betty Crocker version.

Sent from my SM-T380 using Tapatalk

 

[consorts]

hi stubby fans, some bad news from me...

for some reason stubby won't let my ac3100 clamp on to the internet
when connected to verizon fios 100:100 gig capable ont ethernet port.

stubby was working fine from merlin 384.7 & 7_2 and 384.8
but may have fallen apart for me around the time of 384.8_2

at first stubby worked for 384.8_2 then failed on me last week
so maybe something was updated in stubby or diversion that
my isp didn't like, i donno - it wasn't any setting change by me.

confirmed stubby was at fault after a factory reset update to 384.8_2
manually entered all my lan and wifi stuff, then diversion+pixelserv
everything was perfect, but when i added stubby - no more internet.

anyway, i wish i could be more helpful troubleshooting this
but for now all i can do is avoid using stubby, sorry guys.
i will miss having my dns traffic encrypted from my isp

 

[skeal]

confirmed stubby was at fault after a factory reset update to 384.8_2
manually entered all my lan and wifi stuff, then diversion+pixelserv
everything was perfect, but when i added stubby - no more internet.

anyway, i wish i could be more helpful troubleshooting this
but for now all i can do is avoid using stubby, sorry guys.
i will miss having my dns traffic encrypted from my isp

Have you read through this thread as this issue is talked about with possible solutions. This is not a huge thread please read and follow the thread to get your connection working. Make sure that NTP gets updated. There is no reason why installing Stubby would stop your internet. If you reboot though without some suggested edits to the setup, it very well could cause a failure in internet. Read the thread and find where you messed up.

 

[consorts]

Have you read through this thread as this issue is talked about with possible solutions.

i'll read thru and try what is suggested and post if anything helped my situation.
if i'm doing a fresh install and your app does not work, then i didn't "mess up",
so hopefully you'll integrate whatever conflict may exist with your install routine.

 

[skeal]

i'll read thru and try what is suggested and post if anything helped my situation.
if i'm doing a fresh install and your app does not work, then i didn't "mess up",
so hopefully you'll integrate whatever conflict may exist with your install routine.

This is a continuing test of the DoT technology on merlin. Stubby ver.1 hasn't been conceived yet. Please get back to us with your specific issues. I have had this running on a AC3100 for quite a while now.

 

[john9527]

We “forkers” are interlopers here in this thread since we have Stubby baked in.

Just as an FYI for the 'interlopers' (I liked that ) using my fork. The next GetDNS/Stubby release is more of a maintenance release rather than significant change. I had already backported most of the improvements from their upstream master on to my fork.

I've ported over the official update now, and don't see any changes on my development build.

 

[dave14305]

Just as an FYI for the 'interlopers' (I liked that ) using my fork. The next GetDNS/Stubby release is more of a maintenance release rather than significant change. I had already backported most of the improvements from their upstream master on to my fork.

I've ported over the official update now, and don't see any changes on my development build.

You should create a pull request for your hard-fought MIPS fix!

 

[bbunge]

i'll read thru and try what is suggested and post if anything helped my situation.
if i'm doing a fresh install and your app does not work, then i didn't "mess up",
so hopefully you'll integrate whatever conflict may exist with your install routine.

Not getting time sync will cause a wan connect failure. The easy fix is to use a time server ip in lieu of a URL (pool.ntp.org). There is a permanent fix for this in the readme. I know this as I have switched from Merlin to John's fork and back to Merlin today. For some reason stubby did not like ipv6 6rd so I just set up stubby with ipv4 and Cloudflare.

Sent from my SM-T380 using Tapatalk

 

[consorts]

I have had this running on a AC3100 for quite a while now.

thanks for that - it gives me hope it may be worth the time to troubleshoot - i already wasted many hours isolating the problem in the first place and rebuilding my router before my wifi starved family were about to kill me*. just wondering what ISP type, speed and wan-qos you are using with your ac3100 running stubby. *i keep a spare preconfigured router on the shelf, so my life was not really in any danger