DietPi-Globals | G_CHECK_DNS: Replace "ping" with "getent hosts"

[SilverShadow91]

Required Information DietPi version | Any, tested on 8.4.2 Distro version | Any, tested on bullseye Kernel version | Any, tested onLinux DietPi 5.15.32-v7+ SBC model | Any, tested on RPi 3 Model B+ (armv7l)

Additional Information (if applicable) Software title: dietpi-update script Can this issue be replicated on a fresh installation of DietPi? Yes

Steps to reproduce Connect Dietpi-running computer to a network that restricts outbound ICMP Echo requests (ping). Alternatively, install a software firewall on dietpi itself, and block ICMP requests out to reproduce. Run dietpi-update Dietpi-Update will fail at Checking DNS Resolver, due to not only checking DNS resolution but then unneccesarily pinging dns9.quad9.net, which the network firewall blocks. This is despite Quad9 not being the DNS resolver in use in the system.

Note that the exact log entry is: "PING "dns9.quad9.net (149.112.112.9) with 56(84) bytes of data.", indicating that DietPi did resolve dns9.quad9.net correctly.

Expected behaviour Dietpi-Update completes after connecting to the update mirror, the same as all other Linux distributions.

Actual behaviour Dietpi-Updates fails after pinging an adress that it has no reason to be allowed to reach, over a protocol it has no reason to use for this test.

Extra details If the connectivity test before the update is necessary for the script to function, the test should evaluate against actual name resolution, not ping results. The network connectivity test in dietpi-config works even when outbound ping is restricted, so the tools to do this already exist. Alternatively, pinging the actual DNS server used by the system would be more likely to work, despite not resolving the root issue.

[Joulinar]

You can set manually the DNS and ping check target server in dietpi.txt. it is by far not hardcode.

[MichaIng]

Jep, that ping is done to test whether your DNS works, using a DNS provider hostname only because it is multicast and usually best reachable from everywhere. But actually I wonder why we do not use getent hosts "$hostname" instead 🤔.

[Joulinar]

Well we do 2 checks. One to check internet connectivity using an IP address and 2nd to verify DNS resolution. Just because DNS resolution works, doesn't mean internet connection does.

[MichaIng]

Jep, the internet connection check, pinging an IP, would stay untouched.

[Joulinar]

We had it a couple of times where DNS request resolved an IPv6 address. However ping this one was not working due to incorrect IPv6 setup. Just ensuring DNS resolution is done, doesn't mean connection is working on the address that has been resolved.

[H179922]

I have an issue with this as well trying to run the latest dietpi-update. Ping doesn't work in order to kick off the update but I can get to all sites (pihole is working as DNS server) and I can successfully run apt-update as well as apt-upgrade.

[Joulinar]

can you share the exact error message pls.

[H179922]

0fa0ed04-2a5f-42b0-9004-64b8a5e82c9e

bug report upload

[Joulinar]

it would be helpful if you could share the error message with us.

[H179922]

is the bug report not helpful? I can send the error msg, just figured that was more complete

[Joulinar]

well not everybody has access to these reports.

[H179922]

Details:

• Date | Tue May 17 17:27:56 EDT 2022
• DietPi version | v8.1.2 (MichaIng/master)
• Image creator | DietPi Core Team
• Pre-image | Raspberry Pi OS (32-bit) Lite
• Hardware | RPi 4 Model B (armv7l) (ID=4)
• Kernel version | Linux Trinity0 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux
• Distro | buster (ID=5,RASPBIAN=1)
• Command | ping -nc 1 -W 10 1.1.1.1
• Exit code | 1
• Software title | DietPi-Update

Steps to reproduce:

1. ...
2. ...

Expected behaviour:

• ...

Actual behaviour:

• ...

Extra details:

• ...

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

[H179922]

Not much there

[Joulinar]

could you try ping 9.9.9.9 or ping 8.8.8.8

[H179922]

they fail also, but wget works fine

[H179922]

PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data. ^C --- 9.9.9.9 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 115ms

[Joulinar]

or you on some kind of company network and ICMP could be blocked?

[H179922]

nope, and ping from my laptop works its only the RPI. Also I've run dietpi-update on this network without issue multiple times in the past. No config changes

[Joulinar]

are you able to ping your router?

[H179922]

apparently not from the pi...

[Joulinar]

did you setup any security software or firewall on the Pi?

[H179922]

I don't believe so, if I did it was well over 18/20 months ago and I wouldn't have messed with it

[Joulinar]

did you have done a reboot? Just in case 😉

And are you able to ping the system itself locally

[H179922]

hah yeah, many times now. Yeah I'm ssh'ed into it (if you mean pi by the system)

[Joulinar]

no I mean to ping the Pi from it's own. Not from a different system

[H179922]

oh. yes no issue there

[Joulinar]

hmm to bypass the test, you could adjust the following in /boot/dietpi.txt to point to the Pi itself

# General connection and DNS testing
# - IP to ping when checking network connectivity. Default: 9.9.9.9 (Quad9 DNS IP)
CONFIG_CHECK_CONNECTION_IP=9.9.9.9
# - Domain to ping when checking DNS resolver. Default: dns9.quad9.net (Quad9 DNS domain)
CONFIG_CHECK_DNS_DOMAIN=dns9.quad9.net

[H179922]

ah clever. what would the dns domain be? The ping test worked that time

[Joulinar]

you can use localhost or the same IP address should work as well

[H179922]

well that did the trick. So sounds like something on my pfsense is funky with ICMP? I thought I passed all traffic through from the pi...

thank you for the help

[Joulinar]

have a look if ICMP traffic is blocked.

[H179922]

will do thanks