Host Unreachable

Support Debian
#1

Bonjour,
Je découvre un pb intéressant et je cale actuellement pour l’expliquer et bien sûr le résoudre.

Sur un host PC1, le Wifi est connecté, deux IP sont présentes (dhcp et fixe), le routage semble correcte et pourtant le réseau n’est pas opérationnel (ping de la box ne fonctionne pas!)

Les détails :
ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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 
       valid_lft forever preferred_lft forever
2: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 2c:60:0c:2c:d7:8f brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether ac:b5:7d:05:a2:f1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.102/24 brd 192.168.0.255 scope global dynamic wlp2s0
       valid_lft 1849sec preferred_lft 1849sec
    inet 192.168.0.244/24 brd 192.168.0.255 scope global secondary wlp2s0
       valid_lft forever preferred_lft forever
    inet6 fe80::e11b:cd79:a7cb:a6a1/64 scope link 
       valid_lft forever preferred_lft forever

ip route

default via 192.168.0.1 dev wlp2s0 proto static metric 600 
169.254.0.0/16 dev wlp2s0 scope link metric 1000 
192.168.0.0/24 dev wlp2s0 proto kernel scope link src 192.168.0.102 metric 600 
**ping localhost**
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0,092 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0,242 ms
^C--- localhost ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0,092/0,167/0,242/0,075 ms
**ping 192.168.0.1 → Host Unreachable**
PING 192.168.0.1 (192.168.0.1): 56 data bytes
92 bytes from PC1 (192.168.0.102): Destination Host Unreachable
92 bytes from PC1 (192.168.0.102): Destination Host Unreachable
^C--- 192.168.0.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
#2

« host unreachable » signale l’échec de la résolution ARP de l’adresse IP cible.
Soit la requête ARP se perd en chemin.
Soit la réponse ARP se perd en chemin.
Soit aucune interface connectée au réseau ne répond à cette adresse.

#3

Merci Pascal pour aiguiller mes recherches.
Pour info complémentaire.

  1. Juste après ce post, soit ~1h après la découverte du pb, celui-ci s’est résolu tout seul!
  2. Ma box (sfr) a été changée il y a qq jours, depuis cette date le wifi sur ce PC était ‹ instable ›
  3. je viens de découvrir que lors du pb évoqué : arp -n 192.168.0.1 ne retourne pas d’adresse mac
  4. je viens de changer le canal wifi sur ma box, le défaut a disparu et est réapparu après ~30mn!

Après qq recherches sur internet, mon pb est 100% similaire à : https://askubuntu.com/questions/1122683/no-internet-access-after-random-intervals-in-ubuntu-18-04-2-lts
Alors que moi je suis sous Debian 9, sur un PC qui fonctionnait bien depuis ~5ans, ce serait donc un pb de ‹ compatibilité logicielle › entre la box et le PC, … à suivre, je vais upgrader mon PC (debian 10 et/ou Ubuntu 20)
A noter que le pb subsiste lorsque je forc l’adresse dhcp à l’IP fixe.

#4

La commande arp -n ne fait qu’afficher le contenu du cache ARP. Si la résolution ARP pour une adresse IP a échoué, forcément son adresse MAC n’est pas dans le cache.

Le fait que l’adresse IP soit fixe ou variable n’affecte pas la résolution ARP.

Le problème ne se limite probablement pas à la résolution ARP mais affecte toutes les communications sur la liaison wifi. La résolution ARP est seulement la première phase de toute communication IP.

#5

Bonjour,

Je te suggère de reboot tes appareils dans un premier temps , car il arrive que si les serveurs ont eu un changement d’adresse IP la table contenant les adresses est pas à jour et donc un ping KO. (Cache DNS sur chaque hôte, matériel)

Ensuite ping ta passerelle depuis tout tes postes pour vérifier le bon fonctionnement de chacune d’elle.

Ensuite ping les machines en utilisant l’adresse IP et puis l’adresse DNS, car sa permet de diagnostiquer un problème de cache DNS.

Vérifie aussi si le filtrage MAC te pose pas un soucis.

#6

Mon précédent reboot était postérieur à ma nouvelle box, j’ai rebooté hier et le problème n’est pas résolu, j’ai déjà fait les autres vérifs que tu suggères. Merci tout de même.

#7

Je suis passé en Debian 10 avant hier et le pb vient de réapparaître :frowning:

Pas de soucis avec cette affirmation, mais :

  1. j’ai au moins un autre PC en liaison Wifi sans pb sur ce même réseau
  2. je n’ai pas d’idée (à cette heure) sur comment analyser ce pb
#8

Quelle est donc la configuration réseau de cet autre PC ?

