Menu
What's new
By:
Filters Better Search

Info: Stubby 0.2.3 (latest) is on entware.

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.
skeal

skeal

Part of the Furniture
Xentrk

Xentrk

Part of the Furniture
I have given stubby a try. It appears to be running. However, it fails the https://1.1.1.1/help test.

upload_2018-9-16_8-23-32.png


/opt/etc/stubby/stubby.yml
Code: 
#NOTE: See '/etc/stubby/stubby.yml.default' for original config file and descriptions
resolution_type: GETDNS_RESOLUTION_STUB
dnssec_return_status: GETDNS_EXTENSION_TRUE
appdata_dir: "/opt/var/cache/stubby"
tls_ca_file: "/opt/etc/ssl/certs/ca-certificates.crt"
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 10000
tls_backoff_time: 900
listen_addresses:
  - [email protected]

upstream_recursive_servers:
# IPv4 addresses
# # Cloudflare servers
  - address_data: 1.1.1.1
    tls_port: 853
    tls_auth_name: "cloudflare-dns.com"
                 
# # Cloudflare servers
  - address_data: 1.0.0.1    
    tls_port: 853            
    tls_auth_name: "cloudflare-dns.com"

/jffs/configs/dnsmasq.conf.add
Code: 
# Need these for stubby.  Commented out values means the parms are already in /etc/dnsmasq.conf
#no-resolv
#dnssec
 server=127.0.0.1#5453
listen-address=127.0.0.1

Start stubby and validate
Code: 
# stubby -g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log

# netstat -lnptu | grep stubby
tcp        0      0 127.0.0.1:5453          0.0.0.0:*               LISTEN      7899/stubby
udp        0      0 127.0.0.1:5453          0.0.0.0:*                           7899/stubby

 # ps | grep stubby | grep -v grep
 7899 wizard    4892 S    stubby -g -v 5 -C /opt/etc/stubby/stubby.yml
 
Last edited:
Xentrk

Xentrk

Part of the Furniture
john9527 said:
Turn off dnssec.....their test site is not configured correctly for dnssec.
Click to expand...
I remember reading about that in this tutorial.

Specimen
21d
I think I can confirm that there's an issue with cf's https://1.1.1.1/help 5 website, I've setup a stubby on a Windows 10 VM to test that site with DNSSEC on and off, so a setup that is completely different in terms of operating system, except for stubby.

In the default setup of stubby I only changed the upstream servers to be only cloudflare, turned off round robin, and tried with DNSSEC on and off and the results are the same, when DNSSEC is on the site fails to recognize the connection to 1.1.1.1 and DoT, when it's off it consistently recognizes, even thou in both cases it displays AS name as Cloudflare.

I did comment out the DNSSEC line in dnsmasq.conf.add. But I forgot to uncheck the DNSSEC radio button in the firmware. :oops:

/jffs/scripts/dnsmasq.conf.add
Code: 
# Need these for stubby. If comment out, already in /etc/dnsmasq.conf
no-resolv
#dnssec
 
server=127.0.0.1#5453
listen-address=127.0.0.1

I have it working now with some hacks! All of my testing was done on the WAN iface. I'll test using the OpenVPN client tomorrow.

View attachment 14442

The issue appears to be with the firmware DNS setting overriding stubby. The firmware will not allow me to put 127.0.0.1 as a DNS server IP. So, I specified 1.1.1.1 as DNS server 1 and nothing for DNS server 2.

upload_2018-9-16_19-1-5.png


The firmware then populates /tmp/resolv.dnsmasq as:

Code: 
server= 1.1.1.1
server= 10.9.0.1
server= 10.8.0.1

server=1.1.1.1

The 10.9.01 and 10.8.0.1 are the VPN DNS servers. I then changed the 1.1.1.1 to be the loop back IP address followed by a service restart_dnsmasq.

/tmp/resolv.dnsmasq after change

Code: 
server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server=127.0.0.1

Thinking of using the mount hack inside of init-start to allow my overrides to take priority over the firmware overriding changes to resolv.dnsmasq.
Code: 
 mount -o bind /jffs/scripts/resolv.dnsmasq /tmp/resolv.dnsmasq

It works using either one of the three configuration files pasted in the spoilers below. The key was to change
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
to
tls_authentication: GETDNS_AUTHENTICATION_NONE
Source: http://www.linksysinfo.org/index.php?threads/fork-tomato-arm-by-kille72.73397/page-18

