Menu
What's new
By:
Filters Better Search

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

I have noticed my dns getting a bit buggy and would like to update stubby. Is there a reasonably simple way to do this?
 
000111 said:
I have noticed my dns getting a bit buggy and would like to update stubby. Is there a reasonably simple way to do this?
Click to expand...

Stubby hasn't been updated since last spring.
 
Thanks, rmerlin. In that case I will look into my stubby settings and see if I can find something that works reliably for me.
 
000111 said:
Thanks, rmerlin. In that case I will look into my stubby settings and see if I can find something that works reliably for me.
Click to expand...
John’s dev build 40E9 contains newer Stubby/GetDNS code, but it’s broken on MIPS routers.
 
000111 said:
Thanks, rmerlin. In that case I will look into my stubby settings and see if I can find something that works reliably for me.
Click to expand...
dave14305 said:
John’s dev build 40E9 contains newer Stubby/GetDNS code, but it’s broken on MIPS routers.
Click to expand...
Cloudflare by any chance? I can’t say whether it is cloudflare, 40E9, some combination of both, or none of the above, but I started having a lot of lookup problems with it a few weeks ago. After some troubleshooting, switching off DoT and using typical dns fixed it.
 
jrmwvu04 said:
Cloudflare by any chance? I can’t say whether it is cloudflare, 40E9, some combination of both, or none of the above, but I started having a lot of lookup problems with it a few weeks ago. After some troubleshooting, switching off DoT and using typical dns fixed it.
Click to expand...
Yup, I had this problem since long ago, because the router seems to need DNS resolving before it is able to properly start Entware and DoT. I solved it this way: flashed OpenWRT to an old RT-N16, which has become my DNS server (running stubby). Both my routers are behind the modem/router from my internet provider.
 
slobodan said:
Yup, I had this problem since long ago, because the router seems to need DNS resolving before it is able to properly start Entware and DoT. I solved it this way: flashed OpenWRT to an old RT-N16, which has become my DNS server (running stubby). Both my routers are behind the modem/router from my internet provider.
Click to expand...
I created a stubby.postconf for the fork that ensures Stubby can resolve hostnames apart from dnsmasq during startup. Stole the idea from Merlin’s implementation.
Code: 
#!/bin/sh

. /usr/sbin/helper.sh

CONFIG="$1"

[ $(uname -o) = "ASUSWRT-Merlin-LTS" ] && pc_append 'resolvconf: "/tmp/resolv.conf"' "$CONFIG"
 
jrmwvu04 said:
Cloudflare by any chance? I can’t say whether it is cloudflare, 40E9, some combination of both, or none of the above, but I started having a lot of lookup problems with it a few weeks ago. After some troubleshooting, switching off DoT and using typical dns fixed it.
Click to expand...
Same here .. cloudflare issues started a few weeks ago.

Was running 39e3 since April .. Switched to 40e9 for testing .. Same problem.

Now I allowed tls 12 to make it stable again .. (tls_min_version: GETDNS_TLS1_2 into stubby.yml.add )

If you keep tls 13 you get tons of disconnects and DNS timeouts.

For me the DNS problem started a few weeks ago .. did not change my config since April (39e3)
Had no DNS timeouts before.

Still don't know the root cause ..
 
Last edited:
This fixed the Cloudflare DoT issue for me:
Save this file as /jffs/scripts/stubby.postconf
Code: 
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh

pc_replace "tls_min_version: GETDNS_TLS1_3" "tls_min_version: GETDNS_TLS1_2" $CONFIG
Run this command to make the file executable:
Code: 
chmod 777 /jffs/scripts/stubby.postconf
Then reboot the router
 
Rahul_K said:
This fixed the Cloudflare DoT issue for me:
Save this file as /jffs/scripts/stubby.postconf
Code: 
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh

pc_replace "tls_min_version: GETDNS_TLS1_3" "tls_min_version: GETDNS_TLS1_2" $CONFIG
Run this command to make the file executable:
Code: 
chmod 777 /jffs/scripts/stubby.postconf
Then reboot the router
Click to expand...
Like mentioned above .. have a try to add "tmp/resolv.conf".
Will test it later today ..

Hope to keep stable tls 13 connection with cloudflare.
 
dave14305 said:
I created a stubby.postconf for the fork that ensures Stubby can resolve hostnames apart from dnsmasq during startup. Stole the idea from Merlin’s implementation.
Code: 
#!/bin/sh

