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!

Ah I see. Forgive my ignorance, but what does HND stand for? I am managing an AC87U. Will that automatically get the statically linked version?

EDIT:

I see from the github commit that HND must mean running the aarch64 architecture. So my 87U doesn’t get the statically linked version. Is there a reason that stubby is limiting OpenSSL 1.1.1 to arm64 devices? Pixelserv-tls does not have this limitation and my 87U is running that against OpenSSL 1.1.1 fine and I can get tls 1.3 connections to pixelserv-tls

There is no technical limitation that I am aware of beyond the fact we are sourcing the binaries kindly provided by @Odkrys which were aarch64 only.
 
There is no technical limitation that I am aware of beyond the fact we are sourcing the binaries kindly provided by @Odkrys which were aarch64 only.

Ah ok, that’s reasonable. I hope that at some point in the future statically linked openssl stubby can be extended to other, non-HND, devices. I would be happy to help in any way I could (testing etc)
 
I've pushed v1.0.3 which updates the installer to use the new getdns_1.5.1 binary + stubby 0.2.5 from entware. I also fixed the incorrect output in S61stubby.

I've left the other changes that are a WIP from @Xentrk to push when he is ready.
Thank you for making the updates! Glad you have the time to make them as I have had other obligations at the current time. I appreciate your contributions and am sure the Stubby uses do to.
 
Just did a fresh install on a fresh thumb drive. Stubby would not start. May be operator error. Starting over... Stay tuned

Edit: Operator error. Wiped scripts and configs from /jffs, reboot router and started over. Now works.
Now to figure out how to keep warm!
 
Last edited:
I've pushed v1.0.3 which updates the installer to use the new getdns_1.5.1 binary + stubby 0.2.5 from entware. I also fixed the incorrect output in S61stubby.

I've left the other changes that are a WIP from @Xentrk to push when he is ready.
Thank you! This fixed the errors I had above trying to do things manually. I'm back up to my eyeballs again with Stubby, after feeling competent with all my other SNB add-ons. Kind of fun to be challenged again. o_O
 
I've pushed v1.0.3 which updates the installer to use the new getdns_1.5.1 binary + stubby 0.2.5 from entware. I also fixed the incorrect output in S61stubby.

I've left the other changes that are a WIP from @Xentrk to push when he is ready.
Stubby installer installs haveged but does not start it. Restarting entware or router does.

Sent from my SM-T380 using Tapatalk
 
Stubby installer installs haveged but does not start it. Restarting entware or router does.

Thanks, pushed a fix.
 
If I follow, entware is not going to make available the 1.1.1 OpenSSL library, so we seem to be going in the direction of having a static build of stubby, a static build of pixelserv and a third older version in entware for other stuff.
 
If I follow, entware is not going to make available the 1.1.1 OpenSSL library, so we seem to be going in the direction of having a static build of stubby, a static build of pixelserv and a third older version in entware for other stuff.

Yep, unfortunately it seems like this is the way we’re going. Ideally the fw would bundle OpenSSL 1.1.1, especially as it is the new LTS branch. However, Merlin has said that that is up to ASUS, not him, so for now it seems like, if we want TLS 1.3 support, we will have to go for statically linked versions of OpenSSL in stubby and pixelserv-tls. I guess the next best option would be an entware build, but this doesn’t seem to be happening either.
 
If I follow, entware is not going to make available the 1.1.1 OpenSSL library, so we seem to be going in the direction of having a static build of stubby, a static build of pixelserv and a third older version in entware for other stuff.
Bummer!

Where/how did you find out this sad news?
 
If I follow, entware is not going to make available the 1.1.1 OpenSSL library, so we seem to be going in the direction of having a static build of stubby, a static build of pixelserv and a third older version in entware for other stuff.

This team is trying to push OpenSSL 1.1.1a out. And they are very active.
https://github.com/openwrt/openwrt/pull/965
Of coz meanwhile we would need to depend on statically linked binaries if we want edge of technology.

If anyone have time and adventurous enough, they might want to try compile themselves. Anyone?
https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-22#post-457050
 
Where/how did you find out this sad news?
Only recalling @kvic had asked back in the fall, I thought, and been told it wouldn't, and @merlin had poked at it but it involved closed source components.
 
@Xentrk

Small side note:
A wrong forwarding has crept into your description on GitHub. Under "2. DNSSEC Test" the second link hxxp://dnssec.vs.uni-due.de/ refers to hxxps://rootcanary.org/test.html.

:)
Hmm, okay. Thanks.

Fixed now. I plan to do the other message updates tomorrow.
 
Last edited:
Just finished making a minor update to install_stubby.sh. There is no urgent need to reinstall or update as the changes do not impact the functionality.

Changes:
  • Removed message in greeting menu that the use of Stubby on Asuswrt-Merlin is experimental. I think we can safely say that we have moved beyond the experimental stage at this point.
  • Corrected the incorrect path reference to stubby.yml in the comment section
  • Removed the comment that proxy-dnssec can cause issues with Quad9. One of the beta testers reported issues when testing the DNSSEC setting in Stubby when using Quad9. The two settings are not the same. proxy-dnssec is an option that resides in dnsmasq. The official definition from http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html listed below:
--proxy-dnssec
Copy the DNSSEC Authenticated Data bit from upstream servers to downstream clients and cache it. This is an alternative to having dnsmasq validate DNSSEC, but it depends on the security of the network between dnsmasq and the upstream servers, and the trustworthiness of the upstream servers.

References:
getdns 1.5 release notes: https://getdnsapi.net/releases/
Stubby 0.2.5: https://github.com/getdnsapi/stubby/releases/tag/v0.2.5
 
@Xentrk or @Adamm there's a PREARGS="nohup" in the S61stubby. This runs probably in a subshell of rc.unslung.

Why is it needed?
And could it be the cause that when rc.unslung stop with services-stop runs that it not properly terminates the service and therefore causing devices not properly unmount?
 
https://github.com/Entware/Entware/wiki/Compile-packages-from-sources
https://github.com/cotequeiroz/openwrt-1/tree/openssl-1.1_devcrypto/package/libs/openssl

I added this in getdns Makefile.
Code:
CONFIGURE_VARS += \
    LIBS="-Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic -lpthread -lc -lgcc_eh"
Trying to make one for Arm7. Never compile stuff before.

Inside getdns’s Makefile, there is already
Code:
CONFIGURE_VARS += LIBBSD_LIBS=-lc
Do we need to remove it or just add on the bottom?
Code:
CONFIGURE_VARS += \
    LIBS="-Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic -lpthread -lc -lgcc_eh"

Do we need to add anything to stubby’s Makefile?
 

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