What's new

Stubby-Installer-Asuswrt-Merlin

  • 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!

Took the plunge and installed Stubby with @Jack Yaz's patches for the 86U. All the tests check out including the cloudfare help. Super cool. 2 things I noted:

@preacher65's comment about changing the echo | openssl line worked, but I think the correct command is supposed to be:
Code:
echo | openssl s_client -verify on -CApath /opt/etc/ssl/certs -connect 1.1.1.1:853
to ensure the Entware certs were correctly installed. That worked as well and makes more logical sense to me at least since you want to check that those certs were correctly installed.

Looking at the rest of the output from the line above, I noticed this:
Code:
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: 60108C2782ACD64D98C8D33BC329635902F788C8D426B2E3579B28AD96131745
    Session-ID-ctx:
    Master-Key: 05F9C218F5079B34550DD0A0C4E587FC34F8FC34EF7863A047121F95117FE4856A94237B5C3629A455D4FA7BFDB285B3
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 21600 (seconds)
    TLS session ticket:
even though the script downloaded the files patched for TLS1.3 and the patched getdns and stubby show up in 'opkg list-installed'. This happened either way I did the echo | openssl line. So, while not necessarily a problem, I'm curious as to why it used 1.2 and not 1.3.

EDIT: And now after rebooting the router, stubby claims to be working, all of the checks listed on github work, but 1.1.1.1/help and cloudfare's ESNI checker both say DoT is not working ...
 
Last edited:
So, while not necessarily a problem, I'm curious as to why it used 1.2 and not 1.3.
Because your openssl version is 1.0.2.
You can check that stubby is working with tls 1.3 properly.
Code:
getdns_query -sL '{tls_min_version:GETDNS_TLS1_3}' @185.49.141.38 @1.1.1.1 +return_call_reporting
 
Because your openssl version is 1.0.2.
You can check that stubby is working with tls 1.3 properly.
Code:
getdns_query -sL '{tls_min_version:GETDNS_TLS1_3}' @185.49.141.38 @1.1.1.1 +return_call_reporting
I guess there's an updated openssl package that would need pulling in/statically linking for 1.3?
 
@preacher65's comment about changing the echo | openssl line worked, but I think the correct command is supposed to be:
Code:
echo | openssl s_client -verify on -CApath /opt/etc/ssl/certs -connect 1.1.1.1:853
to ensure the Entware certs were correctly installed. That worked as well and makes more logical sense to me at least since you want to check that those certs were correctly installed.
I claim no credit for that, it came from this post https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-15#post-451654
I suggest to avoid future consternation over the OpenSSL test, you amend the github readme to use this command instead:
Code:
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.
Xentrk's github page has been updated to use the verify command with CAfile pointing explicitly to the rom's CA certs, rather than having to install them into entware. The check works, but is the forked stubby using the rom's ca certs or expecting them in the /opt path?

As the fork is now using openssl statically (I think? based on the most recent patched files from @Odkrys) I'm not sure how that changes things, where will it look for the ca certs?

Edit: My stubby.yml file contains the line:
Code:
tls_ca_file: "/rom/etc/ssl/certs/ca-certificates.crt"
So I would assume it is using the rom's ca certs?

I know just enough about CAs to be dangerous but not quite enough to be able to answer my own question. ;)

https://www.cloudflare.com/ssl/encrypted-sni/ and https://1.1.1.1/help both report DoT is working here.
 
Last edited:
Let me know if any issues - I haven't tested this merge
I don’t see what’s different in your fork on GitHub. Maybe you can add that?

Also the AC86U is not mentioned as a supported model. I thought your fork did?
 
Took the plunge and installed Stubby with @Jack Yaz's patches for the 86U. All the tests check out including the cloudfare help. Super cool. 2 things I noted:

@preacher65's comment about changing the echo | openssl line worked, but I think the correct command is supposed to be:
Code:
echo | openssl s_client -verify on -CApath /opt/etc/ssl/certs -connect 1.1.1.1:853
to ensure the Entware certs were correctly installed. That worked as well and makes more logical sense to me at least since you want to check that those certs were correctly installed.

