Closed leonardoaranha-git closed 11 months ago
Could you provide full log of the installer?
Could you provide full log of the installer?
How can I generate the complete log? Just running the default install command?
Full command output from sh -c 'sh -c "$(curl -sSL https://api.controld.com/dl)" -s ******* forced'
root@NanoPiR4S:~# sh -c 'sh -c "$(curl -sSL https://api.controld.com/dl)" -s ****** forced'
__ .__ .___
_____/ |________| | __| _/
_/ ___\ __\_ __ \ | / __ |
\ \___| | | | \/ |__/ /_/ |
\___ >__| |__| |____/\____ |
\/ installer \/
---------------------
| System Info |
---------------------
OS Type : linux
OS Vendor : openwrt
OS Version : 23.05.0-rc2
Arch : aarch64
CPU : aarch64_generic
Free RAM : 3790 MB / 3875 MB
---------------------
| Install Details |
---------------------
Resolver ID : ******
Binary URL : https://assets.controld.com/ctrld/linux/arm64/ctrld
Install Path : /usr/sbin
---------------------
- Starting download
- Making binary executable
- Launching /usr/sbin/ctrld
---------------------
Aug 17 22:52:11.000 NTC Starting service
Aug 17 22:52:20.000 NTC Service started
The above suggests everything installed correctly and passed health tests.
Can you provide output for this command after running the installer: netstat -tupln
Sure.
root@NanoPiR4S:~# netstat -tupln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 1442/uhttpd
tcp 0 0 ***** 0.0.0.0:* LISTEN 9310/dnsmasq
tcp 0 0 192.168.1.1:7681 0.0.0.0:* LISTEN 2657/ttyd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1442/uhttpd
tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN 9310/dnsmasq
tcp 0 0 192.168.1.1:22 0.0.0.0:* LISTEN 2054/dropbear
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 9310/dnsmasq
tcp 0 0 :::443 :::* LISTEN 1442/uhttpd
tcp 0 0 :::80 :::* LISTEN 1442/uhttpd
tcp 0 0 f***** :::* LISTEN 9310/dnsmasq
tcp 0 0 ***** :::* LISTEN 9310/dnsmasq
tcp 0 0 :::5000 :::* LISTEN 7654/miniupnpd
tcp 0 0 ::1:53 :::* LISTEN 9310/dnsmasq
tcp 0 0 ***** :::* LISTEN 9310/dnsmasq
tcp 0 0 :::5354 :::* LISTEN 1025/ctrld
tcp 0 0 ***** :::* LISTEN 9310/dnsmasq
tcp 0 0 ***** :::* LISTEN 9310/dnsmasq
udp 0 0 0.0.0.0:1900 0.0.0.0:* 7654/miniupnpd
udp 0 0 127.0.0.1:53 0.0.0.0:* 9310/dnsmasq
udp 0 0 ***** 0.0.0.0:* 9310/dnsmasq
udp 0 0 192.168.1.1:53 0.0.0.0:* 9310/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 9310/dnsmasq
udp 0 0 0.0.0.0:49387 0.0.0.0:* 9310/dnsmasq
udp 0 0 192.168.1.1:50134 0.0.0.0:* 7654/miniupnpd
udp 0 0 192.168.1.1:5351 0.0.0.0:* 7654/miniupnpd
udp 0 0 0.0.0.0:5353 0.0.0.0:* 1025/ctrld
udp 0 0 0.0.0.0:5353 0.0.0.0:* 1025/ctrld
udp 0 0 0.0.0.0:5353 0.0.0.0:* 1025/ctrld
udp 0 0 ***** :::* 7654/miniupnpd
udp 0 0 ***** :::* 9310/dnsmasq
udp 0 0 ***** :::* 9310/dnsmasq
udp 0 0 ***** :::* 9310/dnsmasq
udp 0 0 ***** :::* 9310/dnsmasq
udp 0 0 ***** :::* 9310/dnsmasq
udp 0 0 ***** :::* 9310/dnsmasq
udp 0 0 :::***** :::* 6494/odhcp6c
udp 0 0 :::***** :::* 4190/odhcpd
udp 0 0 :::***** :::* 7654/miniupnpd
udp 0 0 :::***** :::* 7654/miniupnpd
udp 0 0 :::***** :::* 1025/ctrld
Everything seems fine here. At this point, Im not seeing nay issues here. Those errors you reported, do they happen all the time, and does DNS actually work?
Yes, these errors happen all the time, on average every 15 minutes. DNS is working correctly. I did all the tests that exist in the documentation on the site. I was using OpenWrt 22.03, now I installed version 23.05 and the same error persists. Is there any other test I can do?
Edit: I removed the ctrld and installed the "https-dns-proxy" package, I don't have any errors using this package.
You said DNS worked, so other than seeing these errors, what is the actual problem here?
"https-dns-proxy" package could just be hiding the same types of errors, and you simply don't know they happen.
Basically, is it causing any actual issues for you?
@littl3viking Please try a new dev build.
sh -c 'sh -c "$(curl -sSL https://api.controld.dev/dl)"'
You said DNS worked, so other than seeing these errors, what is the actual problem here?
"https-dns-proxy" package could just be hiding the same types of errors, and you simply don't know they happen.
Basically, is it causing any actual issues for you?
No issues with internet, only errors on log.
@littl3viking Please try a new dev build.
sh -c 'sh -c "$(curl -sSL https://api.controld.dev/dl)"'
I just tested and still the same error in the log.
But other than the errors in the log, are there any actual noticeable problems?
Getting similar errors here too.
In my case I have 2 pi's on the local net, both running latest ctrld and configured with a single upstream (.net doh). The same error also occurs when run on macOS at varying intervals during the day.
Also noticed that I occasionally see ping packets being dropped to the current dns (dns.controld.net) - I do not see this to other major nameservers. This may align with the 'connection reset by peer'? if server having a glitch.
Looking closely at my logs, I had multiple local ctrld instances report the issue at the same time. Just over a 1-2s period, so a very brief blip. Again a connection reset, failures to resolve, and all upstreams failed. No observed blips in other traffic. Using the .net resolvers it looked as if there was a blip. I presume the actual outage may have been 6-7s given a default 5s timeout on queries.
Not sure if this is specific to anycast, or the new anycast when routing changes.
In this regard, for ctrld itself this may be expected behaviour.
However I did check my 'dnsleaktest' an hour ago, plus just now when I noticed the issue. My location had changed (france->germany) so this kinda holds together, and moves the question to that network and mitigation strategies? One option might be an additional upstream - albeit at the risk of skipping ad etc checks (maybe quad9 a good option). caching, stale result serving, cache size may be others that can be done locally.
Are you using DOH3 or DOQ by any chance?
Can you switch it do standard DOH, and see if the same issue reoccurs?
Seems like random timeouts are being triggered. Can you provide an MTR/traceroute to dns.controld.com AND dns.controld.net
That looks fairly reasonable, shouldn't cause any issues as far as timeouts are concerned. Will discuss this internally.
This appears to be a networking issue. At the time of the issue, can you even reach dns.controld.com? ping or load in the browser?
We need a little more details here / external troubleshooting.
Yes, please eliminate all external variables and see if there are any issues then, otherwise these reports are not actionable.
That may suggest your Internet drops out for a bit, which is what this error suggests. Does this cause any actual noticeable problems?
@scumball What DNS Host are you using? https://controld.com/status
If the status page says you're not using Control D, that means your browser has DOH configured, and not using your router at all. https://docs.controld.com/docs/browser-not-using-os-dns
@littl3viking Please try a new dev build.
sh -c 'sh -c "$(curl -sSL https://api.controld.dev/dl)"'
Can you reproduce the issue?
Or try the latest v1.3.3 release.
Hello! I installed Ctrld on the NanoPi R4S (OpenWRT) using the command provided by the site:
sh -c 'sh -c "$(curl -sSL https://api.controld.com/dl)" -s ******* forced'
But I am getting the following errors in the log:
*Censored private information.
Can you help? Thanks.