orm@doc-tcpip.org

Erstellt: Dezember 2000 - Letzte Modifikation: Mai 2001

[ Main | Local ]

Ping im Trace

Hier ein Ping zwischen den Maschinen 192.168.140.2 und 192.168.140.5. Die Maschine 192.168.140.2 möchte gerne wissen, ob die .5 läuft.
Ping ist ein Dienst im Rahmen des ICMP (Internet Control Message Protocol) und ist etwas schwer unterzubringen: es ist ein Teil des IP-Protokolls, obwohl es IP ähnlich benutzt wie die Transportprotokolle (UDP, TCP) auch.
Der Trace stammt wieder einmal von einer AIX-Maschine und ist mit -x formatiert, und ich gehe wieder zuerst das Paket in Hex durch. 



Packet Number 1
ETH: ====( 98 bytes transmitted on interface en0 )==== 09:52:22.267441248
ETH: 00000000     00a00c12 1ba10800 5af8b5b6 08004500     |........Z.....E.|
Die MAC des Empfängers und des Senders, dann 0x0800 für das Ethernetprotokoll. Danach 0x4 für IPv4 und 0x5 für die Länge des IP-Headers (5 32bit Worte). 

ETH: 00000010     0054c379 0000ff01 5ed6c0a8 8c02c0a8     |.T.y....^.......|
ETH: 00000020     8c05.... ........ ........ ........
Das letzte Byte der vorherigen Zeile und das erste Byte dieser Zeile ist der Type of Service - es ist nichts gesetzt. 0x54 ist die Länge des IP-Paketes in Byte: 84 in Dezimal. (Plus 14 Byte für den Ethernet-Header macht das 98 Byte) Dann kommen 2 Byte 0xc379, das ist die IP-ID des Paketes. Fragment Offset ist 0x0000, also gibt es keine Fragmente. 0xff ist 255 und die Anzahl der Hops, die das Paket durchlaufen darf. Jetzt wird es interessant: 0x01 ist die Protokoll Nummer des Paketes, was nach dem IP-Header kommt. Typ 1 ist ICMP. Danach kommt die Checksumme des IP-Headers: 0x5ed6. Dann die IP-Adressen: c0a88c02 und c0a88c0 (Die Quelle zuerst). 

ETH: 00000020     ....0800 e1581f1e 0000.... ........     |.....X....9..6..|
Hier fängt die ICMP-Message als solche an.
Das erste Byte ist der Typ: 0x08, also Typ 8. Das nächste Byte ist der zu diesem Typ gehörende Code: 0x00. Darauf folgt eine Checksumme (16 bit, 2 Byte, 0xe158). Dann kommt der Identifier (0x1f1e) und die Sequenznummer (2 Byte). Das ist das erste Paket dieses Pings, deshalb ist die Sequenznummer 0. 

ETH: 00000020     ........ ........ ....39e6 bf360004     |.....X....9..6..|
ETH: 00000030     13650809 0a0b0c0d 0e0f1011 12131415     |.e..............|
ETH: 00000040     16171819 1a1b1c1d 1e1f2021 22232425     |.......... !"#$%|
ETH: 00000050     26272829 2a2b2c2d 2e2f3031 32333435     |&'()*+,-./012345|
ETH: 00000060     3637                                    |67              |
Diese Daten dienen zum Auffüllen des Paketes...
Wieder bricht ipreport das ganze Benutzerfreundlich auf. 

ETH:    [ 08:00:5a:f8:b5:b6 -> 00:a0:0c:12:1b:a1 ]  type 800  (IP)
IP:  	< SRC =   192.168.140.2 >
IP:  	< DST =   192.168.140.5 >
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=50041, ip_off=0
IP:  	ip_ttl=255, ip_sum=5ed6, ip_p = 1 (ICMP)
ICMP: 	icmp_type=8 (ECHO_REQUEST)  icmp_id=7966  icmp_seq=0
Hier nun die Antwort auf den ECHO_REQUEST. Ich gehe nur auf die Änderungen ein. 

Packet Number 2
ETH: ====( 98 bytes received on interface en0 )==== 09:52:22.268081006
ETH: 00000000     08005af8 b5b600a0 0c121ba1 08004500     |..Z...........E.|
Die MAC Adressen sind natürlich andersherum... 