Looking at the rest of the output from the line above, I noticed this:
Code:
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: 60108C2782ACD64D98C8D33BC329635902F788C8D426B2E3579B28AD96131745
    Session-ID-ctx:
    Master-Key: 05F9C218F5079B34550DD0A0C4E587FC34F8FC34EF7863A047121F95117FE4856A94237B5C3629A455D4FA7BFDB285B3
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 21600 (seconds)
    TLS session ticket:
even though the script downloaded the files patched for TLS1.3 and the patched getdns and stubby show up in 'opkg list-installed'. This happened either way I did the echo | openssl line. So, while not necessarily a problem, I'm curious as to why it used 1.2 and not 1.3.

EDIT: And now after rebooting the router, stubby claims to be working, all of the checks listed on github work, but 1.1.1.1/help and cloudfare's ESNI checker both say DoT is not working ...
Do you have DNSSEC enabled? If so the Cloudflare help page will not work.

Sent from my SM-T380 using Tapatalk
 
I tested the updated fork but am having some issues. Still trying to debug, but thought I'd post here in case there's an easily spotted solution. I first tried to uninstall, but used the new github script rather than just running the existing /jffs/scripts/install_stubby.sh for the uninstall, so not sure if that has made any difference.

The following is the results of the install after uninstalling and rebooting.
Code:
Option ==> 1
/opt/bin/opkg
Downloading http://bin.entware.net/aarch64-k3.10/Packages.gz
Updated list of available packages in /opt/var/opkg-lists/entware
entware successfully updated
/opt/bin/opkg
existing stubby package found
Required dnsmasq parm no-resolv found in /tmp/etc/dnsmasq.conf
server=127.0.0.1#5453 found in /jffs/configs/dnsmasq.conf.add
server=0::1#5453 found in /jffs/configs/dnsmasq.conf.add
Error backing up existing stubby.yml to stubby.yml.2019-01-05_12-41-46
Exiting install_stubby.sh
It seems to be falsely detecting that stubby is installed, opkg list-installed says it isn't, but I'm not sure if any other checks are also used.
I'll have more time to debug in a while, but thought I'd post now, in case anyone has any insights.

Edit: Re-installed and uninstalled using the Jan 4th version of the install_stubby.sh just to check that worked okay, and it did. Assuming the uninstall cleaned everything up correctly so I had a clean base to install, the newer version (after pulling in the formatting changes) still seems to be failing for me around the chk_entware stage.
 
Last edited:
I guess there's an updated openssl package that would need pulling in/statically linking for 1.3?
Static binary doesn't need a shared library.
Look at the getdns library size. 2.5MB lol.
Dynamic
Code:
ldd getdns_query
        linux-vdso.so.1 (0x0000007f9c504000)
        libgetdns.so.10 => /opt/lib/libgetdns.so.10 (0x0000007f9c457000)
        libssl.so.1.0.0 => /opt/lib/libssl.so.1.0.0 (0x0000007f9c3ea000)
        libcrypto.so.1.0.0 => /opt/lib/libcrypto.so.1.0.0 (0x0000007f9c216000)
        libpthread.so.0 => /opt/lib/libpthread.so.0 (0x0000007f9c1e9000)
        libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x0000007f9c1c4000)
        libc.so.6 => /opt/lib/libc.so.6 (0x0000007f9c069000)
        libdl.so.2 => /opt/lib/libdl.so.2 (0x0000007f9c056000)
        /opt/lib/ld-linux-aarch64.so.1 (0x0000007f9c4d8000)
