Stubby-Installer-Asuswrt-Merlin

[cmkelley]

Anyway to fix these time problems when the router is restarting lol.

Yes, I'm working on a script to do just that. I think I have it fixed. Just need my wife to let me restart the router and I'll start a thread on it.

 

[shark]

Yes, I'm working on a script to do just that. I think I have it fixed. Just need my wife to let me restart the router and I'll start a thread on it.

Nice

 

[john9527]

Put in a wait loop until nvram var ntp_ready=1 before starting stubby

 

[cmkelley]

Nice

Okay, the thread is up, but unfortunately for most people relies on a time server somewhere else on your network. Temporarily forgot about that detail, sorry.

Also, I'm going to be away from the computer for a couple hours, I have an errand I have to run.

 

[cmkelley]

After a reboot, what it the output of the command:

grep -E "^no-resolv|^server=" /tmp/etc/dnsmasq.conf

Oh, the syslog shows that Stubby is being started before the router's clock is synced with NTP. Could be a timing problem.

# grep -E "^no-resolv|^server=" /tmp/etc/dnsmasq.conf
no-resolv
server=127.0.0.1#5453
server=0::1#5453
server=/pool.ntp.org/1.1.1.1
#

Yes, I do have the dnsmasq.conf.add file, which the last line above shows is being loaded, because the Stubby installer puts that in there, and I left it in. I know for an absolute fact it's not a timing issue, because I went to a lot of effort (and learned a lot along the way) to make a script to get the time from my local ntp server (which is GPS synced so it's spot-on) as early as possible on boot-up. All seems to make sense in the bootup:

Jan 11 10:55:42 SCRIPT_firewall-start: started [eth0]
Jan 11 10:55:42 Skynet: [*] USB Not Found - Sleeping For 10 Seconds ( Attempt 1 Of 10 )
Jan 11 10:55:43 SCRIPT_pre-mount: started [/dev/sda1]
Jan 11 10:55:43 amtm: Running disk check 'e2fsck -p' on /dev/sda1
Jan 11 10:55:43 amtm: Disk check done on /dev/sda1
Jan 11 10:55:43 SCRIPT_post-mount: started [/tmp/mnt/myssd]
Jan 11 10:55:43 Swap: Starting swap
Jan 11 10:55:43 haveged: haveged starting up
Jan 11 10:55:43 lionroot: Started haveged from /jffs/scripts/post-mount.
Jan 11 10:55:43 S61stubby: Starting Stubby DNS over TLS /opt/etc/init.d/S61stubby
Jan 11 10:55:43 lionroot: Started stubby from /jffs/scripts/post-mount.
Jan 11 10:55:43 Diversion: created br0:pixelserv-tls [redacted], from /opt/etc/init.d/S80pixelserv-tls
Jan 11 10:55:43 pixelserv-tls[1543]: pixelserv-tls 2.2.1 (compiled: Dec 29 2018 15:01:07 flags: tfo tls1_3) options: [redacted]
Jan 11 10:55:44 Entware (aarch64-k3.10): Started pixelserv-tls (Diversion) from /jffs/scripts/post-mount
Jan 11 10:55:44 Diversion: started Entware services, from /jffs/scripts/post-mount

Skynet doesn't find the USB and goes to sleep, the pre-mount fsck runs, and then swap is started. The Stubby script is on the USB SSD so it must be mounted. The interesting thing in the bootup is this:

Jan 11 10:55:34 dnsmasq[814]: ignoring nameserver ww.xx.yy.zz - local interface

where ww.xx.yy.zz is the local network IP of my router. I'm wondering if that's related somehow.

 

[cmkelley]

Okay, the thread is up, but unfortunately for most people relies on a time server somewhere else on your network. Temporarily forgot about that detail, sorry.

Actually, I suppose you could put an external timeserver IP in there which would set your clock as soon as the WAN comes up, but then it's a race to see if it gets the time first or Stubby runs first. @john9527's suggestion is probably the best if you don't have a separate time server on your LAN.

 

[cmkelley]

Found a solution (for me at least!)