ETH: 00000010     00540074 0000ff01 21dcc0a8 8c05c0a8     |.T.t....!.......|
Der Typ ist immer noch ICMP: == Die IPs sind vertauscht, klar. 

ETH: 00000020     8c020000 e9581f1e 000039e6 bf360004     |.....X....9..6..|
====
Hier hat sich jetzt was geändert: Der Typ und der Code sind beide 0. Das ist für den ECHO_REPLY so üblich. Der Identifier (0x1f1e) ist gleich - so kann man verschiedene Instanzen des Ping-Kommandos unterscheiden. Die Sequenznummer ist 0 - es ist das erste Paket. Dann kommt wieder unsinniges Zeug (um das Paket voll zu kriegen). 

ETH: 00000030     13650809 0a0b0c0d 0e0f1011 12131415     |.e..............|
ETH: 00000040     16171819 1a1b1c1d 1e1f2021 22232425     |.......... !"#$%|
ETH: 00000050     26272829 2a2b2c2d 2e2f3031 32333435     |&'()*+,-./012345|
ETH: 00000060     3637                                    |67              |
Dasselbe in Easy-Read: 

ETH:    [ 00:a0:0c:12:1b:a1 -> 08:00:5a:f8:b5:b6 ]  type 800  (IP)
IP:  	< SRC =   192.168.140.5 >
IP:  	< DST =   192.168.140.2 >
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=116, ip_off=0
IP:  	ip_ttl=255, ip_sum=21dc, ip_p = 1 (ICMP)
ICMP: 	icmp_type=0 (ECHO_REPLY)  icmp_id=7966  icmp_seq=0

Packet Number 3
ETH: ====( 98 bytes transmitted on interface en0 )==== 09:52:23.269029601
ETH: 00000000     00a00c12 1ba10800 5af8b5b6 08004500     |........Z.....E.|
ETH: 00000010     0054c37a 0000ff01 5ed5c0a8 8c02c0a8     |.T.z....^.......|
ETH: 00000020     8c050800 dac11f1e 000139e6 bf370004     |..........9..7..|
==
Jetzt wird die Sequenz-Nummer erhöht. 

ETH: 00000030     19fa0809 0a0b0c0d 0e0f1011 12131415     |................|
ETH: 00000040     16171819 1a1b1c1d 1e1f2021 22232425     |.......... !"#$%|
ETH: 00000050     26272829 2a2b2c2d 2e2f3031 32333435     |&'()*+,-./012345|
ETH: 00000060     3637                                    |67              |
ETH:    [ 08:00:5a:f8:b5:b6 -> 00:a0:0c:12:1b:a1 ]  type 800  (IP)
IP:  	< SRC =   192.168.140.2 >
IP:  	< DST =   192.168.140.5 >
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=50042, ip_off=0
IP:  	ip_ttl=255, ip_sum=5ed5, ip_p = 1 (ICMP)
ICMP: 	icmp_type=8 (ECHO_REQUEST)  icmp_id=7966  icmp_seq=1
============  ===========
Was man hier auch sieht: Die ID bleibt aber gleich!! 

Packet Number 4
IP:  	< SRC =   192.168.140.5 >
IP:  	< DST =   192.168.140.2 >
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=117, ip_off=0
IP:  	ip_ttl=255, ip_sum=21db, ip_p = 1 (ICMP)
ICMP: 	icmp_type=0 (ECHO_REPLY)  icmp_id=7966  icmp_seq=1
Die Antwort dazu. 

Packet Number 5
IP:  	< SRC =   192.168.140.2 >
IP:  	< DST =   192.168.140.5 >
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=50043, ip_off=0
IP:  	ip_ttl=255, ip_sum=5ed4, ip_p = 1 (ICMP)
ICMP: 	icmp_type=8 (ECHO_REQUEST)  icmp_id=7966  icmp_seq=2

Packet Number 6
IP:  	< SRC =   192.168.140.5 >
IP:  	< DST =   192.168.140.2 >
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=118, ip_off=0
IP:  	ip_ttl=255, ip_sum=21da, ip_p = 1 (ICMP)
ICMP: 	icmp_type=0 (ECHO_REPLY)  icmp_id=7966  icmp_seq=2
Und so geht es jetzt weiter...

