DietPi-Software DNS ping issue 1.1.1.1

[erwanpb]

Hello everybody!

First of all thanks a lot for all your great content and support!

I am trying to launch my new Dietpi setup and I'm having issues at the very first step.

I am connected using SSH through ethernet and running the latest version of Dietpi so I know the network connection is up and running and I can ping successfully 8.8.8.8 or my router from the command line.

When I run Dietpi-Software, the first step is to ping 1.1.1.1 and it's when the error shows up.
I also have issues to ping 1.1.1.1 from my laptop (maybe coming from local ISP) so I would like to change Dietpi-Software DNS initial check to ping 8.8.8.8 instead of 1.1.1.1.
That's what i selected in Dietpi-Config when I setup my fixed IP address and DNS, but Dietpi-Sofware is still trying to ping 1.1.1.1 when starting-up.

I there a way to change this?

Details:

• Date | Sun 12 Jan 22:47:24 +03 2020
• Bug report | 0aade34c-99ed-4406-8963-f866a4ead37e
• DietPi version | v6.28.0 (MichaIng/master)
• Image creator | DietPi Core Team
• Pre-image | Raspbian Lite
• SBC device | RPi 3 Model B+ (armv7l) (ID=3)
• Kernel version | Linux DietPi 4.19.57-v7+ #1244 SMP Thu Jul 4 18:45:25 BST 2019 armv7l GNU/Linux
• Distro | buster (ID=5)
• Command | ping -c 1 -W 5 1.1.1.1
• Exit code | 1
• Software title | DietPi-Software

Steps to reproduce:

1. Get a fresh Dietpi install
2. Set-up fixed IP config
3. Make sure the DNS is 8.8.8.8
4. Run Dietpi-Sofware

Expected behaviour:

• Dietpi-Sofware should run smoothly

Actual behaviour:

• Dietpi-Sofware cannot ping 1.1.1.1 and stops

Extra details:

• I also have issues pinging 1.1.1.1 from my laptop...

Additional logs:

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

[Joulinar]

@erwanpb
Hi, if you are not able to ping 1.1.1.1 you would have serous issues as it's part of Cloudflares DNS Server. It is the globally available IP address for Cloudflares 1.1.1.1 DNS resolver:

https://www.dnswatch.info/dns/dnslookup?la=en&host=1.1.1.1&submit=Resolve

Anyway if you like to change this, you can do it as follow.

Once you have flashed your SD card, just put it back to your desktop computer. You should have mounted an additional drive called boot. There your have the config files and you could adjust settings that will be applied initially. Locate the file called dietpi.txt and open it with a text editor and search for the following 2 lines:

# General connection and DNS testing
# - IP to ping when checking network connectivity. Default: 1.1.1.1 (Cloudflare DNS, should be very fast world-wide)
CONFIG_CHECK_CONNECTION_IP=1.1.1.1
# - Domain to ping when checking DNS resolver. Default: one.one.one.one (Cloudflare DNS domain, see above)
CONFIG_CHECK_DNS_DOMAIN=one.one.one.one

you can change it to 8.8.8.8 and google.com

[erwanpb]

Perfect, that solved the issue.
I don't know why I have issues with 1.1.1.1 though...
But at least it's working now!

[Joulinar]

Probably blocked by your network or ISP. But it's strange as Cloudflares is one of the biggest public DNS providers and btw the fastest one :smile:

[MichaIng]

@erwanpb
We got similar reports for the domain one.one.one.one failing to ping on DNS resolver check. However that turned out to be an issue when IPv6 is enabled but not supported by the local network for some reason. But pinning the raw IP, which excludes the DNS resolver, indeed is strange.

Since you cannot ping it from notebook, I am thinking of not all of Cloudflares servers answer to ICMP requests (ping). Then indeed this is no great default IP to test connectivity.

Similar: https://community.cloudflare.com/t/unable-to-resolve-ping/59121/3

[MichaIng]

I think I found it: https://superuser.com/questions/970371/what-is-1-1-1-1-why-does-it-work-for-traceoute-but-not-ping#970376

It seems to be that the whole IP range was regularly used for private networks and especially Cisco routers used 1.1.1.1 internally, even that it was never meant to be used like this. Most likely there are still some older routers/firmware or local networks that resolve this network internally, hence ping does not reach what it should...

