Windows TCP Handshake Problème

Question

J'essaie de créer une connexion TCP à partir d'un contrôleur intégré à un serveur Windows Vista. J'écris la partie serveur Windows de l'application. Lorsque le contrôleur tente de se connecter, il peut falloir plusieurs tentatives pour établir la connexion.

J'ai utilisé Wireshark pour déboguer le problème et il semble que la pile TCP de Windows ne suit pas le protocole de prise de contact correct.

décharge Wireshark:

"No","Time","Source","Destination","Protocol","Info" 

Try1:

"39","9.025322","10.0.0.252","10.0.0.92","TCP","49153 > xinuexpansion4 [SYN] Seq=0 Win=127 Len=0" 
"40","9.025377","10.0.0.92","10.0.0.252","TCP","xinuexpansion4 > 49153 [ACK] Seq=1 Ack=1 Win=2048 Len=0" 
"47","10.031750","10.0.0.252","10.0.0.92","TCP","49153 > xinuexpansion4 [RST] Seq=0 Win=127 Len=0" 

Essayez 2:

"55","12.193941","10.0.0.252","10.0.0.92","TCP","49154 > xinuexpansion4 [SYN] Seq=0 Win=127 Len=0" 
"56","12.194045","10.0.0.92","10.0.0.252","TCP","xinuexpansion4 > 49154 [ACK] Seq=1 Ack=1 Win=2048 Len=0" 
"57","13.200431","10.0.0.252","10.0.0.92","TCP","49154 > xinuexpansion4 [RST] Seq=0 Win=127 Len=0" 

Essayez 3:

"67","18.529871","10.0.0.252","10.0.0.92","TCP","49156 > xinuexpansion4 [SYN] Seq=0 Win=127 Len=0" 
"68","18.529957","10.0.0.92","10.0.0.252","TCP","xinuexpansion4 > 49156 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460" 
"69","18.536318","10.0.0.252","10.0.0.92","TCP","49156 > xinuexpansion4 [ACK] Seq=1 Ack=1 Win=127 Len=0" 

10.0.0.252 est le contrôleur qui initie la connexion, 10.0.0.92 est le PC Windows. Si je comprends bien, la séquence correcte est SYN, SYN + ACK, SYN. Ce que je reçois la plupart du temps est SYN, ACK, RST (c'est-à-dire que Windows répond avec ACK plutôt que SYN + ACK). Dans la décharge ci-dessus, il montre 3 tentatives de connexion, le 3ème fonctionne.

Y at-il quelque chose que je peux faire pour 'réparer' Windows afin qu'il réponde correctement?

EDIT - 2 paquet capture

• shows the embedded controller taking 4 attempts to connect.
• shows the windows client connecting and disconnecting twice without problem.

Answer 1

J'ai regardé vos fichiers PPCE, et les seules différences que je peux voir sont:

(1) Le client Windows envoie « aspect aléatoire » numéros de séquence initiale dans leurs paquets SYN, alors que le embarqué le client envoie des numéros de séquence initiaux comme 1, 2, 3 dans leurs paquets SYN. Tant que le serveur n'a absolument aucun état de connexion TCP pour le 4-tuple (source IP, port source, port dest, port dest), cela ne devrait faire aucune différence, mais je voulais le mentionner au cas où cela vous aide, vous ou quelqu'un d'autre, à penser à une idée.(2) Le client Windows envoie des paquets SYN avec des options TCP, tandis que le client intégré envoie des paquets SYN sans options TCP. Encore une fois, autant que je sache, cela ne devrait pas causer le comportement que vous voyez, et encore une fois, cela va peut-être faire retentir quelqu'un d'autre.

Si vous voulez voir plus de détails sur les en-têtes de paquets et leur décodage, je recommande tshark, qui fait partie du paquet wireshark. Vous pouvez obtenir beaucoup de détails en utilisant une ligne de commande comme ceci:

 
tshark -n -V -x -r Embeded-4-attempts.pcap > Embeded-4-attempts.txt 

En ce qui concerne le « il faut 1 plus essayer de se connecter » l'observation que vous faites ci-dessus, je ferai remarquer qu'il faut 1 plus de temps pour le client atteindre un nouveau numéro de séquence initial que le serveur Windows Vista n'a pas encore vu, parce que je parie que chaque fois que vous redémarrez le client, il commence par envoyer à nouveau un paquet SYN avec le numéro de séquence 1, suivi par 2 sur le suivant tentative de connexion, puis 3, etc. Le serveur Windows Vista peut être en attente de voir un nouveau numéro de séquence initial avant qu'il ne réponde correctement à la connexion.

Hmm. Maintenant que j'y pense, le problème est peut-être que le serveur Vista ne répond pas correctement aux paquets RST du client? Si c'est le cas, le serveur pense que toutes ces connexions client sont toujours actives, alors que le client n'a aucun état associé. Le serveur répond avec des ACK aux tentatives de connexion pour lesquelles il a toujours un état, plutôt que des SYN-ACK, car il a toujours l'état pour eux. Le client n'a pas d'état pour lui et se comporte comme s'il s'agissait de nouvelles connexions. Le redémarrage du client lui fait recommencer à essayer le même port source TCP et les mêmes numéros de séquence initiaux que lors de son dernier démarrage, car sa pile TCP simple ne randomise pas ces valeurs comme le ferait probablement le client Windows.

De toute façon, matière à réflexion. Si vous avez accès au code source du client TCP simple, voyez s'il est possible d'utiliser des ports source aléatoires et des numéros de séquence initiaux lors de nouvelles demandes de connexion.

Answer 2

tandis que la poignée de main échoue, ce ne suit le protocole. RST est autorisé à réinitialiser la connexion dans le cadre du protocole. La question est: pourquoi la réinitialisation se produit-elle? Y a-t-il un système entre les deux machines, qui envoie la réinitialisation? Si vous exécutez à la fois le serveur et le client sur le même système, obtenez-vous toujours la réinitialisation (cela suggère un bug dans votre code)? Si vous exécutez le serveur sur un autre système d'exploitation, dans la même prise réseau que le serveur Windows, voyez-vous le RST?

Answer 3

Avez-vous essayé de vous connecter à votre serveur Vista à partir d'un client exécutant un système d'exploitation complet comme Windows ou Linux, en utilisant say telnet? Sur Linux au moins, vous pouvez spécifier un numéro de port TCP auquel vous connecter sur la ligne de commande, et voir si cela peut établir une connexion avec votre serveur Vista ou non.

Une possibilité de vérifier: Le serveur Vista exécute-t-il un type de pare-feu qui empêche la connexion?