Problème réseau illogique : comment le diagnostiquer ?

jpt · 18-09-2020 18:25:47

Bonsoir,

Depuis hier soir mon navigateur ne navigue plus, un ping sur orange.fr me répond unknown host, et une tentative de connexion à la console d'administration de la box échoue.

Ce qui est illogique, c'est que toutes ces commandes, exécutées depuis une machine virtuelle hébergée sur la machine malade fonctionnent très bien.

Ce problème s'était déjà produit il y a 3 semaines environ, mais il avait disparu en éteignant tout.
Cette fois il résiste.
La machine a environ 7 ans d'âge (Debian 7, kernel 3.8.13), et c'est donc la seconde fois que je vois cette embrouille.

Une idée ?
Merci,

Dernière modification par jpt (18-09-2020 18:29:57)

Philou92 · 18-09-2020 19:50:42

Et en faisant un ping sur l’adresse IP de la boxe et celle d’orange ?

ping -c 4 193.252.133.34

Beta-Pictoris · 18-09-2020 19:51:32

Comment est virtualisée ta VM ?

Comment est configuré le bridge virtuel ?

Que donne 'ip a' et 'ip route' ?

raleur · 18-09-2020 20:21:07

Ça n'a rien d'illogique. La réponse de ping indique un échec de la résolution de nom. C'est un processus propre à chaque machine, dont le partage de connexion pour une VM ne dépend pas.
Comme déjà demandé, résultat de ip addr et ip route, de ping sur une adresse IP. J'ajoute le contenu de /etc/resolv.conf.

jpt · 19-09-2020 10:24:38

Bonjour,

Merci pour vos réponses, que je note précieusement dans un coin en attendant une rechute car malheureusement, ce matin, après une bonne nuit de sommeil, tout refonctionne sans que je n'aie rien changé (comme la première fois, sauf que cette fois il lui aura fallu deux nuits).
La machine aurait-elle fait un cauchemar cette nuit-là, et passé une nuit paisible suivie d'un doux réveil ce matin ?

Truc de ouf'...

et désolé pour le dérangement.

jpt · 19-09-2020 11:22:43

-- date dessus erronée, j'avais demandé la suppression de ce post, il est toujours là alors je le recycle aujourd'hui, 28 septembre --

Bonjour,

le problème s'étant reproduit il y a deux jours, voilà certains des renseignements demandés ("certains" car je zappe les machines virtuelles, qui n'ont rien à voir avec tout ça, c'était juste une constatation curieuse, et j'ai mieux, lire + bas).

sur dvlp, qqun m'avait demandé ce traceroute lors du pb, je le rajoute ici, des fois que ça aide :

$ traceroute 8.8.4.4

traceroute to 8.8.4.4 (8.8.4.4), 30 hops max, 60 byte packets

 1  * * *

 2  * * *

...

29  * * *

30  * * *

Philou92 a écrit :

Et en faisant un ping sur l’adresse IP de la box et celle d’orange ?
ping -c 4 193.252.133.34

$ ping -c 4 192.168.1.1

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

--- 192.168.1.1 ping statistics ---

4 packets transmitted, 0 received, 100% packet loss, time 3022ms

$ ping -c 4 193.252.133.34

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

--- 193.252.133.34 ping statistics ---

4 packets transmitted, 0 received, 100% packet loss, time 3022ms

raleur a écrit :

Comme déjà demandé, résultat de ip addr et ip route, de ping sur une adresse IP. J'ajoute le contenu de /etc/resolv.conf.

$ ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    inet6 ::1/128 scope host 

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

    link/ether 00:24:81:f3:93:3b brd ff:ff:ff:ff:ff:ff

    inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0

    inet6 fe80::224:81ff:fef3:933b/64 scope link 

       valid_lft forever preferred_lft forever

3: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000

    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff

$ ip route

default via 192.168.1.1 dev eth0 

169.254.0.0/16 dev eth0  scope link  metric 1000 

192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.3 <-- ça c'est la machine à souci

$ cat /etc/resolv.conf

# Generated by NetworkManager

# 2 lignes rajoutées et modifiées par moi après l'install (mai 2013)

domain MAISON

search MAISON

nameserver 80.10.246.2

Et maintenant le gag : la machine à côté (192.168.1.9) est allumée, alors depuis la .3, la "malade",

$ ping -c 4 192.168.1.9

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

64 bytes from 192.168.1.9: icmp_req=1 ttl=64 time=0.779 ms

64 bytes from 192.168.1.9: icmp_req=2 ttl=64 time=0.560 ms

64 bytes from 192.168.1.9: icmp_req=3 ttl=64 time=0.774 ms

64 bytes from 192.168.1.9: icmp_req=4 ttl=64 time=0.868 ms

--- 192.168.1.9 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3000ms

