Stubby-Installer-Asuswrt-Merlin

[elorimer]

Forgive me if you've dealt with this already, but my install didn't include "export TZ=$(cat /etc/TZ)" in either the stubby or haveged init.d scripts. The logs are misstamped as a result.

 

[Mutzli]

When I looked at this, it would seem that firefox uses DoH connection to facilitate this. When you run the https://1.1.1.1/help it shows the DoH as in use. It used to anyway, maybe it has changed.

Here is what I get with above Firefox config:
Debug Information
Connected to 1.1.1.1 Yes
Using DNS over HTTPS (DoH) Yes
Using DNS over TLS (DoT) Yes
AS Name Cloudflare
AS Number 13335
Cloudflare Data Center DTW
Connectivity to Resolver IP Addresses
1.1.1.1 Yes
1.0.0.1 Yes
2606:4700:4700::1111 Yes
2606:4700:4700::1001 No

 

[elorimer]

I'm not clear on how things ended up the last few pages, but on a reboot I have this in the log:

Feb 10 10:57:25 RT-AC87R (install_stubby.sh): 670 Ending Script Execution
Feb 10 10:57:25 RT-AC87R (install_stubby.sh): 1528 Ending Script Execution

 

[Adamm]

I'm not clear on how things ended up the last few pages, but on a reboot I have this in the log:

Feb 10 10:57:25 RT-AC87R (install_stubby.sh): 670 Ending Script Execution
Feb 10 10:57:25 RT-AC87R (install_stubby.sh): 1528 Ending Script Execution

Update to the latest version, the logging has been updated.

 

[skeal]

I'm not clear on how things ended up the last few pages, but on a reboot I have this in the log:

Feb 10 10:57:25 RT-AC87R (install_stubby.sh): 670 Ending Script Execution
Feb 10 10:57:25 RT-AC87R (install_stubby.sh): 1528 Ending Script Execution

@Adamm This looks familiar doesn't it?

 

[Adamm]

@Adamm This looks familiar doesn't it?

Its not an issue, its debug print that was badly originally implemented. The reason it never showed up previously was because exit_message() was called so the script never reached the end of the file. The new iptables function did reach the end of the file so during the firewall events this debug print was appearing.

Anyway this has been fixed earlier today.

 

[skeal]

Its not an issue, its debug print that was badly originally implemented. The reason it never showed up previously was because exit_message() was called so the script never reached the end of the file. The new iptables function did reach the end of the file so during the firewall events this debug print was appearing.

Anyway this has been fixed earlier today.

I can see now that the logging is correct but I still see two entries of each (udp) and (tcp) prerouting. I would think that this is cosmetic and that nothing is wrong except an additional ip tables entry.

Edit Update: Running "service restart_firewall" command clears the prerouting problem and it displays properly. Hmmm!

 

[DonnyJohnny]

Question on the new setting that forces all traffic through stubby DNS. Firefox offers the Encrypt SNI feature, when enabled it uses its own DNS resolver. If I force all client DNS requests through Stubby does that really force Firefox to use Cloudflare DNS through Stubby when Network TRR is active? Or do I get a "false positive" (as in circumventing the Stubby) since Firefox is using Cloudfare as well?
Here is how I have configured Firefox:
network.security.esni.enabled;true
network.trr.mode;2
network.trr.bootstrapAddress;1.1.1.1

If Firefox trr is active (via doh port 443 and not dns port 53), it will bypass stubby in any way as it is hardcore by Firefox. So to use stubby and diversion, you need to disable Firefox trr.

 

[Adamm]

I can see now that the logging is correct but I still see two entries of each (udp) and (tcp) prerouting. I would think that this is cosmetic and that nothing is wrong except an additional ip tables entry.

Theres no reason that would be caused by the script, every time it runs an iptables add command (-A), it first runs an iptables delete command (-D). Mathematically there can't be more then 1 at a time. Make sure this isn't caused by a custom script or DNSFilter

 

[skeal]

Theres no reason that would be caused by the script, every time it runs an iptables add command (-A), it first runs an iptables delete command (-D). Mathematically there can't be more then 1 at a time. Make sure this isn't caused by a custom script or DNSFilter

The only custom scripts I have are manually run. There would be nothing I have made that affects this. I can include the two custom scripts that do not run at startup if you want. Other than that I have what is offered in AMTM installed from there and maintained form there. I have two custom scripts. One I run to unmount both of my usb drives before reboot. This is run only to cause the system to reboot. It has nothing to do with start up as its done it's job. The other is a vpn warning log remover that I run when it is necessary. I have not had to run that little sed -i script in months and it's not running in the background it runs once. That is all I have on this router (AC3100). Yes mathematically it is impossible, but it is real. I can reproduce over and over. Check my signature under this post. That's all I got going. Thanks @Adamm for sticking with this!!

 

