Scapy: erreur de retransmission TCP

J'utilise Scapy pour envoyer des paquets SCCP ou Skinny à mon téléphone de bureau Cisco. Cependant, je continue à avoir ces erreurs de retransmission TCP et je pense que cela empêche le téléphone Cisco de répondre. J'ai un programme capable de commander le téléphone avec succès. Par exemple, le programme "10.10.50.12" envoie quatre paquets et obtient deux ACK du téléphone ("10.30.37.78"). Voir ci-dessous:

enter image description here

Cependant, lorsque j'utilise Python et que j'envoie les commandes avec Scapy:

enter image description here

Les quatre paquets sont envoyés et même reconnus comme des messages particuliers par Wireshark, mais je reçois l’erreur TCP Retransmission et aucun accusé de réception du téléphone.

Bizarrement, "SetLampMessage" n'a rien de spécial, de sorte qu'il ne reçoive pas l'erreur. C'est simplement parce que c'était le premier paquet envoyé. Si je dois organiser l'ordre des paquets différemment, celui qui sera envoyé en premier n'aura aucune erreur.

J'ai essayé de comparer les sorties hex, voici des comparaisons hex de SetLampMessage:

Programme: enter image description here

Mon Python: enter image description here

La plupart des incohérences entre les sorties hexadécimales sont liées aux identifications et aux sommes de contrôle. Mes identifications sont toujours égales à 0x0001, mais je ne crois pas que ce soit le problème, car j’ai pu envoyer des paquets TCP sans erreur, même s’ils ont tous le même identifiant.

J'ai googlé les erreurs de "retransmission TCP" et il semble que la plupart d'entre elles soient dues au fait que l'ACK ne soit pas renvoyé. Je ne pense pas que ce soit la cause non plus, car j'ai défini plusieurs temps de pause entre chaque paquet envoyé. vérifier si mes paquets sont envoyés trop rapidement.

Un individu éclairé a-t-il une idée de ce que je fais pour causer ces erreurs?

— Nick Williams
source

Donc Warshark ne "reconnaît" rien, il analyse, donc le fait qu'il voit les commandes est vraiment sans importance. La retransmission est simplement ce que vous voyez. Il n'y a pas d'ACK (pour une raison quelconque, par exemple, paquet perdu, encombrement, paquets en désordre, etc.), il demande donc à nouveau dans l'espoir d'une réponse - il s'agit donc simplement d'un symptôme du problème. Si vous développez les paquets que vous envoyez et les comparez aux paquets envoyés par l'application, les données sont-elles correctement formatées? Je suppose que le téléphone ne reconnaît tout simplement pas quelque chose et ne répond pas à vos paquets.

— MaQleod

Je crois que vous avez raison, lorsqu’on envoie des paquets depuis l’application une fois que l’erreur est vue, l’erreur est vue encore. Cependant, il fonctionne toujours. Peut-être qu'un de mes quatre paquets est mauvais.

— Nick Williams

Après quelques travaux, j'ai découvert que mon problème résidait dans les numéros de séquence et d'accusé de réception dans les en-têtes TCP des paquets que j'envoyais. J'envoyais un "0x0001" pour ces deux valeurs.

J'ai particulièrement trouvé cet article très utile pour comprendre comment ces valeurs fonctionnent: http://www.firewall.cx/networking-topics/protocols/tcp/134-tcp-seq-ack-numbers.html

Pour résoudre mon problème, j'ai regardé les numéros de séquence et d'acquittement entre le téléphone Cisco Desk et un gestionnaire d'appels. Je prédis ensuite, calculais les prochaines valeurs Seq et Ack, puis envoyais mes paquets de manière appropriée.

enter image description here

Vous pouvez voir dans l'image ci-dessus que mes messages "maigres", commençant par "SetLampMessage", ne reçoivent plus l'erreur de retransmission TCP.

Cependant, mon téléphone Cisco persiste à ne pas répondre et continue de me détester, mais cela n’est pas pertinent.

— Nick Williams
source