rtt min/avg/max/mdev = 0.560/0.745/0.868/0.114 ms

Et aussi

$ ssh 192.168.1.9

fonctionne très bien ! Et depuis une session ouverte sur la 192.168.1.9, je peux parfaitement récupérer via scp un fichier de la .3.
Donc à priori une partie du réseau est OK. Le problème serait-il dans la box ?
Une fois je m'en étais sorti en l'éteignant, la fois d'après ça n'a pas suffi...

Je résume : les 2 machines sont côte à côte, connectées chacune en rj45 sur la box Orange sans rien de spécial ou de particulier (si : pas de dhcp, ip's fixes), depuis la .9 je pingue la .3 et depuis la .3 je pingue la .9.
Mais la .3 ne pingue pas la box alors que la .9 oui.
Et le lendemain matin tout était normal, sans que j'aie touché à quoi que ce soit.

Je reste sans voix (et sans voie de recherche).

Dernière modification par jpt (28-09-2020 09:37:56)

jpt · 28-09-2020 09:42:10

-- date dessus erronée, j'avais demandé la suppression de ce post, il est toujours là alors je le recycle aujourd'hui, 28 septembre --

Mais son édition ne suffit pas à faire remonter la discussion dans les listes de contributions, d'où cette reply.

Dernière modification par jpt (28-09-2020 09:43:12)

raleur · 28-09-2020 10:06:24

jpt a écrit :

ce post, il est toujours là alors je le recycle

Mauvaise idée car ça ne change pas la date, l'ordre d'affichage ni le statut lu/non lu donc tout est réuni pour qu'on ne le voie pas.

Si tu laisses le ping vers la box courir, est-ce qu'il y a "destination unreachable" ?
Ensuite qu'affiche

ip -4 neigh

Peux-tu faire une capture de trafic sur eth0 (tcpdump, wireshark...) pendant que tu lances un ping vers la box ?
Y a-t-il un pare-feu sur la machine ?

Dernière modification par raleur (28-09-2020 10:06:52)

jpt · 28-09-2020 10:23:36

Merci pour ton retour.

raleur a écrit :

jpt a écrit :
ce post, il est toujours là alors je le recycle

Mauvaise idée car ça ne change pas la date, l'ordre d'affichage ni le statut lu/non lu donc tout est réuni pour qu'on ne le voie pas.

D'où mon post de 10:42

raleur a écrit :

Si tu laisses le ping vers la box courir, est-ce qu'il y a "destination unreachable" ?

Je ne sais pas, en général j'arrête par Ctrl-C au bout de qq secondes.

raleur a écrit :

Ensuite qu'affiche
ip -4 neigh

Rien à l'instant. Mais c'est censé afficher quoi ? Un exemple ?

raleur a écrit :

Peux-tu faire une capture de trafic sur eth0 (tcpdump, wireshark...) pendant que tu lances un ping vers la box ?

Je n'ai pas les outils installés. Si je suis cette voie, merci de me fournir une ligne de commande car je n'ai pas l'habitude du réseau : je branche et ça marche. Si ça ne marche pas je misère...

raleur a écrit :

Y a-t-il un pare-feu sur la machine ?

Non.
Par ailleurs, s'il y en avait un, ça ne fonctionnerait jamais, hors ce problème est neuf (2 mois environ) et très intermittent (3 ou 4 fois seulement).

raleur · 28-09-2020 10:53:18

jpt a écrit :

en général j'arrête par Ctrl-C au bout de qq secondes.

Il faut laisser tourner un peu, au moins 10s.

jpt a écrit :

ip -4 neigh

Rien à l'instant. Mais c'est censé afficher quoi ? Un exemple ?

Il faut le faire juste après le ping. Pour une adresse dont la résolution ARP a réussi :

192.168.0.1 dev eth0 lladdr 00:40:ca:1b:c6:38 STALE/REACHABLE

Pour une adresse dont la résolution ARP a échoué :

192.168.0.2 dev eth0  INCOMPLETE

jpt a écrit :

Je n'ai pas les outils installés. Si je suis cette voie, merci de me fournir une ligne de commande

apt-get install tcpdump

tcpdump -nei eth0 arp or icmp

Ctrl+c pour arrêter.

jpt · 28-09-2020 11:08:35

raleur a écrit :

--snip--

ok bien noté.
Et merci !

Dès que le problème se remanifeste, je tente tout ça.
Sauf pour

raleur a écrit :

apt-get install tcpdump

# apt-get install tcpdump

...

Err http://security.debian.org/ wheezy/updates/main tcpdump i386 4.9.2-1~deb7u1

  404  Not Found [IP : 151.101.64.204 80]

Impossible de récupérer http://security.debian.org/pool/updates/main/t/tcpdump/tcpdump_4.9.2-1~deb7u1_i386.deb  404  Not Found [IP : 151.101.64.204 80]

Comment trouver la nouvelle adresse ?

raleur · 28-09-2020 11:12:46

Wheezy est obsolète depuis très longtemps et ses dépôts ont été archivés sur archive.debian.org.

jpt · 28-09-2020 11:25:59

raleur a écrit :

Wheezy est obsolète depuis très longtemps et ses dépôts ont été archivés sur archive.debian.org.

Rhôôô, ça ne s'invente pas, des trucs pareils !
J'ai souvent l'impression qu'en plus de faire de l'image, du texte, de la vidéo, du son, de la programmation et j'en passe et des meilleures, il faudrait aussi passer son temps sur debian.org, kernel.org et d'autres tous plus ésotériques et time-consuming les uns que les autres.
Et on n'a que 24 h par jour,

Bref, merci pour l'info, outil téléchargé, ça donne ça quand la machine va bien :

# tcpdump -nei eth0 arp or icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

12:20:02.752520 b8:26:6c:7c:57:6e > 00:24:81:f3:93:3b, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.3 tell 192.168.1.1, length 46

12:20:02.752536 00:24:81:f3:93:3b > b8:26:6c:7c:57:6e, ethertype ARP (0x0806), length 42: Reply 192.168.1.3 is-at 00:24:81:f3:93:3b, length 28

^C

2 packets captured

2 packets received by filter

0 packets dropped by kernel

récupéré pendant l'actualisation d'une page du navigateur sur un forum.
Ça servira de référence.

Plus qu'à attendre que ça reparte en vrille...

raleur · 28-09-2020 11:30:33

jpt a écrit :

il faudrait aussi passer son temps sur debian.org

Ou bien s'abonner aux listes de diffusion qui vont bien pour recevoir les annonces.
Faut quand même pas exagérer, wheezy est old-old-oldstable, il ne devrait plus être utilisé depuis longtemps et ne va pas rester sur les miroirs ad vitam eternam.

Dernière modification par raleur (28-09-2020 11:32:44)

jpt · 28-09-2020 11:33:43

raleur a écrit :

... pour recevoir les annonces.

Une tous les 3 mois, ou 10 par jour ?

raleur a écrit :

Faut quand même pas exagérer, wheezy est old-old-oldstable, il ne devrait plus être utilisé depuis longtemps et ne va pas rester sur les miroirs ad vitam eternam.

Je n'exagère pas, si ce n'était pas un problème d'espace disque, cette machine est encore très fiable. Alors pourquoi changer ?

Dernière modification par jpt (28-09-2020 11:35:55)

raleur · 28-09-2020 12:20:51

jpt a écrit :

Une tous les 3 mois, ou 10 par jour ?

Ça dépend des listes. La liste d'annonces de publication et de fin de support a peu de trafic, celle des mises à jour de sécurité un peu plus.

jpt a écrit :

Alors pourquoi changer ?

Parce que les versions de logiciels incluses dans wheezy ne sont plus sûres : elles contiennent des failles de sécurité connues et non corrigées.

Debian-facile

#1 18-09-2020 18:25:47

Problème réseau illogique : comment le diagnostiquer ?

#2 18-09-2020 19:50:42

Re : Problème réseau illogique : comment le diagnostiquer ?

#3 18-09-2020 19:51:32

Re : Problème réseau illogique : comment le diagnostiquer ?

#4 18-09-2020 20:21:07

Re : Problème réseau illogique : comment le diagnostiquer ?

#5 19-09-2020 10:24:38

Re : Problème réseau illogique : comment le diagnostiquer ?

#6 19-09-2020 11:22:43

Re : Problème réseau illogique : comment le diagnostiquer ?

#7 28-09-2020 09:42:10

Re : Problème réseau illogique : comment le diagnostiquer ?

#8 28-09-2020 10:06:24

Re : Problème réseau illogique : comment le diagnostiquer ?

#9 28-09-2020 10:23:36

Re : Problème réseau illogique : comment le diagnostiquer ?

#10 28-09-2020 10:53:18

Re : Problème réseau illogique : comment le diagnostiquer ?

#11 28-09-2020 11:08:35

Re : Problème réseau illogique : comment le diagnostiquer ?

#12 28-09-2020 11:12:46

Re : Problème réseau illogique : comment le diagnostiquer ?

#13 28-09-2020 11:25:59

Re : Problème réseau illogique : comment le diagnostiquer ?

#14 28-09-2020 11:30:33

Re : Problème réseau illogique : comment le diagnostiquer ?

#15 28-09-2020 11:33:43

Re : Problème réseau illogique : comment le diagnostiquer ?

#16 28-09-2020 12:20:51

Re : Problème réseau illogique : comment le diagnostiquer ?

Pied de page des forums