[elorimer]

Update to the latest version, the logging has been updated.

Thanks, thought I had. But I did again through amtm, fixed the time zone, and rebooted. The log messages aren't there now, and neither are the PREROUTING port forwards in the port forward page.

 

[dave14305]

The only custom scripts I have are manually run. There would be nothing I have made that affects this. I can include the two custom scripts that do not run at startup if you want. Other than that I have what is offered in AMTM installed from there and maintained form there. I have two custom scripts. One I run to unmount both of my usb drives before reboot. This is run only to cause the system to reboot. It has nothing to do with start up as its done it's job. The other is a vpn warning log remover that I run when it is necessary. I have not had to run that little sed -i script in months and it's not running in the background it runs once. That is all I have on this router (AC3100). Yes mathematically it is impossible, but it is real. I can reproduce over and over. Check my signature under this post. That's all I got going. Thanks @Adamm for sticking with this!!

Have you confirmed you're not opening your firewall for incoming DNS requests from the WAN? You're not putting any DNS rules in the https://router.asus.com/Advanced_VirtualServer_Content.asp page?
Nevermind. Looking through the Merlin code, I see that the page filters out DNSFilter rules, which is why I never saw similar entries.

 

[eclp]

Sorry, I have to ask again exactly.
The second option "Would you like to force all client DNS requests through Stubby" (Question mark missing) is completely the same as in the router GUI:
LAN --> DNSFilter --> Enable DNS-based Filtering (ON) --> Global Filter Mode (Router); (all fields empty)?

 

[Butterfly Bones]

I can see now that the logging is correct but I still see two entries of each (udp) and (tcp) prerouting. I would think that this is cosmetic and that nothing is wrong except an additional ip tables entry.

Edit Update: Running "service restart_firewall" command clears the prerouting problem and it displays properly. Hmmm!

As I mentioned last night, my scheduled reboot via cron was perfect, everything shutdown and / or unmounted properly. :thumbsup:
Here are the relevant stubby lines of the startup (including the scripts that called it) and even though stubby runs three times, I only have two instances, one UDP, one TCP in Port Forwarding. At the end the stubby script shows stopping three times, but no issues with that.

Feb 10 05:01:01 custom_script: Running /jffs/scripts/nat-start
Feb 10 05:01:01 (install_stubby.sh): 1341 Starting Script Execution
Feb 10 05:01:02 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Feb 10 05:01:03 custom_script: Running /jffs/scripts/nat-start
Feb 10 05:01:03 (install_stubby.sh): 1435 Starting Script Execution
Feb 10 05:01:03 custom_script: Running /jffs/scripts/pre-mount (args: /dev/sda1 ) - max timeout = 120s
Feb 10 05:01:03 amtm: Running disk check 'e2fsck -p' on /dev/sda1
Feb 10 05:01:03 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/SNB ) - max timeout = 120s
Feb 10 05:01:03 haveged: haveged starting up
Feb 10 05:01:03 admin: Started haveged from /jffs/scripts/post-mount.
Feb 10 05:01:03 S61stubby: start Stubby DNS over TLS /opt/etc/init.d/S61stubby
Feb 10 05:01:04 haveged: haveged: ver: 1.9.4; arch: generic; vend: ; build: (gcc 7.3.0 CV); collect: 128K
Feb 10 05:01:04 haveged: haveged: cpu: (); data: 32K (P); inst: 32K (P); idx: 18/40; sz: 30888/71320
Feb 10 05:01:04 haveged: haveged: fills: 0, generated: 0
Feb 10 05:01:05 admin: Started stubby from /jffs/scripts/post-mount.
Feb 10 05:01:13 custom_script: Running /jffs/scripts/nat-start
Feb 10 05:01:13 (install_stubby.sh): 2312 Starting Script Execution
Feb 10 05:01:13 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Feb 10 05:01:14 rc_service: udhcpc 1047:notify_rc start_vpnclient1
Feb 10 05:01:16 (install_stubby.sh): 1341 Ending Script Execution
Feb 10 05:01:16 (install_stubby.sh): 2312 Ending Script Execution
Feb 10 05:01:16 (install_stubby.sh): 1435 Ending Script Execution

 

[Xentrk]