Ping ist jetzt nur ein kleiner Teil des ICMP. Der RFC792 gibt alle benutzten ICMP-Typen und ihre Codes. Je nach Typ ist der Header dabei unterschiedlich - will man das Paket "groken" so muss man sich zB. den Stevens hernehmen (Seite 69). Wichtig ist auch: Je nach Implementation sind andere Messages mit den ICMP-Messages verbunden. Teilweise defaulten verschiedene Codes zur selben User-Message (in 4.4BSD ist zB. "Port unreachable" und "protocol unreachable" diesselbe User-Message: "Connection refused").

Ein Ping mit der -R Option für die genommene Route:

(Am besten mit -n kombinieren - man spart sich die Namensauflösung) 

IPTRACE version: 2.0

Packet Number 1
TOK: ====( 146 bytes transmitted on interface tr0 )==== 14:03:19.820844718
TOK: 00000000     00401000 5ab1a6ef 000629b9 503faaaa     |.@..Z.....).P?..|
TOK: 00000010     03000000 0800.... ........ ........     |......O..|.$....|

TOK: 00000010     ........ ....4f00 007cc424 0000ff01     |......O..|.$....|
=
Hier eine Überraschung: die Länge des Headers wird mit 0xf, also 15 32-bit Worten angegeben! Der Type of Service (die nächsten 2 Byte) ist 0. 0x7c ist die Länge des IP- Teiles, also 124 Byte. 0xc424 ist die Paket ID, die nächsten 2 Byte geben den Fragment Offset an: 0. 0xff sind die möglichen Hops: 255. Als letztes Byte kommt der Protokolltyp nach dem IP-Header: Typ 1, also ICMP. 

TOK: 00000020     b32b0927 004a0935 1c64.... ........     |.+.'.J.5.d.'....|
Checksumme:       ====
Dann die IP-Adressen in Hex: 0927004a und 09351c64. Wie wir oben gesehen haben, hat der IP-Header in diesem Paket die maximale Länge (15 32-Bit Wörter, also 60 Byte.). 

TOK: 00000020     ........ ........ ....0727 04000000     |.+.'.J.5.d.'....|
Es kommt jetzt die IP-Option: 0x07, also 7 Dezimal, und das ist Route Record. Jeder Router auf dem Weg muss seine IP hier Eintragen, am Ziel werden die Adressen in den Datenteil umkopiert und die Router des Rückweges tragen sich wieder in den IP Header ein. Das nächste Byte (0x27) gibt die gesamte Länge der RR Option an: 39 - hier wird standardmässig der maximal-Wert genommen. Was nun kommt, ist ein Pointer zum jeweils aktuellen, freien Eintrag. In diesem Fall ist es 0x04, also das 4. Byte ist das erste Byte der ersten Adresse, die auf dem Weg des Paketes liegt. Der Pointer wird dann erhöht, und der nächste Router schreibt an die angegebene Stelle - das wäre 8. In der Folge kommen die IP-Adressen der Router, und zwar immer das Interface, über dass das Paket den Router verlässt! 

TOK: 00000030     00000000 00000000 00000000 00000000     |................|
TOK: ********
TOK: 00000050     00000800 d950863c 000039ea ee87000c     |.....P.<..9.....|
.                     ==
Hier ist der IP-Header zuende, der normale ICMP-Header beginnt. Ping -R hat also eigentlich nichts mit ICMP zu tun.. ;-) 

TOK: 00000060     84f10809 0a0b0c0d 0e0f1011 12131415     |................|
TOK: 00000070     16171819 1a1b1c1d 1e1f2021 22232425     |.......... !"#$%|
TOK: 00000080     26272829 2a2b2c2d 2e2f3031 32333435     |&'()*+,-./012345|
TOK: 00000090     3637                                    |67              |
TOK: 802.5 packet
TOK: 802.5 MAC header:
TOK: access control field = 0, frame control field = 40
TOK: [ src = 00:06:29:b9:50:3f, dst = 10:00:5a:b1:a6:ef]
TOK: 802.2 LLC header:
TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP:     < SRC =       9.39.0.74 >  (cristina.ncs.mainz.ibm.com)
IP:     < DST =     9.53.28.100 >  (tcaustin.austin.ibm.com)
IP:     ip_v=4, ip_hl=60, ip_tos=0, ip_len=124, ip_id=50212, ip_off=0
Ipreport kümmert sich um den längeren Header nicht... 

