Besoin d'aide pour résoudre un problème de réseau (connexions TCP client bloquées dans FIN_WAIT_2)


1

(Remarque: j'avais à l'origine posé cette question du côté de "l'ingénierie réseau", mais un modérateur l'a rejetée comme étant "hors sujet" et m'a dit de le demander ici à la place.)

J'utilise un serveur de surveillance vidéo appelé ZoneMinder (version 1.26.5) sur une machine Linux Fedora 18. ZoneMinder possède une interface utilisateur Web et utilise un exécutable CGI appelé "zms" pour transmettre un flux vidéo MJPEG à un navigateur Web via TCP. Le problème est que, parfois, la connexion au flux vidéo ne se termine pas correctement. Si je visualise un flux vidéo et ferme la fenêtre du navigateur, la connexion TCP sous-jacente reste ouverte et le processus zms sur le serveur continue d'envoyer des images vidéo sur le réseau. Cela se produit même si j'arrête TOUTES les instances du navigateur sur la machine Windows (vérifié à l'aide du Gestionnaire des tâches). Mon attente est que Windows devrait immédiatement arrêter la connexion TCP une fois le processus de navigateur terminé, mais pour une raison inconnue, cela ne se produit pas toujours, et Windows continue d'accepter les paquets sur la connexion indéfiniment. Lorsque ce problème se produit, le processus zms sur le serveur voit toujours la connexion ouverte et continue de diffuser la vidéo jusqu'à ce que l'ordinateur Windows soit mis hors tension ou que le processus zms soit tué (manuellement, à partir du shell de commande). Lors de l'examen des événements de surveillance, il n'est pas rare d'accumuler une douzaine ou plus de ces processus zms "zombies"; Si je ne me connecte pas à la machine du serveur ZoneMinder via SSH et si je tue ces processus manuellement, ils continueront de fonctionner indéfiniment, consommant de la bande passante d'E / S réseau et de disque et bloquant le reste du système.

Une fois en état d'échec, l'exécution de netstat sur la machine Windows montre que la connexion TCP est à l'état FIN_WAIT_2. Une capture de Wireshark montre que la machine Windows reconnaît toujours des segments sur la connexion, même si aucun processus en cours de traitement ne reçoit ces données.

J'ai 3 machines Windows: un bureau sous Windows 7 Pro SP1, un bureau sous Win 7 Home Premium SP1 et un ordinateur portable sous Win 7 Home Premium SP1. Parmi ces trois machines, les deux ordinateurs de bureau présentent le problème de manière intermittente, alors que l'ordinateur portable ne présente jamais le problème.

J'utilise normalement le navigateur Firefox, mais j'ai aussi essayé Chrome. Les deux fonctionnent à 100% sur l'ordinateur portable et échouent par intermittence sur les ordinateurs de bureau. L'utilisation de Firefox et de Chrome sur d'autres plates-formes que j'ai essayées, telles que Linux et Android, ne présente jamais le problème.

Une des machines Windows en panne est connectée au même commutateur gigabit que le serveur ZoneMinder. l'ordinateur portable Windows qui fonctionne toujours est connecté à un point d'accès WiFi et parvient au serveur ZoneMinder via un second commutateur GigE. Les appareils Android se connectent de l'intérieur et de l'extérieur, au-delà du pare-feu, sans aucun problème.

Pour éliminer la possibilité d’un problème de pilote réseau, sur l’un des ordinateurs de bureau, j’ai essayé d’échanger la carte réseau Realtek avec une carte réseau Intel, mais la défaillance se produit toujours.

Je suis maintenant à court d'idées; Comment puis-je résoudre ce problème plus loin? Je peux fournir des captures Wireshark si cela peut être utile (elles sont grandes - ~ 100 Mo - donc je les ai laissées pour le moment).

Merci de votre aide!


Intéressant - Je savais que le calcul du CRC pouvait être imputé au matériel, mais pas au reste. Dans tous les cas, je ne pense pas que cela s'applique à ma situation, car je suis capable de tout capturer dans Wireshark, pas seulement la poignée de main à trois. J'ai ajouté les clés de registre quand même (elles n'existaient pas auparavant) mais toujours sans succès. Je pense qu'il y a au moins 2 problèmes ici: 1. Pourquoi le serveur n'envoie pas une FIN en réponse à la FIN du client (qui est ACKed par le serveur), et 2. Pourquoi Windows n'envoie pas de segment RST au serveur quand le processus client se termine.
dvarapala

Réponses:


1

L'état TCP FIN_WAIT_2 signifie que l'application est fermée et que le client a envoyé une FIN au serveur. Le serveur envoie un ACK et doit indiquer au serveur d’application de commencer à s’arrêter. Ensuite, il devrait envoyer une FIN au client. Votre client attend sur le serveur pour envoyer sa FIN.

Vos machines Windows présentant le comportement peut-être en utilisant Déchargement de la cheminée TCP qui délègue certaines tâches d’entretien TCP à la carte réseau, par ex. ACKing données et fermetures de connexions. Une fois l'application fermée, la carte réseau prend en charge le traitement de la fermeture finale de la connexion. Cela pourrait expliquer pourquoi votre machine continue à enregistrer les données alors que le navigateur est fermé.

Vous pouvez essayer d’atténuer le problème en désactivant TCP Chimney sous Windows. Les instructions sont ici .

Toutefois, cela ne résout pas la cause fondamentale de l’envoi par le serveur d’un FIN. Avec les captures de trafic sur le client et le serveur, vous pouvez:

  1. Vérifier que le client envoie un FIN
  2. Vérifiez que le serveur reçoit le FIN
  3. Vérifiez que le serveur envoie une FIN
  4. Vérifier que le client reçoit le FIN

Probablement, il y a un vide dans l'une de ces étapes. Si toutes les étapes sont terminées, le problème vient du client et il peut s'agir d'un déchargement TCP Chimney.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.