tcpdump(1M) tcpdump(1M)
NAME
tcpdump - Datenverkehr-Diagnose in einem Netz ausgeben
SYNTAX
tcpdump [-deflmnNOpqStvx] [-c zähler] [-F Datei] [-i schnittstelle]
[-r datei] [-s snaplen] [-A ULLCno] [-w fdatei] ausdruck
BESCHREIBUNG
tcpdump versetzt eine Netzschnittstelle in einen Modus (promiscuous
mode), in dem alle Pakete vom Netz gelesen und ausgewertet werden kön-
nen. Dann filtert tcpdump die Pakete heraus, die zum Wert von ausdruck
passen und gibt die Information aus. Zum Aufrufen von tcpdump benöti-
gen Sie die Systemverwalterberechtigung.
Hinweis:
Dieses Kommando sollte nur von erfahrenen Systemverwaltern zu Diagno-
sezwecken benutzt werden.
OPTIONEN
-c zähler
Kommandoausführung nach dem Empfang von zähler-Paketen beenden.
-d Übersetzten Code des Filter-Ausdrucks auf Standardausgabe ausge-
ben und Kommandoausführung beenden.
-e In jeder Zeile den Header auf Verbindungsebene (link-level hea-
der) ausgeben. In einem Token-Ring-Netz zusätzlich die Source-
Routing-Information ausgeben.
-f foreign (ferne) Internet-Adressen im numerischen und nicht im
symbolischen Format ausgeben.
-F Datei
Datei als Eingabe für den Filter-Ausdruck (expression) benutzen.
Weitere in der Kommandozeile angegebene Ausdrücke werden gegebe-
nenfalls ignoriert.
-i interface
Die Schnittstelle schnittstelle überwachen (listen). Wenn diese
Option nicht angegeben wird, sucht tcpdump in der System-Schnitt-
stellenliste nach der konfigurierten Schnittstelle mit der nie-
drigsten Nummer (Loopback-Schnittstellen werden jedoch nicht
berücksichtigt).
Seite 1 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
-l Die Standardausgabe in den zeilengepufferten Modus versetzen.
Diese Option ist immer dann nützlich, wenn Sie sich die Daten
beim Erfassen ansehen möchten.
Beispiele:
tcpdump -l | tee dat
tcpdump -l > dat & tail -f dat
-m Schaltet die Schnittstelle in den "Multicast Promiscuous Mode",
damit werden alle Multicast-Pakete empfangen.
-n Adressen, d. h. Rechner-Adressen, Portnummern usw. nicht in Namen
umwandeln.
-N Rechnernamen ohne Domänennamen ausgeben. Dadurch zeigt tcpdump
bei Angabe dieses Parameters beispielsweise nur nic an und nicht
nic.ddn.mil.
-O Optimierer für Paketfilter-Code nicht aufrufen. Diese Option ist
nur dann hilfreich, wenn Sie vermuten, daß der Optimierer fehler-
haft arbeitet.
-p Die Schnittstelle nicht in den "promiscuous mode" versetzen.
Beachten Sie, daß die Schnittstelle sich aus irgendeinem anderen
Grund im "promiscuous mode" befinden könnte.
-q Schnelle Ausgabe. Gibt weniger Protokollinformationen aus.
-r datei
Pakete aus datei einlesen (datei wurde mit der Option -w ange-
legt). Bei der Angabe von "-" statt datei wird die Standardein-
gabe benutzt.
-s snaplen
Aus jedem Paket sollen snaplen Byte geholt werden und nicht die
Standardanzahl von 68 Byte. 68 Byte eignen sich für IP, ICMP, TCP
und UDP; allerdings kann es dabei vorkommen, daß Protokollinfor-
mationen aus Name-Server- und NFS-Paketen abgeschnitten werden
(siehe unten). Pakete, die wegen eines zu kleinen snaplen-Werts
abgeschnitten werden, werden auf der Ausgabe mit [proto] gekenn-
zeichnet. proto bezeichnet den Namen der Protokollebene, auf dem
die Information abgeschnitten wurde.
Beachten Sie, daß sich bei einer Erhöhung von snaplen die Verar-
beitungszeit der Pakete verlängert und letztendlich die Anzahl
der gepufferten Pakete verringert. Dadurch können Pakete verlo-
rengehen.
Daher sollten Sie für snaplen den kleinsten Wert angeben, bei dem
die benötigten Protokollinformationen noch erfaßt werden.
Seite 2 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
-S Absolute und keine relativen TCP-Sequenznummern ausgeben.
-t Die einzelnen Zeilen ohne Zeitstempel ausgegeben.
-tt Jede Zeile mit einem unformatierten Zeitstempel ausgeben.
-v (Geringfügig) ausführlichere Ausgabe. Beispielsweise werden die
Lebensdauer (time to live) und der Typ der Service-Informationen
in einem IP-Paket ausgegeben.
-w datei
Die unformatierten Pakete nach datei schreiben, und sie nicht
analysieren und ausgeben. Sie können die Pakete später mit der
Option -r ausgeben. Bei der Angabe eines Bindestrichs (-)
anstelle von datei wird die Standardausgabe benutzt. Es ist zu
beachten, daß beim späteren Ausgeben mit der Option -r nicht mehr
Zeichen pro Paket für die Analyse zur Verfügung stehen, als beim
Schreiben von datei durch Angabe von -s snaplen angegeben wurden.
-x Jedes Paket (ohne seinen Header auf Verbindungsebene) im Hexade-
zimalformat ausgeben. Es wird der kleinere Teil des Gesamtpakets
bzw. snaplen Bytes ausgegeben.
-A ULLCno
Attachment-Unit bezogen auf den ULLC (Universal Link Level Con-
troller). Diese Unit-Nummer (Voreinstellung: 0) wird hochgezählt
für alle Boards, die unter den ULLC eingehängt sind.
ausdruck
Filter-Ausdruck für die Pakete, über die Informationen ausgegeben
werden sollen. Ohne die Angabe von ausdruck werden Informationen
über sämtliche Pakete im Netz ausgegeben. Andernfalls werden
lediglich die Pakete berücksichtigt, für die ausdruck zutrifft.
ausdruck besteht aus einem oder mehreren primitives (Teilausdrük-
ken). Ein primitive besteht im Normalfall aus der Kennung id
(Name oder Nummer), der ein oder mehrere Bezeichner vorangestellt
sind. Man unterscheidet zwischen drei Arten von Bezeichnern:
typ Ein derartiger Bezeichner gibt an, worauf sich die alpha-
numerische bzw. numerische Kennung bezieht. typ kann sein:
host, net oder port (z. B. host saturn, net 128.3, port
20). Ohne die Angabe eines typ-Bezeichners wird host ein-
gesetzt.
dir Ein derartiger Bezeichner gibt eine bestimmte Übertra-
gungsrichtung von/zu id an. Mögliche Richtungen sind: src,
dst, src or dst und src and dst (z. B. src saturn, dst net
128.3, src or dst port ftp-data). Ohne die Angabe eines
dir-Bezeichners wird src or dst eingesetzt.
Seite 3 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
proto Ein derartiger Bezeichner wählt ein bestimmtes Protokoll
aus. proto kann sein: ether, ip, arp, rarp, tcp oder udp
(z. B. ether src saturn, arp net 128.3, tcp port 21). Wird
kein Protokoll-Bezeichner angegeben, werden sämtliche Pro-
tokolle eingesetzt, die zum Protokolltyp konsistent sind.
Beispiel:
src saturn steht für (ip or arp or rarp) src saturn (letz-
teres ist allerdings keine zulässige Syntax), net bar
steht für (ip or arp or rarp) net bar und port 53 steht
für (tcp or udp) port 53.
Zusätzlich gibt es eine Reihe spezieller Teilausdruck-Schlüsselwörter,
die nicht nach diesem Muster aufgebaut sind: gateway, broadcast, less,
greater sowie arithmetische Ausdrücke. Diese Teilausdruck-Schlüssel-
wörter werden unten beschrieben.
Komplexere Filter-Ausdrücke werden durch die Verknüpfung von Teilaus-
drücken mit Hilfe der Wörter and, or und not gebildet (z. B. host
saturn and not port ftp and not port ftp-data). Um den Eingabeaufwand
zu begrenzen, müssen identische Bezeichnerlisten nur jeweils einmal
angegeben werden.
Beispiel:
tcp dst port ftp or ftp-data or domain
hat genau dieselbe Bedeutung wie
tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain
Zulässige Teilausdrücke
dst host rechner
Wahr, wenn im IP-Empfängerfeld des Pakets die Angabe rechner ent-
halten ist; dabei darf es sich entweder um eine Adresse oder um
einen Namen handeln.
src host rechner
Wahr, wenn das IP-Senderfeld des Pakets die Angabe rechner ent-
hält.
host rechner
Wahr, wenn entweder das IP-Sender- oder das Empfängerfeld des
Pakets die Angabe rechner enthält. Jedem der oben aufgeführten
Rechner-Ausdrücke können die Schlüsselwörter ip, arp oder rarp
vorangestellt werden (z. B. ip host rechner ist identisch mit
ether proto \ip and host rechner). Wenn rechner ein Name mit meh-
reren IP-Adressen ist, wird jede Adresse auf Übereinstimmung
überprüft.
Seite 4 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
ether dst macrechner
Wahr, wenn die MAC-Empfängeradresse macrechner ist. macrechner
kann entweder ein Name aus /etc/ethers oder eine Nummer sein.
ether src macrechner
Wahr, wenn die MAC-Senderadresse macrechner ist.
ether host macrechner
Wahr, wenn die MAC-Sender- oder Empfängeradresse macrechner ist.
gateway rechner
Wahr, wenn das Paket rechner wie einen Gateway verwendet hat; das
bedeutet, wenn die MAC-Sender- oder Empfängeradresse rechner war,
aber die Angabe rechner weder im Sender- noch im Empfängerfeld
des IP-Headers enthalten war. rechner muß alphanumerisch und
sowohl in /etc/inet/hosts als auch in /etc/ethers enthalten sein.
(Ein gleichbedeutender Ausdruck ist ether host macrechner and
not host rechner; dieser kann entweder für Namen oder für Nummern
für rechner/macrechner benutzt werden.)
dst net netz
Wahr, wenn die IP-Empfängeradresse des Pakets die Netznummer netz
hat; dabei kann es sich entweder um eine Adresse oder einen Namen
handeln.
src net netz
Wahr, wenn die IP-Senderadresse des Pakets die Netznummer netz
hat.
net netz
Wahr, wenn entweder die IP-Sender- oder die Empfängeradresse des
Pakets die Netznummer netz hat.
dst port portnummer
Wahr, wenn das Paket mit ip/tcp oder ip/udp übermittelt wird und
als "destination port value" (Empfängerportnummer) portnummer
hat. portnummer kann entweder eine Nummer oder ein Name aus
/etc/inet/services sein. Bei der Angabe eines Namens werden
sowohl die Portnummer als auch das Protokoll überprüft. Wird eine
Nummer oder ein zweideutiger Name benutzt, wird lediglich die
Portnummer überprüft (so wird z. B. mit dst port 513 sowohl
tcp/login traffic als auch udp/who traffic ausgegeben, mit port
domain sowohl tcp/domain als auch udp/domain traffic).
src port portnummer
Wahr, wenn das Paket am Sender-Port mit der Portnummer portnummer
abgeschickt wurde.
Seite 5 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
port portnummer
Wahr, wenn portnummer entweder der Sender- oder der Empfänger-
Port des Pakets ist. Jedem der oben genannten Ausdrücke zur
Angabe einer Portnummer kann das Schlüsselwort tcp bzw. udp vor-
angestellt werden (z. B. paßt tcp src port port nur zu tcp-
Paketen).
less länge
Wahr, wenn die Länge des Pakets kleiner oder gleich länge ist.
Dies entspricht der folgenden Angabe: len <= länge.
greater länge
Wahr, wenn das Paket größer oder gleich länge ist. Dies ent-
spricht der folgenden Angabe: len >= länge.
ip proto protokoll
Wahr, wenn das Paket ein ip-Paket [siehe ip(7)] mit dem
Protokoll-Typ protokoll ist. protokoll kann eine Nummer oder
einer der Namen icmp, udp, nd oder tcp sein. Beachten Sie, daß
die Bezeichner tcp, udp und icmp ebenfalls Schlüsselwörter sind,
die mit einem Gegenschrägstrich (\) entwertet werden müssen; in
C-Shell und K-Shell müssen hierzu zwei Gegenschrägstriche (\\)
angegeben werden.
broadcast
Wahr, wenn es sich bei dem Paket um ein Broadcast-Paket handelt.
ether multicast
Wahr, wenn es sich bei dem Paket um ein über LAN (Ethernet, FDDI
usw.) empfangenes Multicast-Paket handelt. Das Schlüsselwort
ether ist optional und ist eine Kurzschreibweise für "ether[0] &
1 != 0".
ip multicast
Wahr, wenn es sich um ein IP-Multicast-Paket handelt.
ether proto protokoll
Wahr, wenn es sich bei dem Paket um ein Ethernet-Paket vom Typ
protokoll handelt. protokoll kann eine Nummer oder ein Name wie
z. B. ip, arp oder rarp sein. Beachten Sie, daß es sich auch bei
diesen Bezeichnern um Schlüsselwörter handelt, die mit einem
Gegenschrägstrich (\) entwertet werden müssen.
ip, arp, rarp
Sind Abkürzungen für ether proto p, wobei p eines der genannten
Protokolle ist.
tcp, udp, icmp
Sind Abkürzungen für ip proto p, wobei p eines der genannten Pro-
tokolle ist.
Seite 6 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
expr relop expr
Wahr, wenn der Vergleich zutrifft. relop kann dabei sein: >, <,
>=, <=, =, !=; expr ist ein arithmetischer Ausdruck aus ganzzah-
ligen Konstanten (die im Standard-C-Format angegeben werden), den
normalen binären Operatoren [+, -, *, /, &, |], einem Längen-
Operator sowie speziellen Zugriffsfunktionen für die Paket-Daten.
Der Zugriff auf die Daten im Paket wird mit folgender Syntax
angegeben:
proto [offset: größe]
proto kann entweder ether, ip, arp, rarp, tcp, udp oder icmp sein
und gibt die Protokollebene für die Indizierungs-Operation an.
Der Byte-Offset relativ zur angegebenen Protokollebene wird mit
offset bezeichnet. größe ist optional und steht für die Anzahl
der Bytes im betreffenden Feld (1, 2 oder 4; Standard: 1). Der
Längen-Operator (Schlüsselwort len) gibt die Länge des Pakets an.
So wird z. B. mit ether[0] & 1!= 0 der gesamte Multicast-Daten-
verkehr erfaßt. Der Ausdruck ip[0] & 0xf!= 5 erfaßt sämtliche
IP-Pakete mit Optionen. Der Ausdruck ip[2:2] & 0x1fff = 0 erfaßt
ausschließlich unfragmentierte Datagramme sowie Fragment 0 von
fragmentierten Datagrammen. Diese Überprüfung wird implizit auf
die tcp- und die udp-Indizierungsoperationen angewandt. So steht
z. B. tcp[0] in jedem Fall für das erste Byte des TCP-Headers, in
keinem Fall für das erste Byte eines der nachfolgenden Fragmente.
Teilausdrücke können folgendermaßen miteinander verknüpft werden:
- Durch Klammerung von Teilausdrücken und Operatoren (Klammern müssen
entwertet werden, damit sie nicht von der Shell interpretiert wer-
den).
- Durch Negation (! oder not).
- Durch logisches UND (and).
- Durch logisches ODER (or).
Die Negation hat die höchste Priorität. Die ODER- und die UND-Verknüp-
fung haben die gleiche Priorität und werden ihrer Reihenfolge entspre-
chend ausgewertet. Beachten Sie, daß eine UND-Verknüpfung jetzt expli-
zit durch den Token and angegeben werden muß; eine Aneinanderreihung
ist nicht mehr ausreichend.
Wenn ein Bezeichner ohne ein Schlüsselwort angegeben wird, wird das
jeweils zuletzt angegebene Schlüsselwort eingesetzt (z. B. ist not
host vs and ace die Kurzform für not host vs and host ace, was nicht
mit not (host vs or ace) verwechselt werden darf).
Seite 7 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
Ausdrucks-Argumente werden an tcpdump entweder als einzelnes Argument
oder als Mehrfach-Argument übergeben; Sie können die Möglichkeit nut-
zen, die in Ihrem Fall am effizientesten ist. Ein Ausdruck mit Shell-
Metazeichen wird am besten als einzelnes, in Hochkommata eingeschlos-
senes Argument übergeben. Werden mehrere Argumente angegeben, so müs-
sen sie vor der Analyse durch Leerzeichen miteinander verknüpft wer-
den.
BEISPIELE
Alle Pakete ausgeben, die von sundown empfangen bzw. abgeschickt wer-
den:
tcpdump host sundown
Datenverkehr zwischen helios und hot oder ace ausgeben:
tcpdump host helios and \(hot or ace \)
Sämtliche IP-Pakete zwischen ace und allen Rechnern außer helios aus-
geben:
tcpdump ip host ace and not helios
Den gesamten ftp-Datenverkehr ausgeben, der über das Internet-Gateway
snup läuft. Beachten Sie, daß der Ausdruck in Hochkommata eingeschlos-
sen ist, um ihn vor einer (versehentlichen) Interpretation durch die
Shell zu schützen:
tcpdump 'gateway snup and (port ftp or ftp-data)'
Den gesamten Datenverkehr ausgeben, der weder von einem lokalen Rech-
ner ausging noch an einen lokalen Rechner gerichtet war. Wenn es sich
um eine Weiterleitung zu einem anderen Netz handelt, dürfen die
betreffenden Daten auf keinen Fall in Ihr lokales Netz eingespeist
werden.
tcpdump ip and not net localnet
Das erste und letzte Paket (die SYN- und FIN-Pakete) jeder TCP-
Kommunikation ausgeben, an der ein nicht lokaler Rechner beteiligt
war.
tcpdump 'tcp[13] & 3!= 0 and not src and dst net localnet'
Alle IP-Pakete ausgeben, die länger als 576 Byte waren und über das
Gateway snup geschickt wurden:
tcpdump 'gateway snup and ip[2:2]> 576'
Seite 8 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
Alle IP-Broadcast- oder Multicast-Pakete ausgeben, die nicht als
Ethernet-Broadcast bzw. Multicast-Pakete geschickt wurden:
tcpdump 'ether[0] & 1 = 0 and ip[16]>= 224'
Alle ICMP-Pakete ausgeben, die keine ECHO-Anforderungen/Antworten
sind, d. h. nicht ping-Pakete:
tcpdump 'icmp[0]!= 8 and icmp[0]!= 0'
Ausgabe von tcpdump
Die Ausgabe von tcpdump ist protokollabhängig. Nachfolgend finden Sie
eine kurze Beschreibung und Beispiele für einen Großteil der Formate.
Headers auf Verbindungsebene (Link-level headers)
Wenn die Option -e angegeben wird, wird der Header auf Verbindungs-
ebene ausgegeben. In Ethernet-Netzen werden die Sender- und
Empfänger-Adressen, das Protokoll sowie die Paketlänge ausgegeben.
In der nachfolgenden Beschreibung werden Kenntnisse des SLIP-Kompri-
mierungsalgorithmus vorausgesetzt, wie er im RFC1144 beschrieben wird.
In SLIP-Verbindungen werden ein Richtungsanzeiger (I für inbound, O
für outbound), der Pakettyp sowie Komprimierungs-Informationen ausge-
geben. Der Pakettyp steht bei der Ausgabe an erster Stelle. Es gibt
die drei Typen ip, utcp und ctcp. Für ip-Pakete werden keine weiteren
Informationen über die Verbindung ausgegeben. Für TCP-Pakete wird der
Verbindungsbezeichner nach dem Pakettyp ausgegeben.
Der Header eines komprimierten Pakets wird in kodierter Form ausgege-
ben. Die Sonderfälle werden im Format *S+n und *SA+n ausgegeben, wobei
n für das Delta steht, um das sich die Sequenznummer bzw. die Sequenz-
nummer und ack geändert hat. Wenn es sich nicht um einen Sonderfall
handelt, werden null oder mehr Änderungen ausgegeben. Bei einer Ände-
rung wird ein U (urgent pointer), W (window), A (ack), S (sequence
number) oder I (Paket-ID) ausgegeben, gefolgt von einem Deltawert (+n
oder -n) oder einem neuen Wert (=n). Abschließend wird die Menge der
Daten im Paket sowie die Länge des komprimierten Headers ausgegeben.
Im folgenden Beispiel zeigt die Zeile ein gesendetes komprimiertes
TCP-Paket mit einem impliziten Verbindungsbezeichner; ack hat sich um
den Wert 6 geändert, die Sequenznummer um den Wert 49 und die Paket-ID
um den Wert 6; die Daten haben eine Länge von 3 Byte, der komprimierte
Header hat eine Länge von 6 Byte:
O ctcp * A+6 S+49 I+6 3 (6)
Hinweis: Unter Reliant UNIX werden SLIP-Schnittstellen für tcpdump
nicht unterstützt.
Seite 9 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
ARP/RARP-Pakete
In der Ausgabe für ARP/RARP-Pakete werden die Art der Anforderung
sowie die zugehörigen Argumente angezeigt. Das Format ist selbsterklä-
rend. Der Anfang einer rlogin-Anforderung von Rechner rtsg an Rechner
csam kann z. B. folgendermaßen aussehen:
arp who-has csam tell rtsg
arp reply csam is-at CSAM
Die erste Zeile bedeutet, daß rtsg ein arp-Paket abschickt, das die
Ethernet-Adresse des Internet-Rechners csam anfordert. csam schickt
als Antwort seine Ethernet-Adresse. In diesem Beispiel werden die
Ethernet-Adressen in Großbuchstaben und die Internet-Adressen in
Kleinbuchstaben angegeben.
Bei Angabe von tcpdump -n werden Adressen numerisch dargestellt:
arp who-has 128.3.254.6 tell 128.3.254.68
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4
Mit tcpdump -e wäre erkennbar, daß das erste Paket ein Broadcast- und
das zweite ein gerichtetes Paket ist:
RTSG Broadcast 0806 64: arp who-has csam tell rtsg
CSAM RTSG 0806 64: arp reply csam is-at CSAM
Dies bedeutet für das erste Paket, daß RTSG die Ethernet-Senderadresse
ist, das Ziel die Broadcast-Adresse ist, das Typfeld den Hexadezimal-
wert 0806 (Typ ETHERARP) enthält und die Gesamtlänge 64 Byte beträgt.
TCP-Pakete
In der folgenden Beschreibung werden unbedingt Kenntnisse des TCP-
Protokolls vorausgesetzt, das im RFC793 beschrieben wird.
Eine tcp-Protokollzeile hat folgendes allgemeines Format:
src> dst: flags data-seqno ack window urgent options
src und dst sind die Sender- und Empfänger-IP-Adressen und -Portnum-
mern.
flags ist entweder eine beliebige Kombination aus den Buchstaben S
(SYN), F (FIN), P (PUSH) und R (RST) oder ein einzelner Punkt (.) für
"keine Flags".
data-seqno beschreibt denjenigen Teil des Sequenznummern-Bereichs, der
durch die Daten in diesem Paket abgedeckt wird (siehe Beispiel unten).
Seite 10 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
ack ist die Sequenznummer der Daten, die auf dieser Verbindung als
nächstes in der anderen Richtung erwartet werden.
window ist die Anzahl der Bytes im Empfangspuffer (Fenstergröße), die
auf dieser Verbindung in der anderen Richtung vorhanden sind.
urg gibt an, daß eilige Daten (urgent) im Paket enthalten sind.
options steht für tcp-Optionen, die in spitze Klammern eingeschlossen
sind (z. B. <mss 1024>).
src, dst und flags sind in jedem Fall vorhanden. Der Inhalt der übri-
gen Felder hängt vom Header des tcp-Protokolls ab und wird nur bei
Bedarf ausgegeben.
Der erste Abschnitt einer rlogin-Anforderung von Rechner rtsg an Rech-
ner csam sieht z. B. folgendermaßen aus:
rtsg.1023> csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login> rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023> csam.login:. ack 1 win 4096
rtsg.1023> csam.login: P 1:2(1) ack 1 win 4096
csam.login> rtsg.1023:. ack 2 win 4096
rtsg.1023> csam.login: P 2:21(19) ack 1 win 4096
csam.login> rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login> rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login> rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
Die erste Zeile bedeutet, daß am tcp-Port 1023 vom Rechner rtsg ein
Paket an Port login von Rechner csam geschickt wurde. S bedeutet, daß
das SYN-Flag gesetzt war. Das Paket hatte die Sequenznummer 768512 und
enthielt keine Daten. Dabei wird das Format "first:last(nbytes)" mit
der folgenden Bedeutung benutzt: Sequenznummern von first bis aus-
schließlich last, was nbytes Byte von Benutzerdaten entspricht. Es gab
kein "piggy-backed" ack (begleitende Rückmeldung), es war ein Emp-
fangsfenster mit einer Größe von 4096 Byte verfügbar, und es gab eine
Option, die eine maximale Segmentgröße (mss) von 1024 Byte anforderte.
Seite 11 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
csam antwortet mit einem ähnlichen Paket, enthält aber ein "piggy-
backed" ack für das SYN-Flag von rtsg. rtsg bestätigt dann das SYN-
Flag von csam. "." bedeutet, daß keine Flags gesetzt waren. Da das
Paket keine Daten enthielt, gibt es keine Daten-Sequenznummer. Beach-
ten Sie, daß die ack-Sequenznummer eine kleine ganze Zahl ist (1).
Wenn tcpdump das erste Paket für eine Verbindung feststellt, gibt es
die Sequenznummer aus dem Paket aus. In den nachfolgenden Paketen bei
aufgebauter Verbindung wird die Differenz zwischen der Sequenznummer
des aktuellen Pakets und dieser ersten Sequenznummer ausgegeben. Somit
können die Sequenznummern nach der ersten als relative Byte-Positionen
innerhalb des Datenstroms der Kommunikation interpretiert werden
(wobei 1 das erste Daten-Byte in jeder Richtung ist). -S hebt diese
Funktion auf, wodurch die ursprünglichen Sequenznummern ausgegeben
werden.
In der sechsten Zeile schickt rtsg an csam Daten mit einer Länge von
19 Byte (Byte 2 bis 20). Im Paket wird das PUSH-Flag gesetzt. In der
siebten Zeile meldet csam, daß er Daten bis ausschließlich Byte 21 von
rtsg empfangen hat. Die meisten dieser Daten befinden sich im Socket-
Puffer, da das Empfangsfenster von csam um 19 Byte verkleinert wurde.
Außerdem schickt csam in diesem Paket ein Daten-Byte an rtsg. In der
achten und neunten Zeile schickt csam zwei "eilige" Daten-Bytes (urg)
mit gesetztem PUSH-Flag an rtsg.
UDP-Pakete
Das UDP-Format wird anhand des folgenden rwho-Pakets erläutert:
actinide.who> broadcast.who: udp 84
Diese Zeile bedeutet, daß der Port who auf dem Rechner actinide ein
udp-Datagramm an den Port who auf dem Rechner broadcast (der
Internet-Broadcast-Adresse) geschickt hat. Das Paket enthielt Benut-
zerdaten mit einer Länge von 84 Byte.
Es werden aufgrund der Sender- oder Empfängerportnummer einige UDP-
Dienste erkannt und die Protokollinformationen der darüberliegenden
Ebene ausgegeben. Dabei handelt es sich speziell um die Anforderungen
des Domain Name-Service (RFC1034/1035) und die Sun RPC-Aufrufe
(RFC1050) von NFS.
Anforderungen an DNS-Name-Server über UDP
In der folgenden Beschreibung werden Kenntnisse des Domain Name
Service-Protokolls vorausgesetzt, das im RFC1035 beschrieben wird.
Anforderungen an den Name-Server werden in folgendem Format angegeben:
src> dst: id op? flags qtype qclass name (len)
h2opolo.1538> helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
Seite 12 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
Der Rechner h2opolo fragte beim Name-Server auf helios nach einem
Adreßdatensatz (qtype=A), der dem Namen ucbvax.berkeley.edu zugeordnet
ist. Die Anfrage hatte die Kennung 3. + bedeutet, daß das Flag
recursion desired gesetzt war. Die Länge der Anfrage betrug 37 Byte,
die Headers des UDP- und des IP-Protokolls nicht mitgerechnet. Bei der
Anfrage handelte es sich um eine normale Anfrage (Query). Somit wurde
das op-Feld nicht ausgegeben. Jeder andere Inhalt des op-Felds wäre
zwischen den Kennungen 3 und + ausgegeben worden. Auch bei qclass han-
delt es sich um eine normale Anfrage (CIN im Feld qclass) und der
Inhalt wurde daher weggelassen. Jeder andere Inhalt von qclass wäre
unmittelbar hinter A ausgegeben worden.
Die Anfrage wird auf bestimmte Besonderheiten überprüft; sind Beson-
derheiten vorhanden, so werden sie in zusätzlichen Feldern ausgegeben,
die in eckige Klammern eingeschlossen sind. Wenn eine Anfrage einen
Antwort-, Name-Server- oder Zonen-Teil enthält, werden anzähler,
nszähler oder arzähler im Format [na], [nn] oder [nau] ausgegeben,
wobei n der entsprechende Zählerwert ist. Wenn ein oder mehrere der
Antwort-Bits (AA, RA oder rcode) gesetzt sind oder ein Teil der must
be zero-Bits in Byte 2 und 3 gesetzt sind, wird [b2&3=x] ausgegeben,
wobei x der Hexadezimalwert der Header-Bytes 2 und 3 ist.
Antworten des DNS-Name-Servers über UDP
Die Antworten des Name-Servers werden in folgendem Format ausgegeben:
src> dst: id op rcode flags a/n/au type class data (len)
helios.domain> h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain> h2opolo.1537: 2 NXDomain* 0/1/0 (97)
Im ersten Beispiel antwortet helios auf die Anfrage mit der Kennung 3
von h2opolo mit drei Antwortsätzen, drei Name-Server-Sätzen und sieben
Zonen-Sätzen. Der erste Antwortsatz ist vom Typ A (address) und ent-
hält die Internet-Adresse 128.32.137.3. Die Gesamtlänge der Antwort
beträgt 273 Byte, wobei die UDP- und die IP-Headers nicht mitgerechnet
werden. Der Operationscode (Query) und der Antwortcode (NoError) wur-
den ebenso wie die Klasse (CIN) des A-Datensatzes weggelassen.
Im zweiten Beispiel antwortet helios auf die Anfrage 2 mit einem Ant-
wortcode für eine nicht vorhanden Domäne (NXDomain), mit null Antwort-
sätzen, einem Name-Server-Satz und ohne Zonen-Sätzen. Der Stern (*)
bedeutet, daß das Bit authoritative answer gesetzt war. Da es keine
Antwort gab, wurden weder der Typ noch die Klasse oder Daten ausgege-
ben.
Zusätzlich können die Flag-Zeichen "-" (recursion available, RA, nicht
gesetzt) und "|" (truncated message, TC, gesetzt) enthalten sein. Wenn
der Frage-Teil nicht exakt einen Eintrag enthält, wird [nq] ausgege-
ben.
Seite 13 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
Beachten Sie, daß die Name-Server-Anforderungen und -Antworten häufig
sehr umfangreich sind und, wenn für snaplen der Standardwert (96 Byte)
benutzt wird, die Größe des erfaßten Paketteils für eine Ausgabe nicht
ausreicht. Wenn Sie ausführliche Informationen über die Name-Server-
Anforderungen und -Antworten benötigen, können Sie snaplen mit dem
Schalter -s erhöhen. Gute Erfahrungen wurden mit der Einstellung -s
128 gemacht.
NFS-Anforderungen
NFS-Aufträge und -Quittungen werden in folgendem Format ausgegeben:
src.xid> dst.nfs: op args
src.nfs> dst.xid: reply op rslt
Bitte beachten Sie, daß die angegebenen Daten vom Typ der NFS-Opera-
tion abhängen. Das Format ist selbsterklärend, wenn es zusammen mit
einer NFS-Protokollspezifikation gelesen wird. Unterstützt werden die
NFS-Versionen 2 (RFC1094) und 3 (RFC1813).
Beispiel:
orion.1dfc1> saturn.nfs: getattr3 fhlen 32 (4,5 / 66076)
saturn.nfs> orion.1dfc1: reply getattr3 DIR 40777 ids 0/1 sz 18432
orion.1dfec> saturn.nfs: lookup3 fhlen 32 (4,5 / 66076) "RCS"
saturn.nfs> orion.1dfec: reply lookup3 fhlen 32 (4,5 / 68577)
In der ersten Zeile schickt der Client-Rechner orion den RPC-Aufruf
mit der Kennung 1dfc1 an saturn. Beachten Sie bitte, daß die Nummer
nach dem Namen des Sender-Rechners eine RCP-Kennung und nicht der
Sender-Port ist. Bei der Operation handelte es sich um getattr3 ("get
attributes" in der NFS-Version 3) für die Datei mit der Gerätenummer
4,5 und dem Inode 66076. Die Gesamtlänge der NFS-Dateikennung (file
handle) beträgt 32 Bytes. Der Server saturn gibt als Antwort die
Attribute der Datei zurück. Die hier angezeigten Attribute umfassen
den Dateityp (DIR), die Zugriffsrechte (oktal 40777), die Benutzer-
und Gruppen-ID des Eigentümers (0/1) und die Größe der Datei (18432
Bytes).
In der dritten Zeile fordert orion den Rechner saturn auf, den Namen
RCS im Verzeichnis mit Gerätenummer 4,5 und Inode 66076 zu suchen. Der
Server saturn gibt daraufhin die Kennung der gefundenen Datei zurück,
sie hat die Gerätenummer 4,5 und die Inode-Nummer 68577.
Die zum NFS Protokoll gehörenden MNT- (Mount Protokoll) und NLM- (Net-
work Lock Manager Protokoll) Pakete werden in einem vergleichbaren
Format ausgegeben.
Seite 14 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
Beachten Sie bitte, daß NFS-Aufträge sehr umfangreich sind und die
obige Ausgabe erst nach einer Erhöhung von snaplen erzeugt wird. Zur
Überwachung des NFS-Datenverkehrs wurde im Beispiel -s 256 benutzt.
KIP-Appletalk (DDP in UDP)
Appletalk DDP-Pakete, die in UDP-Datagrammen verkapselt sind, werden
entkapselt und als DDP-Pakete ausgegeben (d. h., sämtliche Informatio-
nen aus dem UDP-Header werden nicht berücksichtigt). Anhand der Datei
/etc/atalk.names werden Appletalk-Netz- und Knotennummern in Namen
umgesetzt. Die Zeilen in dieser Datei haben das folgende Format:
Seite 15 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
Zahl Name
____________________
1.254 ether
16.1 icsd-net
1.254.110 ace
In den ersten beiden Zeilen sind die Namen von Appletalk-Netzen ent-
halten. Die dritte Zeile enthält den Namen eines bestimmten Rechners
(eine Rechnernummer kann von einer Netznummer durch die dritte Achter-
gruppe innerhalb der Zahl unterschieden werden - eine Netznummer muß
aus zwei Achtergruppen bestehen, eine Rechner-Nummer aus drei). Die
Nummer und der Name sollten durch Zwischenraumzeichen (Leer- oder
Tabulatorzeichen) voneinander getrennt werden. Die Datei
/etc/atalk.names kann Leer- oder Kommentarzeilen enthalten (Zeilen,
die mit den Zeichen # beginnen).
Appletalk-Adressen werden in folgendem Format ausgegeben:
net.host.port
144.1.209.2> icsd-net.112.220
office.2> icsd-net.112.220
jssmag.149.235> icsd-net.2
(Wenn die Datei /etc/atalk.names nicht vorhanden ist oder keinen Ein-
trag für eine Appletalk-Rechner-/Netznummer enthält, werden die Adres-
sen im numerischen Format ausgegeben). Im ersten Beispiel schickt NBP
(DDP-Port 2) im Netz 144.1 am Knoten 209 Daten an den Netzdienst, der
gerade am Port 220 am icsd-Netzknoten 112 wartet. Die zweite Zeile hat
dieselbe Bedeutung, nur ist der Sendeknoten bekannt (office). Bei der
dritten Zeile handelt es sich um einen Broadcast-Sendevorgang vom Port
235 am jssmag-Netzknoten 149 an NBP-Port im icsd-Netz. Beachten Sie,
daß die Broadcast-Adresse (255) über einen Netznamen ohne Netznummer
angegeben wird- aus diesem Grund sollten die Knotennamen in
/etc/atalk.names möglichst von den Netznamen getrennt werden.
Der Inhalt von NBP- (Name Binding Protocol) und ATP- (Appletalk Tran-
saction Protocol) Paketen wird interpretiert. Bei anderen Protokollen
werden lediglich der Protokollname (bzw. die Nummer, wenn für das Pro-
tokoll kein Name eingetragen ist) sowie die Paketgröße ausgegeben.
Das Format für NBP-Pakete sieht wie in den folgenden Beispielen aus:
icsd-net.112.220> jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
jssmag.209.2> icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
techpit.2> icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186
Seite 16 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
Die erste Zeile enthält eine Namenssuch-Anforderung für Laserdrucker
(LaserWriter), die durch den Rechner 112 im Netz icsd abgeschickt und
im Netz jssmag als Broadcast gesendet wird. Die Suche hat die nbp-
Kennung 190. In der zweiten Zeile wird eine Antwort auf diese Anforde-
rung angezeigt (beachten Sie, daß die Kennung gleich geblieben ist),
die vom Rechner jssmag.209 abgeschickt wurde. Diese Antwort bedeutet,
daß eine Laserdrucker-Ressource namens RM1140 am Port 250 eingetragen
ist. Die dritte Zeile ist eine weitere Antwort auf dieselbe Anforde-
rung; sie bedeutet, daß auf dem Rechner techpit der Laserdrucker
techpit:LaserWriter am Port 186 registriert ist.
Das Format für ATP-Pakete sieht wie im folgenden Beispiel aus:
jssmag.209.165> helios.132: atp-req 12266<0-7> 0xae030001
helios.132> jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
helios.132> jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
helios.132> jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
helios.132> jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132> jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
helios.132> jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
helios.132> jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
helios.132> jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
jssmag.209.165> helios.132: atp-req 12266<3,5> 0xae030001
helios.132> jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132> jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
jssmag.209.165> helios.132: atp-rel 12266<0-7> 0xae030001
jssmag.209.133> helios.132: atp-req* 12267<0-7> 0xae030002
jssmag.209 startet die Transaktion mit der Kennung 12266 mit dem Rech-
ner helios, wobei er bis zu 8 Pakete anfordert (<0-7>). Bei der Hex-
Nummer am Ende der Zeile handelt es sich um den Wert des userdata-
Felds in der Anforderung.
helios antwortet mit 8 Paketen zu je 512 Byte. :zahl nach der Trans-
aktions-Kennung gibt die Paket-Sequenznummer innerhalb der Transaktion
an; die Zahl innerhalb der Klammern steht für die Datenmenge im Paket,
den atp-Header ausgenommen. Das Zeichen * bei Paket 7 bedeutet, daß
das EOM-Bit gesetzt war.
jssmag.209 fordert die erneute Übertragung von Paket 3 und 5 an.
helios schickt sie dann erneut ab; daraufhin gibt jssmag.209 die
Transaktion frei. Schließlich startet jssmag.209 die nächste Anforde-
rung. Das Zeichen * bei der Anforderung bedeutet, daß XO (exactly
once) nicht gesetzt war.
Seite 17 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
IP-Fragmentierung
Fragmentierte Internet-Datagramme werden in folgendem Format ausgege-
ben:
(frag id:size@offset+)
(frag id:size@offset)
Das erste Format wird verwendet, wenn es weitere Fragmente gibt. Das
zweite Format wird für das letzte Fragment verwendet.
id ist die Fragment-Kennung (im Hex-Format). size ist die Fragment-
Größe (in Byte), den IP-Kopf nicht eingerechnet. offset ist der Offset
dieses Fragments (in Byte) innerhalb des ursprünglichen Datagramms.
Die Fragment-Informationen werden für jedes Fragment ausgegeben. Das
erste Fragment enthält den Header des darüberliegenden Protokolls; auf
die Protokoll-Informationen folgen die Fragment-Informationen. Die
Fragmente, die auf das erste Fragment folgen, enthalten keinen Header
des darüberliegenden Protokolls; die Fragment-Informationen werden
nach den Sender- und Empfänger-Adressen ausgegeben. Nachfolgend finden
Sie z. B. einen Teil eines ftp von arizona.edu an lbl-rtsg.arpa über
eine CSNET-Verbindung, die offensichtlich keine 576-Byte-Datagramme
verarbeiten kann:
arizona.ftp-data> rtsg.1170:. 1024:1332(308) ack 1 win 4096
(frag 595a:328@0+)
arizona> rtsg: (frag 595a:204@328)
rtsg.1170> arizona.ftp-data:. ack 1536 win 2560
In diesem Beispiel enthalten die Adressen in der zweiten Zeile keine
Portnummern. Dies liegt daran, daß sämtliche TCP-Protokollinformatio-
nen im ersten Fragment enthalten sind und die Port- oder Sequenznum-
mern bei der Ausgabe der darauffolgenden Fragmente vollkommen offen
sind. Zweitens werden die tcp-Folgeinformationen in der ersten Zeile
ausgegeben, als hätten die Benutzerdaten eine Länge von 308 Byte; in
Wirklichkeit beträgt die Gesamtlänge jedoch 512 Byte (308 Byte im
ersten Fragment und 204 im zweiten). Dies kann verwirrend sein, wenn
Sie bei den Sequenznummern nach Lücken suchen oder versuchen, Bestäti-
gungen (acks) Paketen zuzuordnen.
Ein Paket mit dem IP-Flag don't fragment wird mit einem nachstehenden
(DF) markiert.
Zeitstempel
Standardmäßig wird allen Ausgabezeilen ein Zeitstempel vorangestellt.
Der Zeitstempel zeigt die aktuelle Uhrzeit im folgenden Format an:
hh:mm:ss.frac
Seite 18 Reliant UNIX 5.44 Gedruckt 11/98
tcpdump(1M) tcpdump(1M)
Seine Genauigkeit entspricht der Uhrzeit im Systemkern (z. B. ±10 ms).
Der Zeitstempel gibt den Zeitpunkt an, zu dem der Systemkern das Paket
zum ersten Mal feststellte. Es wird nicht versucht, die Zeitverzöge-
rung zwischen dem Zeitpunkt, zu dem die Ethernet-Schnittstelle das
Paket aus der Leitung entfernte, und dem Zeitpunkt, zu dem der System-
kern das new packet-interrupt (-Unterbrechung) bediente, auszuglei-
chen.
Seite 19 Reliant UNIX 5.44 Gedruckt 11/98