. /usr/sbin/helper.sh

CONFIG="$1"

[ $(uname -o) = "ASUSWRT-Merlin-LTS" ] && pc_append 'resolvconf: "/tmp/resolv.conf"' "$CONFIG"
Click to expand...

Should this work on MIPS?
 
Hi all,

quick question, maybe somebody has a handy solution for this already.

After the latest hack on various IoT devices, I would like to shield my IoT devices from the rest of my LAN.
I know I could achieve that by having them logging into a guest Wifi network, which I can set to be AP isolated.

But isnt there any chance by some clever IPTable settings, to allow them to connect to the internet but not to other internal LAN devices? So I can avoid having a guest network spinned up just for this reason?

Thanks for suggestions
Andi
 
dave14305 said:
I created a stubby.postconf for the fork that ensures Stubby can resolve hostnames apart from dnsmasq during startup. Stole the idea from Merlin’s implementation.
Code: 
#!/bin/sh

. /usr/sbin/helper.sh

CONFIG="$1"

[ $(uname -o) = "ASUSWRT-Merlin-LTS" ] && pc_append 'resolvconf: "/tmp/resolv.conf"' "$CONFIG"
Click to expand...

Qickly tested this stuff ..

The stubby.postconf script is adding ..
Code: 
resolvconf: "/tmp/resolv.conf"
in to stubby.yml .. same if you add the line to stubby.yml.add .. 2 ways to reach the same result.

Nevertheless it's not working .. still get tons of timeouts ..

Code: 
tail -f /var/tmp/stubby/stubby.log

[10:14:21.487405] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:21.531755] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:38.400879] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:48.018173] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:53.828763] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:56.820409] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:56.820724] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:56.820957] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:56.821249] STUBBY:    *FAILURE* no valid transports or upstreams available!

stubby -C /etc/stubby.yml -l
[10:45:26.260719] STUBBY: Read config from file /etc/stubby.yml
[10:45:26.261528] STUBBY: DNSSEC Validation is OFF
[10:45:26.261614] STUBBY: Transport list is:
[10:45:26.261663] STUBBY:   - TLS
[10:45:26.261719] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[10:45:26.261773] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[10:45:26.261820] STUBBY: Starting DAEMON....
[10:45:28.540867] STUBBY: --- SETUP(TLS): : Verify locations loaded
[10:45:28.541406] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.576086] STUBBY: 1.1.1.1                                  : Conn closed: TLS - *Failure*
[10:45:28.576563] STUBBY: 1.0.0.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.576785] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[10:45:28.577055] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[10:45:28.577292] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=     0, Conn_fails=     1, Conn_shuts=      0, Backoffs     =     0
[10:45:28.611253] STUBBY: 1.0.0.1                                  : Conn closed: TLS - *Failure*
[10:45:28.611842] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.612057] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:45:28.613141] STUBBY: 1.0.0.1                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[10:45:28.613462] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[10:45:28.613701] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Conns=     0, Conn_fails=     1, Conn_shuts=      0, Backoffs     =     0
[10:45:28.653157] STUBBY: 1.1.1.1                                  : Conn closed: TLS - *Failure*
[10:45:28.653755] STUBBY: 1.0.0.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.653980] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[10:45:28.654248] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[10:45:28.654485] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=     0, Conn_fails=     2, Conn_shuts=      0, Backoffs     =     0
[10:45:28.688670] STUBBY: 1.0.0.1                                  : Conn closed: TLS - *Failure*
[10:45:28.689263] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.689472] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:45:28.689922] STUBBY: 1.0.0.1                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[10:45:28.690224] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[10:45:28.690465] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Conns=     0, Conn_fails=     2, Conn_shuts=      0, Backoffs     =     0
[10:45:28.715978] STUBBY: 1.1.1.1                                  : Conn closed: TLS - *Failure*
[10:45:28.716557] STUBBY: 1.0.0.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.716776] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[10:45:28.717043] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[10:45:28.717283] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=     0, Conn_fails=     3, Conn_shuts=      0, Backoffs     =     0
[10:45:28.756008] STUBBY: 1.0.0.1                                  : Conn closed: TLS - *Failure*
[10:45:28.756582] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.756794] STUBBY:    *FAILURE* no valid transports or upstreams available!