pixelsrv-tls was being started after stubby - in /opt/init.d stubby was S61stubby and pixelsrv-tls was S80pixelserv-tls. I changed stubby to 99stubby and rebooted. Presto! Works right out of the box on reboot. That was way too hard for such a simple solution!

Geh. Nevermind.

 

[dave14305]

I’d look in the syslog to determine what else started that might explain the difference except elapsed time. There should be no conflict between Stubby and Pixelserv otherwise.

What you find might help find the root cause.

 

[cmkelley]

I’d look in the syslog to determine what else started that might explain the difference except elapsed time. There should be no conflict between Stubby and Pixelserv otherwise.

What you find might help find the root cause.

Heh, nope. They literally just swap places in the log, nothing between them. Stubby before pixelsrv:

Jan 11 10:55:43 Swap: Starting swap
Jan 11 10:55:43 haveged: haveged starting up
Jan 11 10:55:43 lionroot: Started haveged from /jffs/scripts/post-mount.
Jan 11 10:55:43 S61stubby: Starting Stubby DNS over TLS /opt/etc/init.d/S61stubby
Jan 11 10:55:43 lionroot: Started stubby from /jffs/scripts/post-mount.
Jan 11 10:55:43 Diversion: created br0:pixelserv-tls [redacted], from /opt/etc/init.d/S80pixelserv-tls
Jan 11 10:55:43 pixelserv-tls[1543]: pixelserv-tls 2.2.1 (compiled: Dec 29 2018 15:01:07 flags: tfo tls1_3) options: [redacted]
Jan 11 10:55:44 Entware (aarch64-k3.10): Started pixelserv-tls (Diversion) from /jffs/scripts/post-mount
Jan 11 10:55:44 Diversion: started Entware services, from /jffs/scripts/post-mount
Jan 11 10:55:44 pixelserv-tls[1543]: Listening on :[redacted]:443
Jan 11 10:55:44 pixelserv-tls[1543]: Listening on :[redacted]:80
Jan 11 10:55:45 SCRIPT_ddns-start: started [redacted]
Jan 11 10:55:46 Diversion: restarted Dnsmasq to apply settings, from /jffs/scripts/dnsmasq.postconf

Stubby after pixelsrv:

Jan 11 19:32:37 Swap: Starting swap
Jan 11 19:32:37 haveged: haveged starting up
Jan 11 19:32:37 lionroot: Started haveged from /jffs/scripts/post-mount.
Jan 11 19:32:37 Diversion: created br0:pixelserv-tls [redacted], from /opt/etc/init.d/S80pixelserv-tls
Jan 11 19:32:37 pixelserv-tls[1520]: pixelserv-tls 2.2.1 (compiled: Dec 29 2018 15:01:07 flags: tfo tls1_3) options: [redacted]
Jan 11 19:32:37 pixelserv-tls[1520]: Listening on :[redacted]:443
Jan 11 19:32:37 pixelserv-tls[1520]: Listening on :[redacted]:80
Jan 11 19:32:38 Entware (aarch64-k3.10): Started pixelserv-tls (Diversion) from /jffs/scripts/post-mount
Jan 11 19:32:38 S61stubby: Starting Stubby DNS over TLS /opt/etc/init.d/S99stubby
Jan 11 19:32:38 lionroot: Started stubby from /jffs/scripts/post-mount.
Jan 11 19:32:38 Diversion: started Entware services, from /jffs/scripts/post-mount
Jan 11 19:32:38 Diversion: restarted Dnsmasq to apply settings, from /jffs/scripts/dnsmasq.postconf
Jan 11 19:32:38 SCRIPT_ddns-start: started [redacted]

Too many times in life "There shouldn't be ..." has turned out to be "Crap, it does." Seems getting @Xentrk and @kvic to agree on new sequence numbers might be worth it.

 

[kvic]

Too many times in life "There shouldn't be ..." has turned out to be "Crap, it does." Seems getting @Xentrk and @kvic to agree on new sequence numbers might be worth it.

Well, first of all I think the Entware guys pick a sensible choice of order in the init script. So it should be fine for Stubby to stay S61 and pixelserv-tls S80.

