Connexion ethernet défaillante

Support Debian
#1

Bonjour,

depuis quelques semaines, mon PC fixe, sous Wheezy, connecté via CPL à ma Livebox (qui sert de routeur), échoue parfois à se connecter normalement. Je précise que le parc contient un autre PC fixe sous wheezy connecté via CPL, sous lequel ce problème ne se produit pas, et deux portables (un wheezy, un jessie) qui passent par le wifi, sans problème non plus.

Plus précisément, lorsque la connexion échoue, je tente de la relancer via ifdown / ifup, et l’appel à ifup semble se dérouler normalement :

...
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from 192.168.1.1
DHCPACK from 192.168.1.1
bound to 192.168.1.10 -- renewal in 39826 seconds

Mais toute navigation reste impossible, et les ping ping -b 192.168.1.1vers la box restent sans réponse. Au démarrage suivant, le problème peut se répéter ou non, sans que j’y vois de raison.

Je ne sais pas où chercher pour résoudre le problème (notamment : quels fichiers logs examiner ? De manière plus générale, lorsque j’ai besoin d’information, je sais que les fichiers logs existent, mais je ne sais pas du tout à quoi est consacré chacun d’entre eux et je suis donc incapable de faire une recherche : y a-t-il un guide des fichiers log ?). Merci de vos conseils.

#2

Yahallo,
Ça m’est arrivé hier, sur ma Lubuntu… J’ai rien compris, donc j’ai réinstallé.

Voici les commandes que j’ai testé (en root) :

echo “nameserver 8.8.8.8” > /etc/resolv.conf;
route;route add default gw [ip de ma box];
route #pour vérifier si il y avait un changement
ping google.fr

Et j’ai versé quelques larmes pour ma Lubuntu 14.04.4, puis suis passé à la 15.10 en attendant la 16.04…

#3

Merci,

bien entendu, je préférerais une solution moins radicale que de tout réinstaller. Il faudra bien que je migre un jour le parc sous jessie, mais cela va demander du travail - je n’ai pas le temps en ce moment.

Voici le retour de la commande route :

Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
default         livebox.home    0.0.0.0         UG    0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

En comparant avec mon portable, je vois que sur celui-ci, une ligne de plus est renvoyée, commençant par link-local (et bien entendu sur le portable l’iface est à wlan0). Est-ce un problème ?

#4 
   Table de routage IP du noyau

    Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
    default         10.8.0.1        128.0.0.0       UG    0      0        0 tun0
    default         192.168.0.111   0.0.0.0         UG    100    0        0 enp8s0
    10.8.0.0        *               255.255.255.0   U     0      0        0 tun0
    128.0.0.0       10.8.0.1        128.0.0.0       UG    0      0        0 tun0
    net.lan         192.168.0.111   255.255.255.255 UGH   0      0        0 enp8s0
    192.168.0.0     *               255.255.255.0   U     100    0        0 enp8s0

Voici la mienne (je tourne sous mon VPN, donc ne tiens pas compte de tun0)

PS : eth0 <=> enp8s0 sous Lubuntu 15.10… Je cherche pas à comprendre, sûrement un développeur qui s’ennuyait…

#5

Est-ce que tu es sûr que la box répond en temps normal aux ping ?
Quel est le retour de ifconfig lorsque tu n’as pas de connexion ( après un ifup ) ?

#6

Oui, la box répond habituellement aux ping.

Je viens de réussir à me reconnecter avec un ifdown / ifup. C’est la première fois que la connexion s’établit correctement lors d’une session où elle n’est pas disponible initialement (bon, habituellement, je n’essaie qu’une fois ou deux et je travaille sans internet - ce qui me permet en moyenne d’être plus efficace).

Dès que l’occasion se présente, je poste le retour de ifconfig. Merci.

Je me permets de reposer une question du premier post : y a-t-il un fichier log que je devrais examiner lors d’une session où la connexion n’est pas valide ?

#7