I am using opportunistic mode because i could not get strict mode working after a reboot. Probably due to wrong router date/time.
Click to expand...
I'll look more into that setting tomorrow.

#NOTE: See '/etc/stubby/stubby.yml.default' for original config file and descriptions

resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
- GETDNS_TRANSPORT_TLS

#tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_authentication: GETDNS_AUTHENTICATION_NONE

tls_query_padding_blocksize: 128

edns_client_subnet_private : 0

round_robin_upstreams: 0

idle_timeout: 10000

listen_addresses:
- [email protected]
- 0::[email protected]

upstream_recursive_servers:
# IPv6 addresses
# # Cloudflare IPv6
- address_data: 2606:4700:4700::1111
tls_auth_name: "cloudflare-dns.com"

# # Quad 9 IPv6
# - address_data: 2620:fe::10
# tls_auth_name: "dns.quad9.net"

# IPv4 addresses
# # Cloudflare servers
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"

# Quad 9 service
# - address_data: 9.9.9.10
# tls_auth_name: "dns.quad9.net"

#NOTE: See '/etc/stubby/stubby.yml.default' for original config file and descriptions

resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
- GETDNS_TRANSPORT_TLS

tls_authentication: GETDNS_AUTHENTICATION_NONE

tls_query_padding_blocksize: 256

edns_client_subnet_private : 1

idle_timeout: 10000

listen_addresses:
- [email protected]
# - 0::[email protected]

round_robin_upstreams: 0

upstream_recursive_servers:
# Quad 9 IPv6
# - address_data: 2620:fe::fe
# tls_auth_name: "dns.quad9.net"
# IPv4 addresses
# The 1.1.1.1 Cloudflare Servers
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
tls_pubkey_pinset:
- digest: "sha256"
value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"
tls_pubkey_pinset:
- digest: "sha256"
value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

#NOTE: See '/etc/stubby/stubby.yml.default' for original config file and descriptions

resolution_type: GETDNS_RESOLUTION_STUB

dnssec_return_status: GETDNS_EXTENSION_TRUE

appdata_dir: "/opt/var/cache/stubby"

tls_ca_file: "/opt/etc/ssl/certs/ca-certificates.crt"

dns_transport_list:
- GETDNS_TRANSPORT_TLS

#tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_authentication: GETDNS_AUTHENTICATION_NONE

tls_query_padding_blocksize: 128

edns_client_subnet_private : 1

round_robin_upstreams: 1

idle_timeout: 10000

tls_backoff_time: 900

listen_addresses:
- [email protected]

upstream_recursive_servers:
# IPv4 addresses
# # Cloudflare servers
- address_data: 1.1.1.1
tls_port: 853
tls_auth_name: "cloudflare-dns.com"

# # Cloudflare servers
- address_data: 1.0.0.1
tls_port: 853
tls_auth_name: "cloudflare-dns.com"

I almost gave up on getting this to work. The post on the tomato form was the key. This topic has been of interest to me for the past year. Glad to have it working! Your recent stubby enhancement on the fork inspired me.

Hoping some others will now jump on this so we can collaborate on how to best implement stubby on Asuswrt-Merlin!

@thelonelycoder - Diversion is still blocking ads with dnsmasq+stubby!
 
Last edited:
Xentrk

Xentrk

Part of the Furniture
Created /opt/etc/init.d/S61stubby so stubby starts at boot:

Code: 
#!/bin/sh

ENABLED=yes
PROCS=stubby
ARGS="-g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log"
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func

Advantage is you can use one of the options below:
Code: 
start|stop|restart|check|kill|reconfigure

Example Usage
Code: 
[email protected]:/tmp/home/root# /opt/etc/init.d/S61stubby check
 Checking stubby...              alive.
[email protected]:/tmp/home/root# /opt/etc/init.d/S61stubby restart
 Shutting down stubby...              done.
 Starting stubby...              done.

Created /jffs/scripts/resolv.dnsmasq to override firmware handling of DNS on the Webgui. See post #5
Code: 
server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server=127.0.0.1

Still working on how to override firmware handling of /tmp/resolv.dnsmasq contents. Something like this?
Code: 
if [ "$(df | grep -c "/tmp/resolv.dnsmasq")" -eq "0" ]; then
 mount -o bind /jffs/scripts/resolv.dnsmasq /tmp/resolv.dnsmasq
 service restart_dnsmasq > /dev/null 2>&1
fi
After a reboot, the contents of /jffs/scripts/resolv.dnsmasq is 1.1.1.1 :eek:
 