Script kiddies on this forum like to add a sleep here and there..very poor programming style IMO. So you might want to check if that causes delayed startup of suspected processes..

(I hope I read your problem correctly...I didn't go through the thread)

 

[cmkelley]

Well, first of all I think the Entware guys pick a sensible choice of order in the init script. So it should be fine for Stubby to stay S61 and pixelserv-tls S80.

Script kiddies on this forum like to add a sleep here and there..very poor programming style IMO. So you might want to check if that causes delayed startup of suspected processes..

(I hope I read your problem correctly...I didn't go through the thread)

So much for my solution. Seemed to be working yesterday, left to spend this morning and afternoon with my dad, came back this evening and back to no DoT. So now I re-ran the Stubby installer and I'll leave the alone for a day and see if DoT goes away again.

So basically the problem is DoT works when I run the installer, but doesn't come back after a reboot, even though stubby is loaded and supposedly working. "service restart_stubby" doesn't help, but I haven't tried directly running the script in init.d to restart it (I have no clue what the service command actually does). If I re-install Stubby it starts working. Last night I switched the order of Stubby and pixelsrv-tls scripts in init.d, and DoT was working on reboot. It can't possibly be a clock-not-set issue as seems to be the case for others, I get system time from a local time server on my network within 2 seconds after init-start runs.

I think everything "unique" I'm running shows up in my signature line. If there's something in particular you don't wish to say out loud please feel free to PM me, I'll keep your (or anyone's for that matter) comments confidential.

 

[shark]

So much for my solution. Seemed to be working yesterday, left to spend this morning and afternoon with my dad, came back this evening and back to no DoT. So now I re-ran the Stubby installer and I'll leave the alone for a day and see if DoT goes away again.

So basically the problem is DoT works when I run the installer, but doesn't come back after a reboot, even though stubby is loaded and supposedly working. "service restart_stubby" doesn't help, but I haven't tried directly running the script in init.d to restart it (I have no clue what the service command actually does). If I re-install Stubby it starts working. Last night I switched the order of Stubby and pixelsrv-tls scripts in init.d, and DoT was working on reboot. It can't possibly be a timing issue, I get system time from a local time server on my network within 2 seconds after init-start runs.

I tried your solution and it indeed does not work... and i am having the same issue, to fix it i need to run the installer again just like you.

 

[preacher65]

I tried your solution and it indeed does not work... and i am having the same issue, to fix it i need to run the installer again just like you.

I know this doesn't help resolve the issue, but I've not had any issues with it persisting here, so it's not universally affecting all AC86Us.

 

[DAVID LONG]

Works fine on mine setup also.

 

[shark]

I know this doesn't help resolve the issue, but I've not had any issues with it persisting here, so it's not universally affecting all AC86Us.

Works fine on mine setup also.

Did you guys tried this test, after a reboot:

https://1.1.1.1/help

and it said yes??? Like here:

This is what we are talking about, in other words, after a reboot, every time you do this test, it says NO and after you run the installer again, it goes back to YES.

 

[preacher65]

Did you guys tried this test, after a reboot

Yep, have rebooted several times today and I have Firefox set to open that as a secondary homepage, so I normally see it, though I do sometimes just close it without checking. Also rebooted twice more before posting above, just in case it had been failing and I'd missed it.

 

[john9527]

If you have a VPN client active, try disabling it (no auto start on boot)

 

[cmkelley]

If you have a VPN client active, try disabling it (no auto start on boot)

No VPN client. VPN server. Turned that off and rebooted, same result.

 

[DAVID LONG]

Yes, every time after a reboot.

I also get the ad flag in drill -D asuswrt.lostrealm.ca @127.0.0.1

 

[shark]

There is a new symptom, yesterday i decided to update my router to the last alpha, from 384.8_2! As always the router reboot when you update its firmware, when the router came back online, i decided to test it with the cloudflare page and it was all fine, in other words, it was showing yes for "Using DNS over TLS(DoT)", after that i decided to do another reboot and with the new reboot, the problem came back!