Fragments UDP manquants lors de la surveillance du trafic avec tcpdump

Question

Je suis sur un LAN local avec seulement 8 ordinateurs connectés utilisant un switch Gigabit Netgear 24 ports, la charge réseau est très faible et les tampons d'envoi/réception sur tous les nœuds impliqués (Slackware 11) ont été réglés sur 16mb. Je cours également tcpdump sur chaque noeud pour surveiller le trafic. Un nœud émetteur envoie un grand paquet UDP de 10044 octets qui le plus souvent (3/4 fois) ne se retrouve pas dans l'application côté réception, dans ces cas, je remarque (en utilisant tcpdump) que les x premiers fragments sont manquants et seulement les 3 derniers (tous avec des offsets> 0 et dans l'ordre) sont attrapés par tcpdump. Le paquet UDP fragmenté ne peut donc pas être réassemblé et est probablement rejeté. Je trouve les fragments manquants étranges puisque j'ai aussi essayé un test de charge simple éclatant 10000 messages UDP de la même taille, l'application réceptrice envoie une réponse et tous les tests jusqu'à présent donnent 100% de réponses en retour.

Des indices ou des indices?

Answer 1

Mettre à jour! Après la reprise du test du logiciel mentionné ci-dessus, j'ai trouvé une manière répétable de recréer l'erreur. En utilisant windump sur l'ordinateur Windows expéditeur, et tcpdump sur l'ordinateur récepteur, après avoir laissé l'application inactive pendant un certain temps (~ 5 minutes), j'ai essayé d'envoyer le message udp, mais seulement avec un seul fragment capturé par windump et tcpdump, les 3 fragments restants sont perdus. Envoyer le même message une fois de plus fonctionne très bien et le stand windump et tcpdump capturent tous les 4 fragments et l'application du côté réception reçoit le message. Le motif est reproductible.

Commencé à chercher et trouvé l'information suivante, mais pour moi, toujours pas une réponse claire.

http://www.eggheadcafe.com/software/aspnet/32856705/first-udp-message-to-a-sp.aspx

Re examinant les journaux, je remarque maintenant la requête ARP/réponse envoyé, qui correspond à l'une des idées données dans le lien ci-dessus.

REMARQUE! Je filtre windump du côté émetteur à l'aide: "host dst receivernode"

Capture à partir windump: d'abord échoué un message udp, doit être de 4 longs fragments

14:52:45.342266 arp who-has receivernode tell sendernode 
14:52:45.342599 IP sendernode> receivernode : udp 

Capture à partir windump: deuxième message udp, exactement le même contenu, tous les 4 fragments capturés

14:52:54.132383 IP sendernode.10104 > receivernode .10113: UDP, length 6019 
14:52:54.132397 IP sendernode> receivernode : udp 
14:52:54.132406 IP sendernode> receivernode : udp 
14:52:54.132414 IP sendernode> receivernode : udp 
14:52:54.132422 IP sendernode> receivernode : udp 
14:52:56.142421 arp reply sendernode is-at 00:11:11:XX:XX:fd (oui unknown) 

Quelqu'un qui a une bonne idée de ce qui se passe? s'il vous plaît élaborer!