As I mentioned last night, my scheduled reboot via cron was perfect, everything shutdown and / or unmounted properly. :thumbsup:
Here are the relevant stubby lines of the startup (including the scripts that called it) and even though stubby runs three times, I only have two instances, one UDP, one TCP in Port Forwarding. At the end the stubby script shows stopping three times, but no issues with that.

Feb 10 05:01:01 custom_script: Running /jffs/scripts/nat-start
Feb 10 05:01:01 (install_stubby.sh): 1341 Starting Script Execution
Feb 10 05:01:02 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Feb 10 05:01:03 custom_script: Running /jffs/scripts/nat-start
Feb 10 05:01:03 (install_stubby.sh): 1435 Starting Script Execution
Feb 10 05:01:03 custom_script: Running /jffs/scripts/pre-mount (args: /dev/sda1 ) - max timeout = 120s
Feb 10 05:01:03 amtm: Running disk check 'e2fsck -p' on /dev/sda1
Feb 10 05:01:03 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/SNB ) - max timeout = 120s
Feb 10 05:01:03 haveged: haveged starting up
Feb 10 05:01:03 admin: Started haveged from /jffs/scripts/post-mount.
Feb 10 05:01:03 S61stubby: start Stubby DNS over TLS /opt/etc/init.d/S61stubby
Feb 10 05:01:04 haveged: haveged: ver: 1.9.4; arch: generic; vend: ; build: (gcc 7.3.0 CV); collect: 128K
Feb 10 05:01:04 haveged: haveged: cpu: (); data: 32K (P); inst: 32K (P); idx: 18/40; sz: 30888/71320
Feb 10 05:01:04 haveged: haveged: fills: 0, generated: 0
Feb 10 05:01:05 admin: Started stubby from /jffs/scripts/post-mount.
Feb 10 05:01:13 custom_script: Running /jffs/scripts/nat-start
Feb 10 05:01:13 (install_stubby.sh): 2312 Starting Script Execution
Feb 10 05:01:13 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Feb 10 05:01:14 rc_service: udhcpc 1047:notify_rc start_vpnclient1
Feb 10 05:01:16 (install_stubby.sh): 1341 Ending Script Execution
Feb 10 05:01:16 (install_stubby.sh): 2312 Ending Script Execution
Feb 10 05:01:16 (install_stubby.sh): 1435 Ending Script Execution

Looks we will have to add code to prevent install_stubby.sh from running the iptables commands concurrently. I have code that does this in https://github.com/Xentrk/netflix-vpn-bypass/blob/master/IPSET_Netflix.sh. @Adamm also has similar lock code in Skynet. I'll defer to him what version he feels comfortable adding to the script due to my recent time constraints.

I think that is why I avoided placing the iptables rules in nat-start. From my experience with the netflix-vpn-bypass and other selective routing scripts, nat-start gets called during OpenVPN up/down events.

Here is a sample of the lock code in netflix-vpn-bypass

# Prevent script from running concurrently when called from nat-start

PROGNAME=$(basename "$0")
LOCKFILE_DIR=/tmp
LOCK_FD=200

lock() {
    local prefix=$1
    local fd=${2:-$LOCK_FD}
    local lock_file=$LOCKFILE_DIR/$prefix.lock

    # create lock file
    eval "exec $fd>$lock_file"

    # acquier the lock
    flock -n $fd \
        && return 0 \
        || return 1
}

error_exit() {
    error_str="$@"
    logger -t "($(basename "$0"))" $$ "$error_str"
    exit 1
}

