Comment vérifier le contenu des paquets retournés dans ICMP Ping / Echo?

Question

Lors de la validation de l'écho de ping, il semble que les utilitaires / bibliothèques ne vérifient souvent que la somme de contrôle du paquet et ne confirment pas réellement que la charge utile envoyée correspond à la charge renvoyée. Par exemple, l'analyseur ICMP de Wireshark ne vérifie que les sommes de contrôle incorrectes, et c'est tout ce que Ruby a net- ruby vérifie également.

Je suis en train de déboguer un problème de pilote réseau de bas niveau et je dois confirmer que les données ne sont pas endommagées lors de la réception. Je souhaite donc tester mon pilote à l'aide d'une requête de bas niveau telle que Écho ICMP . Cependant, mes outils Ping existants sont insuffisants, car je crains que, même si la somme de contrôle puisse correspondre aux données contenues dans la réponse d'écho, les données de la réponse d'écho ne correspondent pas aux données de la demande d'écho. Ainsi, même s'ils ont tous les deux une somme de contrôle valide (il n'y a pas d'erreur dans le code de somme de contrôle), il y a une erreur dans la partie de réception des données, telle que mon pilote ne reçoit pas ce que l'hôte pense envoyer.

Comment puis-je vérifier la charge d'écho pour confirmer que c'est la même chose que ce que j'ai envoyé? S'il existe un "ping paranoïaque autonome" utilitaire que je pourrais utiliser, c’est bien aussi - je dois juste être capable de faire varier les longueurs de ping et les fréquences car je ne vois le problème que lorsque le réseau est inondé.

Je le préférerais sous la forme d’une bibliothèque / d’un extrait Ruby, mais n’importe quel langage ou application autonome est acceptable, pour autant que je puisse le faire fonctionner sous Windows.

Merci!

Answer 1

@Tom: Merci pour la réponse. Vous avez dit:

  

Le destinataire recalcule une somme de contrôle à partir des données et la compare à celle qui a été envoyée.

Mais vous avez également dit:

  

La somme de contrôle ICMP n'inclut pas les en-têtes TCP, mais uniquement le type, le code, la somme de contrôle et les champs de données ICMP.

Le type ICMP est différent entre la demande / réponse en écho (l’un est 0, l’autre, je pense 8). Donc, par définition (et dans la pratique, si vous jetez un coup d’œil avec Wireshark), les sommes de contrôle ICMP ne correspondent pas entre la demande d’envoi et la réponse en écho.

Mon problème était que si les utilitaires / bibliothèques de ping vérifiaient quelque chose (et souvent non), ils vérifiaient uniquement que la somme de contrôle correspondait aux données. Il semble que rarement, les gens vérifient réellement les données envoyées avec la réponse renvoyée pour s'assurer que les deux charges utiles sont identiques. Il est possible qu'une demande et une réponse aient des sommes de contrôle valides, mais des charges utiles différentes et la plupart des routines Ping que j'ai vues n'ont pas vérifié cette condition (mais il s'agit du type de bogue que j'ai sur mon ordinateur. appareil pour le moment).

Merci d'avoir regardé ma question et d'avoir répondu à cela - c'est très apprécié.

@All:

En réponse à ma propre question, j'ai pu utiliser le robuste . Net Ping , car cela me donne un accès immédiat au tampon de réponse reçu (contrairement à la plupart des autres bibliothèques Ping que j'ai trouvées).

Answer 2

Je pense que vous manquez le point de la somme de contrôle. Le but de la somme de contrôle est de valider que les données sont intactes. L'expéditeur calcule la somme de contrôle à partir des données et le transmet avec les données. Le destinataire recalcule une somme de contrôle à partir des données et la compare à celle qui a été envoyée. Si elles ne correspondent pas, les données ne sont pas intactes ou l’un des deux les calcule de manière erronée. Le plus souvent, les mauvaises sommes de contrôle n'aboutissent pas à des pertes de paquets, car il y a beaucoup de piles de protocoles cassées et, bien sûr, des paquets de paquets qui ne corrigent pas la somme de contrôle, mais si les deux côtés le font correctement, la vérification de la somme de contrôle vous indique que les données sont intactes.

Consultez-vous la somme de contrôle TCP ou la somme de contrôle ICMP? La somme de contrôle ICMP n'inclut pas les en-têtes TCP, mais uniquement le type, le code, la somme de contrôle et les champs de données ICMP. Un échec de la somme de contrôle TCP ne signifie pas nécessairement que le contenu ICMP n'est pas intact, cela peut simplement signifier que les en-têtes TCP ont été gâchés (par un NAT cassé, peut-être).