1 .\" @(#) $Header: tcpdump.1,v 1.67 97/06/30 16:31:50 leres Exp $ (LBL)
3 .\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997
4 .\" The Regents of the University of California. All rights reserved.
5 .\" All rights reserved.
7 .\" Redistribution and use in source and binary forms, with or without
8 .\" modification, are permitted provided that: (1) source code distributions
9 .\" retain the above copyright notice and this paragraph in its entirety, (2)
10 .\" distributions including binary code include the above copyright notice and
11 .\" this paragraph in its entirety in the documentation or other materials
12 .\" provided with the distribution, and (3) all advertising materials mentioning
13 .\" features or use of this software display the following acknowledgement:
14 .\" ``This product includes software developed by the University of California,
15 .\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
16 .\" the University nor the names of its contributors may be used to endorse
17 .\" or promote products derived from this software without specific prior
18 .\" written permission.
19 .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
20 .\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
21 .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
25 .TH TCPDUMP 1 "30 June 1997"
27 tcpdump \- dump traffic on a network
70 \fITcpdump\fP prints out the headers of packets on a network interface
71 that match the boolean \fIexpression\fP.
73 .B Under SunOS with nit or bpf:
76 you must have read access to
80 .B Under Solaris with dlpi:
81 You must have read access to the network pseudo device, e.g.
83 .B Under HP-UX with dlpi:
84 You must be root or it must be installed setuid to root.
85 .B Under IRIX with snoop:
86 You must be root or it must be installed setuid to root.
88 You must be root or it must be installed setuid to root.
89 .B Under Ultrix and Digital UNIX:
90 Once the super-user has enabled promiscuous-mode operation using
95 You must have read access to
100 Attempt to convert network and broadcast addresses to names.
103 Exit after receiving \fIcount\fP packets.
106 Dump the compiled packet-matching code in a human readable form to
107 standard output and stop.
110 Dump packet-matching code as a
115 Dump packet-matching code as decimal numbers (preceded with a count).
118 Print the link-level header on each dump line.
121 Print `foreign' internet addresses numerically rather than symbolically
122 (this option is intended to get around serious brain damage in
123 Sun's yp server \(em usually it hangs forever translating non-local
127 Use \fIfile\fP as input for the filter expression.
128 An additional expression given on the command line is ignored.
131 Listen on \fIinterface\fP.
132 If unspecified, \fItcpdump\fP searches the system interface list for the
133 lowest numbered, configured up interface (excluding loopback).
134 Ties are broken by choosing the earliest match.
137 Make stdout line buffered. Useful if you want to see the data
138 while capturing it. E.g.,
140 ``tcpdump\ \ \-l\ \ |\ \ tee dat'' or
141 ``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''.
144 Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
147 Don't print domain name qualification of host names. E.g.,
148 if you give this flag then \fItcpdump\fP will print ``nic''
149 instead of ``nic.ddn.mil''.
152 Do not run the packet-matching code optimizer. This is useful only
153 if you suspect a bug in the optimizer.
156 \fIDon't\fP put the interface
157 into promiscuous mode. Note that the interface might be in promiscuous
158 mode for some other reason; hence, `-p' cannot be used as an abbreviation for
159 `ether host {local-hw-addr} or ether broadcast'.
162 Quick (quiet?) output. Print less protocol information so output
166 Read packets from \fIfile\fR (which was created with the -w option).
167 Standard input is used if \fIfile\fR is ``-''.
170 Snarf \fIsnaplen\fP bytes of data from each packet rather than the
171 default of 68 (with SunOS's NIT, the minimum is actually 96).
172 68 bytes is adequate for IP, ICMP, TCP
173 and UDP but may truncate protocol information from name server and NFS
174 packets (see below). Packets truncated because of a limited snapshot
175 are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP
176 is the name of the protocol level at which the truncation has occurred.
177 Note that taking larger snapshots both increases
178 the amount of time it takes to process packets and, effectively,
179 decreases the amount of packet buffering. This may cause packets to be
180 lost. You should limit \fIsnaplen\fP to the smallest number that will
181 capture the protocol information you're interested in.
184 Force packets selected by "\fIexpression\fP" to be interpreted the
185 specified \fItype\fR. Currently known types are
186 \fBrpc\fR (Remote Procedure Call),
187 \fBrtp\fR (Real-Time Applications protocol),
188 \fBrtcp\fR (Real-Time Applications control protocol),
189 \fBvat\fR (Visual Audio Tool),
191 \fBwb\fR (distributed White Board).
194 Print absolute, rather than relative, TCP sequence numbers.
197 \fIDon't\fP print a timestamp on each dump line.
200 Print an unformatted timestamp on each dump line.
203 (Slightly more) verbose output. For example, the time to live
204 and type of service information in an IP packet is printed.
207 Even more verbose output. For example, additional fields are
208 printed from NFS reply packets.
211 Write the raw packets to \fIfile\fR rather than parsing and printing
212 them out. They can later be printed with the \-r option.
213 Standard output is used if \fIfile\fR is ``-''.
216 Print each packet (minus its link level header) in hex.
217 The smaller of the entire packet or
219 bytes will be printed.
224 but dumps the packet in emacs-hexl like format with ASCII decoding.
225 .IP "\fI expression\fP"
227 selects which packets will be dumped. If no \fIexpression\fP
228 is given, all packets on the net will be dumped. Otherwise,
229 only packets for which \fIexpression\fP is `true' will be dumped.
231 The \fIexpression\fP consists of one or more
233 Primitives usually consist of an
235 (name or number) preceded by one or more qualifiers. There are three
236 different kinds of qualifier:
238 qualifiers say what kind of thing the id name or number refers to.
244 E.g., `host foo', `net 128.3', `port 20'. If there is no type
249 qualifiers specify a particular transfer direction to and/or from
251 Possible directions are
258 E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'. If
259 there is no dir qualifier,
262 For `null' link layers (i.e. point to point protocols such as slip) the
266 qualifiers can be used to specify a desired direction.
268 qualifiers restrict the match to a particular protocol. Possible
286 E.g., `ether src foo', `arp net 128.3', `tcp port 21'. If there is
287 no proto qualifier, all protocols consistent with the type are
288 assumed. E.g., `src foo' means `(ip or arp or rarp) src foo'
289 (except the latter is not legal syntax), `net bar' means `(ip or
290 arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'.
292 [`fddi' is actually an alias for `ether'; the parser treats them
293 identically as meaning ``the data link level used on the specified
294 network interface.'' FDDI headers contain Ethernet-like source
295 and destination addresses, and often contain Ethernet-like packet
296 types, so you can filter on these FDDI fields just as with the
297 analogous Ethernet fields. FDDI headers also contain other fields,
298 but you cannot name them explicitly in a filter expression.]
300 In addition to the above, there are some special `primitive' keywords
301 that don't follow the pattern:
306 and arithmetic expressions. All of these are described below.
308 More complex filter expressions are built up by using the words
313 to combine primitives. E.g., `host foo and not port ftp and not port ftp-data'.
314 To save typing, identical qualifier lists can be omitted. E.g.,
315 `tcp dst port ftp or ftp-data or domain' is exactly the same as
316 `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.
318 Allowable primitives are:
319 .IP "\fBdst host \fIhost\fR"
320 True if the IP destination field of the packet is \fIhost\fP,
321 which may be either an address or a name.
322 .IP "\fBsrc host \fIhost\fR"
323 True if the IP source field of the packet is \fIhost\fP.
324 .IP "\fBhost \fIhost\fP
325 True if either the IP source or destination of the packet is \fIhost\fP.
326 Any of the above host expressions can be prepended with the keywords,
327 \fBip\fP, \fBarp\fP, or \fBrarp\fP as in:
330 \fBip host \fIhost\fR
333 which is equivalent to:
336 \fBether proto \fI\\ip\fB and host \fIhost\fR
339 If \fIhost\fR is a name with multiple IP addresses, each address will
340 be checked for a match.
341 .IP "\fBether dst \fIehost\fP
342 True if the ethernet destination address is \fIehost\fP. \fIEhost\fP
343 may be either a name from /etc/ethers or a number (see
346 .IP "\fBether src \fIehost\fP
347 True if the ethernet source address is \fIehost\fP.
348 .IP "\fBether host \fIehost\fP
349 True if either the ethernet source or destination address is \fIehost\fP.
350 .IP "\fBgateway\fP \fIhost\fP
351 True if the packet used \fIhost\fP as a gateway. I.e., the ethernet
352 source or destination address was \fIhost\fP but neither the IP source
353 nor the IP destination was \fIhost\fP. \fIHost\fP must be a name and
354 must be found in both /etc/hosts and /etc/ethers. (An equivalent
358 \fBether host \fIehost \fBand not host \fIhost\fR
361 which can be used with either names or numbers for \fIhost / ehost\fP.)
362 .IP "\fBdst net \fInet\fR"
363 True if the IP destination address of the packet has a network
364 number of \fInet\fP. \fINet\fP may be either a name from /etc/networks
365 or a network number (see \fInetworks(4)\fP for details).
366 .IP "\fBsrc net \fInet\fR"
367 True if the IP source address of the packet has a network
369 .IP "\fBnet \fInet\fR"
370 True if either the IP source or destination address of the packet has a network
372 .IP "\fBnet \fInet\fR \fBmask \fImask\fR"
373 True if the IP address matches \fInet\fR with the specific netmask.
374 May be qualified with \fBsrc\fR or \fBdst\fR.
375 .IP "\fBnet \fInet\fR/\fIlen\fR"
376 True if the IP address matches \fInet\fR a netmask \fIlen\fR bits wide.
377 May be qualified with \fBsrc\fR or \fBdst\fR.
378 .IP "\fBdst port \fIport\fR"
379 True if the packet is ip/tcp or ip/udp and has a
380 destination port value of \fIport\fP.
381 The \fIport\fP can be a number or a name used in /etc/services (see
385 If a name is used, both the port
386 number and protocol are checked. If a number or ambiguous name is used,
387 only the port number is checked (e.g., \fBdst port 513\fR will print both
388 tcp/login traffic and udp/who traffic, and \fBport domain\fR will print
389 both tcp/domain and udp/domain traffic).
390 .IP "\fBsrc port \fIport\fR"
391 True if the packet has a source port value of \fIport\fP.
392 .IP "\fBport \fIport\fR"
393 True if either the source or destination port of the packet is \fIport\fP.
394 Any of the above port expressions can be prepended with the keywords,
395 \fBtcp\fP or \fBudp\fP, as in:
398 \fBtcp src port \fIport\fR
401 which matches only tcp packets whose source port is \fIport\fP.
402 .IP "\fBless \fIlength\fR"
403 True if the packet has a length less than or equal to \fIlength\fP.
404 This is equivalent to:
407 \fBlen <= \fIlength\fP.
410 .IP "\fBgreater \fIlength\fR"
411 True if the packet has a length greater than or equal to \fIlength\fP.
412 This is equivalent to:
415 \fBlen >= \fIlength\fP.
418 .IP "\fBip proto \fIprotocol\fR"
419 True if the packet is an ip packet (see
421 of protocol type \fIprotocol\fP.
422 \fIProtocol\fP can be a number or one of the names
423 \fIicmp\fP, \fIigrp\fP, \fIudp\fP, \fInd\fP, or \fItcp\fP.
424 Note that the identifiers \fItcp\fP, \fIudp\fP, and \fIicmp\fP are also
425 keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell.
426 .IP "\fBether broadcast\fR"
427 True if the packet is an ethernet broadcast packet. The \fIether\fP
429 .IP "\fBip broadcast\fR"
430 True if the packet is an IP broadcast packet. It checks for both
431 the all-zeroes and all-ones broadcast conventions, and looks up
432 the local subnet mask.
433 .IP "\fBether multicast\fR"
434 True if the packet is an ethernet multicast packet. The \fIether\fP
436 This is shorthand for `\fBether[0] & 1 != 0\fP'.
437 .IP "\fBip multicast\fR"
438 True if the packet is an IP multicast packet.
439 .IP "\fBether proto \fIprotocol\fR"
440 True if the packet is of ether type \fIprotocol\fR.
441 \fIProtocol\fP can be a number or a name like
442 \fIip\fP, \fIarp\fP, or \fIrarp\fP.
443 Note these identifiers are also keywords
444 and must be escaped via backslash (\\).
445 [In the case of FDDI (e.g., `\fBfddi protocol arp\fR'), the
446 protocol identification comes from the 802.2 Logical Link Control
447 (LLC) header, which is usually layered on top of the FDDI header.
448 \fITcpdump\fP assumes, when filtering on the protocol identifier,
449 that all FDDI packets include an LLC header, and that the LLC header
450 is in so-called SNAP format.]
451 .IP "\fBdecnet src \fIhost\fR"
452 True if the DECNET source address is
454 which may be an address of the form ``10.123'', or a DECNET host
455 name. [DECNET host name support is only available on Ultrix systems
456 that are configured to run DECNET.]
457 .IP "\fBdecnet dst \fIhost\fR"
458 True if the DECNET destination address is
460 .IP "\fBdecnet host \fIhost\fR"
461 True if either the DECNET source or destination address is
463 .IP "\fBip\fR, \fBarp\fR, \fBrarp\fR, \fBdecnet\fR, \fBiso\fR"
467 \fBether proto \fIp\fR
470 where \fIp\fR is one of the above protocols.
471 .IP "\fBlat\fR, \fBmoprc\fR, \fBmopdl\fR"
475 \fBether proto \fIp\fR
478 where \fIp\fR is one of the above protocols.
480 \fItcpdump\fP does not currently know how to parse these protocols.
481 .IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
488 where \fIp\fR is one of the above protocols.
489 .IP "\fBesis\fR, \fBisis\fR"
496 where \fIp\fR is one of the above protocols.
497 Note that \fItcpdump\fR does an incomplete job of parsing these protocols.
498 .IP "\fIexpr relop expr\fR"
499 True if the relation holds, where \fIrelop\fR is one of >, <, >=, <=, =, !=,
500 and \fIexpr\fR is an arithmetic expression composed of integer constants
501 (expressed in standard C syntax), the normal binary operators
502 [+, -, *, /, &, |], a length operator, and special packet data accessors.
504 data inside the packet, use the following syntax:
507 \fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
510 \fIProto\fR is one of \fBether, fddi,
511 ip, arp, rarp, tcp, udp, \fRor \fBicmp\fR, and
512 indicates the protocol layer for the index operation.
513 The byte offset, relative to the indicated protocol layer, is
515 \fISize\fR is optional and indicates the number of bytes in the
516 field of interest; it can be either one, two, or four, and defaults to one.
517 The length operator, indicated by the keyword \fBlen\fP, gives the
518 length of the packet.
520 For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic.
521 The expression `\fBip[0] & 0xf != 5\fP'
522 catches all IP packets with options. The expression
523 `\fBip[6:2] & 0x1fff = 0\fP'
524 catches only unfragmented datagrams and frag zero of fragmented datagrams.
525 This check is implicitly applied to the \fBtcp\fP and \fBudp\fP
527 For instance, \fBtcp[0]\fP always means the first
528 byte of the TCP \fIheader\fP, and never means the first byte of an
529 intervening fragment.
531 Primitives may be combined using:
533 A parenthesized group of primitives and operators
534 (parentheses are special to the Shell and must be escaped).
536 Negation (`\fB!\fP' or `\fBnot\fP').
538 Concatenation (`\fB&&\fP' or `\fBand\fP').
540 Alternation (`\fB||\fP' or `\fBor\fP').
542 Negation has highest precedence.
543 Alternation and concatenation have equal precedence and associate
544 left to right. Note that explicit \fBand\fR tokens, not juxtaposition,
545 are now required for concatenation.
547 If an identifier is given without a keyword, the most recent keyword
552 \fBnot host vs and ace\fR
558 \fBnot host vs and host ace\fR
561 which should not be confused with
564 \fBnot ( host vs or ace )\fR
568 Expression arguments can be passed to tcpdump as either a single argument
569 or as multiple arguments, whichever is more convenient.
570 Generally, if the expression contains Shell metacharacters, it is
571 easier to pass it as a single, quoted argument.
572 Multiple arguments are concatenated with spaces before being parsed.
575 To print all packets arriving at or departing from \fIsundown\fP:
578 \fBtcpdump host sundown\fP
582 To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR:
585 \fBtcpdump host helios and \\( hot or ace \\)\fP
589 To print all IP packets between \fIace\fR and any host except \fIhelios\fR:
592 \fBtcpdump ip host ace and not helios\fP
596 To print all traffic between local hosts and hosts at Berkeley:
600 tcpdump net ucb-ether
604 To print all ftp traffic through internet gateway \fIsnup\fP:
605 (note that the expression is quoted to prevent the shell from
606 (mis-)interpreting the parentheses):
610 tcpdump 'gateway snup and (port ftp or ftp-data)'
614 To print traffic neither sourced from nor destined for local hosts
615 (if you gateway to one other net, this stuff should never make it
616 onto your local net).
620 tcpdump ip and not net \fIlocalnet\fP
624 To print the start and end packets (the SYN and FIN packets) of each
625 TCP conversation that involves a non-local host.
629 tcpdump 'tcp[13] & 3 != 0 and not src and dst net \fIlocalnet\fP'
633 To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP:
637 tcpdump 'gateway snup and ip[2:2] > 576'
641 To print IP broadcast or multicast packets that were
643 sent via ethernet broadcast or multicast:
647 tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
651 To print all ICMP packets that are not echo requests/replies (i.e., not
656 tcpdump 'icmp[0] != 8 and icmp[0] != 0'
661 The output of \fItcpdump\fP is protocol dependent. The following
662 gives a brief description and examples of most of the formats.
670 If the '-e' option is given, the link level header is printed out.
671 On ethernets, the source and destination addresses, protocol,
672 and packet length are printed.
674 On FDDI networks, the '-e' option causes \fItcpdump\fP to print
675 the `frame control' field, the source and destination addresses,
676 and the packet length. (The `frame control' field governs the
677 interpretation of the rest of the packet. Normal packets (such
678 as those containing IP datagrams) are `async' packets, with a priority
679 value between 0 and 7; for example, `\fBasync4\fR'. Such packets
680 are assumed to contain an 802.2 Logical Link Control (LLC) packet;
681 the LLC header is printed if it is \fInot\fR an ISO datagram or a
682 so-called SNAP packet.
684 \fI(N.B.: The following description assumes familiarity with
685 the SLIP compression algorithm described in RFC-1144.)\fP
687 On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound),
688 packet type, and compression information are printed out.
689 The packet type is printed first.
690 The three types are \fIip\fP, \fIutcp\fP, and \fIctcp\fP.
691 No further link information is printed for \fIip\fR packets.
692 For TCP packets, the connection identifier is printed following the type.
693 If the packet is compressed, its encoded header is printed out.
694 The special cases are printed out as
695 \fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR is the amount by which
696 the sequence number (or sequence number and ack) has changed.
697 If it is not a special case,
698 zero or more changes are printed.
699 A change is indicated by U (urgent pointer), W (window), A (ack),
700 S (sequence number), and I (packet ID), followed by a delta (+n or -n),
702 Finally, the amount of data in the packet and compressed header length
705 For example, the following line shows an outbound compressed TCP packet,
706 with an implicit connection identifier; the ack has changed by 6,
707 the sequence number by 49, and the packet ID by 6; there are 3 bytes of
708 data and 6 bytes of compressed header:
711 \fBO ctcp * A+6 S+49 I+6 3 (6)\fP
717 Arp/rarp output shows the type of request and its arguments. The
718 format is intended to be self explanatory.
719 Here is a short sample taken from the start of an `rlogin' from
720 host \fIrtsg\fP to host \fIcsam\fP:
724 \f(CWarp who-has csam tell rtsg
725 arp reply csam is-at CSAM\fP
729 The first line says that rtsg sent an arp packet asking
730 for the ethernet address of internet host csam. Csam
731 replies with its ethernet address (in this example, ethernet addresses
732 are in caps and internet addresses in lower case).
734 This would look less redundant if we had done \fBtcpdump \-n\fP:
738 \f(CWarp who-has 128.3.254.6 tell 128.3.254.68
739 arp reply 128.3.254.6 is-at 02:07:01:00:01:c4\fP
743 If we had done \fBtcpdump \-e\fP, the fact that the first packet is
744 broadcast and the second is point-to-point would be visible:
748 \f(CWRTSG Broadcast 0806 64: arp who-has csam tell rtsg
749 CSAM RTSG 0806 64: arp reply csam is-at CSAM\fP
753 For the first packet this says the ethernet source address is RTSG, the
754 destination is the ethernet broadcast address, the type field
755 contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
759 \fI(N.B.:The following description assumes familiarity with
760 the TCP protocol described in RFC-793. If you are not familiar
761 with the protocol, neither this description nor tcpdump will
762 be of much use to you.)\fP
764 The general format of a tcp protocol line is:
768 \fIsrc > dst: flags data-seqno ack window urgent options\fP
772 \fISrc\fP and \fIdst\fP are the source and destination IP
773 addresses and ports. \fIFlags\fP are some combination of S (SYN),
774 F (FIN), P (PUSH) or R (RST) or a single `.' (no flags).
775 \fIData-seqno\fP describes the portion of sequence space covered
776 by the data in this packet (see example below).
777 \fIAck\fP is sequence number of the next data expected the other
778 direction on this connection.
779 \fIWindow\fP is the number of bytes of receive buffer space available
780 the other direction on this connection.
781 \fIUrg\fP indicates there is `urgent' data in the packet.
782 \fIOptions\fP are tcp options enclosed in angle brackets (e.g., <mss 1024>).
784 \fISrc, dst\fP and \fIflags\fP are always present. The other fields
785 depend on the contents of the packet's tcp protocol header and
786 are output only if appropriate.
788 Here is the opening portion of an rlogin from host \fIrtsg\fP to
793 \s-2\f(CWrtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
794 csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
795 rtsg.1023 > csam.login: . ack 1 win 4096
796 rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
797 csam.login > rtsg.1023: . ack 2 win 4096
798 rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
799 csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
800 csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
801 csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fP\s+2
805 The first line says that tcp port 1023 on rtsg sent a packet
807 on csam. The \fBS\fP indicates that the \fISYN\fP flag was set.
808 The packet sequence number was 768512 and it contained no data.
809 (The notation is `first:last(nbytes)' which means `sequence
811 up to but not including \fIlast\fP which is \fInbytes\fP bytes of user data'.)
812 There was no piggy-backed ack, the available receive window was 4096
813 bytes and there was a max-segment-size option requesting an mss of
816 Csam replies with a similar packet except it includes a piggy-backed
817 ack for rtsg's SYN. Rtsg then acks csam's SYN. The `.' means no
819 The packet contained no data so there is no data sequence number.
820 Note that the ack sequence
821 number is a small integer (1). The first time \fBtcpdump\fP sees a
822 tcp `conversation', it prints the sequence number from the packet.
823 On subsequent packets of the conversation, the difference between
824 the current packet's sequence number and this initial sequence number
825 is printed. This means that sequence numbers after the
826 first can be interpreted
827 as relative byte positions in the conversation's data stream (with the
828 first data byte each direction being `1'). `-S' will override this
829 feature, causing the original sequence numbers to be output.
831 On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20
832 in the rtsg \(-> csam side of the conversation).
833 The PUSH flag is set in the packet.
834 On the 7th line, csam says it's received data sent by rtsg up to
835 but not including byte 21. Most of this data is apparently sitting in the
836 socket buffer since csam's receive window has gotten 19 bytes smaller.
837 Csam also sends one byte of data to rtsg in this packet.
838 On the 8th and 9th lines,
839 csam sends two bytes of urgent, pushed data to rtsg.
841 If the snapshot was small enough that \fBtcpdump\fP didn't capture
842 the full TCP header, it interprets as much of the header as it can
843 and then reports ``[|\fItcp\fP]'' to indicate the remainder could not
844 be interpreted. If the header contains a bogus option (one with a length
845 that's either too small or beyond the end of the header), tcpdump reports
846 it as ``[\fIbad opt\fP]'' and does not interpret any further options (since
847 it's impossible to tell where they start). If the header length indicates
848 options are present but the IP datagram length is not long enough for the
849 options to actually be there, tcpdump reports it as ``[\fIbad hdr length\fP]''.
854 UDP format is illustrated by this rwho packet:
858 \f(CWactinide.who > broadcast.who: udp 84\fP
862 This says that port \fIwho\fP on host \fIactinide\fP sent a udp
863 datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet
864 broadcast address. The packet contained 84 bytes of user data.
866 Some UDP services are recognized (from the source or destination
867 port number) and the higher level protocol information printed.
868 In particular, Domain Name service requests (RFC-1034/1035) and Sun
869 RPC calls (RFC-1050) to NFS.
871 UDP Name Server Requests
873 \fI(N.B.:The following description assumes familiarity with
874 the Domain Service protocol described in RFC-1035. If you are not familiar
875 with the protocol, the following description will appear to be written
878 Name server requests are formatted as
882 \fIsrc > dst: id op? flags qtype qclass name (len)\fP
884 \f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fP
888 Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an
889 address record (qtype=A) associated with the name \fIucbvax.berkeley.edu.\fP
890 The query id was `3'. The `+' indicates the \fIrecursion desired\fP flag
891 was set. The query length was 37 bytes, not including the UDP and
892 IP protocol headers. The query operation was the normal one, \fIQuery\fP,
893 so the op field was omitted. If the op had been anything else, it would
894 have been printed between the `3' and the `+'.
895 Similarly, the qclass was the normal one,
896 \fIC_IN\fP, and omitted. Any other qclass would have been printed
897 immediately after the `A'.
899 A few anomalies are checked and may result in extra fields enclosed in
900 square brackets: If a query contains an answer, name server or
906 are printed as `[\fIn\fPa]', `[\fIn\fPn]' or `[\fIn\fPau]' where \fIn\fP
907 is the appropriate count.
908 If any of the response bits are set (AA, RA or rcode) or any of the
909 `must be zero' bits are set in bytes two and three, `[b2&3=\fIx\fP]'
910 is printed, where \fIx\fP is the hex value of header bytes two and three.
912 UDP Name Server Responses
914 Name server responses are formatted as
918 \fIsrc > dst: id op rcode flags a/n/au type class data (len)\fP
920 \f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
921 helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fP
925 In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP
926 with 3 answer records, 3 name server records and 7 authority records.
927 The first answer record is type A (address) and its data is internet
928 address 128.32.137.3. The total size of the response was 273 bytes,
929 excluding UDP and IP headers. The op (Query) and response code
930 (NoError) were omitted, as was the class (C_IN) of the A record.
932 In the second example, \fIhelios\fP responds to query 2 with a
933 response code of non-existent domain (NXDomain) with no answers,
934 one name server and no authority records. The `*' indicates that
935 the \fIauthoritative answer\fP bit was set. Since there were no
936 answers, no type, class or data were printed.
938 Other flag characters that might appear are `\-' (recursion available,
939 RA, \fInot\fP set) and `|' (truncated message, TC, set). If the
940 `question' section doesn't contain exactly one entry, `[\fIn\fPq]'
943 Note that name server requests and responses tend to be large and the
944 default \fIsnaplen\fP of 68 bytes may not capture enough of the packet
945 to print. Use the \fB\-s\fP flag to increase the snaplen if you
946 need to seriously investigate name server traffic. `\fB\-s 128\fP'
947 has worked well for me.
950 NFS Requests and Replies
952 Sun NFS (Network File System) requests and replies are printed as:
956 \fIsrc.xid > dst.nfs: len op args\fP
957 \fIsrc.nfs > dst.xid: reply stat len op results\fP
960 sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
961 wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
962 sushi.201b > wrl.nfs:
963 144 lookup fh 9,74/4096.6878 "xcolors"
964 wrl.nfs > sushi.201b:
965 reply ok 128 lookup fh 9,74/4134.3150
970 In the first line, host \fIsushi\fP sends a transaction with id \fI6709\fP
971 to \fIwrl\fP (note that the number following the src host is a
972 transaction id, \fInot\fP the source port). The request was 112 bytes,
973 excluding the UDP and IP headers. The operation was a \fIreadlink\fP
974 (read symbolic link) on file handle (\fIfh\fP) 21,24/10.731657119.
975 (If one is lucky, as in this case, the file handle can be interpreted
976 as a major,minor device number pair, followed by the inode number and
978 \fIWrl\fP replies `ok' with the contents of the link.
980 In the third line, \fIsushi\fP asks \fIwrl\fP to lookup the name
981 `\fIxcolors\fP' in directory file 9,74/4096.6878. Note that the data printed
982 depends on the operation type. The format is intended to be self
983 explanatory if read in conjunction with
984 an NFS protocol spec.
986 If the \-v (verbose) flag is given, additional information is printed.
992 sushi.1372a > wrl.nfs:
993 148 read fh 21,11/12.195 8192 bytes @ 24576
994 wrl.nfs > sushi.1372a:
995 reply ok 1472 read REG 100664 ids 417/0 sz 29388
1000 (\-v also prints the IP header TTL, ID, and fragmentation fields,
1001 which have been omitted from this example.) In the first line,
1002 \fIsushi\fP asks \fIwrl\fP to read 8192 bytes from file 21,11/12.195,
1003 at byte offset 24576. \fIWrl\fP replies `ok'; the packet shown on the
1004 second line is the first fragment of the reply, and hence is only 1472
1005 bytes long (the other bytes will follow in subsequent fragments, but
1006 these fragments do not have NFS or even UDP headers and so might not be
1007 printed, depending on the filter expression used). Because the \-v flag
1008 is given, some of the file attributes (which are returned in addition
1009 to the file data) are printed: the file type (``REG'', for regular file),
1010 the file mode (in octal), the uid and gid, and the file size.
1012 If the \-v flag is given more than once, even more details are printed.
1014 Note that NFS requests are very large and much of the detail won't be printed
1015 unless \fIsnaplen\fP is increased. Try using `\fB\-s 192\fP' to watch
1018 NFS reply packets do not explicitly identify the RPC operation. Instead,
1019 \fItcpdump\fP keeps track of ``recent'' requests, and matches them to the
1020 replies using the transaction ID. If a reply does not closely follow the
1021 corresponding request, it might not be parsable.
1023 KIP Appletalk (DDP in UDP)
1025 Appletalk DDP packets encapsulated in UDP datagrams are de-encapsulated
1026 and dumped as DDP packets (i.e., all the UDP header information is
1027 discarded). The file
1029 is used to translate appletalk net and node numbers to names.
1030 Lines in this file have the form
1042 The first two lines give the names of appletalk networks. The third
1043 line gives the name of a particular host (a host is distinguished
1044 from a net by the 3rd octet in the number \-
1045 a net number \fImust\fP have two octets and a host number \fImust\fP
1046 have three octets.) The number and name should be separated by
1047 whitespace (blanks or tabs).
1050 file may contain blank lines or comment lines (lines starting with
1053 Appletalk addresses are printed in the form
1059 \f(CW144.1.209.2 > icsd-net.112.220
1060 office.2 > icsd-net.112.220
1061 jssmag.149.235 > icsd-net.2\fP
1067 doesn't exist or doesn't contain an entry for some appletalk
1068 host/net number, addresses are printed in numeric form.)
1069 In the first example, NBP (DDP port 2) on net 144.1 node 209
1070 is sending to whatever is listening on port 220 of net icsd node 112.
1071 The second line is the same except the full name of the source node
1072 is known (`office'). The third line is a send from port 235 on
1073 net jssmag node 149 to broadcast on the icsd-net NBP port (note that
1074 the broadcast address (255) is indicated by a net name with no host
1075 number \- for this reason it's a good idea to keep node names and
1076 net names distinct in /etc/atalk.names).
1078 NBP (name binding protocol) and ATP (Appletalk transaction protocol)
1079 packets have their contents interpreted. Other protocols just dump
1080 the protocol name (or number if no name is registered for the
1081 protocol) and packet size.
1083 \fBNBP packets\fP are formatted like the following examples:
1087 \s-2\f(CWicsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
1088 jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
1089 techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fP\s+2
1093 The first line is a name lookup request for laserwriters sent by net icsd host
1094 112 and broadcast on net jssmag. The nbp id for the lookup is 190.
1095 The second line shows a reply for this request (note that it has the
1096 same id) from host jssmag.209 saying that it has a laserwriter
1097 resource named "RM1140" registered on port 250. The third line is
1098 another reply to the same request saying host techpit has laserwriter
1099 "techpit" registered on port 186.
1101 \fBATP packet\fP formatting is demonstrated by the following example:
1105 \s-2\f(CWjssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001
1106 helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
1107 helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
1108 helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
1109 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
1110 helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
1111 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
1112 helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
1113 helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
1114 jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001
1115 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
1116 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
1117 jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001
1118 jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fP\s+2
1122 Jssmag.209 initiates transaction id 12266 with host helios by requesting
1123 up to 8 packets (the `<0-7>'). The hex number at the end of the line
1124 is the value of the `userdata' field in the request.
1126 Helios responds with 8 512-byte packets. The `:digit' following the
1127 transaction id gives the packet sequence number in the transaction
1128 and the number in parens is the amount of data in the packet,
1129 excluding the atp header. The `*' on packet 7 indicates that the
1132 Jssmag.209 then requests that packets 3 & 5 be retransmitted. Helios
1133 resends them then jssmag.209 releases the transaction. Finally,
1134 jssmag.209 initiates the next request. The `*' on the request
1135 indicates that XO (`exactly once') was \fInot\fP set.
1140 Fragmented Internet datagrams are printed as
1144 \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR
1145 \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR
1149 (The first form indicates there are more fragments. The second
1150 indicates this is the last fragment.)
1152 \fIId\fP is the fragment id. \fISize\fP is the fragment
1153 size (in bytes) excluding the IP header. \fIOffset\fP is this
1154 fragment's offset (in bytes) in the original datagram.
1156 The fragment information is output for each fragment. The first
1157 fragment contains the higher level protocol header and the frag
1158 info is printed after the protocol info. Fragments
1159 after the first contain no higher level protocol header and the
1160 frag info is printed after the source and destination addresses.
1161 For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa
1162 over a CSNET connection that doesn't appear to handle 576 byte datagrams:
1166 \s-2\f(CWarizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
1167 arizona > rtsg: (frag 595a:204@328)
1168 rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560\fP\s+2
1172 There are a couple of things to note here: First, addresses in the
1173 2nd line don't include port numbers. This is because the TCP
1174 protocol information is all in the first fragment and we have no idea
1175 what the port or sequence numbers are when we print the later fragments.
1176 Second, the tcp sequence information in the first line is printed as if there
1177 were 308 bytes of user data when, in fact, there are 512 bytes (308 in
1178 the first frag and 204 in the second). If you are looking for holes
1179 in the sequence space or trying to match up acks
1180 with packets, this can fool you.
1182 A packet with the IP \fIdon't fragment\fP flag is marked with a
1183 trailing \fB(DF)\fP.
1187 By default, all output lines are preceded by a timestamp. The timestamp
1188 is the current clock time in the form
1194 and is as accurate as the kernel's clock.
1195 The timestamp reflects the time the kernel first saw the packet. No attempt
1196 is made to account for the time lag between when the
1197 ethernet interface removed the packet from the wire and when the kernel
1198 serviced the `new packet' interrupt.
1204 Steven McCanne, all of the
1205 Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
1207 The current version is available via anonymous ftp:
1210 .I ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
1213 Please send bug reports to tcpdump@ee.lbl.gov.
1215 NIT doesn't let you watch your own outbound traffic, BPF will.
1216 We recommend that you use the latter.
1218 Some attempt should be made to reassemble IP fragments or, at least
1219 to compute the right length for the higher level protocol.
1221 Name server inverse queries are not dumped correctly: The (empty)
1222 question section is printed rather than real query in the answer
1223 section. Some believe that inverse queries are themselves a bug and
1224 prefer to fix the program generating them rather than tcpdump.
1226 Apple Ethertalk DDP packets could be dumped as easily as KIP DDP
1228 Even if we were inclined to do anything to promote the use of
1229 Ethertalk (we aren't), LBL doesn't allow Ethertalk on any of its
1230 networks so we'd would have no way of testing this code.
1232 A packet trace that crosses a daylight savings time change will give
1233 skewed time stamps (the time change is ignored).
1235 Filters expressions that manipulate FDDI headers assume that all FDDI
1236 packets are encapsulated Ethernet packets. This is true for IP, ARP,
1237 and DECNET Phase IV, but is not true for protocols such as ISO CLNS.
1238 Therefore, the filter may inadvertently accept certain packets that
1239 do not properly match the filter expression.
projects / FreeBSD / FreeBSD.git / blob