Last edited:
Xentrk

Xentrk

Part of the Furniture
stubby is now working using Strict mode:
Code: 
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED

Not sure why it did not work before. o_O

This is the TL;DR on tls_authentication settings:
# Selects Strict or Opportunistic Usage profile as described in
# https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/
# Strict mode requires that authentication information for the upstreams is
# specified below. Opportunistic may fallback to clear text DNS if UDP or TCP is
# included in the transport list above.
# For Strict use GETDNS_AUTHENTICATION_REQUIRED
# For Opportunistic use GETDNS_AUTHENTICATION_NONE
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
Click to expand...

Stubby was not running again this morning. Something is killing the process. :confused: Requires some more analysis.

Still looking into how best to hack a fix for /tmp/resolv.dnsmasq.
 
Last edited:
Xentrk

Xentrk

Part of the Furniture
I solved the /tmp/resolv.dnsmasq update issue by creating a user script in /jffs/scripts/dnsmasq.postconf:

Code: 
#!/bin/sh
cp /jffs/configs/resolv.dnsmasq /tmp/resolv.dnsmasq
service restart_dnsmasq

/jffs/configs/resolv.dnsmasq
Code: 
server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server=127.0.0.1
stubby is now working on system restart!
 
skeal

skeal

Part of the Furniture
Xentrk said:
I solved the /tmp/resolv.dnsmasq update issue by creating a user script in /jffs/scripts/dnsmasq.postconf:

Code: 
#!/bin/sh
cp /jffs/configs/resolv.dnsmasq /tmp/resolv.dnsmasq
service restart_dnsmasq

jffs/configs/resolv.dnsmasq
Code: 
server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server= 127.0.0.1
server= 10.9.0.1
server= 10.8.0.1

server=127.0.0.1
stubby is now working on system restart!
Click to expand...
Wow! I am really interested in this! Hope we can install this on our routers soon! :)
 
Xentrk

Xentrk

Part of the Furniture
skeal said:
Wow! I am really interested in this! Hope we can install this on our routers soon! :)
Click to expand...

Since you have entware, you can install stubby using these commands:
Code: 
opkg update
opkg install stubby
opkg install ca-certificates
You probably already have ca-certificates installed. Look in /opt/etc/ssl

add to /jffs/scripts/dnsmasq.postconf
Code: 
cp /jffs/configs/resolv.dnsmasq /tmp/resolv.dnsmasq
[code]
If the file does not exist, add the shebang to the first line #!/bin/sh and make chmod 744

If you use an OpenVPN client, add the same to /jffs/scripts/openvpn-event

/jffs/configs/resolv.dnsmasq
[CODE]server=127.0.0.1

/opt/etc/stubby/stubby.yml
Code: 
# 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
appdata_dir: "/opt/var/cache/stubby"
listen_addresses:
  - [email protected]
  - 0::[email protected]

dnssec_return_status: GETDNS_EXTENSION_TRUE

listen_addresses:
  - [email protected]
  - 0::[email protected]
upstream_recursive_servers:
# Quad 9 Secure Primary
#  - address_data: 9.9.9.9
#    tls_auth_name: "dns.quad9.net"
# Quad 9 Secure Primary
#  - address_data: 2620:fe::fe
#    tls_auth_name: "dns.quad9.net"
# Cloudflare Primary IPv4
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Primary IPv6
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"

/opt/etc/init.d/S61stubby
Code: 
#!/bin/sh

ENABLED=yes
PROCS=stubby
ARGS="-g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log"
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func

/jffs/configs/dnsmasq.conf.add (also, disable DNSSEC in webgui)
Code: 
# Need these for stubby. If comment out, already in /etc/dnsmasq.conf
#no-resolv
server=127.0.0.1#5453
listen-address=127.0.0.1

Code: 
service restart_dnsmasq
/opt/etc/init.d/S61stubby start

You may need to do the dnsmasq.postconf hack in the previous post. Take note of the current values before making the update in case you need to restore. That should be all that is required. I still need to determine why stubby is not running the last two mornings. Perhaps the dnsmasq.postconf hack is the key. I'll see what happens tomorrow morning and take it from there.

Go to https://1.1.1.1/help to test.

I believe DNSSEC works with stubby. It is just the 1.1.1.1/help test site where DNSSEC does not work. I need to research this some more. But I think that is the take away from the posts I read in the openwrt.org forums.

