Salut le forum linuxfr,
J'ai un p'tit pépin bizarre, j'ai posté ça sous le sous forum Debian mais ce n'est pas nécessairement lié à la distribution.
Lorsque je me connecte en ssh depuis ma machine cliente une Arch vers mon serveur maison une Debian Stable (les deux en local), j'ai très fréquemment de vilaines latences de plusieurs secondes de saisies très très fatigantes, souvent le prompt se fige pour ne me rendre la main que quelques dizaines secondes plus tard parfois, et la connexion ssh peut durée une éternité jusqu'a 30 secondes.
Le serveur idle à fond les manettes 0.0.0 en charge, et ne délivre qu'un service Samba en local et un lighttpd ouvert sur Internet lui en revanche, bien qu'ayant regardé dans les logs à part de temps à autre quelques gugus qui tentent de trouver le répertoire d'install de phpmyadmin (3 fois par jour à tout casser) et un p'tit scan http par ci par là, rien à déclarer.
Le port 22 n'est accessible qu'en local lui en revanche.
Bref je ne vois pas trop comment régler le problème la pile TCP/IP est-elle à la ramasse ? C'est assez usant … si quelqu'un avait une piste pour me dépanner parce que là fiou …
# dns ?
Posté par jigso . Évalué à 2.
j'ai déjà observé des latences à l'ouverture de la connexion pour des problèmes de résolution de noms, ça se résout assez bien en jouant sur les /etc/hosts pour rajouter les noms des machines (sur le client et/ou le serveur, je ne sais plus bien).
C'est juste une piste… Tes soucis ont l'air de se produire pendant la session, donc les dns ne doivent plus vraiment jouer à ce moment-là.
Sinon c'est en wifi ? filaire ? CPL ?
# GSS API
Posté par lom (site web personnel) . Évalué à 2.
Chaque fois que j'ai eu ce problème, c'était du à GSSAPI. Rajouter la ligne suivante dans ton ~/.ssh/config peut peut être aider:
GSSAPIAuthentication no
# Connexion depuis où ?
Posté par Kerro . Évalué à 2.
Coupe Internet pour voir s'il y a une différence. En principe non.
Fais un test basique avec netcat. Tu tapes du texte pendant que ton ssh est également ouvert. As-tu le même problème ?
Ensuite il te reste à regarder ce qui se passe avec tcpdump. Tu stoppes capture juste après une coupure et tu regardes s'il y a des paquets de retransmission par exemple. Tu auras une bonne idée de l'origine du problème.
# -vvv, ping, tcpdump, strace, sysrq-t
Posté par Krunch (site web personnel) . Évalué à 3. Dernière modification le 15 octobre 2012 à 20:38.
DNS et GSSAPI sont souvent impliqués lorsque la connexion met « longtemps » à s'établir mais si les « freezes » se produisent pendant la session, il semble peu probable que ça soit lié.
Je suppose que le client reste réactif lorsque le problème se produit ? Ce qui signifie que le problème est soit au niveau réseau soit au niveau serveur. Si le load average reste effectivement proche de 0 juste après le problème, il semble plus probable que le réseau en soit la source.
Les idées qui me viennent à l'esprit pour tenter de diagnostiquer le problème seraient :
* pinguer le serveur en continu et voir s'il y a une augmentation de la latence ou des pertes de paquets lorsque le problème se produit ;
* tcpdumper des deux côtés jusqu'à ce que le problème se produise et voir lequel des deux arrète d'emettre lorsqu'il devrait (ou bien s'ils émettent tous les deux et qu'il y a des paquets qui se perdent) ;
* laisser tourner un truc genre "while true ; do date ; sleep 1 ; done > date.log" sur le serveur et voir si la séquence est ralentie lorsque le problème se produit ;
* ajouter des -v à ta ligne de commande ssh, relancer sshd en mode debug et voir si tu as des indices qui apparaissent lorsque le problème se produit ;
* stracer sshd et voir dans quel(s) appel(s) système(s) ça coince ;
* si tu peux obtenir un accès physique de manière pratique lorsque le problème se produit, essai de voir si la console locale est elle aussi « freezée » auquel cas tu pourrais commencer par un sysrq-t.
À partir de là, si tu n'as toujours pas trouvé tu devrais au moins savoir s'il s'agit d'un problème réseau (auquel cas tu peux éliminer les éléments intermédiaires jusqu'à trouver le fautif) ou local (auquel cas il va être temps d'apprendre à comprendre ce que strace et sysrq-t racontent).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Divers tests et observations.
Posté par Kwiknclean . Évalué à 0. Dernière modification le 15 octobre 2012 à 21:03.
Merci vous ne manquez pas d'idées pour me dépanner.
Voici mes tests :
Le problème ne vient pas du DNS car j'attaque la machine par l'IP et il se produit même une fois connecté.
Test avec un port d'ouvert en NETCAT et envoie avec nc de l'autre côté : le problème se reproduit effectivement à un moment j'ai de la latence et le serveur n'affiche plus ce qu'il reçoit et affiche les lignes reçu à la bourre à partir d'un moment non déterminé.
Test avec NETCAT + TCPDUMP en parallèle .. le problème ne semble plus se reproduire .. (c'est que ça cause un tcpdump initié en ssh … Observation le problème se renouvèle lorsque j'arrête d'envoyer toute manipulation opération ou transfert d'infos pendant quelques secondes sur le port en écoute via Netcat, (tcpdump coupé) donc difficile de capturer quoique ce soit en l'état pour l'instant.
Ping du client vers le serveur longue durée en cours ; duréé de transfert du paquet approximative 0.136ms à noter du serveur -> client 0.315 ms (ça n'a rien à voir mais c'est tout de même trois fois plus long).
Je laisse tourne un ping intensif pour voir si y a de la perte (pour l'instant c'est clean) et je retente du tcpdump sur un netcat pour voir éventuellement et je passe aux autres opérationx ssh mode débug, boucle sur la durée … je vous tiens au jus selon les résultats.
En attendant je vais tcpdumper mes nouilles.
# Effectivement le ping foire lorsque j'arrête toute activité.
Posté par Kwiknclean . Évalué à 0.
Après avoir laissé plus de 2000 ping se passé sans aucun probléme, j'arrête l'opération, sans aucune coupure du prompt distant.
5 seconde après al coupure le prompt distant se fige >> je ping depuis ma machine cliente avec tcpdump sur la machine cliente.
et sur tcpdump :
[^] # Re: Effectivement le ping foire lorsque j'arrête toute activité.
Posté par symoon . Évalué à 2. Dernière modification le 15 octobre 2012 à 22:33.
[^] # Re: Effectivement le ping foire lorsque j'arrête toute activité.
Posté par Kerro . Évalué à 2.
Vouai c'est louche ce truc.
Quand j'ai vu que tu passes par le switch de numéricable, j'ai eu comme une petite voix qui me disait "ça sent pas bon ce truc" :-)
Au cas où ce n'est pas lui qui est en cause :
- stopper les processus non vitaux, re-tester
- vérifier s'il n'y a pas une règle de pare-feu (mais bon, je ne vois pas ce qui pourrait faire ce type de problème)
- et surtout, changer de carte réseau. Mais il faut en avoir une sous la main
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.