diff options
Diffstat (limited to 'contrib/tcpdump/tcpdump.1')
| -rw-r--r-- | contrib/tcpdump/tcpdump.1 | 2359 |
1 files changed, 0 insertions, 2359 deletions
diff --git a/contrib/tcpdump/tcpdump.1 b/contrib/tcpdump/tcpdump.1 deleted file mode 100644 index d13b4de..0000000 --- a/contrib/tcpdump/tcpdump.1 +++ /dev/null @@ -1,2359 +0,0 @@ -.\" @(#) $Header: /tcpdump/master/tcpdump/tcpdump.1,v 1.167.2.11 2007/06/15 20:13:49 guy Exp $ (LBL) -.\" -.\" $NetBSD: tcpdump.8,v 1.9 2003/03/31 00:18:17 perry Exp $ -.\" -.\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997 -.\" The Regents of the University of California. All rights reserved. -.\" All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that: (1) source code distributions -.\" retain the above copyright notice and this paragraph in its entirety, (2) -.\" distributions including binary code include the above copyright notice and -.\" this paragraph in its entirety in the documentation or other materials -.\" provided with the distribution, and (3) all advertising materials mentioning -.\" features or use of this software display the following acknowledgement: -.\" ``This product includes software developed by the University of California, -.\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of -.\" the University nor the names of its contributors may be used to endorse -.\" or promote products derived from this software without specific prior -.\" written permission. -.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED -.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF -.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. -.\" -.TH TCPDUMP 1 "18 April 2005" -.SH NAME -tcpdump \- dump traffic on a network -.SH SYNOPSIS -.na -.B tcpdump -[ -.B \-AdDeflLnNOpqRStuUvxX -] [ -.B \-c -.I count -] -.br -.ti +8 -[ -.B \-C -.I file_size -] [ -.B \-F -.I file -] -.br -.ti +8 -[ -.B \-i -.I interface -] -[ -.B \-m -.I module -] -[ -.B \-M -.I secret -] -.br -.ti +8 -[ -.B \-r -.I file -] -[ -.B \-s -.I snaplen -] -[ -.B \-T -.I type -] -[ -.B \-w -.I file -] -.br -.ti +8 -[ -.B \-W -.I filecount -] -.br -.ti +8 -[ -.B \-E -.I spi@ipaddr algo:secret,... -] -.br -.ti +8 -[ -.B \-y -.I datalinktype -] -[ -.B \-Z -.I user -] -.ti +8 -[ -.I expression -] -.br -.ad -.SH DESCRIPTION -.LP -\fITcpdump\fP prints out a description of the contents of packets on a -network interface that match the boolean \fIexpression\fP. It can also -be run with the -.B \-w -flag, which causes it to save the packet data to a file for later -analysis, and/or with the -.B \-r -flag, which causes it to read from a saved packet file rather than to -read packets from a network interface. In all cases, only packets that -match -.I expression -will be processed by -.IR tcpdump . -.LP -.I Tcpdump -will, if not run with the -.B \-c -flag, continue capturing packets until it is interrupted by a SIGINT -signal (generated, for example, by typing your interrupt character, -typically control-C) or a SIGTERM signal (typically generated with the -.BR kill (1) -command); if run with the -.B \-c -flag, it will capture packets until it is interrupted by a SIGINT or -SIGTERM signal or the specified number of packets have been processed. -.LP -When -.I tcpdump -finishes capturing packets, it will report counts of: -.IP -packets ``captured'' (this is the number of packets that -.I tcpdump -has received and processed); -.IP -packets ``received by filter'' (the meaning of this depends on the OS on -which you're running -.IR tcpdump , -and possibly on the way the OS was configured - if a filter was -specified on the command line, on some OSes it counts packets regardless -of whether they were matched by the filter expression and, even if they -were matched by the filter expression, regardless of whether -.I tcpdump -has read and processed them yet, on other OSes it counts only packets that were -matched by the filter expression regardless of whether -.I tcpdump -has read and processed them yet, and on other OSes it counts only -packets that were matched by the filter expression and were processed by -.IR tcpdump ); -.IP -packets ``dropped by kernel'' (this is the number of packets that were -dropped, due to a lack of buffer space, by the packet capture mechanism -in the OS on which -.I tcpdump -is running, if the OS reports that information to applications; if not, -it will be reported as 0). -.LP -On platforms that support the SIGINFO signal, such as most BSDs -(including Mac OS X) and Digital/Tru64 UNIX, it will report those counts -when it receives a SIGINFO signal (generated, for example, by typing -your ``status'' character, typically control-T, although on some -platforms, such as Mac OS X, the ``status'' character is not set by -default, so you must set it with -.BR stty (1) -in order to use it) and will continue capturing packets. -.LP -Reading packets from a network interface may require that you have -special privileges: -.TP -.B Under SunOS 3.x or 4.x with NIT or BPF: -You must have read access to -.I /dev/nit -or -.IR /dev/bpf* . -.TP -.B Under Solaris with DLPI: -You must have read/write access to the network pseudo device, e.g. -.IR /dev/le . -On at least some versions of Solaris, however, this is not sufficient to -allow -.I tcpdump -to capture in promiscuous mode; on those versions of Solaris, you must -be root, or -.I tcpdump -must be installed setuid to root, in order to capture in promiscuous -mode. Note that, on many (perhaps all) interfaces, if you don't capture -in promiscuous mode, you will not see any outgoing packets, so a capture -not done in promiscuous mode may not be very useful. -.TP -.B Under HP-UX with DLPI: -You must be root or -.I tcpdump -must be installed setuid to root. -.TP -.B Under IRIX with snoop: -You must be root or -.I tcpdump -must be installed setuid to root. -.TP -.B Under Linux: -You must be root or -.I tcpdump -must be installed setuid to root (unless your distribution has a kernel -that supports capability bits such as CAP_NET_RAW and code to allow -those capability bits to be given to particular accounts and to cause -those bits to be set on a user's initial processes when they log in, in -which case you must have CAP_NET_RAW in order to capture and -CAP_NET_ADMIN to enumerate network devices with, for example, the -.B \-D -flag). -.TP -.B Under ULTRIX and Digital UNIX/Tru64 UNIX: -Any user may capture network traffic with -.IR tcpdump . -However, no user (not even the super-user) can capture in promiscuous -mode on an interface unless the super-user has enabled promiscuous-mode -operation on that interface using -.IR pfconfig (8), -and no user (not even the super-user) can capture unicast traffic -received by or sent by the machine on an interface unless the super-user -has enabled copy-all-mode operation on that interface using -.IR pfconfig , -so -.I useful -packet capture on an interface probably requires that either -promiscuous-mode or copy-all-mode operation, or both modes of -operation, be enabled on that interface. -.TP -.B Under BSD (this includes Mac OS X): -You must have read access to -.I /dev/bpf* -on systems that don't have a cloning BPF device, or to -.I /dev/bpf -on systems that do. -On BSDs with a devfs (this includes Mac OS X), this might involve more -than just having somebody with super-user access setting the ownership -or permissions on the BPF devices - it might involve configuring devfs -to set the ownership or permissions every time the system is booted, -if the system even supports that; if it doesn't support that, you might -have to find some other way to make that happen at boot time. -.LP -Reading a saved packet file doesn't require special privileges. -.SH OPTIONS -.TP -.B \-A -Print each packet (minus its link level header) in ASCII. Handy for -capturing web pages. -.TP -.B \-c -Exit after receiving \fIcount\fP packets. -.TP -.B \-C -Before writing a raw packet to a savefile, check whether the file is -currently larger than \fIfile_size\fP and, if so, close the current -savefile and open a new one. Savefiles after the first savefile will -have the name specified with the -.B \-w -flag, with a number after it, starting at 1 and continuing upward. -The units of \fIfile_size\fP are millions of bytes (1,000,000 bytes, -not 1,048,576 bytes). -.TP -.B \-d -Dump the compiled packet-matching code in a human readable form to -standard output and stop. -.TP -.B \-dd -Dump packet-matching code as a -.B C -program fragment. -.TP -.B \-ddd -Dump packet-matching code as decimal numbers (preceded with a count). -.TP -.B \-D -Print the list of the network interfaces available on the system and on -which -.I tcpdump -can capture packets. For each network interface, a number and an -interface name, possibly followed by a text description of the -interface, is printed. The interface name or the number can be supplied -to the -.B \-i -flag to specify an interface on which to capture. -.IP -This can be useful on systems that don't have a command to list them -(e.g., Windows systems, or UNIX systems lacking -.BR "ifconfig \-a" ); -the number can be useful on Windows 2000 and later systems, where the -interface name is a somewhat complex string. -.IP -The -.B \-D -flag will not be supported if -.I tcpdump -was built with an older version of -.I libpcap -that lacks the -.B pcap_findalldevs() -function. -.TP -.B \-e -Print the link-level header on each dump line. -.TP -.B \-E -Use \fIspi@ipaddr algo:secret\fP for decrypting IPsec ESP packets that -are addressed to \fIaddr\fP and contain Security Parameter Index value -\fIspi\fP. This combination may be repeated with comma or newline seperation. -.IP -Note that setting the secret for IPv4 ESP packets is supported at this time. -.IP -Algorithms may be -\fBdes-cbc\fP, -\fB3des-cbc\fP, -\fBblowfish-cbc\fP, -\fBrc3-cbc\fP, -\fBcast128-cbc\fP, or -\fBnone\fP. -The default is \fBdes-cbc\fP. -The ability to decrypt packets is only present if \fItcpdump\fP was compiled -with cryptography enabled. -.IP -\fIsecret\fP is the ASCII text for ESP secret key. -If preceeded by 0x, then a hex value will be read. -.IP -The option assumes RFC2406 ESP, not RFC1827 ESP. -The option is only for debugging purposes, and -the use of this option with a true `secret' key is discouraged. -By presenting IPsec secret key onto command line -you make it visible to others, via -.IR ps (1) -and other occasions. -.IP -In addition to the above syntax, the syntax \fIfile name\fP may be used -to have tcpdump read the provided file in. The file is opened upon -receiving the first ESP packet, so any special permissions that tcpdump -may have been given should already have been given up. -.TP -.B \-f -Print `foreign' IPv4 addresses numerically rather than symbolically -(this option is intended to get around serious brain damage in -Sun's NIS server \(em usually it hangs forever translating non-local -internet numbers). -.IP -The test for `foreign' IPv4 addresses is done using the IPv4 address and -netmask of the interface on which capture is being done. If that -address or netmask are not available, available, either because the -interface on which capture is being done has no address or netmask or -because the capture is being done on the Linux "any" interface, which -can capture on more than one interface, this option will not work -correctly. -.TP -.B \-F -Use \fIfile\fP as input for the filter expression. -An additional expression given on the command line is ignored. -.TP -.B \-i -Listen on \fIinterface\fP. -If unspecified, \fItcpdump\fP searches the system interface list for the -lowest numbered, configured up interface (excluding loopback). -Ties are broken by choosing the earliest match. -.IP -On Linux systems with 2.2 or later kernels, an -.I interface -argument of ``any'' can be used to capture packets from all interfaces. -Note that captures on the ``any'' device will not be done in promiscuous -mode. -.IP -If the -.B \-D -flag is supported, an interface number as printed by that flag can be -used as the -.I interface -argument. -.TP -.B \-l -Make stdout line buffered. -Useful if you want to see the data -while capturing it. -E.g., -.br -``tcpdump\ \ \-l\ \ |\ \ tee dat'' or -``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''. -.TP -.B \-L -List the known data link types for the interface and exit. -.TP -.B \-m -Load SMI MIB module definitions from file \fImodule\fR. -This option -can be used several times to load several MIB modules into \fItcpdump\fP. -.TP -.B \-M -Use \fIsecret\fP as a shared secret for validating the digests found in -TCP segments with the TCP-MD5 option (RFC 2385), if present. -.TP -.B \-n -Don't convert addresses (i.e., host addresses, port numbers, etc.) to names. -.TP -.B \-N -Don't print domain name qualification of host names. -E.g., -if you give this flag then \fItcpdump\fP will print ``nic'' -instead of ``nic.ddn.mil''. -.TP -.B \-O -Do not run the packet-matching code optimizer. -This is useful only -if you suspect a bug in the optimizer. -.TP -.B \-p -\fIDon't\fP put the interface -into promiscuous mode. -Note that the interface might be in promiscuous -mode for some other reason; hence, `-p' cannot be used as an abbreviation for -`ether host {local-hw-addr} or ether broadcast'. -.TP -.B \-q -Quick (quiet?) output. -Print less protocol information so output -lines are shorter. -.TP -.B \-R -Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829). -If specified, \fItcpdump\fP will not print replay prevention field. -Since there is no protocol version field in ESP/AH specification, -\fItcpdump\fP cannot deduce the version of ESP/AH protocol. -.TP -.B \-r -Read packets from \fIfile\fR (which was created with the -.B \-w -option). -Standard input is used if \fIfile\fR is ``-''. -.TP -.B \-S -Print absolute, rather than relative, TCP sequence numbers. -.TP -.B \-s -Snarf \fIsnaplen\fP bytes of data from each packet rather than the -default of 68 (with SunOS's NIT, the minimum is actually 96). -68 bytes is adequate for IP, ICMP, TCP -and UDP but may truncate protocol information from name server and NFS -packets (see below). -Packets truncated because of a limited snapshot -are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP -is the name of the protocol level at which the truncation has occurred. -Note that taking larger snapshots both increases -the amount of time it takes to process packets and, effectively, -decreases the amount of packet buffering. -This may cause packets to be -lost. -You should limit \fIsnaplen\fP to the smallest number that will -capture the protocol information you're interested in. -Setting -\fIsnaplen\fP to 0 means use the required length to catch whole packets. -.TP -.B \-T -Force packets selected by "\fIexpression\fP" to be interpreted the -specified \fItype\fR. -Currently known types are -\fBaodv\fR (Ad-hoc On-demand Distance Vector protocol), -\fBcnfp\fR (Cisco NetFlow protocol), -\fBrpc\fR (Remote Procedure Call), -\fBrtp\fR (Real-Time Applications protocol), -\fBrtcp\fR (Real-Time Applications control protocol), -\fBsnmp\fR (Simple Network Management Protocol), -\fBtftp\fR (Trivial File Transfer Protocol), -\fBvat\fR (Visual Audio Tool), -and -\fBwb\fR (distributed White Board). -.TP -.B \-t -\fIDon't\fP print a timestamp on each dump line. -.TP -.B \-tt -Print an unformatted timestamp on each dump line. -.TP -.B \-ttt -Print a delta (in micro-seconds) between current and previous line -on each dump line. -.TP -.B \-tttt -Print a timestamp in default format proceeded by date on each dump line. -.TP -.B \-u -Print undecoded NFS handles. -.TP -.B \-U -Make output saved via the -.B \-w -option ``packet-buffered''; i.e., as each packet is saved, it will be -written to the output file, rather than being written only when the -output buffer fills. -.IP -The -.B \-U -flag will not be supported if -.I tcpdump -was built with an older version of -.I libpcap -that lacks the -.B pcap_dump_flush() -function. -.TP -.B \-v -When parsing and printing, produce (slightly more) verbose output. -For example, the time to live, -identification, total length and options in an IP packet are printed. -Also enables additional packet integrity checks such as verifying the -IP and ICMP header checksum. -.IP -When writing to a file with the -.B \-w -option, report, every 10 seconds, the number of packets captured. -.TP -.B \-vv -Even more verbose output. -For example, additional fields are -printed from NFS reply packets, and SMB packets are fully decoded. -.TP -.B \-vvv -Even more verbose output. -For example, -telnet \fBSB\fP ... \fBSE\fP options -are printed in full. -With -.B \-X -Telnet options are printed in hex as well. -.TP -.B \-w -Write the raw packets to \fIfile\fR rather than parsing and printing -them out. -They can later be printed with the \-r option. -Standard output is used if \fIfile\fR is ``-''. -.TP -.B \-W -Used in conjunction with the -.B \-C -option, this will limit the number -of files created to the specified number, and begin overwriting files -from the beginning, thus creating a 'rotating' buffer. -In addition, it will name -the files with enough leading 0s to support the maximum number of -files, allowing them to sort correctly. -.TP -.B \-x -When parsing and printing, -in addition to printing the headers of each packet, print the data of -each packet (minus its link level header) in hex. -The smaller of the entire packet or -.I snaplen -bytes will be printed. Note that this is the entire link-layer -packet, so for link layers that pad (e.g. Ethernet), the padding bytes -will also be printed when the higher layer packet is shorter than the -required padding. -.TP -.B \-xx -When parsing and printing, -in addition to printing the headers of each packet, print the data of -each packet, -.I including -its link level header, in hex. -.TP -.B \-X -When parsing and printing, -in addition to printing the headers of each packet, print the data of -each packet (minus its link level header) in hex and ASCII. -This is very handy for analysing new protocols. -.TP -.B \-XX -When parsing and printing, -in addition to printing the headers of each packet, print the data of -each packet, -.I including -its link level header, in hex and ASCII. -.TP -.B \-y -Set the data link type to use while capturing packets to \fIdatalinktype\fP. -.TP -.B \-Z -Drops privileges (if root) and changes user ID to -.I user -and the group ID to the primary group of -.IR user . -.IP -This behavior can also be enabled by default at compile time. -.IP "\fI expression\fP" -.RS -selects which packets will be dumped. -If no \fIexpression\fP -is given, all packets on the net will be dumped. -Otherwise, -only packets for which \fIexpression\fP is `true' will be dumped. -.LP -The \fIexpression\fP consists of one or more -.I primitives. -Primitives usually consist of an -.I id -(name or number) preceded by one or more qualifiers. -There are three -different kinds of qualifier: -.IP \fItype\fP -qualifiers say what kind of thing the id name or number refers to. -Possible types are -.BR host , -.B net , -.B port -and -.BR portrange . -E.g., `host foo', `net 128.3', `port 20', `portrange 6000-6008'. -If there is no type -qualifier, -.B host -is assumed. -.IP \fIdir\fP -qualifiers specify a particular transfer direction to and/or from -.IR id . -Possible directions are -.BR src , -.BR dst , -.B "src or dst" -and -.B "src and" -.BR dst . -E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'. -If -there is no dir qualifier, -.B "src or dst" -is assumed. -For some link layers, such as SLIP and the ``cooked'' Linux capture mode -used for the ``any'' device and for some other device types, the -.B inbound -and -.B outbound -qualifiers can be used to specify a desired direction. -.IP \fIproto\fP -qualifiers restrict the match to a particular protocol. -Possible -protos are: -.BR ether , -.BR fddi , -.BR tr , -.BR wlan , -.BR ip , -.BR ip6 , -.BR arp , -.BR rarp , -.BR decnet , -.B tcp -and -.BR udp . -E.g., `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange -7000-7009'. -If there is -no proto qualifier, all protocols consistent with the type are -assumed. -E.g., `src foo' means `(ip or arp or rarp) src foo' -(except the latter is not legal syntax), `net bar' means `(ip or -arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'. -.LP -[`fddi' is actually an alias for `ether'; the parser treats them -identically as meaning ``the data link level used on the specified -network interface.'' FDDI headers contain Ethernet-like source -and destination addresses, and often contain Ethernet-like packet -types, so you can filter on these FDDI fields just as with the -analogous Ethernet fields. -FDDI headers also contain other fields, -but you cannot name them explicitly in a filter expression. -.LP -Similarly, `tr' and `wlan' are aliases for `ether'; the previous -paragraph's statements about FDDI headers also apply to Token Ring -and 802.11 wireless LAN headers. For 802.11 headers, the destination -address is the DA field and the source address is the SA field; the -BSSID, RA, and TA fields aren't tested.] -.LP -In addition to the above, there are some special `primitive' keywords -that don't follow the pattern: -.BR gateway , -.BR broadcast , -.BR less , -.B greater -and arithmetic expressions. -All of these are described below. -.LP -More complex filter expressions are built up by using the words -.BR and , -.B or -and -.B not -to combine primitives. -E.g., `host foo and not port ftp and not port ftp-data'. -To save typing, identical qualifier lists can be omitted. -E.g., -`tcp dst port ftp or ftp-data or domain' is exactly the same as -`tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'. -.LP -Allowable primitives are: -.IP "\fBdst host \fIhost\fR" -True if the IPv4/v6 destination field of the packet is \fIhost\fP, -which may be either an address or a name. -.IP "\fBsrc host \fIhost\fR" -True if the IPv4/v6 source field of the packet is \fIhost\fP. -.IP "\fBhost \fIhost\fP -True if either the IPv4/v6 source or destination of the packet is \fIhost\fP. -.IP -Any of the above host expressions can be prepended with the keywords, -\fBip\fP, \fBarp\fP, \fBrarp\fP, or \fBip6\fP as in: -.in +.5i -.nf -\fBip host \fIhost\fR -.fi -.in -.5i -which is equivalent to: -.in +.5i -.nf -\fBether proto \fI\\ip\fB and host \fIhost\fR -.fi -.in -.5i -If \fIhost\fR is a name with multiple IP addresses, each address will -be checked for a match. -.IP "\fBether dst \fIehost\fP -True if the Ethernet destination address is \fIehost\fP. -\fIEhost\fP -may be either a name from /etc/ethers or a number (see -.IR ethers (3N) -for numeric format). -.IP "\fBether src \fIehost\fP -True if the Ethernet source address is \fIehost\fP. -.IP "\fBether host \fIehost\fP -True if either the Ethernet source or destination address is \fIehost\fP. -.IP "\fBgateway\fP \fIhost\fP -True if the packet used \fIhost\fP as a gateway. -I.e., the Ethernet -source or destination address was \fIhost\fP but neither the IP source -nor the IP destination was \fIhost\fP. -\fIHost\fP must be a name and -must be found both by the machine's host-name-to-IP-address resolution -mechanisms (host name file, DNS, NIS, etc.) and by the machine's -host-name-to-Ethernet-address resolution mechanism (/etc/ethers, etc.). -(An equivalent expression is -.in +.5i -.nf -\fBether host \fIehost \fBand not host \fIhost\fR -.fi -.in -.5i -which can be used with either names or numbers for \fIhost / ehost\fP.) -This syntax does not work in IPv6-enabled configuration at this moment. -.IP "\fBdst net \fInet\fR" -True if the IPv4/v6 destination address of the packet has a network -number of \fInet\fP. -\fINet\fP may be either a name from the networks database -(/etc/networks, etc.) or a network number. -An IPv4 network number can be written as a dotted quad (e.g., 192.168.1.0), -dotted triple (e.g., 192.168.1), dotted pair (e.g, 172.16), or single -number (e.g., 10); the netmask is 255.255.255.255 for a dotted quad -(which means that it's really a host match), 255.255.255.0 for a dotted -triple, 255.255.0.0 for a dotted pair, or 255.0.0.0 for a single number. -An IPv6 network number must be written out fully; the netmask is -ff:ff:ff:ff:ff:ff:ff:ff, so IPv6 "network" matches are really always -host matches, and a network match requires a netmask length. -.IP "\fBsrc net \fInet\fR" -True if the IPv4/v6 source address of the packet has a network -number of \fInet\fP. -.IP "\fBnet \fInet\fR" -True if either the IPv4/v6 source or destination address of the packet has a network -number of \fInet\fP. -.IP "\fBnet \fInet\fR \fBmask \fInetmask\fR" -True if the IPv4 address matches \fInet\fR with the specific \fInetmask\fR. -May be qualified with \fBsrc\fR or \fBdst\fR. -Note that this syntax is not valid for IPv6 \fInet\fR. -.IP "\fBnet \fInet\fR/\fIlen\fR" -True if the IPv4/v6 address matches \fInet\fR with a netmask \fIlen\fR -bits wide. -May be qualified with \fBsrc\fR or \fBdst\fR. -.IP "\fBdst port \fIport\fR" -True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a -destination port value of \fIport\fP. -The \fIport\fP can be a number or a name used in /etc/services (see -.IR tcp (4P) -and -.IR udp (4P)). -If a name is used, both the port -number and protocol are checked. -If a number or ambiguous name is used, -only the port number is checked (e.g., \fBdst port 513\fR will print both -tcp/login traffic and udp/who traffic, and \fBport domain\fR will print -both tcp/domain and udp/domain traffic). -.IP "\fBsrc port \fIport\fR" -True if the packet has a source port value of \fIport\fP. -.IP "\fBport \fIport\fR" -True if either the source or destination port of the packet is \fIport\fP. -.IP "\fBdst portrange \fIport1\fB-\fIport2\fR" -True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a -destination port value between \fIport1\fP and \fIport2\fP. -.I port1 -and -.I port2 -are interpreted in the same fashion as the -.I port -parameter for -.BR port . -.IP "\fBsrc portrange \fIport1\fB-\fIport2\fR" -True if the packet has a source port value between \fIport1\fP and -\fIport2\fP. -.IP "\fBportrange \fIport1\fB-\fIport2\fR" -True if either the source or destination port of the packet is between -\fIport1\fP and \fIport2\fP. -.IP -Any of the above port or port range expressions can be prepended with -the keywords, \fBtcp\fP or \fBudp\fP, as in: -.in +.5i -.nf -\fBtcp src port \fIport\fR -.fi -.in -.5i -which matches only tcp packets whose source port is \fIport\fP. -.IP "\fBless \fIlength\fR" -True if the packet has a length less than or equal to \fIlength\fP. -This is equivalent to: -.in +.5i -.nf -\fBlen <= \fIlength\fP. -.fi -.in -.5i -.IP "\fBgreater \fIlength\fR" -True if the packet has a length greater than or equal to \fIlength\fP. -This is equivalent to: -.in +.5i -.nf -\fBlen >= \fIlength\fP. -.fi -.in -.5i -.IP "\fBip proto \fIprotocol\fR" -True if the packet is an IPv4 packet (see -.IR ip (4P)) -of protocol type \fIprotocol\fP. -\fIProtocol\fP can be a number or one of the names -\fBicmp\fP, \fBicmp6\fP, \fBigmp\fP, \fBigrp\fP, \fBpim\fP, \fBah\fP, -\fBesp\fP, \fBvrrp\fP, \fBudp\fP, or \fBtcp\fP. -Note that the identifiers \fBtcp\fP, \fBudp\fP, and \fBicmp\fP are also -keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell. -Note that this primitive does not chase the protocol header chain. -.IP "\fBip6 proto \fIprotocol\fR" -True if the packet is an IPv6 packet of protocol type \fIprotocol\fP. -Note that this primitive does not chase the protocol header chain. -.IP "\fBip6 protochain \fIprotocol\fR" -True if the packet is IPv6 packet, -and contains protocol header with type \fIprotocol\fR -in its protocol header chain. -For example, -.in +.5i -.nf -\fBip6 protochain 6\fR -.fi -.in -.5i -matches any IPv6 packet with TCP protocol header in the protocol header chain. -The packet may contain, for example, -authentication header, routing header, or hop-by-hop option header, -between IPv6 header and TCP header. -The BPF code emitted by this primitive is complex and -cannot be optimized by BPF optimizer code in \fItcpdump\fP, -so this can be somewhat slow. -.IP "\fBip protochain \fIprotocol\fR" -Equivalent to \fBip6 protochain \fIprotocol\fR, but this is for IPv4. -.IP "\fBether broadcast\fR" -True if the packet is an Ethernet broadcast packet. -The \fIether\fP -keyword is optional. -.IP "\fBip broadcast\fR" -True if the packet is an IPv4 broadcast packet. -It checks for both the all-zeroes and all-ones broadcast conventions, -and looks up the subnet mask on the interface on which the capture is -being done. -.IP -If the subnet mask of the interface on which the capture is being done -is not available, either because the interface on which capture is being -done has no netmask or because the capture is being done on the Linux -"any" interface, which can capture on more than one interface, this -check will not work correctly. -.IP "\fBether multicast\fR" -True if the packet is an Ethernet multicast packet. -The \fBether\fP -keyword is optional. -This is shorthand for `\fBether[0] & 1 != 0\fP'. -.IP "\fBip multicast\fR" -True if the packet is an IPv4 multicast packet. -.IP "\fBip6 multicast\fR" -True if the packet is an IPv6 multicast packet. -.IP "\fBether proto \fIprotocol\fR" -True if the packet is of ether type \fIprotocol\fR. -\fIProtocol\fP can be a number or one of the names -\fBip\fP, \fBip6\fP, \fBarp\fP, \fBrarp\fP, \fBatalk\fP, \fBaarp\fP, -\fBdecnet\fP, \fBsca\fP, \fBlat\fP, \fBmopdl\fP, \fBmoprc\fP, -\fBiso\fP, \fBstp\fP, \fBipx\fP, or \fBnetbeui\fP. -Note these identifiers are also keywords -and must be escaped via backslash (\\). -.IP -[In the case of FDDI (e.g., `\fBfddi protocol arp\fR'), Token Ring -(e.g., `\fBtr protocol arp\fR'), and IEEE 802.11 wireless LANS (e.g., -`\fBwlan protocol arp\fR'), for most of those protocols, the -protocol identification comes from the 802.2 Logical Link Control (LLC) -header, which is usually layered on top of the FDDI, Token Ring, or -802.11 header. -.IP -When filtering for most protocol identifiers on FDDI, Token Ring, or -802.11, \fItcpdump\fR checks only the protocol ID field of an LLC header -in so-called SNAP format with an Organizational Unit Identifier (OUI) of -0x000000, for encapsulated Ethernet; it doesn't check whether the packet -is in SNAP format with an OUI of 0x000000. -The exceptions are: -.RS -.TP -\fBiso\fP -\fItcpdump\fR checks the DSAP (Destination Service Access Point) and -SSAP (Source Service Access Point) fields of the LLC header; -.TP -\fBstp\fP and \fBnetbeui\fP -\fItcpdump\fR checks the DSAP of the LLC header; -.TP -\fBatalk\fP -\fItcpdump\fR checks for a SNAP-format packet with an OUI of 0x080007 -and the AppleTalk etype. -.RE -.IP -In the case of Ethernet, \fItcpdump\fR checks the Ethernet type field -for most of those protocols. The exceptions are: -.RS -.TP -\fBiso\fP, \fBstp\fP, and \fBnetbeui\fP -\fItcpdump\fR checks for an 802.3 frame and then checks the LLC header as -it does for FDDI, Token Ring, and 802.11; -.TP -\fBatalk\fP -\fItcpdump\fR checks both for the AppleTalk etype in an Ethernet frame and -for a SNAP-format packet as it does for FDDI, Token Ring, and 802.11; -.TP -\fBaarp\fP -\fItcpdump\fR checks for the AppleTalk ARP etype in either an Ethernet -frame or an 802.2 SNAP frame with an OUI of 0x000000; -.TP -\fBipx\fP -\fItcpdump\fR checks for the IPX etype in an Ethernet frame, the IPX -DSAP in the LLC header, the 802.3-with-no-LLC-header encapsulation of -IPX, and the IPX etype in a SNAP frame. -.RE -.IP "\fBdecnet src \fIhost\fR" -True if the DECNET source address is -.IR host , -which may be an address of the form ``10.123'', or a DECNET host -name. -[DECNET host name support is only available on ULTRIX systems -that are configured to run DECNET.] -.IP "\fBdecnet dst \fIhost\fR" -True if the DECNET destination address is -.IR host . -.IP "\fBdecnet host \fIhost\fR" -True if either the DECNET source or destination address is -.IR host . -.IP "\fBifname \fIinterface\fR" -True if the packet was logged as coming from the specified interface (applies -only to packets logged by OpenBSD's -.BR pf (4)). -.IP "\fBon \fIinterface\fR" -Synonymous with the -.B ifname -modifier. -.IP "\fBrnr \fInum\fR" -True if the packet was logged as matching the specified PF rule number -(applies only to packets logged by OpenBSD's -.BR pf (4)). -.IP "\fBrulenum \fInum\fR" -Synonomous with the -.B rnr -modifier. -.IP "\fBreason \fIcode\fR" -True if the packet was logged with the specified PF reason code. The known -codes are: -.BR match , -.BR bad-offset , -.BR fragment , -.BR short , -.BR normalize , -and -.B memory -(applies only to packets logged by OpenBSD's -.BR pf (4)). -.IP "\fBrset \fIname\fR" -True if the packet was logged as matching the specified PF ruleset -name of an anchored ruleset (applies only to packets logged by -.BR pf (4)). -.IP "\fBruleset \fIname\fR" -Synonomous with the -.B rset -modifier. -.IP "\fBsrnr \fInum\fR" -True if the packet was logged as matching the specified PF rule number -of an anchored ruleset (applies only to packets logged by -.BR pf (4)). -.IP "\fBsubrulenum \fInum\fR" -Synonomous with the -.B srnr -modifier. -.IP "\fBaction \fIact\fR" -True if PF took the specified action when the packet was logged. Known actions -are: -.B pass -and -.B block -(applies only to packets logged by OpenBSD's -.BR pf (4)). -.IP "\fBip\fR, \fBip6\fR, \fBarp\fR, \fBrarp\fR, \fBatalk\fR, \fBaarp\fR, \fBdecnet\fR, \fBiso\fR, \fBstp\fR, \fBipx\fR, \fInetbeui\fP" -Abbreviations for: -.in +.5i -.nf -\fBether proto \fIp\fR -.fi -.in -.5i -where \fIp\fR is one of the above protocols. -.IP "\fBlat\fR, \fBmoprc\fR, \fBmopdl\fR" -Abbreviations for: -.in +.5i -.nf -\fBether proto \fIp\fR -.fi -.in -.5i -where \fIp\fR is one of the above protocols. -Note that -\fItcpdump\fP does not currently know how to parse these protocols. -.IP "\fBvlan \fI[vlan_id]\fR" -True if the packet is an IEEE 802.1Q VLAN packet. -If \fI[vlan_id]\fR is specified, only true if the packet has the specified -\fIvlan_id\fR. -Note that the first \fBvlan\fR keyword encountered in \fIexpression\fR -changes the decoding offsets for the remainder of \fIexpression\fR on -the assumption that the packet is a VLAN packet. The \fBvlan -\fI[vlan_id]\fR expression may be used more than once, to filter on VLAN -hierarchies. Each use of that expression increments the filter offsets -by 4. -.IP -For example: -.in +.5i -.nf -\fBvlan 100 && vlan 200\fR -.fi -.in -.5i -filters on VLAN 200 encapsulated within VLAN 100, and -.in +.5i -.nf -\fBvlan && vlan 300 && ip\fR -.fi -.in -.5i -filters IPv4 protocols encapsulated in VLAN 300 encapsulated within any -higher order VLAN. -.IP "\fBmpls \fI[label_num]\fR" -True if the packet is an MPLS packet. -If \fI[label_num]\fR is specified, only true is the packet has the specified -\fIlabel_num\fR. -Note that the first \fBmpls\fR keyword encountered in \fIexpression\fR -changes the decoding offsets for the remainder of \fIexpression\fR on -the assumption that the packet is a MPLS-encapsulated IP packet. The -\fBmpls \fI[label_num]\fR expression may be used more than once, to -filter on MPLS hierarchies. Each use of that expression increments the -filter offsets by 4. -.IP -For example: -.in +.5i -.nf -\fBmpls 100000 && mpls 1024\fR -.fi -.in -.5i -filters packets with an outer label of 100000 and an inner label of -1024, and -.in +.5i -.nf -\fBmpls && mpls 1024 && host 192.9.200.1\fR -.fi -.in -.5i -filters packets to or from 192.9.200.1 with an inner label of 1024 and -any outer label. -.IP \fBpppoed\fP -True if the packet is a PPP-over-Ethernet Discovery packet (Ethernet -type 0x8863). -.IP \fBpppoes\fP -True if the packet is a PPP-over-Ethernet Session packet (Ethernet -type 0x8864). -Note that the first \fBpppoes\fR keyword encountered in \fIexpression\fR -changes the decoding offsets for the remainder of \fIexpression\fR on -the assumption that the packet is a PPPoE session packet. -.IP -For example: -.in +.5i -.nf -\fBpppoes && ip\fR -.fi -.in -.5i -filters IPv4 protocols encapsulated in PPPoE. -.IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR" -Abbreviations for: -.in +.5i -.nf -\fBip proto \fIp\fR\fB or ip6 proto \fIp\fR -.fi -.in -.5i -where \fIp\fR is one of the above protocols. -.IP "\fBiso proto \fIprotocol\fR" -True if the packet is an OSI packet of protocol type \fIprotocol\fP. -\fIProtocol\fP can be a number or one of the names -\fBclnp\fP, \fBesis\fP, or \fBisis\fP. -.IP "\fBclnp\fR, \fBesis\fR, \fBisis\fR" -Abbreviations for: -.in +.5i -.nf -\fBiso proto \fIp\fR -.fi -.in -.5i -where \fIp\fR is one of the above protocols. -.IP "\fBl1\fR, \fBl2\fR, \fBiih\fR, \fBlsp\fR, \fBsnp\fR, \fBcsnp\fR, \fBpsnp\fR" -Abbreviations for IS-IS PDU types. -.IP "\fBvpi\fP \fIn\fR -True if the packet is an ATM packet, for SunATM on Solaris, with a -virtual path identifier of -.IR n . -.IP "\fBvci\fP \fIn\fR -True if the packet is an ATM packet, for SunATM on Solaris, with a -virtual channel identifier of -.IR n . -.IP \fBlane\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -an ATM LANE packet. -Note that the first \fBlane\fR keyword encountered in \fIexpression\fR -changes the tests done in the remainder of \fIexpression\fR -on the assumption that the packet is either a LANE emulated Ethernet -packet or a LANE LE Control packet. If \fBlane\fR isn't specified, the -tests are done under the assumption that the packet is an -LLC-encapsulated packet. -.IP \fBllc\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -an LLC-encapsulated packet. -.IP \fBoamf4s\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -a segment OAM F4 flow cell (VPI=0 & VCI=3). -.IP \fBoamf4e\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -an end-to-end OAM F4 flow cell (VPI=0 & VCI=4). -.IP \fBoamf4\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)). -.IP \fBoam\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)). -.IP \fBmetac\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -on a meta signaling circuit (VPI=0 & VCI=1). -.IP \fBbcc\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -on a broadcast signaling circuit (VPI=0 & VCI=2). -.IP \fBsc\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -on a signaling circuit (VPI=0 & VCI=5). -.IP \fBilmic\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -on an ILMI circuit (VPI=0 & VCI=16). -.IP \fBconnectmsg\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -on a signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect, -Connect Ack, Release, or Release Done message. -.IP \fBmetaconnect\fP -True if the packet is an ATM packet, for SunATM on Solaris, and is -on a meta signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect, -Release, or Release Done message. -.IP "\fIexpr relop expr\fR" -True if the relation holds, where \fIrelop\fR is one of >, <, >=, <=, =, -!=, and \fIexpr\fR is an arithmetic expression composed of integer -constants (expressed in standard C syntax), the normal binary operators -[+, -, *, /, &, |, <<, >>], a length operator, and special packet data -accessors. Note that all comparisons are unsigned, so that, for example, -0x80000000 and 0xffffffff are > 0. -To access -data inside the packet, use the following syntax: -.in +.5i -.nf -\fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR -.fi -.in -.5i -\fIProto\fR is one of \fBether, fddi, tr, wlan, ppp, slip, link, -ip, arp, rarp, tcp, udp, icmp, ip6\fR or \fBradio\fR, and -indicates the protocol layer for the index operation. -(\fBether, fddi, wlan, tr, ppp, slip\fR and \fBlink\fR all refer to the -link layer. \fBradio\fR refers to the "radio header" added to some -802.11 captures.) -Note that \fItcp, udp\fR and other upper-layer protocol types only -apply to IPv4, not IPv6 (this will be fixed in the future). -The byte offset, relative to the indicated protocol layer, is -given by \fIexpr\fR. -\fISize\fR is optional and indicates the number of bytes in the -field of interest; it can be either one, two, or four, and defaults to one. -The length operator, indicated by the keyword \fBlen\fP, gives the -length of the packet. - -For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic. -The expression `\fBip[0] & 0xf != 5\fP' -catches all IPv4 packets with options. -The expression -`\fBip[6:2] & 0x1fff = 0\fP' -catches only unfragmented IPv4 datagrams and frag zero of fragmented -IPv4 datagrams. -This check is implicitly applied to the \fBtcp\fP and \fBudp\fP -index operations. -For instance, \fBtcp[0]\fP always means the first -byte of the TCP \fIheader\fP, and never means the first byte of an -intervening fragment. - -Some offsets and field values may be expressed as names rather than -as numeric values. -The following protocol header field offsets are -available: \fBicmptype\fP (ICMP type field), \fBicmpcode\fP (ICMP -code field), and \fBtcpflags\fP (TCP flags field). - -The following ICMP type field values are available: \fBicmp-echoreply\fP, -\fBicmp-unreach\fP, \fBicmp-sourcequench\fP, \fBicmp-redirect\fP, -\fBicmp-echo\fP, \fBicmp-routeradvert\fP, \fBicmp-routersolicit\fP, -\fBicmp-timxceed\fP, \fBicmp-paramprob\fP, \fBicmp-tstamp\fP, -\fBicmp-tstampreply\fP, \fBicmp-ireq\fP, \fBicmp-ireqreply\fP, -\fBicmp-maskreq\fP, \fBicmp-maskreply\fP. - -The following TCP flags field values are available: \fBtcp-fin\fP, -\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP, -\fBtcp-ack\fP, \fBtcp-urg\fP. -.LP -Primitives may be combined using: -.IP -A parenthesized group of primitives and operators -(parentheses are special to the Shell and must be escaped). -.IP -Negation (`\fB!\fP' or `\fBnot\fP'). -.IP -Concatenation (`\fB&&\fP' or `\fBand\fP'). -.IP -Alternation (`\fB||\fP' or `\fBor\fP'). -.LP -Negation has highest precedence. -Alternation and concatenation have equal precedence and associate -left to right. -Note that explicit \fBand\fR tokens, not juxtaposition, -are now required for concatenation. -.LP -If an identifier is given without a keyword, the most recent keyword -is assumed. -For example, -.in +.5i -.nf -\fBnot host vs and ace\fR -.fi -.in -.5i -is short for -.in +.5i -.nf -\fBnot host vs and host ace\fR -.fi -.in -.5i -which should not be confused with -.in +.5i -.nf -\fBnot ( host vs or ace )\fR -.fi -.in -.5i -.LP -Expression arguments can be passed to \fItcpdump\fP as either a single -argument or as multiple arguments, whichever is more convenient. -Generally, if the expression contains Shell metacharacters, it is -easier to pass it as a single, quoted argument. -Multiple arguments are concatenated with spaces before being parsed. -.SH EXAMPLES -.LP -To print all packets arriving at or departing from \fIsundown\fP: -.RS -.nf -\fBtcpdump host sundown\fP -.fi -.RE -.LP -To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR: -.RS -.nf -\fBtcpdump host helios and \\( hot or ace \\)\fP -.fi -.RE -.LP -To print all IP packets between \fIace\fR and any host except \fIhelios\fR: -.RS -.nf -\fBtcpdump ip host ace and not helios\fP -.fi -.RE -.LP -To print all traffic between local hosts and hosts at Berkeley: -.RS -.nf -.B -tcpdump net ucb-ether -.fi -.RE -.LP -To print all ftp traffic through internet gateway \fIsnup\fP: -(note that the expression is quoted to prevent the shell from -(mis-)interpreting the parentheses): -.RS -.nf -.B -tcpdump 'gateway snup and (port ftp or ftp-data)' -.fi -.RE -.LP -To print traffic neither sourced from nor destined for local hosts -(if you gateway to one other net, this stuff should never make it -onto your local net). -.RS -.nf -.B -tcpdump ip and not net \fIlocalnet\fP -.fi -.RE -.LP -To print the start and end packets (the SYN and FIN packets) of each -TCP conversation that involves a non-local host. -.RS -.nf -.B -tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net \fIlocalnet\fP' -.fi -.RE -.LP -To print all IPv4 HTTP packets to and from port 80, i.e. print only -packets that contain data, not, for example, SYN and FIN packets and -ACK-only packets. (IPv6 is left as an exercise for the reader.) -.RS -.nf -.B -tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' -.fi -.RE -.LP -To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP: -.RS -.nf -.B -tcpdump 'gateway snup and ip[2:2] > 576' -.fi -.RE -.LP -To print IP broadcast or multicast packets that were -.I not -sent via Ethernet broadcast or multicast: -.RS -.nf -.B -tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224' -.fi -.RE -.LP -To print all ICMP packets that are not echo requests/replies (i.e., not -ping packets): -.RS -.nf -.B -tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply' -.fi -.RE -.SH OUTPUT FORMAT -.LP -The output of \fItcpdump\fP is protocol dependent. -The following -gives a brief description and examples of most of the formats. -.de HD -.sp 1.5 -.B -.. -.HD -Link Level Headers -.LP -If the '-e' option is given, the link level header is printed out. -On Ethernets, the source and destination addresses, protocol, -and packet length are printed. -.LP -On FDDI networks, the '-e' option causes \fItcpdump\fP to print -the `frame control' field, the source and destination addresses, -and the packet length. -(The `frame control' field governs the -interpretation of the rest of the packet. -Normal packets (such -as those containing IP datagrams) are `async' packets, with a priority -value between 0 and 7; for example, `\fBasync4\fR'. -Such packets -are assumed to contain an 802.2 Logical Link Control (LLC) packet; -the LLC header is printed if it is \fInot\fR an ISO datagram or a -so-called SNAP packet. -.LP -On Token Ring networks, the '-e' option causes \fItcpdump\fP to print -the `access control' and `frame control' fields, the source and -destination addresses, and the packet length. -As on FDDI networks, -packets are assumed to contain an LLC packet. -Regardless of whether -the '-e' option is specified or not, the source routing information is -printed for source-routed packets. -.LP -On 802.11 networks, the '-e' option causes \fItcpdump\fP to print -the `frame control' fields, all of the addresses in the 802.11 header, -and the packet length. -As on FDDI networks, -packets are assumed to contain an LLC packet. -.LP -\fI(N.B.: The following description assumes familiarity with -the SLIP compression algorithm described in RFC-1144.)\fP -.LP -On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound), -packet type, and compression information are printed out. -The packet type is printed first. -The three types are \fIip\fP, \fIutcp\fP, and \fIctcp\fP. -No further link information is printed for \fIip\fR packets. -For TCP packets, the connection identifier is printed following the type. -If the packet is compressed, its encoded header is printed out. -The special cases are printed out as -\fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR is the amount by which -the sequence number (or sequence number and ack) has changed. -If it is not a special case, -zero or more changes are printed. -A change is indicated by U (urgent pointer), W (window), A (ack), -S (sequence number), and I (packet ID), followed by a delta (+n or -n), -or a new value (=n). -Finally, the amount of data in the packet and compressed header length -are printed. -.LP -For example, the following line shows an outbound compressed TCP packet, -with an implicit connection identifier; the ack has changed by 6, -the sequence number by 49, and the packet ID by 6; there are 3 bytes of -data and 6 bytes of compressed header: -.RS -.nf -\fBO ctcp * A+6 S+49 I+6 3 (6)\fP -.fi -.RE -.HD -ARP/RARP Packets -.LP -Arp/rarp output shows the type of request and its arguments. -The -format is intended to be self explanatory. -Here is a short sample taken from the start of an `rlogin' from -host \fIrtsg\fP to host \fIcsam\fP: -.RS -.nf -.sp .5 -\f(CWarp who-has csam tell rtsg -arp reply csam is-at CSAM\fR -.sp .5 -.fi -.RE -The first line says that rtsg sent an arp packet asking -for the Ethernet address of internet host csam. -Csam -replies with its Ethernet address (in this example, Ethernet addresses -are in caps and internet addresses in lower case). -.LP -This would look less redundant if we had done \fItcpdump \-n\fP: -.RS -.nf -.sp .5 -\f(CWarp 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\fP -.fi -.RE -.LP -If we had done \fItcpdump \-e\fP, the fact that the first packet is -broadcast and the second is point-to-point would be visible: -.RS -.nf -.sp .5 -\f(CWRTSG Broadcast 0806 64: arp who-has csam tell rtsg -CSAM RTSG 0806 64: arp reply csam is-at CSAM\fR -.sp .5 -.fi -.RE -For the first packet this says the Ethernet source address is RTSG, the -destination is the Ethernet broadcast address, the type field -contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes. -.HD -TCP Packets -.LP -\fI(N.B.:The following description assumes familiarity with -the TCP protocol described in RFC-793. -If you are not familiar -with the protocol, neither this description nor \fItcpdump\fP will -be of much use to you.)\fP -.LP -The general format of a tcp protocol line is: -.RS -.nf -.sp .5 -\fIsrc > dst: flags data-seqno ack window urgent options\fP -.sp .5 -.fi -.RE -\fISrc\fP and \fIdst\fP are the source and destination IP -addresses and ports. -\fIFlags\fP are some combination of S (SYN), -F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo), or a single -`.' (no flags). -\fIData-seqno\fP describes the portion of sequence space covered -by the data in this packet (see example below). -\fIAck\fP is sequence number of the next data expected the other -direction on this connection. -\fIWindow\fP is the number of bytes of receive buffer space available -the other direction on this connection. -\fIUrg\fP indicates there is `urgent' data in the packet. -\fIOptions\fP are tcp options enclosed in angle brackets (e.g., <mss 1024>). -.LP -\fISrc, dst\fP and \fIflags\fP are always present. -The other fields -depend on the contents of the packet's tcp protocol header and -are output only if appropriate. -.LP -Here is the opening portion of an rlogin from host \fIrtsg\fP to -host \fIcsam\fP. -.RS -.nf -.sp .5 -\s-2\f(CWrtsg.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\fR\s+2 -.sp .5 -.fi -.RE -The first line says that tcp port 1023 on rtsg sent a packet -to port \fIlogin\fP -on csam. -The \fBS\fP indicates that the \fISYN\fP flag was set. -The packet sequence number was 768512 and it contained no data. -(The notation is `first:last(nbytes)' which means `sequence -numbers \fIfirst\fP -up to but not including \fIlast\fP which is \fInbytes\fP bytes of user data'.) -There was no piggy-backed ack, the available receive window was 4096 -bytes and there was a max-segment-size option requesting an mss of -1024 bytes. -.LP -Csam replies with a similar packet except it includes a piggy-backed -ack for rtsg's SYN. -Rtsg then acks csam's SYN. -The `.' means no -flags were set. -The packet contained no data so there is no data sequence number. -Note that the ack sequence -number is a small integer (1). -The first time \fItcpdump\fP sees a -tcp `conversation', it prints the sequence number from the packet. -On subsequent packets of the conversation, the difference between -the current packet's sequence number and this initial sequence number -is printed. -This means that sequence numbers after the -first can be interpreted -as relative byte positions in the conversation's data stream (with the -first data byte each direction being `1'). -`-S' will override this -feature, causing the original sequence numbers to be output. -.LP -On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20 -in the rtsg \(-> csam side of the conversation). -The PUSH flag is set in the packet. -On the 7th line, csam says it's received data sent by rtsg up to -but not including byte 21. -Most of this data is apparently sitting in the -socket buffer since csam's receive window has gotten 19 bytes smaller. -Csam also sends one byte of data to rtsg in this packet. -On the 8th and 9th lines, -csam sends two bytes of urgent, pushed data to rtsg. -.LP -If the snapshot was small enough that \fItcpdump\fP didn't capture -the full TCP header, it interprets as much of the header as it can -and then reports ``[|\fItcp\fP]'' to indicate the remainder could not -be interpreted. -If the header contains a bogus option (one with a length -that's either too small or beyond the end of the header), \fItcpdump\fP -reports it as ``[\fIbad opt\fP]'' and does not interpret any further -options (since it's impossible to tell where they start). -If the header -length indicates options are present but the IP datagram length is not -long enough for the options to actually be there, \fItcpdump\fP reports -it as ``[\fIbad hdr length\fP]''. -.HD -.B Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.) -.PP -There are 8 bits in the control bits section of the TCP header: -.IP -.I CWR | ECE | URG | ACK | PSH | RST | SYN | FIN -.PP -Let's assume that we want to watch packets used in establishing -a TCP connection. -Recall that TCP uses a 3-way handshake protocol -when it initializes a new connection; the connection sequence with -regard to the TCP control bits is -.PP -.RS -1) Caller sends SYN -.RE -.RS -2) Recipient responds with SYN, ACK -.RE -.RS -3) Caller sends ACK -.RE -.PP -Now we're interested in capturing packets that have only the -SYN bit set (Step 1). -Note that we don't want packets from step 2 -(SYN-ACK), just a plain initial SYN. -What we need is a correct filter -expression for \fItcpdump\fP. -.PP -Recall the structure of a TCP header without options: -.PP -.nf - 0 15 31 ------------------------------------------------------------------ -| source port | destination port | ------------------------------------------------------------------ -| sequence number | ------------------------------------------------------------------ -| acknowledgment number | ------------------------------------------------------------------ -| HL | rsvd |C|E|U|A|P|R|S|F| window size | ------------------------------------------------------------------ -| TCP checksum | urgent pointer | ------------------------------------------------------------------ -.fi -.PP -A TCP header usually holds 20 octets of data, unless options are -present. -The first line of the graph contains octets 0 - 3, the -second line shows octets 4 - 7 etc. -.PP -Starting to count with 0, the relevant TCP control bits are contained -in octet 13: -.PP -.nf - 0 7| 15| 23| 31 -----------------|---------------|---------------|---------------- -| HL | rsvd |C|E|U|A|P|R|S|F| window size | -----------------|---------------|---------------|---------------- -| | 13th octet | | | -.fi -.PP -Let's have a closer look at octet no. 13: -.PP -.nf - | | - |---------------| - |C|E|U|A|P|R|S|F| - |---------------| - |7 5 3 0| -.fi -.PP -These are the TCP control bits we are interested -in. -We have numbered the bits in this octet from 0 to 7, right to -left, so the PSH bit is bit number 3, while the URG bit is number 5. -.PP -Recall that we want to capture packets with only SYN set. -Let's see what happens to octet 13 if a TCP datagram arrives -with the SYN bit set in its header: -.PP -.nf - |C|E|U|A|P|R|S|F| - |---------------| - |0 0 0 0 0 0 1 0| - |---------------| - |7 6 5 4 3 2 1 0| -.fi -.PP -Looking at the -control bits section we see that only bit number 1 (SYN) is set. -.PP -Assuming that octet number 13 is an 8-bit unsigned integer in -network byte order, the binary value of this octet is -.IP -00000010 -.PP -and its decimal representation is -.PP -.nf - 7 6 5 4 3 2 1 0 -0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2 = 2 -.fi -.PP -We're almost done, because now we know that if only SYN is set, -the value of the 13th octet in the TCP header, when interpreted -as a 8-bit unsigned integer in network byte order, must be exactly 2. -.PP -This relationship can be expressed as -.RS -.B -tcp[13] == 2 -.RE -.PP -We can use this expression as the filter for \fItcpdump\fP in order -to watch packets which have only SYN set: -.RS -.B -tcpdump -i xl0 tcp[13] == 2 -.RE -.PP -The expression says "let the 13th octet of a TCP datagram have -the decimal value 2", which is exactly what we want. -.PP -Now, let's assume that we need to capture SYN packets, but we -don't care if ACK or any other TCP control bit is set at the -same time. -Let's see what happens to octet 13 when a TCP datagram -with SYN-ACK set arrives: -.PP -.nf - |C|E|U|A|P|R|S|F| - |---------------| - |0 0 0 1 0 0 1 0| - |---------------| - |7 6 5 4 3 2 1 0| -.fi -.PP -Now bits 1 and 4 are set in the 13th octet. -The binary value of -octet 13 is -.IP - 00010010 -.PP -which translates to decimal -.PP -.nf - 7 6 5 4 3 2 1 0 -0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2 = 18 -.fi -.PP -Now we can't just use 'tcp[13] == 18' in the \fItcpdump\fP filter -expression, because that would select only those packets that have -SYN-ACK set, but not those with only SYN set. -Remember that we don't care -if ACK or any other control bit is set as long as SYN is set. -.PP -In order to achieve our goal, we need to logically AND the -binary value of octet 13 with some other value to preserve -the SYN bit. -We know that we want SYN to be set in any case, -so we'll logically AND the value in the 13th octet with -the binary value of a SYN: -.PP -.nf - - 00010010 SYN-ACK 00000010 SYN - AND 00000010 (we want SYN) AND 00000010 (we want SYN) - -------- -------- - = 00000010 = 00000010 -.fi -.PP -We see that this AND operation delivers the same result -regardless whether ACK or another TCP control bit is set. -The decimal representation of the AND value as well as -the result of this operation is 2 (binary 00000010), -so we know that for packets with SYN set the following -relation must hold true: -.IP -( ( value of octet 13 ) AND ( 2 ) ) == ( 2 ) -.PP -This points us to the \fItcpdump\fP filter expression -.RS -.B - tcpdump -i xl0 'tcp[13] & 2 == 2' -.RE -.PP -Note that you should use single quotes or a backslash -in the expression to hide the AND ('&') special character -from the shell. -.HD -.B -UDP Packets -.LP -UDP format is illustrated by this rwho packet: -.RS -.nf -.sp .5 -\f(CWactinide.who > broadcast.who: udp 84\fP -.sp .5 -.fi -.RE -This says that port \fIwho\fP on host \fIactinide\fP sent a udp -datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet -broadcast address. -The packet contained 84 bytes of user data. -.LP -Some UDP services are recognized (from the source or destination -port number) and the higher level protocol information printed. -In particular, Domain Name service requests (RFC-1034/1035) and Sun -RPC calls (RFC-1050) to NFS. -.HD -UDP Name Server Requests -.LP -\fI(N.B.:The following description assumes familiarity with -the Domain Service protocol described in RFC-1035. -If you are not familiar -with the protocol, the following description will appear to be written -in greek.)\fP -.LP -Name server requests are formatted as -.RS -.nf -.sp .5 -\fIsrc > dst: id op? flags qtype qclass name (len)\fP -.sp .5 -\f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fR -.sp .5 -.fi -.RE -Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an -address record (qtype=A) associated with the name \fIucbvax.berkeley.edu.\fP -The query id was `3'. -The `+' indicates the \fIrecursion desired\fP flag -was set. -The query length was 37 bytes, not including the UDP and -IP protocol headers. -The query operation was the normal one, \fIQuery\fP, -so the op field was omitted. -If the op had been anything else, it would -have been printed between the `3' and the `+'. -Similarly, the qclass was the normal one, -\fIC_IN\fP, and omitted. -Any other qclass would have been printed -immediately after the `A'. -.LP -A few anomalies are checked and may result in extra fields enclosed in -square brackets: If a query contains an answer, authority records or -additional records section, -.IR ancount , -.IR nscount , -or -.I arcount -are printed as `[\fIn\fPa]', `[\fIn\fPn]' or `[\fIn\fPau]' where \fIn\fP -is the appropriate count. -If any of the response bits are set (AA, RA or rcode) or any of the -`must be zero' bits are set in bytes two and three, `[b2&3=\fIx\fP]' -is printed, where \fIx\fP is the hex value of header bytes two and three. -.HD -UDP Name Server Responses -.LP -Name server responses are formatted as -.RS -.nf -.sp .5 -\fIsrc > dst: id op rcode flags a/n/au type class data (len)\fP -.sp .5 -\f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) -helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fR -.sp .5 -.fi -.RE -In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP -with 3 answer records, 3 name server records and 7 additional records. -The first answer record is type A (address) and its data is internet -address 128.32.137.3. -The total size of the response was 273 bytes, -excluding UDP and IP headers. -The op (Query) and response code -(NoError) were omitted, as was the class (C_IN) of the A record. -.LP -In the second example, \fIhelios\fP responds to query 2 with a -response code of non-existent domain (NXDomain) with no answers, -one name server and no authority records. -The `*' indicates that -the \fIauthoritative answer\fP bit was set. -Since there were no -answers, no type, class or data were printed. -.LP -Other flag characters that might appear are `\-' (recursion available, -RA, \fInot\fP set) and `|' (truncated message, TC, set). -If the -`question' section doesn't contain exactly one entry, `[\fIn\fPq]' -is printed. -.LP -Note that name server requests and responses tend to be large and the -default \fIsnaplen\fP of 68 bytes may not capture enough of the packet -to print. -Use the \fB\-s\fP flag to increase the snaplen if you -need to seriously investigate name server traffic. -`\fB\-s 128\fP' -has worked well for me. - -.HD -SMB/CIFS decoding -.LP -\fItcpdump\fP now includes fairly extensive SMB/CIFS/NBT decoding for data -on UDP/137, UDP/138 and TCP/139. -Some primitive decoding of IPX and -NetBEUI SMB data is also done. - -By default a fairly minimal decode is done, with a much more detailed -decode done if -v is used. -Be warned that with -v a single SMB packet -may take up a page or more, so only use -v if you really want all the -gory details. - -For information on SMB packet formats and what all te fields mean see -www.cifs.org or the pub/samba/specs/ directory on your favorite -samba.org mirror site. -The SMB patches were written by Andrew Tridgell -(tridge@samba.org). - -.HD -NFS Requests and Replies -.LP -Sun NFS (Network File System) requests and replies are printed as: -.RS -.nf -.sp .5 -\fIsrc.xid > dst.nfs: len op args\fP -\fIsrc.nfs > dst.xid: reply stat len op results\fP -.sp .5 -\f(CW -sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165 -wrl.nfs > sushi.6709: reply ok 40 readlink "../var" -sushi.201b > wrl.nfs: - 144 lookup fh 9,74/4096.6878 "xcolors" -wrl.nfs > sushi.201b: - reply ok 128 lookup fh 9,74/4134.3150 -\fR -.sp .5 -.fi -.RE -In the first line, host \fIsushi\fP sends a transaction with id \fI6709\fP -to \fIwrl\fP (note that the number following the src host is a -transaction id, \fInot\fP the source port). -The request was 112 bytes, -excluding the UDP and IP headers. -The operation was a \fIreadlink\fP -(read symbolic link) on file handle (\fIfh\fP) 21,24/10.731657119. -(If one is lucky, as in this case, the file handle can be interpreted -as a major,minor device number pair, followed by the inode number and -generation number.) -\fIWrl\fP replies `ok' with the contents of the link. -.LP -In the third line, \fIsushi\fP asks \fIwrl\fP to lookup the name -`\fIxcolors\fP' in directory file 9,74/4096.6878. -Note that the data printed -depends on the operation type. -The format is intended to be self -explanatory if read in conjunction with -an NFS protocol spec. -.LP -If the \-v (verbose) flag is given, additional information is printed. -For example: -.RS -.nf -.sp .5 -\f(CW -sushi.1372a > wrl.nfs: - 148 read fh 21,11/12.195 8192 bytes @ 24576 -wrl.nfs > sushi.1372a: - reply ok 1472 read REG 100664 ids 417/0 sz 29388 -\fP -.sp .5 -.fi -.RE -(\-v also prints the IP header TTL, ID, length, and fragmentation fields, -which have been omitted from this example.) In the first line, -\fIsushi\fP asks \fIwrl\fP to read 8192 bytes from file 21,11/12.195, -at byte offset 24576. -\fIWrl\fP replies `ok'; the packet shown on the -second line is the first fragment of the reply, and hence is only 1472 -bytes long (the other bytes will follow in subsequent fragments, but -these fragments do not have NFS or even UDP headers and so might not be -printed, depending on the filter expression used). -Because the \-v flag -is given, some of the file attributes (which are returned in addition -to the file data) are printed: the file type (``REG'', for regular file), -the file mode (in octal), the uid and gid, and the file size. -.LP -If the \-v flag is given more than once, even more details are printed. -.LP -Note that NFS requests are very large and much of the detail won't be printed -unless \fIsnaplen\fP is increased. -Try using `\fB\-s 192\fP' to watch -NFS traffic. -.LP -NFS reply packets do not explicitly identify the RPC operation. -Instead, -\fItcpdump\fP keeps track of ``recent'' requests, and matches them to the -replies using the transaction ID. -If a reply does not closely follow the -corresponding request, it might not be parsable. -.HD -AFS Requests and Replies -.LP -Transarc AFS (Andrew File System) requests and replies are printed -as: -.HD -.RS -.nf -.sp .5 -\fIsrc.sport > dst.dport: rx packet-type\fP -\fIsrc.sport > dst.dport: rx packet-type service call call-name args\fP -\fIsrc.sport > dst.dport: rx packet-type service reply call-name args\fP -.sp .5 -\f(CW -elvis.7001 > pike.afsfs: - rx data fs call rename old fid 536876964/1/1 ".newsrc.new" - new fid 536876964/1/1 ".newsrc" -pike.afsfs > elvis.7001: rx data fs reply rename -\fR -.sp .5 -.fi -.RE -In the first line, host elvis sends a RX packet to pike. -This was -a RX data packet to the fs (fileserver) service, and is the start of -an RPC call. -The RPC call was a rename, with the old directory file id -of 536876964/1/1 and an old filename of `.newsrc.new', and a new directory -file id of 536876964/1/1 and a new filename of `.newsrc'. -The host pike -responds with a RPC reply to the rename call (which was successful, because -it was a data packet and not an abort packet). -.LP -In general, all AFS RPCs are decoded at least by RPC call name. -Most -AFS RPCs have at least some of the arguments decoded (generally only -the `interesting' arguments, for some definition of interesting). -.LP -The format is intended to be self-describing, but it will probably -not be useful to people who are not familiar with the workings of -AFS and RX. -.LP -If the -v (verbose) flag is given twice, acknowledgement packets and -additional header information is printed, such as the the RX call ID, -call number, sequence number, serial number, and the RX packet flags. -.LP -If the -v flag is given twice, additional information is printed, -such as the the RX call ID, serial number, and the RX packet flags. -The MTU negotiation information is also printed from RX ack packets. -.LP -If the -v flag is given three times, the security index and service id -are printed. -.LP -Error codes are printed for abort packets, with the exception of Ubik -beacon packets (because abort packets are used to signify a yes vote -for the Ubik protocol). -.LP -Note that AFS requests are very large and many of the arguments won't -be printed unless \fIsnaplen\fP is increased. -Try using `\fB-s 256\fP' -to watch AFS traffic. -.LP -AFS reply packets do not explicitly identify the RPC operation. -Instead, -\fItcpdump\fP keeps track of ``recent'' requests, and matches them to the -replies using the call number and service ID. -If a reply does not closely -follow the -corresponding request, it might not be parsable. - -.HD -KIP AppleTalk (DDP in UDP) -.LP -AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated -and dumped as DDP packets (i.e., all the UDP header information is -discarded). -The file -.I /etc/atalk.names -is used to translate AppleTalk net and node numbers to names. -Lines in this file have the form -.RS -.nf -.sp .5 -\fInumber name\fP - -\f(CW1.254 ether -16.1 icsd-net -1.254.110 ace\fR -.sp .5 -.fi -.RE -The first two lines give the names of AppleTalk networks. -The third -line gives the name of a particular host (a host is distinguished -from a net by the 3rd octet in the number \- -a net number \fImust\fP have two octets and a host number \fImust\fP -have three octets.) The number and name should be separated by -whitespace (blanks or tabs). -The -.I /etc/atalk.names -file may contain blank lines or comment lines (lines starting with -a `#'). -.LP -AppleTalk addresses are printed in the form -.RS -.nf -.sp .5 -\fInet.host.port\fP - -\f(CW144.1.209.2 > icsd-net.112.220 -office.2 > icsd-net.112.220 -jssmag.149.235 > icsd-net.2\fR -.sp .5 -.fi -.RE -(If the -.I /etc/atalk.names -doesn't exist or doesn't contain an entry for some AppleTalk -host/net number, addresses are printed in numeric form.) -In the first example, NBP (DDP port 2) on net 144.1 node 209 -is sending to whatever is listening on port 220 of net icsd node 112. -The second line is the same except the full name of the source node -is known (`office'). -The third line is a send from port 235 on -net jssmag node 149 to broadcast on the icsd-net NBP port (note that -the broadcast address (255) is indicated by a net name with no host -number \- for this reason it's a good idea to keep node names and -net names distinct in /etc/atalk.names). -.LP -NBP (name binding protocol) and ATP (AppleTalk transaction protocol) -packets have their contents interpreted. -Other protocols just dump -the protocol name (or number if no name is registered for the -protocol) and packet size. - -\fBNBP packets\fP are formatted like the following examples: -.RS -.nf -.sp .5 -\s-2\f(CWicsd-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\fR\s+2 -.sp .5 -.fi -.RE -The first line is a name lookup request for laserwriters sent by net icsd host -112 and broadcast on net jssmag. -The nbp id for the lookup is 190. -The second line shows a reply for this request (note that it has the -same id) from host jssmag.209 saying that it has a laserwriter -resource named "RM1140" registered on port 250. -The third line is -another reply to the same request saying host techpit has laserwriter -"techpit" registered on port 186. - -\fBATP packet\fP formatting is demonstrated by the following example: -.RS -.nf -.sp .5 -\s-2\f(CWjssmag.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\fR\s+2 -.sp .5 -.fi -.RE -Jssmag.209 initiates transaction id 12266 with host helios by requesting -up to 8 packets (the `<0-7>'). -The hex number at the end of the line -is the value of the `userdata' field in the request. -.LP -Helios responds with 8 512-byte packets. -The `:digit' following the -transaction id gives the packet sequence number in the transaction -and the number in parens is the amount of data in the packet, -excluding the atp header. -The `*' on packet 7 indicates that the -EOM bit was set. -.LP -Jssmag.209 then requests that packets 3 & 5 be retransmitted. -Helios -resends them then jssmag.209 releases the transaction. -Finally, -jssmag.209 initiates the next request. -The `*' on the request -indicates that XO (`exactly once') was \fInot\fP set. - -.HD -IP Fragmentation -.LP -Fragmented Internet datagrams are printed as -.RS -.nf -.sp .5 -\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR -\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR -.sp .5 -.fi -.RE -(The first form indicates there are more fragments. -The second -indicates this is the last fragment.) -.LP -\fIId\fP is the fragment id. -\fISize\fP is the fragment -size (in bytes) excluding the IP header. -\fIOffset\fP is this -fragment's offset (in bytes) in the original datagram. -.LP -The fragment information is output for each fragment. -The first -fragment contains the higher level protocol header and the frag -info is printed after the protocol info. -Fragments -after the first contain no higher level protocol header and the -frag info is printed after the source and destination addresses. -For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa -over a CSNET connection that doesn't appear to handle 576 byte datagrams: -.RS -.nf -.sp .5 -\s-2\f(CWarizona.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\fP\s+2 -.sp .5 -.fi -.RE -There are a couple of things to note here: First, addresses in the -2nd line don't include port numbers. -This is because the TCP -protocol information is all in the first fragment and we have no idea -what the port or sequence numbers are when we print the later fragments. -Second, the tcp sequence information in the first line is printed as if there -were 308 bytes of user data when, in fact, there are 512 bytes (308 in -the first frag and 204 in the second). -If you are looking for holes -in the sequence space or trying to match up acks -with packets, this can fool you. -.LP -A packet with the IP \fIdon't fragment\fP flag is marked with a -trailing \fB(DF)\fP. -.HD -Timestamps -.LP -By default, all output lines are preceded by a timestamp. -The timestamp -is the current clock time in the form -.RS -.nf -\fIhh:mm:ss.frac\fP -.fi -.RE -and is as accurate as the kernel's clock. -The timestamp reflects the time the kernel first saw the packet. -No attempt -is made to account for the time lag between when the -Ethernet interface removed the packet from the wire and when the kernel -serviced the `new packet' interrupt. -.SH "SEE ALSO" -stty(1), pcap(3), bpf(4), nit(4P), pfconfig(8) -.SH AUTHORS -The original authors are: -.LP -Van Jacobson, -Craig Leres and -Steven McCanne, all of the -Lawrence Berkeley National Laboratory, University of California, Berkeley, CA. -.LP -It is currently being maintained by tcpdump.org. -.LP -The current version is available via http: -.LP -.RS -.I http://www.tcpdump.org/ -.RE -.LP -The original distribution is available via anonymous ftp: -.LP -.RS -.I ftp://ftp.ee.lbl.gov/tcpdump.tar.Z -.RE -.LP -IPv6/IPsec support is added by WIDE/KAME project. -This program uses Eric Young's SSLeay library, under specific configuration. -.SH BUGS -Please send problems, bugs, questions, desirable enhancements, etc. to: -.LP -.RS -tcpdump-workers@tcpdump.org -.RE -.LP -Please send source code contributions, etc. to: -.LP -.RS -patches@tcpdump.org -.RE -.LP -NIT doesn't let you watch your own outbound traffic, BPF will. -We recommend that you use the latter. -.LP -On Linux systems with 2.0[.x] kernels: -.IP -packets on the loopback device will be seen twice; -.IP -packet filtering cannot be done in the kernel, so that all packets must -be copied from the kernel in order to be filtered in user mode; -.IP -all of a packet, not just the part that's within the snapshot length, -will be copied from the kernel (the 2.0[.x] packet capture mechanism, if -asked to copy only part of a packet to userland, will not report the -true length of the packet; this would cause most IP packets to get an -error from -.BR tcpdump ); -.IP -capturing on some PPP devices won't work correctly. -.LP -We recommend that you upgrade to a 2.2 or later kernel. -.LP -Some attempt should be made to reassemble IP fragments or, at least -to compute the right length for the higher level protocol. -.LP -Name server inverse queries are not dumped correctly: the (empty) -question section is printed rather than real query in the answer -section. -Some believe that inverse queries are themselves a bug and -prefer to fix the program generating them rather than \fItcpdump\fP. -.LP -A packet trace that crosses a daylight savings time change will give -skewed time stamps (the time change is ignored). -.LP -Filter expressions on fields other than those in Token Ring headers will -not correctly handle source-routed Token Ring packets. -.LP -Filter expressions on fields other than those in 802.11 headers will not -correctly handle 802.11 data packets with both To DS and From DS set. -.LP -.BR "ip6 proto" -should chase header chain, but at this moment it does not. -.BR "ip6 protochain" -is supplied for this behavior. -.LP -Arithmetic expression against transport layer headers, like \fBtcp[0]\fP, -does not work against IPv6 packets. -It only looks at IPv4 packets. |