And lastly, need to determine why stubby was not running when I checked the last two mornings. Maybe the dnsmasq.postconf hack will be the fix?

The maintainer of DNSCrypt stopped supporting it, closed the repository on GitHub and put the domain on sale.
 
Last edited:
skeal

skeal

Part of the Furniture
Xentrk said:
Since you have entware, you can install stubby using these commands:
Code: 
opkg update
opkg install stubby
opkg install ca-certificates
You probably already have ca-certificates installed. Look in /opt/etc/ssl

/opt/etc/stubby/stubby.yml
Code: 
#NOTE: See '/etc/stubby/stubby.yml.default' for original config file and descriptions
resolution_type: GETDNS_RESOLUTION_STUB
dnssec_return_status: GETDNS_EXTENSION_TRUE
appdata_dir: "/opt/var/cache/stubby"
tls_ca_file: "/opt/etc/ssl/certs/ca-certificates.crt"
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 256
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 10000
tls_backoff_time: 900
listen_addresses:
  - [email protected]
upstream_recursive_servers:
# IPv4 addresses
# # Cloudflare servers
  - address_data: 1.1.1.1
    tls_port: 853
    tls_auth_name: "cloudflare-dns.com"
                 
# # Cloudflare servers
  - address_data: 1.0.0.1    
    tls_port: 853            
    tls_auth_name: "cloudflare-dns.com"

/opt/etc/init.d/S61stubby
Code: 
#!/bin/sh

ENABLED=yes
PROCS=stubby
ARGS="-g -v 5 -C /opt/etc/stubby/stubby.yml 2>/opt/var/log/stubby.log"
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func

/jffs/configs/dnsmasq.conf.add (also, disable DNSSEC in webgui)
Code: 
# Need these for stubby. If comment out, already in /etc/dnsmasq.conf
no-resolv
#dnssec
 server=127.0.0.1#5453
listen-address=127.0.0.1
You may need to do the dnsmasq.postconf hack in the previous post. Take note of the current values before making the update in case you need to restore. That should be all that is required. I still need to determine why stubby is not running the last two mornings. Perhaps the dnsmasq.postconf hack is the key. I'll see what happens tomorrow morning and take it from there.

Go to https://1.1.1.1/help to test.

The maintainer of DNSCrypt stopped supporting it, closed the repository on GitHub and put the domain on sale.
Click to expand...
I'll wait to do this tomorrow after your next post. The stubby not running the next day concerns me, I know you will figure it out!! Would be great to have an installer. This would take off like a rocket if it did!! So excited!! :)
 
Xentrk

Xentrk

Part of the Furniture
Ugh! One of my changes broke something. Diversion is not blocking ads any longer and I'm having routing issues e.g. unable to resolve some websites. Will pick it up tomorrow. I'll reverse my changes and implement one by one to see where it breaks. Looks like the revisions to /tmp/resolv.dnsmasq may be a concern or with my /opt/etc/init.d/S61snubby script. The end goal is to have dnsmasq work with stubby DNS over TLS.
 
owine

owine

Regular Contributor
I don't understand the need to mess around with resolv.dnsmasq. I presently use the dnscrypt-proxy installer, but previously when I had it setup manually the only config changes required were adding no-resolv to dnsmasq.conf.add and an entry to point dnsmasq to the resolving proxy/stub. I have the DNS fields blank on both the WAN and LAN pages on the webui and both my resolv.dnsmasq and resolv.conf files are accordingly blank. The router only points to itself (i.e. dnsmasq) for DNS resolution which is in turn set to use the proxy/stub set in dnsmasq.conf.add. In review of the manager code provided by the installer from bigeyes0x0, these are the same revisions it makes (in a different manner) and does not need the resolv.dnsmasq changes.
 
Xentrk

Xentrk

Part of the Furniture
owine said:
I don't understand the need to mess around with resolv.dnsmasq.
Click to expand...
Me either! I thought the no-resolv line in /jfffs/configs/dnsmasq.conf.add was the option to have dnsmasq ignore resolv.conf and resolv.dnsmasq. I saw some forum posts where the hack to resolv.dnsmasq was required.

owine said:
I presently use the dnscrypt-proxy installer, but previously when I had it setup manually the only config changes required were adding no-resolv to dnsmasq.conf.add and an entry to point dnsmasq to the resolving proxy/stub. I have the DNS fields blank on both the WAN and LAN pages on the webui and both my resolv.dnsmasq and resolv.conf files are accordingly blank.
Click to expand...
The firmware does not allow me to leave the DNS setting on the WAN page empty with a caveat. The default is to use the DNS server of the ISP.
upload_2018-9-19_13-40-2.png


