Hvordan kan vi manuelt lese og tolke pakker riktig uten å bruke wireshark?
Nå fra Ethernet-overskriften Jeg vet at destinasjons-MAC-adressen skal være på 5. byte (etter konvertering av biter / byte). Så fra disse dataene trodde jeg at det ville være 4a og utover. I virkeligheten er det imidlertid «s 00:17:f2:d0:4c:82.
Det samme gjelder IP-kildedestinasjonen. For eksempel skal kilden være 13-16 byte. I henhold til avlesningene, antar jeg at det skal være 0800 og utover. Men i virkeligheten er det på 0a 32 e7 85 men jeg skjønner ikke hvorfor? Jeg er bare forvirret over hvordan jeg skal tolke disse dataene riktig, eller kanskje jeg forstår den generelle overskriftsstrukturen feil.
https://ntquan87.wordpress.com/2015/08/17/reading-packet-hex-dumps-manually-no-wireshark/
Svar
Jeg antar at det du ser er en nivå 2 Ethernet-ramme og derfor inngangen mangler. Også Ethernet-kontrollsummen ser ut til å mangle. I dette tilfellet ser det ut til at alt stemmer overens (pakketypen inne i Ethernet-rammen, IPv4-versjonen, IPv4-pakkelengden, pakketypen, dvs. TCP, inne i IP-pakken, …). Så hadde du lest pakken din som på bildet.
TCP-nyttelasten er
474554202f20485454502f312e300d0a 557365722d4167656e743a2057676574 2f312e31312e340d0a4163636570743a 202a2f2a0d0a486f73743a207777772e 696574662e6f72670d0a436f6e6e6563 74696f6e3a204b6565702d416c697665 0d0a0d0a og dekoder til:
GET / HTTP/1.0 User-Agent: Wget/1.11.4 Accept: */* Host: www.ietf.org Connection: Keep-Alive som er sammenhengende med at destinasjonsporten er 80.
Kommentarer
- Fordi jeg feilaktig hadde byttet ut etikettene for kilde og destinasjon .. Det er dårlig. Jeg har oppdatert bildet. Det er ingen kontrollsum fordi IPv4-overskriftene sier at IPv4-pakken er 152 byte lang, dvs. at den slutter nøyaktig på slutten av dataene dine. Du kan enkelt se at alle de siste byte er en del av nyttelasten etter deres dekodede versjon (den ' er en HTTP GET-forespørsel).
- Jeg don ' t vet hvor du ' får disse tallene fra. Ethernet-nyttelasten (IPv4-pakke) starter fra den 15. byten. Se: no .wikipedia.org / wiki / Ethernet_frame . Innenfor I Pv4-pakke, lengden er i 3. og 4. byte. Se: no.wikipedia.org/wiki/IPv4#Packet_structure . Derfor er lengden 0x0098 (i heksadesimal), det vil si 152 byte. Dette er lengden på hele IPv4-pakken (boksen med den blå rammen på bildet).
- Jeg forsto hvor du ' får tak i tallene fra: du leser diagrammet du la ut på feil måte! Lengden på Ethernet-destinasjonsadressen er ikke 32 bits! Det ' s 48 bits = 6 byte … i diagrammet, " Destinasjons MAC-adresse " -feltet slutter ikke på slutten av den andre linjen, men det fortsetter også på den tredje linjen (i det hvite rommet til " | " separator). Det samme gjelder kildeadressen (som starter fra det tomme rommet på den tredje linjen og ender i den fjerde linjen). Jeg foreslår at du bruker et mindre forvirrende diagram …
- Jeg vet ikke ' hvorfor i dine svar byttes kilden og destinasjonen til mac-adressene. Det høres ut som et godt spørsmål til den som ga deg svarene … Når det gjelder IP-pakken, skjønner jeg ikke ' hvorfor du vil fjerne IP-overskriftssummen ?? Fra diagrammene dine er det nøyaktig 12 byte i IP-pakken før " Kildeadresse " -feltet. Dette samsvarer nøyaktig med figuren min.
- Applikasjonslagsprotokollen er HTTP . Flaggene er satt til 000011000 i binær. Hvis du ser på en flaggliste , vil du ' se at 5. og 6. flagg (tilsvarer sett bits) er ACK og PSH.