IP:     ip_ttl=255, ip_sum=b32b, ip_p = 1 (ICMP)
ICMP:   icmp_type=8 (ECHO_REQUEST)  icmp_id=34364  icmp_seq=0
Hier jetzt das Paket nach der Ankunft, also nach einen Round Trip (Rundlauf). 

Packet Number 2
TOK: ====( 146 bytes received on interface tr0 )==== 14:03:20.026738653
TOK: 00000000     10400006 29b9503f 4282100c 0602aaaa     |.@..).P?B.......|
TOK: 00000010     03000000 08004f00 007c864b 0000f501     |......O..|.K....|
TOK: 00000020     2c730935 1c640927 004a0727 28092700     |,s.5.d.'.J.'(.'.|
Hier fängt der RR an: == Es sind immer noch 60 Byte, klar. == Der Pointer ist aber jetzt anders! == (40 Dezimal) Das heisst, das wir wahrscheinlich schon Pech gehabt haben. Es sind 9 IP- Adressen im Header. Mehr passen nicht rein, und werden auch nicht mitgeschnitten. 

TOK: 00000030     bf098b78 04091fe5 4e098b66 8209204a     |...x....N..f.. J|
TOK: 00000040     36092001 2d092069 39090385 b909033f     |6. .-. i9......?|
TOK: 00000050     fd...... ........ ........ ........     |.....P.<..9.....|
Das heisst, das die Router, über die das Packet gelaufen ist, folgende IP haben: 092700bf, 098b7804, 091fe54e, 098b6682, 09204a36, 0920012d, 09206939, 090385b9 und 09033ffd. 

TOK: 00000050     ..000000 e150863c 000039ea ee87000c     |.....P.<..9.....|
.                     ====
Hier findet sich wieder der Start des ICMP-Paketes. Der Identifier stimmt auch: 0x863c. Und die zweite 0000 ist die Sequenznummer 0. Dann kommen wieder sinnlose Daten. 

TOK: 00000060     84f10809 0a0b0c0d 0e0f1011 12131415     |................|
TOK: 00000070     16171819 1a1b1c1d 1e1f2021 22232425     |.......... !"#$%|
TOK: 00000080     26272829 2a2b2c2d 2e2f3031 32333435     |&'()*+,-./012345|
TOK: 00000090     3637                                    |67              |
TOK: 802.5 packet
TOK: 802.5 MAC header:
TOK: access control field = 10, frame control field = 40
TOK: [ src = 42:82:10:0c:06:02, dst = 00:06:29:b9:50:3f]
TOK: 802.2 LLC header:
TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP)
IP:     < SRC =     9.53.28.100 >  (tcaustin.austin.ibm.com)
IP:     < DST =       9.39.0.74 >  (cristina.ncs.mainz.ibm.com)
IP:     ip_v=4, ip_hl=60, ip_tos=0, ip_len=124, ip_id=34379, ip_off=0
IP:     ip_ttl=245, ip_sum=2c73, ip_p = 1 (ICMP)
Auch hier kümmert sich ipreport nicht um die Header-Erweiterungen. 

ICMP:   icmp_type=0 (ECHO_REPLY)  icmp_id=34364  icmp_seq=0

Wie sieht ein Ping auf sich selbst aus?

Pingt man sein eigenes Interface, dann erkennt die IP-Schicht aufgrund der Routing Table, das es sich um das eigene Interface handelt und der Verkehr geht dann über das Loopback.
So ist das Interface gesetzt: 


en0: flags=e080863< UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT>
inet 192.168.140.3 netmask 0xffffff00 broadcast 192.168.140.255
Hier die Routing Table: 

Routing tables
Destination      Gateway           Flags   Refs     Use  If   PMTU  Exp  Groups

Route Tree for Protocol Family 2 (Internet):
default          9.39.0.191        UG        7    98072  tr0     -   -
9.39/20          9.39.0.74         U       113   691329  tr0     -   -
127/8            127.0.0.1         U         3    11846  lo0     -   -
192.168.140/24   192.168.140.3     U         1  2457493  en0     -   -