My stubby.yml.add ..
Code: 
tls_min_version: GETDNS_TLS1_2
idle_timeout: 10000
timeout: 3000
resolvconf: "/tmp/resolv.conf"

I have RT-AC68U device running on 40E9 now .. same problem with 39E3.

How to get (back) stable TLS_V13 connection with cloudflare (1.1.1.1) ?
 
Andi P said:
So I can avoid having a guest network spinned up just for this reason?
Click to expand...
There is nothing bad about guest network (only a second beacon is sent out using about 1% airtime, not worth to mention), you could even hide it.
Its pretty perfect for this purpose.
 
followmsi said:
Qickly tested this stuff ..

The stubby.postconf script is adding ..
Code: 
resolvconf: "/tmp/resolv.conf"
in to stubby.yml .. same if you add the line to stubby.yml.add .. 2 ways to reach the same result.

Nevertheless it's not working .. still get tons of timeouts ..

I have RT-AC68U device running on 40E9 now .. same problem with 39E3.

How to get (back) stable TLS_V13 connection with cloudflare (1.1.1.1) ?
Click to expand...
Here AC56U with 40E9, using stubby with Cleanbrowsing. I don't have this problem. Too lazy to try Quad1.

BTW, I no longer use the N16 as DNS server.
 
followmsi said:
Qickly tested this stuff ..

The stubby.postconf script is adding ..
Code: 
resolvconf: "/tmp/resolv.conf"
in to stubby.yml .. same if you add the line to stubby.yml.add .. 2 ways to reach the same result.

Nevertheless it's not working .. still get tons of timeouts ..

Code: 
tail -f /var/tmp/stubby/stubby.log

[10:14:21.487405] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:21.531755] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:38.400879] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:48.018173] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:53.828763] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:56.820409] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:56.820724] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:56.820957] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:14:56.821249] STUBBY:    *FAILURE* no valid transports or upstreams available!

stubby -C /etc/stubby.yml -l
[10:45:26.260719] STUBBY: Read config from file /etc/stubby.yml
[10:45:26.261528] STUBBY: DNSSEC Validation is OFF
[10:45:26.261614] STUBBY: Transport list is:
[10:45:26.261663] STUBBY:   - TLS
[10:45:26.261719] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[10:45:26.261773] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[10:45:26.261820] STUBBY: Starting DAEMON....
[10:45:28.540867] STUBBY: --- SETUP(TLS): : Verify locations loaded
[10:45:28.541406] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.576086] STUBBY: 1.1.1.1                                  : Conn closed: TLS - *Failure*
[10:45:28.576563] STUBBY: 1.0.0.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.576785] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[10:45:28.577055] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[10:45:28.577292] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=     0, Conn_fails=     1, Conn_shuts=      0, Backoffs     =     0
[10:45:28.611253] STUBBY: 1.0.0.1                                  : Conn closed: TLS - *Failure*
[10:45:28.611842] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.612057] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:45:28.613141] STUBBY: 1.0.0.1                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[10:45:28.613462] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[10:45:28.613701] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Conns=     0, Conn_fails=     1, Conn_shuts=      0, Backoffs     =     0
[10:45:28.653157] STUBBY: 1.1.1.1                                  : Conn closed: TLS - *Failure*
[10:45:28.653755] STUBBY: 1.0.0.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.653980] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[10:45:28.654248] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[10:45:28.654485] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=     0, Conn_fails=     2, Conn_shuts=      0, Backoffs     =     0
[10:45:28.688670] STUBBY: 1.0.0.1                                  : Conn closed: TLS - *Failure*
[10:45:28.689263] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.689472] STUBBY:    *FAILURE* no valid transports or upstreams available!
[10:45:28.689922] STUBBY: 1.0.0.1                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[10:45:28.690224] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[10:45:28.690465] STUBBY: 1.0.0.1                                  : Upstream   : TLS - Conns=     0, Conn_fails=     2, Conn_shuts=      0, Backoffs     =     0
[10:45:28.715978] STUBBY: 1.1.1.1                                  : Conn closed: TLS - *Failure*
[10:45:28.716557] STUBBY: 1.0.0.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.716776] STUBBY: 1.1.1.1                                  : Conn closed: TLS - Resps=     0, Timeouts  =     0, Curr_auth =   None, Keepalive(ms)=     0
[10:45:28.717043] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Resps=     0, Timeouts  =     0, Best_auth =   None
[10:45:28.717283] STUBBY: 1.1.1.1                                  : Upstream   : TLS - Conns=     0, Conn_fails=     3, Conn_shuts=      0, Backoffs     =     0
[10:45:28.756008] STUBBY: 1.0.0.1                                  : Conn closed: TLS - *Failure*
[10:45:28.756582] STUBBY: 1.1.1.1                                  : Conn opened: TLS - Strict Profile
[10:45:28.756794] STUBBY:    *FAILURE* no valid transports or upstreams available!

