3 poignée de main dans Scapy

Im essayant de construire un 3 way handshake dans Scapy. En utilisant le code suivant,

#!/usr/local/bin/python

from scapy.all import *

sport = random.randint(1024,65535)

# SYN     
ip=IP(src='172.16.120.5',dst='172.16.100.101')
SYN=TCP(sport=sport,dport=443,flags='S',seq=1000)
SYNACK=sr1(ip/SYN)

# ACK              
my_ack = SYNACK.seq + 1
ACK=TCP(sport=sport, dport=443, flags='A', seq=1001, ack=my_ack)
send(ip/ACK)

Cependant sur le serveur, je ne vois que SYN_RECV même si le retour SYN-ACK est envoyé et l'accusé de réception est envoyé en retour. Voici une capture à partir du serveur (172.16.100.101),

08:10:19.455038 IP 172.16.120.5.58972 > 172.16.100.101.https: S 1000:1000(0) win 8192
08:10:19.455343 IP 172.16.100.101.https > 172.16.120.5.58972: S 2541678705:2541678705(0) ack 1001 win 18484 <mss 1460>
08:10:19.545808 IP 172.16.120.5.58972 > 172.16.100.101.https: . ack 1 win 8192
08:10:24.015204 IP 172.16.100.101.https > 172.16.120.5.58972: S 2541678705:2541678705(0) ack 1001 win 18484 <mss 1460>

Comme vous pouvez le voir le SYN-ACK est envoyé deux fois donc il semble que le serveur ne marche pas comme le dernier accusé de réception. Des idées ?

EDIT :

Ive également imprimé la sortie de chacun des paquets directement à partir de python. Notez que c'était pour une autre connexion.

>>> SYN
<TCP  sport=26193 dport=https seq=1000 flags=S |>
>>> 
>>> SYNACK
<IP  version=4L ihl=5L tos=0x0 len=44 id=0 flags=DF frag=0L ttl=63 proto=tcp chksum=0x741 src=172.16.100.101 dst=172.16.120.5 options=[] |<TCP  sport=https dport=26193 seq=1023579974 ack=1001 dataofs=6L reserved=0L flags=SA window=18484 chksum=0xdb18 urgptr=0 options=[('MSS', 1460)] |<Padding  load='\x00\x00' |>>>
>>> 
>>> ACK
<TCP  sport=26193 dport=https seq=1001 ack=1023579975 flags=A |>

EDIT 2 :

Ci-dessous montre un succès et unsucessful connexion.

SCAPY

20:58:37.357056 IP 172.16.120.5.35957 > 172.16.100.101.https: S 10:10(0) win 8192
20:58:37.357369 IP 172.16.100.101.https > 172.16.120.5.35957: S 900629853:900629853(0) ack 11 win 18484 <mss 1460>
20:58:37.445888 IP 172.16.120.5.35957 > 172.16.100.101.https: . ack 900629854 win 8192

CURL

20:58:46.165413 IP 172.16.120.5.33241 > 172.16.100.101.https: S 2266708589:2266708589(0) win 5840 <mss 1460,sackOK,timestamp 17370497 0,nop,wscale 6>
20:58:46.166296 IP 172.16.100.101.https > 172.16.120.5.33241: S 2138155488:2138155488(0) ack 2266708590 win 18460 <mss 1460,sackOK,timestamp 107550664 17370497,nop,wscale 7>
20:58:46.169026 IP 172.16.120.5.33241 > 172.16.100.101.https: . ack 2138155489 win 92 <nop,nop,timestamp 17370497 107550664>
Le SYN-ACK paquet est enregistré comme ack 1 win 8192, ce qui semble indiquer une ack avec un numéro de séquence de 1 au lieu de 2541678706. Pouvez-vous imprimer SYNACK et my_ack (bien qu'ils semblent être réglé correctement)?
Ive mis à jour la question. Pense que vous avez raison l'a finalement accusé de réception a le tort accusé de réception numéro. Cependant, si je prends une connexion ie effectuer une boucle sur le port 443 qui est établie avec succès, ce qui montre aussi l'ACK avec un 1
Pouvez vous aussi poster un équivalent du journal d'un succès curl de connexion? Comment est le serveur de mise en œuvre? Pouvez-vous le remplacer par un scapy script qui imprime les paquets reçus?
L'ACK n'est pas le problème comme si je effectuer un tcpdump avec l'option-S je.e montrant la relative seq/ack de chiffres, il est comme prévu.
question mise à jour.

OriginalL'auteur felix001 | 2014-10-21