Analyse Problème de packet perdus

Inscrit
22 Aout 2019
Messages
14
J'aime
2
#1
Bonjour,

Je suis confronté à un problème qui m’embête un peu, je suis en train développer un sniffer en python avec pyshark, sauf que parfois, (par exemple quand je change de map), il y a beaucoup de packet en en plus il y a des packets reçus et envoyés en même temps, ce qui fait qu'une fois sur 5 environ, il y a un packet perdu. J'ai donc fait en sorte que quand ça se produit, le message non complet soit ignoré. Seulement j'aimerai savoir si il est possible de remédier à ce problème autrement ?

Par exemple avec une lib qui ne perd pas les packet ?

Merci d'avance !
 
Inscrit
26 Janvier 2016
Messages
12
J'aime
1
#2
Hello ,

J ai été confronté au même problème que toi il y a peu je crois , est ce que tu croises des paquets avec des ids "suspects" ?
 
Inscrit
22 Aout 2019
Messages
14
J'aime
2
#3
Oui effectivement c'est ça le principal problème, en réalité c'est pas une mauvaise id, c'est juste que comme on perd un packet seulement quand il y a beaucoup d'infos, le packet perdu possède tout le temps un message de taille supérieur à 1460 (limite pour une trame tcp), donc la suite du message va être sur le packet suivant, seulement vu que le premier packet est perdu, le packet lu est la suite du message, donc si le début de cette suite ne commence pas par un id connu, ça va buger ou autre en fonction du code, cependant même si cet id est reconnu, le message n'est pas bon. C'est pourquoi il faut soit pouvoir retrouver le packet (je pense que c'est impossible), ignorer le message avec l'id suspect ou trouver une lib pour sniffer qui annule ou minimise ce problème de perte ..
 
Inscrit
22 Aout 2019
Messages
14
J'aime
2
#4
Après, j'ai remarqué que étrangement ça le fait que lors de changement de map, quand je je vais voir l'hdv des archis-monstres, j'ai un message de 200.000 octets voir plus et je reçois bien tous les packets, dans le bon ordre, sans pertes. Donc c'est vraiment quand les message client -> serveur et serveur -> client arrivent en même temps et avec de larges tailles j'ai l'impression
 
Inscrit
26 Janvier 2016
Messages
12
J'aime
1
#5
Tu lis plusieurs packet DOFUS sur un meme packet TCP ?

Ps : add moi discord on travaille sur la meme base ce sera plus "sympa" ^^'
Namelistone#9040
 
Inscrit
22 Aout 2019
Messages
14
J'aime
2
#6
Tu peux avoir plusieurs packet ODUFS sur un packet TCP ET un packet DOFUS sur plusieurs packet TCP
 
Inscrit
22 Aout 2019
Messages
14
J'aime
2
#7
Alors, je viens de trouver le solution :

Ce qu'il se passe, c'est que j'utilise pyshark (qui lui utilise wireshark) pour récupérer les packets tcp, donc si j'ai un problème sur mon sniffeur python, il y a le même sur wireshark.

Je vais donc voir sur wireshark, et là je vois quelque fois :

1567201283676.png

La structure de l'erreur est toujours la même, un packet potentiellement perdu, un out of ordre et ensuite tout va bien.

(Je passe les retransmission car c'est pas important)

La solution est simple, il suffit d'analyser les numéros de séquence et de len, on voit clairement que :

seq_pkt83 = 4973 = seq_pkt85 + len_pkt85
seq_pkt84 = 3513 = seq_pkt79 + len_pkt79

Puis que seq_pkt87 = 5005 = seq_pkt83 + len_pkt83

En gros on en déduit que l'ordre vrai est le suivant :
pkt 79 -> pkt 85 -> pkt 83 -> pkt 87

J'ai donc ajouté dans mon code une mise en mémoire du packet si le flag Previous segment not captured est présent, et ensuite ce packet est ajouté à la fin du packet suivant pour remettre le tout dans l'ordre.

J'ai testé avec tous les endroits où ce problème apparaît et ça fonctionne à 100% (et heureusement car sinon ça voudrait dire que les packets tcp c'est naze..)
 
Haut Bas