My stubby.yml.add ..
Code: 
tls_min_version: GETDNS_TLS1_2
idle_timeout: 10000
timeout: 3000
resolvconf: "/tmp/resolv.conf"

I have RT-AC68U device running on 40E9 now .. same problem with 39E3.

How to get (back) stable TLS_V13 connection with cloudflare (1.1.1.1) ?
Click to expand...
Can you run
Code: 
stubby -C /etc/stubby.yml -i
and post the config results?
 
What version of OpenSSL does Stubby use in 39E? According to https://github.com/getdnsapi/stubby/issues/130#issuecomment-421774281 Stubby should use the system's version of OpenSSL, which in 39E is OpenSSL 1.0.2r . But stubby -C /etc/stubby.yml -i has this line:

"openssl_version_string": <bindata of "OpenSSL 1.1.1b 26 Feb 2019">,
Click to expand...

OpenSSL 1.0.2r doesn't seem to support TLS 1.3. When I run echo | openssl s_client -tls1_3 -connect 1.1.1.1:853 I get the error unknown option -tls1_3
 
Rahul_K said:
What version of OpenSSL does Stubby use in 39E? According to https://github.com/getdnsapi/stubby/issues/130#issuecomment-421774281 Stubby should use the system's version of OpenSSL, which in 39E is OpenSSL 1.0.2r . But stubby -C /etc/stubby.yml -i has this line:



OpenSSL 1.0.2r doesn't seem to support TLS 1.3. When I run echo | openssl s_client -tls1_3 -connect 1.1.1.1:853 I get the error unknown option -tls1_3
Click to expand...
For stubby John has built and linked openssl 1.1 static lib.

As I understood in Merlin build there is also openssl11 binary to test openssl standalone.
In John's fork there is no openssl11 binary just the staitc lib for stubby.
 
You must log in or register to reply here.

Similar threads

C
Where to Download GNUton's Asus Merlin For DSL-AC68U
Replies
5
Views
519
sabrewulf86
S
David Cavalli
Merlin "End of Life" for 386.x firmware implications
2
Replies
20
Views
2K
dfunked
D
RMerlin
  • Locked
Beta Asuswrt-Merlin 3004.388.6 Beta is now available
12 13 14
Replies
279
Views
35K
RMerlin
RMerlin
RMerlin
  • Locked
Beta Asuswrt-Merlin 386.10 beta is now available for AC models
2 3
Replies
44
Views
11K
RMerlin
RMerlin
RMerlin
Release Asuswrt-Merlin 3004.388.4 is now available
33 34 35
Replies
692
Views
105K
Unetwork
U
Similar threads
Thread starter Title Forum Replies Date
J How do I use GNUton's fork for my DSL-AX82U please. Asuswrt-Merlin 6
Z Sudden network issues, looking to fully reset my TUF-AX5400 router running Gnuton's Merlin fork Asuswrt-Merlin 1
F [Issue] Flashing With Merlin Fork GNUton 3004.388.4_0 on Zen Wifi XT8 Asuswrt-Merlin 2
TwoWheels CT8/AC3000 and ASUSWRT? Asuswrt-Merlin 6
RMerlin Beta Asuswrt-Merlin 3004.388.7 beta is now available Asuswrt-Merlin 100
H Solved xbox one not able to sign in when connected through router running asuswrt-merlin on an rt-ac5300. Asuswrt-Merlin 5
RMerlin Release Asuswrt-Merlin 386.13 is now available for AC models Asuswrt-Merlin 38
RMerlin Beta Asuswrt-Merlin 386.13 beta is now available for AC models Asuswrt-Merlin 32
visortgw asuswrt-merlin.net Website Site Down? Asuswrt-Merlin 18
C Asuswrt-Merlin 3004.388.6 Memory Leak Asuswrt-Merlin 13

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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

Members online

Total: 1,151 (members: 34, guests: 1,117)
Top