summaryrefslogtreecommitdiffstats
path: root/tcpdump.1.in
diff options
context:
space:
mode:
Diffstat (limited to 'tcpdump.1.in')
-rw-r--r--tcpdump.1.in87
1 files changed, 33 insertions, 54 deletions
diff --git a/tcpdump.1.in b/tcpdump.1.in
index 87e0fbb..3ed261d 100644
--- a/tcpdump.1.in
+++ b/tcpdump.1.in
@@ -20,7 +20,7 @@
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\"
-.TH TCPDUMP 1 "12 March 2023"
+.TH TCPDUMP 1 "26 March 2024"
.SH NAME
tcpdump \- dump traffic on a network
.SH SYNOPSIS
@@ -32,7 +32,6 @@ tcpdump \- dump traffic on a network
.B \-B
.I buffer_size
]
-.br
.ti +8
[
.B \-c
@@ -408,7 +407,7 @@ which should include a time format as defined by
.BR strftime (3).
If no time format is specified, each new file will overwrite the previous.
Whenever a generated filename is not unique, tcpdump will overwrite the
-pre-existing data; providing a time specification that is coarser than the
+preexisting data; providing a time specification that is coarser than the
capture period is therefore not advised.
.IP
If used in conjunction with the
@@ -625,7 +624,7 @@ instead of ``nic.ddn.mil''.
.TP
.B \-\-number
.PD
-Print an optional packet number at the beginning of the line.
+Print a packet number at the beginning of the line.
.TP
.B \-O
.PD 0
@@ -1105,8 +1104,7 @@ gives a brief description and examples of most of the formats.
.sp 1.5
.B
..
-.HD
-Timestamps
+.SS Timestamps
.LP
By default, all output lines are preceded by a timestamp.
The timestamp
@@ -1126,8 +1124,16 @@ packet from the network and the time when an interrupt was delivered to
the kernel to get it to read the packet and a delay between the time
when the kernel serviced the `new packet' interrupt and the time when it
applied a time stamp to the packet.
-.HD
-Link Level Headers
+.SS Interface
+.LP
+When the \fIany\fP interface is selected on capture or when a link-type
+\fILINUX_SLL2\fP capture file is read the
+interface name is printed after the timestamp. This is followed by the packet
+type with \fIIn\fP and \fIOut\fP denoting a packet destined for this host or
+originating from this host respectively. Other possible values are \fIB\fP
+for broadcast packets, \fIM\fP for multicast packets, and \fIP\fP for packets
+destined for other hosts.
+.SS 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,
@@ -1191,8 +1197,7 @@ data and 6 bytes of compressed header:
\fBO ctcp * A+6 S+49 I+6 3 (6)\fP
.fi
.RE
-.HD
-ARP/RARP Packets
+.SS ARP/RARP Packets
.LP
ARP/RARP output shows the type of request and its arguments.
The
@@ -1235,8 +1240,7 @@ CSAM RTSG 0806 64: arp reply csam is-at CSAM\fR
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
-IPv4 Packets
+.SS IPv4 Packets
.LP
If the link-layer header is not being printed, for IPv4 packets,
\fBIP\fP is printed after the time stamp.
@@ -1263,7 +1267,8 @@ part of a fragmented datagram or not.
and \fBDF\fP is reported if F is set. If neither are set, \fB.\fP is
reported.
\fIproto\fP is the protocol ID field.
-\fIlength\fP is the total length field.
+\fIlength\fP is the total length field; if the packet is a presumed TSO
+(TCP Segmentation Offload) send, [was 0, presumed TSO] is reported.
\fIoptions\fP are the IP options, if any.
.LP
Next, for TCP and UDP packets, the source and destination IP addresses
@@ -1279,8 +1284,7 @@ protocol header. Fragmentation information will be printed only with
the
.B \-v
flag, in the IP header information, as described above.
-.HD
-TCP Packets
+.SS TCP Packets
.LP
\fI(N.B.:The following description assumes familiarity with
the TCP protocol described in RFC 793.
@@ -1387,8 +1391,7 @@ 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.)
+.SS Particular TCP Flag Combinations (SYN-ACK, URG-ACK, etc.)
.PP
There are 8 bits in the control bits section of the TCP header:
.IP
@@ -1506,7 +1509,7 @@ 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
+tcpdump -i xl0 'tcp[13] == 2'
.RE
.PP
The expression says "let the 13th octet of a TCP datagram have
@@ -1590,9 +1593,7 @@ This can be demonstrated as:
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
+.SS UDP Packets
.LP
UDP format is illustrated by this rwho packet:
.RS
@@ -1611,8 +1612,7 @@ 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
-TCP or UDP Name Server Requests
+.SS TCP or UDP Name Server Requests
.LP
\fI(N.B.:The following description assumes familiarity with
the Domain Service protocol described in RFC 1035.
@@ -1658,8 +1658,7 @@ 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
-TCP or UDP Name Server Responses
+.SS TCP or UDP Name Server Responses
.LP
Name server responses are formatted as
.RS
@@ -1682,7 +1681,7 @@ 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,
+response code of nonexistent domain (NXDomain) with no answers,
one name server and no authority records.
The `*' indicates that
the \fIauthoritative answer\fP bit was set.
@@ -1694,8 +1693,7 @@ RA, \fInot\fP set) and `|' (truncated message, TC, set).
If the
`question' section doesn't contain exactly one entry, `[\fIn\fPq]'
is printed.
-.HD
-SMB/CIFS decoding
+.SS SMB/CIFS Decoding
.LP
\fItcpdump\fP now includes fairly extensive SMB/CIFS/NBT decoding for data
on UDP/137, UDP/138 and TCP/139.
@@ -1712,8 +1710,7 @@ For information on SMB packet formats and what all the fields mean see
\%https://download.samba.org/pub/samba/specs/ and other online resources.
The SMB patches were written by Andrew Tridgell
(tridge@samba.org).
-.HD
-NFS Requests and Replies
+.SS NFS Requests and Replies
.LP
Sun NFS (Network File System) requests and replies are printed as:
.RS
@@ -1795,8 +1792,7 @@ Instead,
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
+.SS AFS Requests and Replies
.LP
Transarc AFS (Andrew File System) requests and replies are printed
as:
@@ -1860,8 +1856,7 @@ If a reply does not closely
follow the
corresponding request, it might not be parsable.
-.HD
-KIP AppleTalk (DDP in UDP)
+.SS 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
@@ -1925,7 +1920,8 @@ 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:
+.SS NBP Packets
+NBP packets are formatted like the following examples:
.RS
.nf
.sp .5
@@ -1945,7 +1941,8 @@ 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:
+.SS ATP Packets
+ATP packet formatting is demonstrated by the following example:
.RS
.nf
.sp .5
@@ -2044,24 +2041,6 @@ in the tcpdump source tree root.
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 userspace, 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