Route Tree for Protocol Family 24 (Internet v6):
::1              ::1               UH        0        0  lo0 16896   -
Und hier der Trace:
Im Trace oben wurde zuerst ein ARP geschickt, weil die Adresse unbekannt, aber über eine Route zu erreichen war. Hier ist in diesem Prozess klar geworden, das der beste Weg der Loopback ist.
Wichtig bei der Sache ist, das es keinen Eintrag in der arp-Table für das eigene Interface gibt! Der Rechner geht ja nicht über den Draht, und braucht deshalb auch keine MAC Adresse. 

Packet Number 1
====( 84 bytes transmitted on interface lo0 )==== 11:29:27.262417944
00000000     45000054 6d710000 ff01b4e3 c0a88c01     |E..Tmq..........|
00000010     c0a88c01 08002bf5 5eea0000 39f94af7     |......+.^...9.J.|
00000020     0003fd29 08090a0b 0c0d0e0f 10111213     |...)............|
00000030     14151617 18191a1b 1c1d1e1f 20212223     |............ !"#|
00000040     24252627 28292a2b 2c2d2e2f 30313233     |$%&'()*+,-./0123|
00000050     34353637                                |4567            |
OTHER packet   (IP)
IP:     < SRC =   192.168.140.1 >
IP:     < DST =   192.168.140.1 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=28017, ip_off=0
IP:     ip_ttl=255, ip_sum=b4e3, ip_p = 1 (ICMP)
ICMP:   icmp_type=8 (ECHO_REQUEST)  icmp_id=24298  icmp_seq=0

Packet Number 2
====( 84 bytes transmitted on interface lo0 )==== 11:29:27.262469172
00000000     45000054 6d720000 ff01b4e2 c0a88c01     |E..Tmr..........|
00000010     c0a88c01 000033f5 5eea0000 39f94af7     |......3.^...9.J.|
00000020     0003fd29 08090a0b 0c0d0e0f 10111213     |...)............|
00000030     14151617 18191a1b 1c1d1e1f 20212223     |............ !"#|
00000040     24252627 28292a2b 2c2d2e2f 30313233     |$%&'()*+,-./0123|
00000050     34353637                                |4567            |
OTHER packet   (IP)
IP:     < SRC =   192.168.140.1 >
IP:     < DST =   192.168.140.1 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=28018, ip_off=0
IP:     ip_ttl=255, ip_sum=b4e2, ip_p = 1 (ICMP)
ICMP:   icmp_type=0 (ECHO_REPLY)  icmp_id=24298  icmp_seq=0

Packet Number 3
====( 84 bytes transmitted on interface lo0 )==== 11:29:28.265362305
00000000     45000054 6d730000 ff01b4e1 c0a88c01     |E..Tms..........|
00000010     c0a88c01 08001f7c 5eea0001 39f94af8     |.......|^...9.J.|
00000020     000409a0 08090a0b 0c0d0e0f 10111213     |................|
00000030     14151617 18191a1b 1c1d1e1f 20212223     |............ !"#|
00000040     24252627 28292a2b 2c2d2e2f 30313233     |$%&'()*+,-./0123|
00000050     34353637                                |4567            |
OTHER packet   (IP)
IP:     < SRC =   192.168.140.1 >
IP:     < DST =   192.168.140.1 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=28019, ip_off=0
IP:     ip_ttl=255, ip_sum=b4e1, ip_p = 1 (ICMP)
ICMP:   icmp_type=8 (ECHO_REQUEST)  icmp_id=24298  icmp_seq=1

Packet Number 4
====( 84 bytes transmitted on interface lo0 )==== 11:29:28.265416441
00000000     45000054 6d740000 ff01b4e0 c0a88c01     |E..Tmt..........|
00000010     c0a88c01 0000277c 5eea0001 39f94af8     |......'|^...9.J.|
00000020     000409a0 08090a0b 0c0d0e0f 10111213     |................|
00000030     14151617 18191a1b 1c1d1e1f 20212223     |............ !"#|
00000040     24252627 28292a2b 2c2d2e2f 30313233     |$%&'()*+,-./0123|
00000050     34353637                                |4567            |
OTHER packet   (IP)
IP:     < SRC =   192.168.140.1 >
IP:     < DST =   192.168.140.1 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=84, ip_id=28020, ip_off=0
IP:     ip_ttl=255, ip_sum=b4e0, ip_p = 1 (ICMP)
ICMP:   icmp_type=0 (ECHO_REPLY)  icmp_id=24298  icmp_seq=1

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]

Copyright 2001-2021 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )