Destination Host Unreachable

Support Debian
,
Tags: #<Tag:0x00007fc9e1c01a40> #<Tag:0x00007fc9e1c01888>
#1

Bonjour,

Je viens vers vous car j’ai un soucis récemment concernant ma machine.
J’ai un Raspberry Pi4, sous Debian 12 ARM64.
J’ai essayé d’installer Plex et donc mettre une IP Statique via NetworkManager, et en essayant de ping vers un site pour voir si ça fonctionne, j’obtiens un Destination Host Unreachable.

J’ai regardé mon NetworkManager, et tout est ok. J’étais en ethernet, donc j’ai essayé avec le wifi et bingo, même soucis…

Ci joint mon NM:

> ip addr show wlan0
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
>     link/ether d8:3a:dd:2a:67:c7 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.113/24 brd 192.168.1.255 scope global noprefixroute wlan0
>        valid_lft forever preferred_lft forever
>     inet6 2001:861:2084:25a0:dc91:8be1:c3d8:67/64 scope global dynamic noprefixroute 
>        valid_lft 86268sec preferred_lft 14268sec
>     inet6 fdda:4600:dd85:6247:d1ba:2861:134f:390b/64 scope global dynamic noprefixroute 
>        valid_lft 1684sec preferred_lft 1684sec
>     inet6 fe80::4c84:658:4c6c:5981/64 scope link noprefixroute 
>        valid_lft forever preferred_lft forever

Capture d’écran 2024-11-15 à 18.07.23

J’ai désactivé mon ethernet en attendant.
J’utilisais DHCP mais depuis que je suis passé Bookworm, je suis un peu perdu :sweat_smile:

Je vous remercie à tous :slight_smile:

#2

salut
ton 192.168.1.113/24 dans la confdevrait surement être 192.168.1.113 ( mais le /24 apparait quand même dans le ip addr show wlan0 )
le /24 signifie que tu es sur un réseau où les 24 premiers bits ( soient 192 , 168 et 1 ) sont fixes et les 8 derniers sont variables , ce qui autorise un réseau qui va de 192.168.1.0 à 192.168.1.255 ( même si le .0 n’est jamais utilisé, je ne sais plus pourquoi )

#3

Tout à fais, ça je l’avais compris, mais je sais pas pourquoi impossible de me connecter. J’ai essayer de remettre en dynamique et même problème…
Pas trop envie de reset…

#4

Peux-tu au moins pinger un serveur dns. Que dit ceci:

ping -c2  8.8.8.8
systemctl status systemd-resolved.service
#5

Alors le ping retourne le même message.
Par contre le systemd-resolved.service, n’existe pas de mon côté

#7

Ta connexion est-elle active ?
Peux-tu au moins pinger 192.168.1.1 ?
Il te faut un resolver de DNS. Installe systemd-resolved, puis:
systemctl enable --now systemd-resolved

#9

sans filtre que donnent les deux commandes:

ip a
ip route
#10

Même message…

knocxx@raspberrypi:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether d8:3a:dd:2a:67:c6 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.111/24 brd 192.168.1.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 2001:861:2084:25a0:883c:308a:38a4:2e73/64 scope global dynamic noprefixroute
valid_lft 86307sec preferred_lft 14307sec
inet6 fe80::4b4a:b2cb:511e:7b20/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DORMANT group default qlen 1000
link/ether d8:3a:dd:2a:67:c7 brd ff:ff:ff:ff:ff:ff
knocxx@raspberrypi:~ $ ip route
default via 192.168.1.1 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.111 metric 100

Sinon à défaut, je peux faire un reset de mon OS.
J’ai désactivé le DHCP de ma box si ça peut aider.

#11

@Knocxx
Je suis intervenu uniquement parce-que personne ne te répondait. Ton sujet regagne subitement de l’intérêt semble-t-il.
Il n’y a jamais de solution unique dans un sujet réseau, et chacun peut être subitement tenté de donner son avis, mais mon avis est que moins il y a d’interférences et de contradiction dans un sujet réseau, plus c’est simple.
Je propose dans un premier temps une analyse pragmatique. Ceci étant dit…

Si tu ne peux pas pinger ton gateway (ou routeur), tu dois bien te douter qu’essayer de joindre internet est impossible. Logique de base.
Il faut donc commencer par activer ta connexion au routeur.
On va commencer par une connexion filaire, pour faire abstraction de tout problème de configuration spécifique wifi.
En connexion filaire ethernet, peux-tu faire ça:

nmcli connection up id eth0
nmcli device status
nmcli device show eth0 |awk '/DNS/{printf $2"  "}'
systemctl status systemd-resolved.service

Une fois la connexion eth0 clarifiée et DNS fonctionnel, tu pourras passer au wifi.

#12

Je te remercie de l’intérêt que tu porte à ce sujet. En effet difficile pour moi de commencer sur bookworm :frowning: .
Sinon c’est effectué, le status de systemd-resolved est bien actif.
Le retour du DNS est celui la:

8.8.8.8 8.8.4.4 2001:861:2084:25a0:56c4:5bff:fe01:b76c

Par contre désormais lorsque je veux ping, j’ai ce message désormais :

ping: github.com: Temporary failure in name resolution

#13

Quelle difficulté rencontres-tu pour donner le retour exact des commandes ?
Je ne te demande pas de les interpréter, mais de les donner. Il y en avait 4, et un peu plus maintenant. Et… peux-tu pinger ton routeur ou pas ?

Que dit ceci, sans l’interpéter.

nmcli connection up id eth0
nmcli device status
nmcli device show eth0 |grep DNS
systemctl status systemd-resolved.service

ping -c2 192.168.1.1

readlink /etc/resolv.conf
awk '!/#/' /etc/resolv.conf
cat /etc/NetworkManager/NetworkManager.conf
#14

knocxx@raspberrypi:~ $ sudo nmcli connection up id eth0
Error: unknown connection ‹ eth0 ›.

knocxx@raspberrypi:~ $ sudo nmcli connection up id « Wired connection 1 »
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/6)

knocxx@raspberrypi:~ $ nmcli device status
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected Wired connection 1
wlan0 wifi connected Bbox-29D56DB3
lo loopback connected (externally) lo
p2p-dev-wlan0 wifi-p2p disconnected –

knocxx@raspberrypi:~ $ nmcli device show eth0 |grep DNS
IP4.DNS[1]: 8.8.8.8
IP4.DNS[2]: 8.8.4.4
IP6.DNS[1]: 2001:861:2084:25a0:56c4:5bff:fe01:b76c

systemctl status systemd-resolved.service

● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
Active: active (running) since Sat 2024-11-16 22:01:14 CET; 49min ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 1182 (systemd-resolve)
Status: « Processing requests… »
Tasks: 1 (limit: 3911)
CPU: 257ms
CGroup: /system.slice/systemd-resolved.service
└─1182 /lib/systemd/systemd-resolved

Nov 16 22:01:14 raspberrypi systemd[1]: Starting systemd-resolved.service - Network Name Resolution…
Nov 16 22:01:14 raspberrypi systemd-resolved[1182]: Positive Trust Anchors:
Nov 16 22:01:14 raspberrypi systemd-resolved[1182]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Nov 16 22:01:14 raspberrypi systemd-resolved[1182]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arp>
Nov 16 22:01:14 raspberrypi systemd-resolved[1182]: Using system hostname ‹ raspberrypi ›.
Nov 16 22:01:14 raspberrypi systemd[1]: Started systemd-resolved.service - Network Name Resolution.

knocxx@raspberrypi:~ $ readlink /etc/resolv.conf

../run/systemd/resolve/stub-resolv.conf

knocxx@raspberrypi:~ $ awk '!/#/' /etc/resolv.conf

nameserver 127.0.0.53

options edns0 trust-ad

search .

knocxx@raspberrypi:~ $ cat /etc/NetworkManager/NetworkManager.conf

[main]

plugins=ifupdown,keyfile

[ifupdown]

managed=false

[device]

wifi.scan-rand-mac-address=no

Voila…

#15

Ça fait 2 fois que je demande si tu peux pinguer ton routeur.
Peux-tu dire : oui ou non, voir … donner le retour du ping demandé.
Je ne vois pas du tout ce qu’il y a de compliqué.

Ensuite, edite /etc/resolv.conf , et ajoute sous nameserver 127.0.0.53