Static
Code:
ldd getdns_query
        linux-vdso.so.1 (0x0000007f7806a000)
        libgetdns.so.10 => /opt/lib/libgetdns.so.10 (0x0000007f77d7d000)
        libpthread.so.0 => /opt/lib/libpthread.so.0 (0x0000007f77d50000)
        libc.so.6 => /opt/lib/libc.so.6 (0x0000007f77bf5000)
        libdl.so.2 => /opt/lib/libdl.so.2 (0x0000007f77be2000)
        libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x0000007f77bbd000)
        /opt/lib/ld-linux-aarch64.so.1 (0x0000007f7803e000)
 
On 86U do I have to uninstall and reinstall to get the latest updates, or is there a way to update current setup?
 
On 86U do I have to uninstall and reinstall to get the latest updates, or is there a way to update current setup?
Code:
/usr/sbin/curl -L -s --retry 3 "https://github.com/jackyaz/Stubby-Installer-Asuswrt-Merlin/raw/master/getdns_1.5.0-tls1.3_aarch64-3.10.ipk" -o /var/tmp/patchedgetdns.ipk
/usr/sbin/curl -L -s --retry 3 "https://github.com/jackyaz/Stubby-Installer-Asuswrt-Merlin/raw/master/stubby_0.2.4-tls1.3_aarch64-3.10.ipk" -o /var/tmp/patchedstubby.ipk

/opt/etc/init.d/S61stubby stop

opkg install /var/tmp/patchedgetdns.ipk
opkg install /var/tmp/patchedstubby.ipk
rm /var/tmp/patchedgetdns.ipk
rm /var/tmp/patchedstubby.ipk

/opt/etc/init.d/S61stubby start
 
Edit: Re-installed and uninstalled using the Jan 4th version of the install_stubby.sh just to check that worked okay, and it did. Assuming the uninstall cleaned everything up correctly so I had a clean base to install, the newer version (after pulling in the formatting changes) still seems to be failing for me around the chk_entware stage.

Jack pulled some changes from my rewrite that weren't ready to go live. I committed some patches accordingly to his fork until the full rewrite is ready to go.
 
Jack pulled some changes from my rewrite that weren't ready to go live. I committed some patches accordingly to his fork until the full rewrite is ready to go.
I only took stuff from the PR - which I thought had been submitted due to working/ready to merge. My bad.

Thanks for patching
 
Jack pulled some changes from my rewrite that weren't ready to go live. I committed some patches accordingly to his fork until the full rewrite is ready to go.
I am getting this error trying to install on RT-AC86U:

/jffs/scripts/install_stubby.sh: line 365: syntax error: unexpected "do"
 
Code:
/usr/sbin/curl -L -s --retry 3 "https://github.com/jackyaz/Stubby-Installer-Asuswrt-Merlin/raw/master/getdns_1.5.0-tls1.3_aarch64-3.10.ipk" -o /var/tmp/patchedgetdns.ipk
/usr/sbin/curl -L -s --retry 3 "https://github.com/jackyaz/Stubby-Installer-Asuswrt-Merlin/raw/master/stubby_0.2.4-tls1.3_aarch64-3.10.ipk" -o /var/tmp/patchedstubby.ipk

/opt/etc/init.d/S61stubby stop

opkg install /var/tmp/patchedgetdns.ipk
opkg install /var/tmp/patchedstubby.ipk
rm /var/tmp/patchedgetdns.ipk
rm /var/tmp/patchedstubby.ipk

/opt/etc/init.d/S61stubby start


Thanks, worked great.
 
Just wanted to update the 5300 is indeed working just fine. I did, add the entry to "dnsmasq.conf.add"

Code:
server=/pool.ntp.org/1.1.1.1
Seems my problem was the power glitch, it must have affected my ISP as well. Went to bed last night with some wonky connection speeds, and high pings. It was not related to Stubby.

Today they are back to normal, and as I said Stubby working just fine. :)
 
Last edited:
I am getting this error trying to install on RT-AC86U:

/jffs/scripts/install_stubby.sh: line 365: syntax error: unexpected "do"
I was able to successfully install using the @Xentrk baseline followed by the @Odkrys patch install.
 
Last edited:

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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