Tente de passer par network-manager au pire, non ?

#8

A part syslog, je ne vois pas.
Je ne suis pas sûr que cela apporte beaucoup d’informations utiles dans ton cas.

#9

Il n’y a pas de log dédié au réseau. Les logs du noyau contiennent entre autres choses des messages relatifs aux basses couches du réseau. Les logs du noyau sont dans /var/log/syslog mais mélangés à bien d’autres logs, et ne contiennent pas que des messages relatifs au réseau donc autant ne pas s’encombrer au départ. Les logs du noyau seuls sont consultable avec la commande dmesg qui affiche le tampon des derniers messages, ou dans le fichier /var/log/kern.log. Par contre ils ne contiennent pas les messages écrits par les démons comme le client DHCP qui sont plutôt dans /var/log/syslog (mais avec un préfixe explicite qui permet de les filtrer) Ceci dit, la configuration par DHCP semble bien se passer d’après ce qu’affiche ifup dans ton message initial.

Pourquoi ping -b ? L’adresse de la box n’est pas une adresse de broadcast.

As-tu essayé de redémarrer la box quand le problème se produit et ifup+ifdown reste sans effet ? Que les autres machines n’aient pas de problème ne signifie pas que la box fonctionne correctement. J’ai déjà vu des box partiellement plantées avec pour résultat des machines pouvant se connecter et d’autres pas.

Les navigateurs web sont les pires outils pour faire des tests. Leur fonctionnement est si complexe et leurs messages d’erreur si vagues qu’il est généralement impossible d’en déduire ce qui ne fonctionne pas.

Il faut privilégier les outils simples qui font le moins de choses possibles comme arping(résolution ARP), ping, traceroute/tcptraceroute, dig/host (résolution DNS), nc(netcat)/telnet (connexion à un port TCP ou UDP)…
Même un programme en apparence simple commeping fait plusieurs choses : résolution DNS, résolution ARP et enfin envoi des requêtes ICMP echo. Ainsi si on l’utilise avec un nom d’hôte au lieu d’une adresse IP et si la résolution DNS échoue, on ne saura pas si c’est un problème général de connectivité IP ou un problème plus spécifique de résolution DNS puisque celle-ci a besoin de la connectivité IP. Les différents messages d’erreur, et même l’absence de message d’erreur peuvent fournir des information précieuses.

En plus des logs, il faut vérifier la configuration IP active : adresses IP avec ip addr, table de routage principale avec ip route, règles de routage avec ip rule, règles iptables avec iptables-save, cache ARP/NDP avec ip neigh. Et comparer quand ça marche et quand ça ne marche pas pour voir s’il y a des différences (adresse IP différente par exemple).

Un outil de diagnostic précieux est la capture de paquets avec tcpdump, wireshark ou équivalent. Si possible, envoyer des paquets à une machine sur laquelle on peut aussi faire une capture de paquets pour vérifier si les paquets émis d’un côté sont reçus de l’autre.

#10

Merci Pascal pour la description des logs et des différents outils pour comprendre les défaillances réseau. Le travail va effectivement être de comparer les résultats quand ça marche et quand ça ne marche pas.

Concernant l’option -b dans le ping, j’ai pris l’habitude de la passer systématiquement, car il m’arrivait de l’oublier pour un ping vers l’extérieur - et il me semble qu’elle n’empêche pas la commande de fonctionner aussi sur le réseau local.

Aujourd’hui, le deuxième poste fixe a présenté brièvement les mêmes symptômes. Je n’ai pas été assez diligent pour rassembler les informations requises, mais j’ai eu le temps de constater (une fois, je ne sais pas si c’est reproductible) :

  • que les pc répondent au ping entre eux même quand la box ne répond pas à l’un d’entre eux ;
  • que je parviens à me connecter en ssh à celui qui est en rade depuis l’autre.

Du coup, je suis effectivement tenté par l’hypothèse d’une défaillance de la box. A creuser dans les jours à venir. Merci à tous.