nameserver 8.8.8.8
nameserver 8.8.4.4

Puis
sudo systemctl restart systemd-resolved.service
sudo systemctl restart NetworkManager

#16

J’avais déjà répondu, même message que celui de base:
Mais sinon tiens:

ping -c2 192.168.1.1

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

From 192.168.1.111 icmp_seq=1 Destination Host Unreachable

Après avoir fait ceci:

Le retour de mon ping vers routeur:

ping -c2 192.168.1.1

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

From 192.168.1.111 icmp_seq=1 Destination Host Unreachable

#17

Si tu caches l’information demandée, ça va être compliqué.
Est-ce que au moins tu as compris que si tu n’as pas accès à ton routeur, tu n’auras évidemment pas accès à github (…). Sinon, réfléchis-y.
C’est la première chose à réussir si la connexion est bien active.
Il y a un strict minimum de logique à avoir.
Le réseau est une partie complexe et particulièrement la partie DNS, à solutions multiples.
On verra ça plus tard.
En attendant, vérifie que l’adresse de ton gateway est bien 192.168.1.1.
Inutile d’aller plus loin sans pouvoir pinguer ton routeur.

#18

Je n’ai cacher aucune information, j’avais déjà répondu à la question.
Et bien sûr je sais bien que si je n’arrive pas à ping mon routeur, le reste fonctionne pas.
Sinon pour répondre à ta question oui, mon Gateway est bien régler sur 192.168.1.1

#19

Je n’ai caché aucune information, j’avais déjà répondu à la question.

Avant ou après connexion, le ping de ton routeur fonctionne ou pas.
Si je demandais avec insistance et répétition le ping routeur après activation apparente de la connexion, c’est que j’avais besoin de vérification, et non d’hypothèse.
Donc en résumé, avant de s’occuper du sujet ‹ Destination Host Unreachable ›, il faut commencer par résoudre ‹ Gateway Unreachable ›, sinon c’est une perte totale de temps.

La chronologie:
1 ) accès local → le ping du routeur doit fonctionner si connexion active

2 ) ping serveur DNS → ne nécessite pas de résolution DNS

3 ) ping serveur quelconque → nécessite DNS fonctionnel : tout va bien.

S’obstiner sur l’étape 3 (accès github par exemple) avant la 1 n’a pas de sens.

Raspberry Pi4, sous Debian 12 ARM64. J’ai essayé d’installer Plex.

N’ayant pas l’expérience de cette configuration, et sans connaître l’historique de ton système, j’espère que la méthodologie de base aidera à progresser dans les investigations.
J’ignore pourquoi le ping de ta Bbox semble impossible.
C’est un point de blocage dans ma compréhension. Désolé.

#20

J’avais tout à fais compris la chronologie.
Est ce que je dois désactiver mon DHCP de ma Bbox ? Est ce que tu souhaite que je reset mon système pour avoir une connexion active avec mon routeur et essaye une installation d’une IP Statique.

Je n’ai aucun soucis à effectuer le reset, il est tout juste installer le Debian.

#21

Tu ne l’as pas prouvé, mais admettons.
Que dit ceci (il y a 2 commandes).

hostname
cat /etc/hosts

Et une hypothèse relative à la BBOX: refus de configuration DNS autre que celle imposée par la BBOX. J’ai bien dit hypothèse.

Des BBox ont pour adresse 192.168.1.254 d’où ma demande de confirmation à 100%.

#22

La réponse:

knocxx@raspberrypi:~ $ hostname

raspberrypi

knocxx@raspberrypi:~ $ cat /etc/hosts

127.0.0.1 localhost

::1 localhost ip6-localhost ip6-loopback

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

127.0.1.1 raspberrypi

knocxx@raspberrypi:~ $ hostname -i

127.0.1.1

Ma bbox:
Capture d’écran 2024-11-17 à 17.40.18

Je vais tester avec 192.168.1.254.
Edit: Si je ping 192.168.1.254:

ping -c2 192.168.1.254

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

64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=10.5 ms

64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=7.32 ms

--- 192.168.1.254 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1002ms

rtt min/avg/max/mdev = 7.318/8.915/10.512/1.597 ms