Hoe kunnen we pakketten handmatig lezen en interpreteren zonder dradenhark te gebruiken?
Nu vanuit de Ethernet-header Ik weet dat het bestemmings-MAC-adres op de 5e byte moet staan (na het converteren van bits / bytes). Dus op basis van deze gegevens dacht ik dat het vanaf 4a zou zijn. In werkelijkheid is het echter “s 00:17:f2:d0:4c:82.
Hetzelfde geldt voor de IP-bronbestemming. De bron zou bijvoorbeeld 13-16 bytes moeten zijn. Volgens de metingen, ik denk dat het 0800 en hoger zou moeten zijn. Maar in werkelijkheid staat het op 0a 32 e7 85 maar ik begrijp niet waarom? Ik weet niet meer hoe ik deze gegevens correct moet interpreteren of misschien begrijp ik de algemene headerstructuur niet goed.
https://ntquan87.wordpress.com/2015/08/17/reading-packet-hex-dumps-manually-no-wireshark/
Answer
Ik vermoed dat wat u ziet een Ethernet-frame van niveau 2 is en daarom de preambule ontbreekt. Ook de Ethernet-checksum lijkt te ontbreken. In dit geval lijkt alles op één lijn te liggen (het pakkettype binnen het Ethernet-frame, de IPv4-versie, de IPv4-pakketlengte, het pakkettype, d.w.z. TCP, binnen het IP-pakket, …). Dan “had je je pakket gelezen zoals op de afbeelding.
De TCP-payload is
474554202f20485454502f312e300d0a 557365722d4167656e743a2057676574 2f312e31312e340d0a4163636570743a 202a2f2a0d0a486f73743a207777772e 696574662e6f72670d0a436f6e6e6563 74696f6e3a204b6565702d416c697665 0d0a0d0a en decodeert naar:
GET / HTTP/1.0 User-Agent: Wget/1.11.4 Accept: */* Host: www.ietf.org Connection: Keep-Alive wat samenhangt met het feit dat de bestemmingspoort 80 is.
Opmerkingen
- Omdat ik per ongeluk de labels had verwisseld voor bron en bestemming .. Mijn fout. Ik heb de afbeelding bijgewerkt. Er is geen checksum omdat de IPv4-headers zeggen dat het IPv4-pakket 152 bytes lang is, dwz het eindigt precies aan het einde van je gegevens. Je kunt gemakkelijk zien dat alle laatste bytes deel van de payload door hun gedecodeerde versie (het ' is een HTTP GET-verzoek).
- Ik don ' Ik weet niet waar u ' deze nummers vandaan haalt. De Ethernet-payload (IPv4-pakket) begint vanaf de 15e byte. Zie: nl .wikipedia.org / wiki / Ethernet_frame . Binnen het I Pv4-pakket, de lengte is in de 3e en 4e byte. Zie: en.wikipedia.org/wiki/IPv4#Packet_structure . Daarom is de lengte 0x0098 (in hexadecimaal), dat wil zeggen 152 bytes. Dit is de lengte van het volledige IPv4-pakket (het vak met de blauwe rand in de afbeelding).
- Ik begreep waar je ' de nummers vandaan haalt: je leest het diagram dat je op de verkeerde manier hebt gepost! De lengte van het Ethernet-bestemmingsadres is niet 32 bits! Het ' s 48 bits = 6 bytes … in het diagram, het " doel-MAC-adres " veld niet eindigt aan het einde van de tweede regel, maar het gaat ook door op de derde regel (in de witruimte, tot het " | " scheidingsteken). Hetzelfde geldt voor het bronadres (dat begint vanaf de lege ruimte van de derde regel en eindigt op de vierde regel). Ik stel voor om een minder verwarrend diagram te gebruiken …
- Ik weet niet ' waarom in je antwoorden de bron- en bestemmings-mac-adressen worden verwisseld. Dat klinkt als een goede vraag voor degene die je de antwoorden heeft gegeven … Wat betreft het IP-pakket, ik snap ' niet waarom je de IP-headers checksum ?? Van uw diagrammen zijn er precies 12 bytes in het IP-pakket vóór het veld " Bronadres ". Dit komt exact overeen met mijn figuur.
- Het protocol van de toepassingslaag is HTTP . De vlaggen zijn binair ingesteld op 000011000. Als je een lijst met vlaggen bekijkt, ' zie je dat de 5e en 6e vlag (die overeenkomen met set bits) zijn ACK en PSH.