/tmp/resolv.dnsmasq
Code: 
server= 1.1.1.1
server= 10.9.0.1
server= 10.8.0.1

server= 1.1.1.1
server= 10.9.0.1
server= 10.8.0.1

server=110.164.252.222
server=110.164.252.223
Note the 1.1.1.1 entries. Did stubby create those?
upload_2018-9-19_13-40-37.png


/tmp/resolv.dnsmasq
Code: 
server= 1.1.1.1
server= 10.9.0.1
server= 10.8.0.1

server=1.1.1.1

owine said:
The router only points to itself (i.e. dnsmasq) for DNS resolution which is in turn set to use the proxy/stub set in dnsmasq.conf.add. In review of the manager code provided by the installer from bigeyes0x0, these are the same revisions it makes (in a different manner) and does not need the resolv.dnsmasq changes.
Click to expand...

I have stubby working when either /tmp/resolv.conf and /tmp/resolv.dnsmasq are empty or contain the values nameserver 127.0.0.1 and server=127.0.0.1 respectively. The routing issues I reported in my prior post are now solved! Unfortunately, the Diversion ad blocker is the only item that appears to not work. I have not tested my VPN interfaces yet. Everything so far has been done on the WAN iface. I also enabled DNSSEC and https://1.1.1.1/help page reports sweet success!

View attachment 14478

At this point, I have hit a wall and not sure what other steps to take. I did more web searches and nothing new arose. Hoping that @john9527, @RMerlin or another forum member can help on the work accomplished so far.
 
owine

owine

Regular Contributor
Xentrk said:
Me either! I thought the no-resolv line in /jfffs/configs/dnsmasq.conf.add was the option to have dnsmasq ignore resolv.conf and resolv.dnsmasq. I saw some forum posts where the hack to resolv.dnsmasq was required.


The firmware does not allow me to leave the DNS setting on the WAN page empty with a caveat. The default is to use the DNS server of the ISP.
View attachment 14476
Click to expand...
Set this to No.

Xentrk said:
View attachment 14477
Click to expand...
Leave this set as No and blank both DNS fields (you currently have 1.1.1.1 defined)

On the LAN -> DHCP Server page, make sure both DNS fields are blank but set "Advertise router's IP in addition to user-specified DNS" to Yes.
 
skeal

skeal

Part of the Furniture
On my router you cannot leave both fields of WAN DNS to nothing. It cannot be done.
 
skeal

skeal

Part of the Furniture
[email protected] said:
I was about to confirm that, but I can leave them blank and apply. That's on 384.7 beta 1, btw.
Click to expand...
You cannot do that when using a static ip however. I have a static ip.
 
M

[email protected]

Guest
skeal said:
You cannot do that when using a static ip however. I have a static ip.
Click to expand...

Ah, I see. I have a 'static' IP as well, but it's assigned by DHCP from my ISP, so my configuration is probably different from yours.

Edit: 'Static' as in it hasn't changed in years. I believe they use the ISP's routers MAC-address for assignment, (not just like a static lease, apparently they 'calculate' your IP based on your MAC address, within their own pool) so as long as I don't get a new router from them, my IP will remain the same.
 
You must log in or register to reply here.
Similar threads
Thread starter Title Forum Replies Date
G date info on RT-AX86U when logging to SSH Asuswrt-Merlin 2
D What causes this info in the log Asuswrt-Merlin 11
D New info in system log. Does anyone know what it might be? Asuswrt-Merlin 8
P How to clear obsolete Client status info? (RT-AC86U, Merlin 384.18) Asuswrt-Merlin 5
L Customize stubby.yml Asuswrt-Merlin 4
doublehd Hi guys,need a help about stubby logging thru SSH Asuswrt-Merlin 12
M DNS-over-TLS very slow (up to 10 seconds/query) via stubby, fast if queried directly on RT-AC86U Asuswrt-Merlin 10
I how to fix this RT-AC86U latest asuswrt merlin Asuswrt-Merlin 1
D RT AC68U can't achieve more than 600Mbps on latest firmware Asuswrt-Merlin 13
fafot Upgrading RT-AC87U from Merlin 380.65_2 to the latest 384.13_10 Asuswrt-Merlin 2

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: 535 (members: 35, guests: 500)
Top