_T_c_p_d_u_m_p prints out a description of the contents of packets on a network interface that match the boolean _e_x_p_r_e_s_s_i_o_n. It can also be run with the -w flag, which causes it to save the packet data to a file for later analysis, and/or with the -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 expression will be processed by tcpdump.
Tcpdump will, if not run with the -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 kill(1) command); if run with the -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.
When tcpdump finishes capturing packets, it will report counts of:
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) and will continue capturing packets.
Reading packets from a network interface may require that you have special privileges:
You must have read access to
/dev/bpf .
Reading a saved packet file doesn't require special privileges.
The _e_x_p_r_e_s_s_i_o_n consists of one or more primitives. Primitives usually consist of an id (name or number) preceded by one or more qualifiers. There are three different kinds of qualifier:
[`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.
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.]
In addition to the above, there are some special `primitive' keywords that don't follow the pattern: gateway, broadcast, less, greater and arithmetic expressions. All of these are described below.
More complex filter expressions are built up by using the words and, or and 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'.
Allowable primitives are:
>
iipp hhoosstt _h_o_s_t
which is equivalent to:
eetthheerr pprroottoo _\_i_p aanndd hhoosstt _h_o_s_tIf _h_o_s_t is a name with multiple IP addresses, each address will be checked for a match.
> eetthheerr hhoosstt _e_h_o_s_t aanndd nnoott hhoosstt _h_o_s_t which can be used with either names or numbers for _h_o_s_t _/ _e_h_o_s_t.) This syntax does not work in IPv6-enabled configuration at this moment.
ttccpp ssrrcc ppoorrtt _p_o_r_twhich matches only tcp packets whose source port is _p_o_r_t.
lleenn <<== _l_e_n_g_t_h.. </pprree>> <> <>ggrreeaatteerr _l_e_n_g_t_h True if the packet has a length greater than or equal to _l_e_n_g_t_h. - This is equivalent to:
lleenn >>== _l_e_n_g_t_h.. </pprree>> <> <>iipp pprroottoo _p_r_o_t_o_c_o_l True if the packet is an IPv4 packet (see - ip(4P)) of protocol type _p_r_o_t_o_c_o_l. _P_r_o_t_o_c_o_l can be a number or one of the names iiccmmpp, iiccmmpp66, iiggmmpp, iiggrrpp, ppiimm, aahh, eesspp, vvrrrrpp, uuddpp, or ttccpp. Note that the identifiers ttccpp, uuddpp, and iiccmmpp 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.
- iipp66 pprroottoo _p_r_o_t_o_c_o_l True if the packet is an IPv6 packet of protocol type _p_r_o_t_o_c_o_l.
- Note that this primitive does not chase the protocol header chain.
- iipp66 pprroottoocchhaaiinn _p_r_o_t_o_c_o_l True if the packet is IPv6 packet,
- and contains protocol header with type _p_r_o_t_o_c_o_l in its protocol header chain. For example,
iipp66 pprroottoocchhaaiinn 66matches 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 _t_c_p_d_u_m_p, so this can be somewhat slow.- iipp pprroottoocchhaaiinn _p_r_o_t_o_c_o_l Equivalent to iipp66 pprroottoocchhaaiinn _p_r_o_t_o_c_o_l, but this is for IPv4.
- eetthheerr bbrrooaaddccaasstt True if the packet is an Ethernet broadcast packet.
- The _e_t_h_e_r keyword is optional.
- iipp bbrrooaaddccaasstt 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.
- 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.
- eetthheerr mmuullttiiccaasstt True if the packet is an Ethernet multicast packet.
- The eetthheerr keyword is optional. This is shorthand for `eetthheerr[[00]] && 11 !!== 00'.
- iipp mmuullttiiccaasstt True if the packet is an IPv4 multicast packet.
- iipp66 mmuullttiiccaasstt True if the packet is an IPv6 multicast packet.
- eetthheerr pprroottoo _p_r_o_t_o_c_o_l True if the packet is of ether type _p_r_o_t_o_c_o_l.
- _P_r_o_t_o_c_o_l can be a number or one of the names iipp, iipp66, aarrpp, rraarrpp, aattaallkk, aaaarrpp, ddeeccnneett, ssccaa, llaatt, mmooppddll, mmoopprrcc, iissoo, ssttpp, iippxx, or nneettbbeeuuii. Note these identifiers are also keywords and must be escaped via backslash (\).
- [In the case of FDDI (e.g., `ffddddii pprroottooccooll aarrpp'), Token Ring
- (e.g., `ttrr pprroottooccooll aarrpp'), and IEEE 802.11 wireless LANS (e.g., `wwllaann pprroottooccooll aarrpp'), 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.
- When filtering for most protocol identifiers on FDDI, Token Ring, or
- 802.11, _t_c_p_d_u_m_p 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:
- iissoo
- _t_c_p_d_u_m_p checks the DSAP (Destination Service Access Point) and SSAP (Source Service Access Point) fields of the LLC header;
- ssttpp and nneettbbeeuuii
- _t_c_p_d_u_m_p checks the DSAP of the LLC header;
- aattaallkk
- _t_c_p_d_u_m_p checks for a SNAP-format packet with an OUI of 0x080007 and the AppleTalk etype.
- In the case of Ethernet, _t_c_p_d_u_m_p checks the Ethernet type field
- for most of those protocols. The exceptions are:
- iissoo, ssttpp, and nneettbbeeuuii
- _t_c_p_d_u_m_p checks for an 802.3 frame and then checks the LLC header as it does for FDDI, Token Ring, and 802.11;
- aattaallkk
- _t_c_p_d_u_m_p 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;
- aaaarrpp
- _t_c_p_d_u_m_p checks for the AppleTalk ARP etype in either an Ethernet frame or an 802.2 SNAP frame with an OUI of 0x000000;
- iippxx
- _t_c_p_d_u_m_p 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.
- ddeeccnneett ssrrcc _h_o_s_t True if the DECNET source address is
- 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.]
- ddeeccnneett ddsstt _h_o_s_t True if the DECNET destination address is
- host.
- ddeeccnneett hhoosstt _h_o_s_t True if either the DECNET source or destination address is
- host.
- iiffnnaammee _i_n_t_e_r_f_a_c_e True if the packet was logged as coming from the specified interface (applies
- only to packets logged by OpenBSD's pf(4)).
- oonn _i_n_t_e_r_f_a_c_e Synonymous with the
- ifname modifier.
- rrnnrr _n_u_m True if the packet was logged as matching the specified PF rule number
- (applies only to packets logged by OpenBSD's pf(4)).
- rruulleennuumm _n_u_m Synonomous with the
- rnr modifier.
- rreeaassoonn _c_o_d_e True if the packet was logged with the specified PF reason code. The known
- codes are: match, bad-offset, fragment, short, normalize, and memory (applies only to packets logged by OpenBSD's pf(4)).
- rrsseett _n_a_m_e True if the packet was logged as matching the specified PF ruleset
- name of an anchored ruleset (applies only to packets logged by pf(4)).
- rruulleesseett _n_a_m_e Synonomous with the
- rset modifier.
- ssrrnnrr _n_u_m True if the packet was logged as matching the specified PF rule number
- of an anchored ruleset (applies only to packets logged by pf(4)).
- ssuubbrruulleennuumm _n_u_m Synonomous with the
- srnr modifier.
- aaccttiioonn _a_c_t True if PF took the specified action when the packet was logged. Known actions
- are: pass and block (applies only to packets logged by OpenBSD's pf(4)).
- iipp, iipp66, aarrpp, rraarrpp, aattaallkk, aaaarrpp, ddeeccnneett, iissoo, ssttpp, iippxx, _n_e_t_b_e_u_i Abbreviations for:
eetthheerr pprroottoo _pwhere _p is one of the above protocols.- llaatt, mmoopprrcc, mmooppddll Abbreviations for:
eetthheerr pprroottoo _pwhere _p is one of the above protocols. Note that _t_c_p_d_u_m_p does not currently know how to parse these protocols.- vvllaann _[_v_l_a_n___i_d_] True if the packet is an IEEE 802.1Q VLAN packet.
- If _[_v_l_a_n___i_d_] is specified, only true if the packet has the specified _v_l_a_n___i_d. Note that the first vvllaann keyword encountered in _e_x_p_r_e_s_s_i_o_n changes the decoding offsets for the remainder of _e_x_p_r_e_s_s_i_o_n on the assumption that the packet is a VLAN packet. The vvllaann _[_v_l_a_n___i_d_] expression may be used more than once, to filter on VLAN hierarchies. Each use of that expression increments the filter offsets by 4.
- For example:
vvllaann 110000 &&&& vvllaann 220000filters on VLAN 200 encapsulated within VLAN 100, and
vvllaann &&&& vvllaann 330000 &&&& iippfilters IPv4 protocols encapsulated in VLAN 300 encapsulated within any higher order VLAN.- mmppllss _[_l_a_b_e_l___n_u_m_] True if the packet is an MPLS packet.
- If _[_l_a_b_e_l___n_u_m_] is specified, only true is the packet has the specified _l_a_b_e_l___n_u_m. Note that the first mmppllss keyword encountered in _e_x_p_r_e_s_s_i_o_n changes the decoding offsets for the remainder of _e_x_p_r_e_s_s_i_o_n on the assumption that the packet is a MPLS-encapsulated IP packet. The mmppllss _[_l_a_b_e_l___n_u_m_] expression may be used more than once, to filter on MPLS hierarchies. Each use of that expression increments the filter offsets by 4.
- For example:
mmppllss 110000000000 &&&& mmppllss 11002244filters packets with an outer label of 100000 and an inner label of 1024, and
mmppllss &&&& mmppllss 11002244 &&&& hhoosstt 119922..99..220000..11filters packets to or from 192.9.200.1 with an inner label of 1024 and any outer label.- ppppppooeedd True if the packet is a PPP-over-Ethernet Discovery packet (Ethernet
- type 0x8863).
- ppppppooeess True if the packet is a PPP-over-Ethernet Session packet (Ethernet
- type 0x8864). Note that the first ppppppooeess keyword encountered in _e_x_p_r_e_s_s_i_o_n changes the decoding offsets for the remainder of _e_x_p_r_e_s_s_i_o_n on the assumption that the packet is a PPPoE session packet.
- For example:
ppppppooeess &&&& iippfilters IPv4 protocols encapsulated in PPPoE.- ttccpp, uuddpp, iiccmmpp Abbreviations for:
iipp pprroottoo _p oorr iipp66 pprroottoo _pwhere _p is one of the above protocols.- iissoo pprroottoo _p_r_o_t_o_c_o_l True if the packet is an OSI packet of protocol type _p_r_o_t_o_c_o_l.
- _P_r_o_t_o_c_o_l can be a number or one of the names ccllnnpp, eessiiss, or iissiiss.
- ccllnnpp, eessiiss, iissiiss Abbreviations for:
iissoo pprroottoo _pwhere _p is one of the above protocols.- ll11, ll22, iiiihh, llsspp, ssnnpp, ccssnnpp, ppssnnpp Abbreviations for IS-IS PDU types.
- vvppii _n True if the packet is an ATM packet, for SunATM on Solaris, with a
- virtual path identifier of n.
- vvccii _n True if the packet is an ATM packet, for SunATM on Solaris, with a
- virtual channel identifier of n.
- llaannee True if the packet is an ATM packet, for SunATM on Solaris, and is
- an ATM LANE packet. Note that the first llaannee keyword encountered in _e_x_p_r_e_s_s_i_o_n changes the tests done in the remainder of _e_x_p_r_e_s_s_i_o_n on the assumption that the packet is either a LANE emulated Ethernet packet or a LANE LE Control packet. If llaannee isn't specified, the tests are done under the assumption that the packet is an LLC-encapsulated packet.
- llllcc True if the packet is an ATM packet, for SunATM on Solaris, and is
- an LLC-encapsulated packet.
- ooaammff44ss True if the packet is an ATM packet, for SunATM on Solaris, and is
- a segment OAM F4 flow cell (VPI=0 & VCI=3).
- ooaammff44ee 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).
- ooaammff44 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)).
- ooaamm 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)).
- mmeettaacc True if the packet is an ATM packet, for SunATM on Solaris, and is
- on a meta signaling circuit (VPI=0 & VCI=1).
- bbcccc True if the packet is an ATM packet, for SunATM on Solaris, and is
- on a broadcast signaling circuit (VPI=0 & VCI=2).
- sscc True if the packet is an ATM packet, for SunATM on Solaris, and is
- on a signaling circuit (VPI=0 & VCI=5).
- iillmmiicc True if the packet is an ATM packet, for SunATM on Solaris, and is
- on an ILMI circuit (VPI=0 & VCI=16).
- ccoonnnneeccttmmssgg 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.
- mmeettaaccoonnnneecctt 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.
- _e_x_p_r _r_e_l_o_p _e_x_p_r True if the relation holds, where _r_e_l_o_p is one of >, <, >=, <=, =,
- !=, and _e_x_p_r 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:
_p_r_o_t_o [[ _e_x_p_r :: _s_i_z_e ]]_P_r_o_t_o is one of eetthheerr,, ffddddii,, ttrr,, wwllaann,, pppppp,, sslliipp,, lliinnkk,, iipp,, aarrpp,, rraarrpp,, ttccpp,, uuddpp,, iiccmmpp,, iipp66 or rraaddiioo, and indicates the protocol layer for the index operation. (eetthheerr,, ffddddii,, wwllaann,, ttrr,, pppppp,, sslliipp and lliinnkk all refer to the link layer. rraaddiioo refers to the "radio header" added to some 802.11 captures.) Note that _t_c_p_, _u_d_p 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 _e_x_p_r. _S_i_z_e 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 lleenn, gives the length of the packet.For example, `eetthheerr[[00]] && 11 !!== 00' catches all multicast traffic. The expression `iipp[[00]] && 00xxff !!== 55' catches all IPv4 packets with options. The expression `iipp[[66::22]] && 00xx11ffffff == 00' catches only unfragmented IPv4 datagrams and frag zero of fragmented IPv4 datagrams. This check is implicitly applied to the ttccpp and uuddpp index operations. For instance, ttccpp[[00]] always means the first byte of the TCP _h_e_a_d_e_r, 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: iiccmmppttyyppee (ICMP type field), iiccmmppccooddee (ICMP code field), and ttccppffllaaggss (TCP flags field).
The following ICMP type field values are available: iiccmmpp--eecchhoorreeppllyy, iiccmmpp--uunnrreeaacchh, iiccmmpp--ssoouurrcceeqquueenncchh, iiccmmpp--rreeddiirreecctt, iiccmmpp--eecchhoo, iiccmmpp--rroouutteerraaddvveerrtt, iiccmmpp--rroouutteerrssoolliicciitt, iiccmmpp--ttiimmxxcceeeedd, iiccmmpp--ppaarraammpprroobb, iiccmmpp--ttssttaammpp, iiccmmpp--ttssttaammpprreeppllyy, iiccmmpp--iirreeqq, iiccmmpp--iirreeqqrreeppllyy, iiccmmpp--mmaasskkrreeqq, iiccmmpp--mmaasskkrreeppllyy.
The following TCP flags field values are available: ttccpp--ffiinn, ttccpp--ssyynn, ttccpp--rrsstt, ttccpp--ppuusshh, ttccpp--aacckk, ttccpp--uurrgg.
Primitives may be combined using:
Negation has highest precedence. Alternation and concatenation have equal precedence and associate left to right. Note that explicit aanndd tokens, not juxtaposition, are now required for concatenation.
If an identifier is given without a keyword, the most recent keyword
is assumed.
For example,
nnoott hhoosstt vvss aanndd aacceeis short for
nnoott hhoosstt vvss aanndd hhoosstt aacceewhich should not be confused with
nnoott (( hhoosstt vvss oorr aaccee ))
Expression arguments can be passed to _t_c_p_d_u_m_p 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.
To print all packets arriving at or departing from _s_u_n_d_o_w_n:
ttccppdduummpp hhoosstt ssuunnddoowwnn
To print traffic between _h_e_l_i_o_s and either _h_o_t or _a_c_e:
ttccppdduummpp hhoosstt hheelliiooss aanndd \\(( hhoott oorr aaccee \\))
To print all IP packets between _a_c_e and any host except _h_e_l_i_o_s:
ttccppdduummpp iipp hhoosstt aaccee aanndd nnoott hheelliiooss
To print all traffic between local hosts and hosts at Berkeley:
tcpdump net ucb-ether
To print all ftp traffic through internet gateway _s_n_u_p:
(note that the expression is quoted to prevent the shell from
(mis-)interpreting the parentheses):
tcpdump 'gateway snup and (port ftp or ftp-data)'
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).
tcpdump ip and not net _l_o_c_a_l_n_e_t
To print the start and end packets (the SYN and FIN packets) of each
TCP conversation that involves a non-local host.
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net _l_o_c_a_l_n_e_t'
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.)
tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
To print IP packets longer than 576 bytes sent through gateway _s_n_u_p:
tcpdump 'gateway snup and ip[2:2] > 576'
To print IP broadcast or multicast packets that were
not
sent via Ethernet broadcast or multicast:
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
To print all ICMP packets that are not echo requests/replies (i.e., not
ping packets):
tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
The output of _t_c_p_d_u_m_p is protocol dependent.
The following
gives a brief description and examples of most of the formats.
Link Level Headers
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.
On FDDI networks, the '-e' option causes _t_c_p_d_u_m_p 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, `aassyynncc44'. Such packets are assumed to contain an 802.2 Logical Link Control (LLC) packet; the LLC header is printed if it is _n_o_t an ISO datagram or a so-called SNAP packet.
On Token Ring networks, the '-e' option causes _t_c_p_d_u_m_p 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.
On 802.11 networks, the '-e' option causes _t_c_p_d_u_m_p 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.
_(_N_._B_._: _T_h_e _f_o_l_l_o_w_i_n_g _d_e_s_c_r_i_p_t_i_o_n _a_s_s_u_m_e_s _f_a_m_i_l_i_a_r_i_t_y _w_i_t_h _t_h_e _S_L_I_P _c_o_m_p_r_e_s_s_i_o_n _a_l_g_o_r_i_t_h_m _d_e_s_c_r_i_b_e_d _i_n _R_F_C_-_1_1_4_4_._)
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 _i_p, _u_t_c_p, and _c_t_c_p. No further link information is printed for _i_p 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 **SS++_n and **SSAA++_n, where _n 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.
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:
OO ccttccpp ** AA++66 SS++4499 II++66 33 ((66))
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 _r_t_s_g to host _c_s_a_m:
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).
arp who-has csam tell rtsg arp reply csam is-at CSAM
This would look less redundant if we had done _t_c_p_d_u_m_p _-_n:
arp who-has 128.3.254.6 tell 128.3.254.68 arp reply 128.3.254.6 is-at 02:07:01:00:01:c4
If we had done _t_c_p_d_u_m_p _-_e, the fact that the first packet is
broadcast and the second is point-to-point would be visible:
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.
RTSG Broadcast 0806 64: arp who-has csam tell rtsg CSAM RTSG 0806 64: arp reply csam is-at CSAM
_(_N_._B_._:_T_h_e _f_o_l_l_o_w_i_n_g _d_e_s_c_r_i_p_t_i_o_n _a_s_s_u_m_e_s _f_a_m_i_l_i_a_r_i_t_y _w_i_t_h
_t_h_e _T_C_P _p_r_o_t_o_c_o_l _d_e_s_c_r_i_b_e_d _i_n _R_F_C_-_7_9_3_.
_I_f _y_o_u _a_r_e _n_o_t _f_a_m_i_l_i_a_r
_w_i_t_h _t_h_e _p_r_o_t_o_c_o_l_, _n_e_i_t_h_e_r _t_h_i_s _d_e_s_c_r_i_p_t_i_o_n _n_o_r _t_c_p_d_u_m_p _w_i_l_l
_b_e _o_f _m_u_c_h _u_s_e _t_o _y_o_u_._)
_<_p_>
_T_h_e _g_e_n_e_r_a_l _f_o_r_m_a_t _o_f _a _t_c_p _p_r_o_t_o_c_o_l _l_i_n_e _i_s_:
_<_b_r_>
_<_p_r_e_>
_<_b_r_>_<_b_r_>
_s_r_c _> _d_s_t_: _f_l_a_g_s _d_a_t_a_-_s_e_q_n_o _a_c_k _w_i_n_d_o_w _u_r_g_e_n_t _o_p_t_i_o_n_s
_<_b_r_>_<_b_r_>
_<_/_p_r_e_>
_S_r_c _a_n_d _d_s_t _a_r_e _t_h_e _s_o_u_r_c_e _a_n_d _d_e_s_t_i_n_a_t_i_o_n _I_P
_a_d_d_r_e_s_s_e_s _a_n_d _p_o_r_t_s_.
_F_l_a_g_s _a_r_e _s_o_m_e _c_o_m_b_i_n_a_t_i_o_n _o_f _S _(_S_Y_N_)_,
_F _(_F_I_N_)_, _P _(_P_U_S_H_)_, _R _(_R_S_T_)_, _W _(_E_C_N _C_W_R_) _o_r _E _(_E_C_N_-_E_c_h_o_)_, _o_r _a _s_i_n_g_l_e
_`_._' _(_n_o _f_l_a_g_s_)_.
_D_a_t_a_-_s_e_q_n_o _d_e_s_c_r_i_b_e_s _t_h_e _p_o_r_t_i_o_n _o_f _s_e_q_u_e_n_c_e _s_p_a_c_e _c_o_v_e_r_e_d
_b_y _t_h_e _d_a_t_a _i_n _t_h_i_s _p_a_c_k_e_t _(_s_e_e _e_x_a_m_p_l_e _b_e_l_o_w_)_.
_A_c_k _i_s _s_e_q_u_e_n_c_e _n_u_m_b_e_r _o_f _t_h_e _n_e_x_t _d_a_t_a _e_x_p_e_c_t_e_d _t_h_e _o_t_h_e_r
_d_i_r_e_c_t_i_o_n _o_n _t_h_i_s _c_o_n_n_e_c_t_i_o_n_.
_W_i_n_d_o_w _i_s _t_h_e _n_u_m_b_e_r _o_f _b_y_t_e_s _o_f _r_e_c_e_i_v_e _b_u_f_f_e_r _s_p_a_c_e _a_v_a_i_l_a_b_l_e
_t_h_e _o_t_h_e_r _d_i_r_e_c_t_i_o_n _o_n _t_h_i_s _c_o_n_n_e_c_t_i_o_n_.
_U_r_g _i_n_d_i_c_a_t_e_s _t_h_e_r_e _i_s _`_u_r_g_e_n_t_' _d_a_t_a _i_n _t_h_e _p_a_c_k_e_t_.
_O_p_t_i_o_n_s _a_r_e _t_c_p _o_p_t_i_o_n_s _e_n_c_l_o_s_e_d _i_n _a_n_g_l_e _b_r_a_c_k_e_t_s _(_e_._g_._, _<_m_s_s _1_0_2_4_>_)_.
_<_p_>
_S_r_c_, _d_s_t _a_n_d _f_l_a_g_s _a_r_e _a_l_w_a_y_s _p_r_e_s_e_n_t_.
_T_h_e _o_t_h_e_r _f_i_e_l_d_s
_d_e_p_e_n_d _o_n _t_h_e _c_o_n_t_e_n_t_s _o_f _t_h_e _p_a_c_k_e_t_'_s _t_c_p _p_r_o_t_o_c_o_l _h_e_a_d_e_r _a_n_d
_a_r_e _o_u_t_p_u_t _o_n_l_y _i_f _a_p_p_r_o_p_r_i_a_t_e_.
_<_p_>
_H_e_r_e _i_s _t_h_e _o_p_e_n_i_n_g _p_o_r_t_i_o_n _o_f _a_n _r_l_o_g_i_n _f_r_o_m _h_o_s_t _r_t_s_g _t_o
_h_o_s_t _c_s_a_m_.
_<_b_r_>
_<_p_r_e_>
_<_b_r_>_<_b_r_>
_r_t_s_g_._1_0_2_3 _> _c_s_a_m_._l_o_g_i_n_: _S _7_6_8_5_1_2_:_7_6_8_5_1_2_(_0_) _w_i_n _4_0_9_6 _<_m_s_s _1_0_2_4_>
_c_s_a_m_._l_o_g_i_n _> _r_t_s_g_._1_0_2_3_: _S _9_4_7_6_4_8_:_9_4_7_6_4_8_(_0_) _a_c_k _7_6_8_5_1_3 _w_i_n _4_0_9_6 _<_m_s_s _1_0_2_4_>
_r_t_s_g_._1_0_2_3 _> _c_s_a_m_._l_o_g_i_n_: _. _a_c_k _1 _w_i_n _4_0_9_6
_r_t_s_g_._1_0_2_3 _> _c_s_a_m_._l_o_g_i_n_: _P _1_:_2_(_1_) _a_c_k _1 _w_i_n _4_0_9_6
_c_s_a_m_._l_o_g_i_n _> _r_t_s_g_._1_0_2_3_: _. _a_c_k _2 _w_i_n _4_0_9_6
_r_t_s_g_._1_0_2_3 _> _c_s_a_m_._l_o_g_i_n_: _P _2_:_2_1_(_1_9_) _a_c_k _1 _w_i_n _4_0_9_6
_c_s_a_m_._l_o_g_i_n _> _r_t_s_g_._1_0_2_3_: _P _1_:_2_(_1_) _a_c_k _2_1 _w_i_n _4_0_7_7
_c_s_a_m_._l_o_g_i_n _> _r_t_s_g_._1_0_2_3_: _P _2_:_3_(_1_) _a_c_k _2_1 _w_i_n _4_0_7_7 _u_r_g _1
_c_s_a_m_._l_o_g_i_n _> _r_t_s_g_._1_0_2_3_: _P _3_:_4_(_1_) _a_c_k _2_1 _w_i_n _4_0_7_7 _u_r_g _1
The first line says that tcp port 1023 on rtsg sent a packet
to port _l_o_g_i_n
on csam.
The SS indicates that the _S_Y_N flag was set.
The packet sequence number was 768512 and it contained no data.
(The notation is `first:last(nbytes)' which means `sequence
numbers _f_i_r_s_t
up to but not including _l_a_s_t which is _n_b_y_t_e_s 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.
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 _t_c_p_d_u_m_p 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.
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.
If the snapshot was small enough that _t_c_p_d_u_m_p didn't capture
the full TCP header, it interprets as much of the header as it can
and then reports ``[|_t_c_p]'' 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), _t_c_p_d_u_m_p
reports it as ``[_b_a_d _o_p_t]'' 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, _t_c_p_d_u_m_p reports
it as ``[_b_a_d _h_d_r _l_e_n_g_t_h]''.
Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.)
There are 8 bits in the control bits section of the TCP header:
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
1) Caller sends SYN 2) Recipient responds with SYN, ACK 3) Caller sends ACK
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 _t_c_p_d_u_m_p.
Recall the structure of a TCP header without options:
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 | -----------------------------------------------------------------
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.
Starting to count with 0, the relevant TCP control bits are contained in octet 13:
0 7| 15| 23| 31 ----------------|---------------|---------------|---------------- | HL | rsvd |C|E|U|A|P|R|S|F| window size | ----------------|---------------|---------------|---------------- | | 13th octet | | |
Let's have a closer look at octet no. 13:
| | |---------------| |C|E|U|A|P|R|S|F| |---------------| |7 5 3 0|
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.
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:
|C|E|U|A|P|R|S|F| |---------------| |0 0 0 0 0 0 1 0| |---------------| |7 6 5 4 3 2 1 0|
Looking at the control bits section we see that only bit number 1 (SYN) is set.
Assuming that octet number 13 is an 8-bit unsigned integer in network byte order, the binary value of this octet is
and its decimal representation is
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
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.
This relationship can be expressed as tcp[13] == 2
We can use this expression as the filter for _t_c_p_d_u_m_p in order to watch packets which have only SYN set: tcpdump -i xl0 tcp[13] == 2
The expression says "let the 13th octet of a TCP datagram have the decimal value 2", which is exactly what we want.
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:
|C|E|U|A|P|R|S|F| |---------------| |0 0 0 1 0 0 1 0| |---------------| |7 6 5 4 3 2 1 0|
Now bits 1 and 4 are set in the 13th octet. The binary value of octet 13 is
which translates to decimal
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
Now we can't just use 'tcp[13] == 18' in the _t_c_p_d_u_m_p 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.
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:
00010010 SYN-ACK 00000010 SYN AND 00000010 (we want SYN) AND 00000010 (we want SYN) -------- -------- = 00000010 = 00000010
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:
This points us to the _t_c_p_d_u_m_p filter expression tcpdump -i xl0 'tcp[13] & 2 == 2'
Note that you should use single quotes or a backslash
in the expression to hide the AND ('&') special character
from the shell.
UDP Packets
UDP format is illustrated by this rwho packet:
This says that port _w_h_o on host _a_c_t_i_n_i_d_e sent a udp datagram to port _w_h_o on host _b_r_o_a_d_c_a_s_t, the Internet broadcast address. The packet contained 84 bytes of user data.
actinide.who > broadcast.who: udp 84
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.
UDP Name Server Requests
_(_N_._B_._:_T_h_e _f_o_l_l_o_w_i_n_g _d_e_s_c_r_i_p_t_i_o_n _a_s_s_u_m_e_s _f_a_m_i_l_i_a_r_i_t_y _w_i_t_h _t_h_e _D_o_m_a_i_n _S_e_r_v_i_c_e _p_r_o_t_o_c_o_l _d_e_s_c_r_i_b_e_d _i_n _R_F_C_-_1_0_3_5_. _I_f _y_o_u _a_r_e _n_o_t _f_a_m_i_l_i_a_r _w_i_t_h _t_h_e _p_r_o_t_o_c_o_l_, _t_h_e _f_o_l_l_o_w_i_n_g _d_e_s_c_r_i_p_t_i_o_n _w_i_l_l _a_p_p_e_a_r _t_o _b_e _w_r_i_t_t_e_n _i_n _g_r_e_e_k_._)
Name server requests are formatted as
Host _h_2_o_p_o_l_o asked the domain server on _h_e_l_i_o_s for an address record (qtype=A) associated with the name _u_c_b_v_a_x_._b_e_r_k_e_l_e_y_._e_d_u_. The query id was `3'. The `+' indicates the _r_e_c_u_r_s_i_o_n _d_e_s_i_r_e_d flag was set. The query length was 37 bytes, not including the UDP and IP protocol headers. The query operation was the normal one, _Q_u_e_r_y, 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, _C___I_N, and omitted. Any other qclass would have been printed immediately after the `A'.
_s_r_c _> _d_s_t_: _i_d _o_p_? _f_l_a_g_s _q_t_y_p_e _q_c_l_a_s_s _n_a_m_e _(_l_e_n_)
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
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,
ancount,
nscount,
or
arcount
are printed as `[_na]', `[_nn]' or `[_nau]' where _n
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=_x]'
is printed, where _x is the hex value of header bytes two and three.
UDP Name Server Responses
Name server responses are formatted as
In the first example, _h_e_l_i_o_s responds to query id 3 from _h_2_o_p_o_l_o 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.
_s_r_c _> _d_s_t_: _i_d _o_p _r_c_o_d_e _f_l_a_g_s _a_/_n_/_a_u _t_y_p_e _c_l_a_s_s _d_a_t_a _(_l_e_n_)
helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)
In the second example, _h_e_l_i_o_s 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 _a_u_t_h_o_r_i_t_a_t_i_v_e _a_n_s_w_e_r bit was set. Since there were no answers, no type, class or data were printed.
Other flag characters that might appear are `-' (recursion available, RA, _n_o_t set) and `|' (truncated message, TC, set). If the `question' section doesn't contain exactly one entry, `[_nq]' is printed.
Note that name server requests and responses tend to be large and the default _s_n_a_p_l_e_n of 68 bytes may not capture enough of the packet to print. Use the --ss flag to increase the snaplen if you need to seriously investigate name server traffic. `--ss 112288' has worked well for me.
SMB/CIFS decoding
_t_c_p_d_u_m_p 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).
NFS Requests and Replies
Sun NFS (Network File System) requests and replies are printed as:
In the first line, host _s_u_s_h_i sends a transaction with id _6_7_0_9 to _w_r_l (note that the number following the src host is a transaction id, _n_o_t the source port). The request was 112 bytes, excluding the UDP and IP headers. The operation was a _r_e_a_d_l_i_n_k (read symbolic link) on file handle (_f_h) 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.) _W_r_l replies `ok' with the contents of the link.
_s_r_c_._x_i_d _> _d_s_t_._n_f_s_: _l_e_n _o_p _a_r_g_s _s_r_c_._n_f_s _> _d_s_t_._x_i_d_: _r_e_p_l_y _s_t_a_t _l_e_n _o_p _r_e_s_u_l_t_s
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
In the third line, _s_u_s_h_i asks _w_r_l to lookup the name `_x_c_o_l_o_r_s' 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.
If the -v (verbose) flag is given, additional information is printed.
For example:
(-v also prints the IP header TTL, ID, length, and fragmentation fields, which have been omitted from this example.) In the first line, _s_u_s_h_i asks _w_r_l to read 8192 bytes from file 21,11/12.195, at byte offset 24576. _W_r_l 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.
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
If the -v flag is given more than once, even more details are printed.
Note that NFS requests are very large and much of the detail won't be printed unless _s_n_a_p_l_e_n is increased. Try using `--ss 119922' to watch NFS traffic.
NFS reply packets do not explicitly identify the RPC operation.
Instead,
_t_c_p_d_u_m_p 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.
AFS Requests and Replies
Transarc AFS (Andrew File System) requests and replies are printed
as:
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).
_s_r_c_._s_p_o_r_t _> _d_s_t_._d_p_o_r_t_: _r_x _p_a_c_k_e_t_-_t_y_p_e _s_r_c_._s_p_o_r_t _> _d_s_t_._d_p_o_r_t_: _r_x _p_a_c_k_e_t_-_t_y_p_e _s_e_r_v_i_c_e _c_a_l_l _c_a_l_l_-_n_a_m_e _a_r_g_s _s_r_c_._s_p_o_r_t _> _d_s_t_._d_p_o_r_t_: _r_x _p_a_c_k_e_t_-_t_y_p_e _s_e_r_v_i_c_e _r_e_p_l_y _c_a_l_l_-_n_a_m_e _a_r_g_s
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
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).
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.
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.
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.
If the -v flag is given three times, the security index and service id are printed.
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).
Note that AFS requests are very large and many of the arguments won't be printed unless _s_n_a_p_l_e_n is increased. Try using `--ss 225566' to watch AFS traffic.
AFS reply packets do not explicitly identify the RPC operation. Instead, _t_c_p_d_u_m_p 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.
KIP AppleTalk (DDP in UDP)
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
/etc/atalk.names
is used to translate AppleTalk net and node numbers to names.
Lines in this file have the form
_n_u_m_b_e_r _n_a_m_e
1.254 ether
16.1 icsd-net
1.254.110 ace
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 _m_u_s_t have two octets and a host number _m_u_s_t
have three octets.) The number and name should be separated by
whitespace (blanks or tabs).
The
/etc/atalk.names
file may contain blank lines or comment lines (lines starting with
a `#').
AppleTalk addresses are printed in the form
_n_e_t_._h_o_s_t_._p_o_r_t
144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2
(If the
/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).
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.
NNBBPP ppaacckkeettss are formatted like the following examples:
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.
icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*" jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250 techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186
AATTPP ppaacckkeett formatting is demonstrated by the following example:
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.
jssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000 jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001 jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002
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.
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 _n_o_t set.
IP Fragmentation
Fragmented Internet datagrams are printed as
(The first form indicates there are more fragments. The second indicates this is the last fragment.)
((ffrraagg _i_d::_s_i_z_e@@_o_f_f_s_e_t++)) ((ffrraagg _i_d::_s_i_z_e@@_o_f_f_s_e_t))
_I_d is the fragment id. _S_i_z_e is the fragment size (in bytes) excluding the IP header. _O_f_f_s_e_t is this fragment's offset (in bytes) in the original datagram.
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:
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.
arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+) arizona > rtsg: (frag 595a:204@328) rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560
A packet with the IP _d_o_n_'_t _f_r_a_g_m_e_n_t flag is marked with a
trailing ((DDFF)).
Timestamps
By default, all output lines are preceded by a timestamp.
The timestamp
is the current clock time in the form
_h_h_:_m_m_:_s_s_._f_r_a_cand 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.
Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
It is currently being maintained by tcpdump.org.
The current version is available via http:
http://www.tcpdump.org/
The original distribution is available via anonymous ftp:
ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
IPv6/IPsec support is added by WIDE/KAME project. This program uses Eric Young's SSLeay library, under specific configuration.
tcpdump-workers@tcpdump.org
Please send source code contributions, etc. to:
patches@tcpdump.org
Some attempt should be made to reassemble IP fragments or, at least to compute the right length for the higher level protocol.
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 _t_c_p_d_u_m_p.
A packet trace that crosses a daylight savings time change will give skewed time stamps (the time change is ignored).
Filter expressions on fields other than those in Token Ring headers will not correctly handle source-routed Token Ring packets.
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.
ip6 proto should chase header chain, but at this moment it does not. ip6 protochain is supplied for this behavior.
Arithmetic expression against transport layer headers, like ttccpp[[00]], does not work against IPv6 packets. It only looks at IPv4 packets.