#9

PC1 - pb présent
Debian 10 - NetworkManager
ip a du Wifi
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether ac:b5:7d:05:a2:f1 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.102/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp2s0
valid_lft 3311sec preferred_lft 3311sec
inet 192.168.0.244/24 brd 192.168.0.255 scope global secondary noprefixroute wlp2s0
valid_lft forever preferred_lft forever
inet6 fe80::1b26:9a5b:798e:775/64 scope link noprefixroute
valid_lft forever preferred_lft forever
apr -n
Adresse TypeMap AdresseMat Indicateurs Iface
192.168.0.230 ether 80:c5:f2:7b:c5:67 C wlp2s0
192.168.0.1 ether 88:71:b1:aa:60:5f C wlp2s0
192.168.0.246 ether 80:c5:f2:7b:c5:67 C wlp2s0
Le pb : tout ou partie de ces adresses mat passent parfois à incomplete
C’est le cas pour les 3 6mn après avoir rédigé ce post.

PC3 - Ok
Ubuntu 20 - NetworkManager
ip a du wifi
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 80:c5:f2:7b:c5:67 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.230/24 brd 192.168.0.255 scope global dynamic noprefixroute wlo1
valid_lft 2657sec preferred_lft 2657sec
inet 192.168.0.246/24 brd 192.168.0.255 scope global secondary noprefixroute wlo1
valid_lft forever preferred_lft forever
inet6 fe80::9f78:4732:5132:ca8c/64 scope link noprefixroute
valid_lft forever preferred_lft forever
arp -n
Adresse TypeMap AdresseMat Indicateurs Iface
192.168.0.102 ether ac:b5:7d:05:a2:f1 C wlo1
192.168.0.244 ether ac:b5:7d:05:a2:f1 C wlo1
192.168.0.1 ether 88:71:b1:aa:60:5f C wlo1
192.168.0.180 ether 54:04:a6:b4:aa:09 C wlo1
192.168.0.190 ether ec:9a:74:42:f2:74 C wlo1

#10

Après analyse avec tcpdump ( tcpdump -i wlp2s0 arp ), je vois bien la requête arp toutes les secondes vers la box (ou autre), mais, lorsque le pb est présent, aucune réponse.

Jusqu’à présent pour ‹ résoudre › le pb j’éteignais et rallumais le wifi, maintenant j’ai réussi en indiquant manuellement les adresses (arp -s … ). C’est bourrin, cela n’explique pas le pb mais ça fonctionne. Je laisse le pb ouvert pour le cas où un lecteur aurait une idée complémentaire de test à réaliser.

#11

Le problème se situe soit au niveau des réglages WiFi sur le PC1, à comparer avec le second PC, soit au niveau de la carte WiFi et son pilote.

#12

(message retiré par son auteur, il sera supprimé automatiquement dans 24 heures à moins qu’il ne soit signalé)

#13

Est-ce que tcpdump sur une autre machine voit ces requêtes ARP arriver ?

Ce qui supprime le besoin pour la machine d’envoyer des requêtes ARP. Donc le problème affecte le trafic ARP mais pas le trafic IP, du moins dans l’utilisation qui en est faite.

Hypothèses possibles :

  • Ce sont spécifiquement les requêtes et/ou les réponses ARP qui se perdent.
  • Ce sont seulement les requêtes ARP émises en broadcast , et peut-être tous les paquets émis en broadcast, qui se perdent.

Ça peut se tester avec tcpdump des deux côtés, ping en mode broadcast et arping en spécifiant l’adresse MAC destination dans les deux sens.

#14

Malheureusement @PmGs a supprimé son message qui explique que le problème venait d’un autre point d’accès WiFi actif sur le réseau.

#15

Je trouve l’explication par un conflit de DHCP peu crédible.

#16

Bonjour,

D’après le retour de ton poste la configuration IP et la table ARP est cohérent.
Je penses que ton problèmes pourrait venir d’un de ses points.

  • Le protocole IPV6
  • Le pare-feu
  • La configuration DHCP (Masque de sous-réseau)
  • Un hub, switch qui boucle

Question 1: As-tu essayé de désactiver le protocole IPV6 ?

L’idée est de désactiver le protocole IPV6 pour diagnostiquer le protocole IPV4.
Si le protocole IPV4 fonctionne sans problème c’est que c’est le protocole IPV6.

Question 2: Peux tu poster la configuration de ton serveur DHCP et de tes postes ? (As tu aussi penser à reboot les appareils)

  • Adresse Reseau = 192.168.0.0
  • Adresse Broadcast = 192.168.0.255
  • Masque de Sous-Reseau = 255.255.255.0
  • Nombre de Machines = 254
  • Premiere machine = 192.168.0.1
  • Derniere machine = 192.168.0.254
  • Serveur DNS = 192.168.0.1