main() {
    lock "$PROGNAME" || error_exit "Exiting $PROGNAME. Only one instance of $PROGNAME can run at one time."
<snip>

 

[Butterfly Bones]

Looks we will have to add code to prevent install_stubby.sh from running the iptables commands concurrently. I have code that does this in https://github.com/Xentrk/netflix-vpn-bypass/blob/master/IPSET_Netflix.sh. @Adamm also has similar lock code in Skynet. I'll defer to him what version he feels comfortable adding to the script due to my recent time constraints.

I think that is why I avoided placing the iptables rules in nat-start. From my experience with the netflix-vpn-bypass and other selective routing scripts, nat-start gets called during OpenVPN up/down events.

Here is a sample of the lock code in netflix-vpn-bypass

# Prevent script from running concurrently when called from nat-start

PROGNAME=$(basename "$0")
LOCKFILE_DIR=/tmp
LOCK_FD=200

lock() {
    local prefix=$1
    local fd=${2:-$LOCK_FD}
    local lock_file=$LOCKFILE_DIR/$prefix.lock

    # create lock file
    eval "exec $fd>$lock_file"

    # acquier the lock
    flock -n $fd \
        && return 0 \
        || return 1
}

error_exit() {
    error_str="$@"
    logger -t "($(basename "$0"))" $$ "$error_str"
    exit 1
}

main() {
    lock "$PROGNAME" || error_exit "Exiting $PROGNAME. Only one instance of $PROGNAME can run at one time."
<snip>

I'n not sure we need to do anything else, referencing these posts from @Adamm. I'll let you two work that out, it works with no issues for me at all, and I think @skeal is the only one posting with issues like double PREROUTING entries in Port Forwarding.

https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-48#post-465118

https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-50#post-465274

 

[EmeraldDeer]

Sorry, I have to ask again exactly.
The second option "Would you like to force all client DNS requests through Stubby" (Question mark missing) is completely the same as in the router GUI:
LAN --> DNSFilter --> Enable DNS-based Filtering (ON) --> Global Filter Mode (Router); (all fields empty)?

Yes, it is. So @Adamm added code to install_stubby.sh to throw an error if already set through the GUI.
https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-46#post-464944
https://github.com/Xentrk/Stubby-In...mmit/e7c2aedf618cb27ea7a2fbe370567201df502a04

# nvram get dnsfilter_enable_x
1

 

[Adamm]

I'n not sure we need to do anything else, referencing these posts from @Adamm. I'll let you two work that out, it works with no issues for me at all, and I think @skeal is the only one posting with issues like double PREROUTING entries in Port Forwarding.

https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-48#post-465118

https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-50#post-465274

I still am also unable to produce duplicate entries, seems to be an isolated issue.

skynet@RT-AX88U-DC28:/tmp/home/root# iptables -vL PREROUTING -t nat
Chain PREROUTING (policy ACCEPT 20308 packets, 2985K bytes)
 pkts bytes target     prot opt in     out     source               destination
   31  2542 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:1194
14286 1723K VSERVER    all  --  any    any     anywhere             *******************
    0     0 VSERVER    all  --  any    any     anywhere             ********
 5730  390K DNAT       udp  --  br0    any     anywhere             anywhere             udp dpt:domain to:192.168.1.1
    0     0 DNAT       tcp  --  br0    any     anywhere             anywhere             tcp dpt:domain to:192.168.1.1

 

[skeal]

I still am also unable to produce duplicate entries, seems to be an isolated issue.

skynet@RT-AX88U-DC28:/tmp/home/root# iptables -vL PREROUTING -t nat
Chain PREROUTING (policy ACCEPT 20308 packets, 2985K bytes)
 pkts bytes target     prot opt in     out     source               destination
   31  2542 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:1194
14286 1723K VSERVER    all  --  any    any     anywhere             *******************
    0     0 VSERVER    all  --  any    any     anywhere             ********
 5730  390K DNAT       udp  --  br0    any     anywhere             anywhere             udp dpt:domain to:192.168.1.1
    0     0 DNAT       tcp  --  br0    any     anywhere             anywhere             tcp dpt:domain to:192.168.1.1

I can reproduce over and over . Let me know if there is anything I can do to help track this down. I have reset to default, manually configured, added one script at a time. As soon as I add Stubby it happens.

 

[skeal]

@Adamm It seems haveged log entries are out by 6 hours. I see this and I have updated to the newest release of stubby.

Feb 10 16:54:07 Entware (armv7sf-k2.6): Started pixelserv-tls (Diversion) from /jffs/scripts/post-mount
Feb 10 16:54:07 Diversion: started Entware services, from /jffs/scripts/post-mount
Feb 10 16:54:07 rc_service: service 4511:notify_rc restart_dnsmasq
Feb 10 16:54:07 dnsmasq[297]: exiting on receipt of SIGTERM
Feb 10 16:54:07 pixelserv-tls[4503]: pixelserv-tls 2.2.1 (compiled: Dec 29 2018 15:01:03 flags: tls1_3) options: 192.168.xx.4
Feb 10 16:54:08 custom_config: Appending content of /jffs/configs/dnsmasq.conf.add.
Feb 10 16:54:08 custom_script: Running /jffs/scripts/dnsmasq.postconf (args: /etc/dnsmasq.conf ) - max timeout = 120s
Feb 10 22:54:08 haveged: haveged: ver: 1.9.4; arch: generic; vend: ; build: (gcc 7.3.0 CV); collect: 128K
Feb 10 22:54:08 haveged: haveged: cpu: (); data: 32K (P); inst: 32K (P); idx: 18/40; sz: 31104/71972
Feb 10 22:54:08 haveged: haveged: fills: 0, generated: 0

Edit: Removed sensitive info.