libnet crée des paquets UDP avec des sommes de contrôle invalides

Question

J'utilise pylibnet pour construire et envoyer des paquets UDP. Les paquets UDP que je construis de cette manière semblent tous avoir des sommes de contrôle invalides. Exemple:

# python 
Python 2.4.3 (#1, Sep 3 2009, 15:37:12) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2 
Type "help", "copyright", "credits" or "license" for more information. 
>>> 
>>> import libnet 
>>> from libnet.constants import * 
>>> 
>>> net = libnet.context(RAW4, 'venet0:0') 
>>> ip = net.name2addr4('www.stackoverflow.com', RESOLVE) 
>>> data = 'This is my payload.' 
>>> udptag = net.build_udp(sp=54321, dp=54321, payload=data) 
>>> packetlen = IPV4_H + UDP_H + len(data) 
>>> iptag = net.autobuild_ipv4(len=packetlen, prot=IPPROTO_UDP, dst=ip) 
>>> 
>>> net.write() 

capture le paquet ci-dessus sur l'hôte émetteur révèle une somme de contrôle invalide:

# tcpdump -i venet0:0 -n -v -v port 54321 
tcpdump: WARNING: arptype 65535 not supported by libpcap - falling back to cooked socket 
tcpdump: listening on venet0:0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 
08:16:10.303719 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto: UDP (17), length: 47) 192.168.55.10.54321 > 69.59.196.211.54321: [bad udp cksum 50c3!] UDP, length 0 

que je fais quelque chose de mal ici?

Answer 1

Il n'y a rien à voir avec les bugs tcpdump ou de contrôle de déchargement. Libnet calcule également la somme de contrôle en mode utilisateur (FYI). Le problème a à voir avec le fait que vous n'avez pas spécifié de longueur pour l'en-tête UDP. Ce n'est pas automagiquement calculé dans pylibnet ou libnet donc vous devez le spécifier pour le moment. Voici la version corrigée de votre code. J'appliquerai un patch à pylibnet pour détecter automagiquement la longueur de l'en-tête dans rc6. Restez à l'écoute http://sourceforge.net/projects/pylibnet pour les mises à jour. Je vais pousser une nouvelle version corrigeant ce problème. En passant, n'hésitez pas à me contacter via la page pylibnet de sourceforge si vous avez des demandes de bugs ou de fonctionnalités. J'aime entendre des développeurs utilisant mon logiciel :)

---

import libnet 
from libnet.constants import * 

net = libnet.context(RAW4, 'venet0:0') 
ip = net.name2addr4('www.stackoverflow.com', RESOLVE) 
data = 'This is my payload.' 
udptag = net.build_udp(len=UDP_H+len(data), sp=54321, dp=54321, payload=data) 
packetlen = IPV4_H + UDP_H + len(data) 
iptag = net.autobuild_ipv4(len=packetlen, prot=IPPROTO_UDP, dst=ip) 

net.write() 

Answer 2

Le travail de calcul des sommes de contrôle n'est généralement pas effectué dans la bibliothèque de l'espace utilisateur mais dans le pilote de périphérique ou dans le matériel. Je crois que vous voyez le résultat de "checksum déchargement", où le périphérique physique calcule les sommes de contrôle sur les paquets sortants, en économisant des cycles de CPU sur l'hôte. Beaucoup (sinon toutes) les cartes Ethernet modernes le font, et les pilotes ne calculent pas la somme de contrôle. Puisque tcpdump capture les paquets dans le pilote, avant qu'ils ne parviennent au périphérique physique, il devient juste corrompu dans le champ checksum (probablement ce qui reste dans le buffer) et se plaint. Il y avait plusieurs "bogues" rapportés contre Wireshark pendant la période 2005-2008 couvrant ceci, et Wireshark (qui est juste un wrapper GUI sur tcpdump ou son équivalent Windoze) a maintenant une option pour désactiver la validation de checksum pour le cas de déchargement .

http://wiki.wireshark.org/TCP_Checksum_Verification

En tout état de cause, je ne serais pas attendre pylibnet (ou libnet) d'être responsable des checksums.

Voir aussi http://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html#id4744523

Answer 3

J'ai mis à jour pour inclure pylibnet une détermination automatique de la taille des champs de longueur dans la plupart des en-têtes. De cette façon, si vous oubliez de spécifier la longueur de l'en-tête pour l'un des en-têtes qui l'exigent, il tentera de le déterminer automatiquement. Vous évite le mal de tête de comprendre pourquoi votre somme de contrôle est mauvaise;)