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

RMerlin
Release Asuswrt-Merlin 386.14 is now available for AC models
8 9 10
Replies
186
Views
28K
bibikalka
B
D
Release GNUton [Official Fork] 388.8_2 Release
2
Replies
31
Views
6K
user_20240830
user_20240830
D
Release GNUTON- 388.7_1 release [Official FORK]
Replies
4
Views
3K
MatteoPV
M
RMerlin
New models to be introduced with 3006.102.2
4 5 6
Replies
116
Views
18K
sl4fko
sl4fko
Q
How to permanently disable autoconf on router (wsdd2 and avahi-daemon)
Replies
2
Views
181
Qwinn
Q
Similar threads
Thread starter Title Forum Replies Date
D Release GNUton [Official Fork] 388.8_2 Release Asuswrt-Merlin 31
D Release GNUTON- 388.7_1 release [Official FORK] Asuswrt-Merlin 4
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
RMerlin Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices Asuswrt-Merlin 28
B Unable to establish VPN connection to my PiVPN (ovpn) from my Asus RT-AC86U running Asuswrt-Merlin 386.14 Asuswrt-Merlin 1
F Several Questions Re:Asuswrt-Merlin Feature Implementation Asuswrt-Merlin 2
Yota How to enable port randomization in Asuswrt-Merlin? Asuswrt-Merlin 4
RMerlin Beta Asuswrt-Merlin 3006.102.2 Beta is now available for Wifi 7 devices Asuswrt-Merlin 70

Similar threads

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!

Members online

Total: 723 (members: 15, guests: 708)
Top