Question 3: As-tu regarder si un pare-feu bloque pas la réponse ICMP ? (IPTABLES, UFW)

Je te suggères pour des questions de diagnostique de tout désactiver en attendant.

Question 4: As-tu un hub/switch (répéteur) sur ton réseau? (Ethernet)

Pourrais tu me poster sa référence, indiquer sa configuration réseau .

Analyse

Le PC1 dispose de 2 IPV4 pour une interface. (Elle devrait en avoir 1 seule)
La table ARP affiche bien les 2 IPV4 du système Ubuntu avec son adresse MAC, ce qui est cohérent.
Ce qui est pas cohérent à mon avis est le protocole IPV6.

PC1 - wlp2s0 (ac:b5:7d:05:a2:f1)
inet 192.168.0.102/24
inet 192.168.0.244/24
inet6 fe80::1b26:9a5b:798e:775/64

arp -n
192.168.0.230 ether 80:c5:f2:7b:c5:67 C wlp2s0
192.168.0.1 ether 88:71:b1:aa:60:5f C wlp2s0
192.168.0.246 ether 80:c5:f2:7b:c5:67 C wlp2s0

Ubuntu 20 - wlo1 (0:c5:f2:7b:c5:67)
inet 192.168.0.230/24
inet 192.168.0.246/24
inet6 fe80::9f78:4732:5132:ca8c/64

arp -n
192.168.0.102 ether ac:b5:7d:05:a2:f1 C wlo1
192.168.0.244 ether ac:b5:7d:05:a2:f1 C wlo1
192.168.0.1 ether 88:71:b1:aa:60:5f C wlo1

#17

Je l’ai supprimé parce que j’ai crié victoire trop vite, le problème est réapparu avec un seul point d’accès Wifi.
Pour info, le wifi dans la chambre de mon fils est peu fiable, nous avons tiré un câble ethernet il y a qq années et mon fils a récupéré et mis en place un switch dans la même période que le changement de la Box. Ce switch est en fait un router wifi et l’ayant découvert hier j’ai dans un premier temps désactiver son mode dhcp et régler le wifi en répéteur de ma box si bien que mon fils avait le wifi. Je dis avais, car suite à la réapparition du pb, j’ai également désactivé le wifi. Je n’exclus nullement que cet équipement soit à l’origine du pb et comme dexter74 l’écrit il faut retirer le maximum de chose … Par ailleurs il faut aussi repartir propre (rebooter) pour conclure sur chaque manip. Merci à vous 3 pour votre aide, je continue de mon côté à valider, dans un 1er temps, si le pb vient de ce switch/router qui est donc de fait un 2ème elt nouveau avec ma box.

#18

Pour info je ne fais qu’une modif après l’autre et après que le pb est réapparu.
J’ai écris un petit script pour piéger tous les pb d’arp de ma box, ce script tourne sur les 2 PCs.

Le pb est apparu, ce jour, vers 14h, soit ~5h après le début du script, sur PC1, entre ~14 et ~15h, le pb est apparu/disparu ~10 fois.

Entre 17 et 18h, j’ai eu 2 petites coupures (28s et 4s) sur le PC3, point nouveau que je n’avais pas remarqué avant (sans le script).

A 18h j’ai changé de canal wifi (auto -> 1 fixe , 1 étant celui qui était le plus libre dans mon environnement et je surveille les différents canaux via mon mobile (sais pas s’il existe qqc sous linux et si cela fonctionerait wifi en service)

Le pb est réapparu, sur le PC1, entre 20h et 20h45, heure à laquelle j’ai supprimé le switch (router wifi avec wifi et dhcp préalablement désactivés)

#19

Suppression de l’IPV6 sur les 2 PCs

  • Ajout de l’option ‹ ipv6.disable=1 › à la ligne GRUB_CMDLINE_LINUX_DEFAULT de /etc/default
  • update-grub2
  • reboot

20mn plus tard le pb est réapparu pendant 7s sur PC3 et 2h plus tard pendant 32s sur PC1.
Je ne sais pas si c’est significatif, c’est mon script qui le voit mais c’est a priori ‹ transparent › pour le fonctionnement.

A suivre

#20

Bonjour,
Pourrais tu poste ton script, je me demande si c’est pas lui la source de ton problème.

As tu regarder si tu peux isolé le réseau 2.4 GHz et 5 GHz. Sa se trouve ta un soucis sur ce point.
Dans la box tu nomme différents les réseaux et tu test le 2.4 puis le 5