Dietpi: Checking network connectivity fails (via ssh)

[lokmanhakim]

Details:

• Date | Thu 13 Feb 16:40:13 +08 2020
• Bug report | N/A
• DietPi version | v6.28.0 (MichaIng/master)
• Image creator | DietPi Core Team
• Pre-image | Raspbian Lite
• SBC device | RPi B (armv6l) (ID=0)
• Kernel version | Linux DietPi 4.19.75+ #1270 Tue Sep 24 18:38:54 BST 2019 armv6l 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. ...whenever try to install dietpi software, dietpi will run network check but it always fails.
2. ...

Expected behaviour:

• ...

Actual behaviour:

• ...

Extra details:

• connected via SSH
• when ping normally, it goes through

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]

@lokmanhakim
many thanks for your report.

if you are not able to ping 1.1.1.1 you would have local 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.

Do nano /DietPi/dietpi.txt 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

It's a similar issue like this #3337 and #3369

[MichaIng]

Aside of the workaround provided by Joulinar, if there is any chance, check your router/local network settings, if it somehow uses 1.1.1.1 (respectively the whole 1/8 IP range) internally. This is the case for e.g. older Cisco routers. If possible, then disable this internal usage to allow connection to these IPs on global level.

Background about that topic: https://news.ycombinator.com/item?id=14862748
The default has already been changed with DietPi v6.29 btw since this 1/8 misuse is a bid systematical.

[teamallnighter]

│ Checking network connectivity
│
│ - Command: ping -c 1 -W 5 8.8.8.8
│ - Exit code: 1
│ - DietPi version: v6.28.0 (MichaIng/master) | HW_MODEL:4 | HW_ARCH:2 | DISTRO:5
│ - Image creator: DietPi Core Team
│ - Pre-image: Raspbian Lite
│
│ Log file content:
│ PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
│
│ --- 8.8.8.8 ping statistics ---
│ 1 packets transmitted, 0 received, 100% packet loss, time 0ms
│

[teamallnighter]

@MichaIng My router looks like its using 64.59.135.133 for the dns my modem:
HW Version:2.2
Vendor:Technicolor
BOOT Version:S1TC-3.49.18.14
Core Version:1.0
Model:CGM4140COM
Product Type:XB6
Flash Part:8192 MB
Download Version:Prod_18.1_d31 & Prod_18.1
Serial Number:2143068334709452

DNS:

Primary DNS Server (IPv4): 64.59.135.133
Secondary DNS Server (IPv4):64.59.128.120
Primary DNS Server (IPv6):2001:4e8:0:4001::16
Secondary DNS Server (IPv6):2001:4e8:0:4006::16

[Joulinar]

So you are even not able to ping Google DNS server? What about Quad9 DNS server 9.9.9.9 ?

[teamallnighter]

No. but when I go to into config and do a network test it goes to google

[MichaIng]

@teamallnighter
Hmm, when you run the following from console:

ping 8.8.8.8

Are all packages lost or are probably some answers received? Probably the connection is simply a bid unstable.

[Joulinar]

Can you do a ping google.com from SSH command line

[Superbatros]

Hello !

I have the problem teamallnighter encounter. I made the change in diepi.txt file but it has no effects (I'm connected throug ssh).
I tried ping google.com but all the packet sent are lost even if I see I'm connected with diepi-config network menu.
Could you please help me?

[EDIT]
I can ping 1.1.1.1 without any loss but I can't ping a "regular" URL like one.one.one.one or google.com

[Joulinar]

ok it seems DNS resolution is not working correctly. Do you use an own DNS server or do you use a public one? How does DNS configuration on your system looks like?

[Superbatros]

ok it seems DNS resolution is not working correctly. Do you use an own DNS server or do you use a public one? How does DNS configuration on your system looks like?

I use a public DNS (I guess : I use the default configuration given by my internet provider).

I just manage to run dietpi-software : I change one.one.one.one by 1.1.1.1 in dietpi.txt file. Now it works but I don’t understand why... thanks for your help !

[Joulinar]

what did you changed exactly? CONFIG_CHECK_DNS_DOMAIN=one.one.one.one into CONFIG_CHECK_DNS_DOMAIN=1.1.1.1?? If yes, you are now going to bypass DNS check. As far as I understood you are not able to ping FQDN from os level. So that's something to find out.

pls can you do following and post the output.

ping -c 1 -W 5 one.one.one.one
ping -c 1 -W 5 dns.google
ping -c 1 -W 5 dns.quad9.net

[Superbatros]

what did you changed exactly? CONFIG_CHECK_DNS_DOMAIN=one.one.one.one into CONFIG_CHECK_DNS_DOMAIN=1.1.1.1??

Yes I dit that and it works : the DNS resolve test works (I don't know if it is bypassed or not) and I manage to run the installation of diet pi, the update and upgrade after first launch.

[Joulinar]

yes if you changed CONFIG_CHECK_DNS_DOMAIN from a FQDN to an IP address, you are going to bypass the DNS check completely because there is no DNS resolution done on this test at all.

[Superbatros]

yes if you changed CONFIG_CHECK_DNS_DOMAIN from a FQDN to an IP address, you are going to bypass the DNS check completely.

Ok! Understood. As it was enough to go through the installation of diet pi, I think I won't change it.

[MichaIng]

@Superbatros
Hmm strange that obviously DNS resolution in other cases works, only for ping not. Could you run the following commands and paste them here:

ping -c 1 -W 5 google.com
ping -c 1 -W 5 github.com
wget --spider google.com
wget --spider github.com

[MichaIng]

I mark this as closed. Feel free to reopen if required.