[Joulinar]

@MichaIng
Probably it would be better to switch to some other ping check IP like Quad9 to avoid to run in such issues to often.

https://www.quad9.net/

Honesty I don't like Google that much even if it might be availability all over the globe. :wink:

[MichaIng]

@Joulinar
Probably, but I think this issue is extremely rare, note that we have ~10000 DietPi v6.27/28 installs but only one report for this issue so far.

However I agree as of above links this can occur for others as well.

I moved many defaults from Google to Cloudflare, from a giant to a growing relatively new player, also for personal preference but especially because ping times for Cloudflare are world avarage the shortest. They have more servers for their DNS service than Google DNS.

Quad9 would be my personal sympathy preference, but while they are well placed and quick on must western cities, they are really placed in other regions. Even here in Hamburg I have 20 seconds ping compared to 4 seconds on Cloudflare and 8 seconds on Google, if I remember right. County-side and in 3rd-world regions it is much worse from what I read. I mean yeah we talk about milliseconds, so probably it doesn't play a role for such one-time checks.

[Joulinar]

@MichaIng
I like Cloudflare as it's the fastes DNS actually. I did some test on my PiHole and added all 3 DNS resolver to it: Cloudflare, Google and Quad9. After some days I checked it and Cloudflare was resolving around 90% of my DNS queries. 😉

Even here in Hamburg

A little bit off topic but your are from HH? I'm from B 😄

[MichaIng]

@Joulinar

A little bit off topic but your are from HH? I'm from B :smile:

Jep, currently, but we'll move to Thuringia soon.

---

Still thinking which default IP/domain to use for connection and resolver test. For connectivity probably Quad9 is okay indeed.

Some more ping times, although probably things have changed in nearly two years: https://news.ycombinator.com/item?id=16729310

Of course with high ping, one should not use it as DNS resolver, but to see if it is reachable to check network connectivity it should be fine. Generally any anycast address should be okay, Quad9 is nearly as beautiful as 1.1.1.1 and has my sympathy from from organisation structure and envolved companies.

About the domain, I think it is actually good to have one that by default resolves as IPv6 address. That way one recognises immediately if IPv6 should be disabled, instead of getting different connection issues later on, in the middle of some software install process or such. What I am not sure about, if pinging 1.1.1.1 fails, if then pinging one.one.one.one (resolving to 1.1.1.1) fails as well. This would actually make sense :thinking:. Quad9 DNS domain would be: dns9.quad9.net. quad9.net would be simpler but resolves to no anycast IP, AFAIK, but a fixed server in USA. This is not good for reliablility.

[Joulinar]

@MichaIng
hmm nice Thüringen the green heart

It just stepped into my mind but it would require some larger developments I guess.

If checks with Cloudflare are failing (DNS and/or ping), to execute both checks with an alternative like Quad9 automatically. Benefit would be:

1. less user impact
2. checks could be performed more seamless
3. build-in fallback scenario if Cloudflare is failing

Downside would be, as already said, the needed development

[MichaIng]

@Joulinar
That sounds a bid to complicated for my personal teste 😉. I would simply switch to a default that is not known to have issues (even in rare circumstances) and in case of any failure (theoretically a local network can assign any IP/domain locally, overriding the global one), allow to change all related settings directly from the error prompt. But as well a larger task, but planned anyway: https://github.com/MichaIng/DietPi/projects/4

[Joulinar]

That sounds a bid to complicated for my personal teste

well I did not say that it was a good idea 🤣

[erwanpb]

Glad to have raised a discussion on that topic!

Indeed, a back-up scenario would be ideal to keep Cloudflares as preferred DNS but avoid blocking points like I had here :)

[MichaIng]

Okay I changed our defaults: https://github.com/MichaIng/DietPi/commit/ffd9431cba7a9f5fda48faec5edd7bc9a12e82ed
Note that this is no solution. As long as the local network/router overrides/redirects 1.* IPs internally, related public servers are not reachable from the system, hence this should be fixed anyway.

I planned to add some general system check script, based on regularly reported issues not related to DietPi. Added ping 1.1.1.1 to the list.