Comment pouvons-nous lire et interpréter manuellement les paquets correctement sans utiliser WireShark?
Maintenant à partir de len-tête Ethernet Je sais que ladresse MAC de destination doit être au 5ème octet (après la conversion des bits / octets). Donc, à partir de ces données, jai pensé que ce serait à partir de 4a. Cependant, en réalité, il « s 00:17:f2:d0:4c:82.
Il en va de même pour la destination source IP. Par exemple, la source doit être de 13 à 16 octets. Selon les lectures, je suppose que cela devrait être 0800. Mais en réalité, cest sur 0a 32 e7 85 mais je ne comprends pas pourquoi? Je ne sais pas comment interpréter correctement ces données ou peut-être que je comprends mal la structure générale des en-têtes.
https://ntquan87.wordpress.com/2015/08/17/reading-packet-hex-dumps-manually-no-wireshark/
Réponse
Je suppose que ce que vous voyez est une trame Ethernet de niveau 2 et donc le préambule est absent. De plus, la somme de contrôle Ethernet semble manquer. Dans ce cas, tout semble saligner (le type de paquet à lintérieur de la trame Ethernet, la version IPv4, la longueur du paquet IPv4, le type de paquet, cest-à-dire TCP, à lintérieur du paquet IP, …). Ensuite, vous « auriez lu votre paquet comme sur limage.
La charge utile TCP est
474554202f20485454502f312e300d0a 557365722d4167656e743a2057676574 2f312e31312e340d0a4163636570743a 202a2f2a0d0a486f73743a207777772e 696574662e6f72670d0a436f6e6e6563 74696f6e3a204b6565702d416c697665 0d0a0d0a et décode en:
GET / HTTP/1.0 User-Agent: Wget/1.11.4 Accept: */* Host: www.ietf.org Connection: Keep-Alive ce qui est cohérent avec le fait que le port de destination est 80.
Commentaires
- Parce que javais inversé par erreur les étiquettes pour la source et la destination .. . Mon mauvais. Jai mis à jour limage. Il ny a pas de somme de contrôle car les en-têtes IPv4 indiquent que le paquet IPv4 fait 152 octets, cest-à-dire quil se termine exactement à la fin de vos données. Vous pouvez facilement voir que tous les derniers octets sont partie de la charge utile par leur version décodée (il ' est une requête HTTP GET).
- Je ne ' Je ne sais pas doù vous ' obtenir ces numéros. La charge utile Ethernet (paquet IPv4) commence au 15ème octet. Voir: fr .wikipedia.org / wiki / Ethernet_frame . Dans le I Paquet Pv4, sa longueur est comprise entre le 3ème et le 4ème octet. Voir: en.wikipedia.org/wiki/IPv4#Packet_structure . Par conséquent, la longueur est 0x0098 (en hexadécimal), cest-à-dire 152 octets. Il sagit de la longueur du paquet IPv4 entier (la case avec la bordure bleue sur limage).
- Jai compris où vous ' obtenir les nombres de: vous lisez le diagramme que vous avez posté dans le mauvais sens! La longueur de ladresse de destination Ethernet nest pas de 32 bits! Il ' s 48 bits = 6 octets … dans le diagramme, " Adresse MAC de destination " ne se termine pas à la fin de la deuxième ligne, mais il continue également sur la troisième ligne (dans lespace blanc, jusquà ce que le " | " séparateur). Il en va de même pour ladresse source (qui commence à partir de lespace vide de la troisième ligne et se termine dans la quatrième ligne). Je suggère dutiliser un diagramme moins déroutant …
- Je ne ' pas savoir pourquoi dans vos réponses les adresses mac source et destination sont permutées. Cela ressemble à une bonne question pour celui qui vous a donné les réponses … En ce qui concerne le paquet IP, je ne comprends pas pourquoi vous voudriez supprimer la somme de contrôle des en-têtes IP ?? Daprès vos diagrammes, il y a exactement 12 octets dans le paquet IP avant le champ " Adresse source ". Cela correspond exactement à mon chiffre.
- Le protocole de la couche application est HTTP . Les indicateurs sont définis sur 000011000 en binaire. Si vous regardez une liste dindicateurs , vous ' verrez que les 5e et 6e indicateurs (correspondant à bits) sont ACK et PSH.