283 lines
8.5 KiB
Plaintext
283 lines
8.5 KiB
Plaintext
--- tcpdump.1.orig Mon Jun 30 16:32:09 1997
|
|
+++ tcpdump.1 Wed Jan 6 13:23:11 1999
|
|
@@ -20,12 +20,12 @@
|
|
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
|
|
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
|
|
.\"
|
|
-.TH TCPDUMP 1 "30 June 1997"
|
|
+.TH SMBTCPDUMP 1 "30 June 1997"
|
|
.SH NAME
|
|
-tcpdump \- dump traffic on a network
|
|
+smbtcpdump \- dump traffic on a network (supports SMB related protocols)
|
|
.SH SYNOPSIS
|
|
.na
|
|
-.B tcpdump
|
|
+.B smbtcpdump
|
|
[
|
|
.B \-adeflnNOpqStvx
|
|
] [
|
|
@@ -65,12 +65,20 @@
|
|
.ad
|
|
.SH DESCRIPTION
|
|
.LP
|
|
-\fITcpdump\fP prints out the headers of packets on a network interface
|
|
-that match the boolean \fIexpression\fP.
|
|
+\fIsmbTcpdump\fP prints out the headers of packets on a network interface
|
|
+that match the boolean \fIexpression\fP. The easiest way to capture
|
|
+SMB related traffic is to envoke
|
|
+.I smbtcpdump
|
|
+as:
|
|
+.in +.5i
|
|
+.nf
|
|
+\fBsmbtcpdump -s 1500 'port 139 and host foo'\fR
|
|
+.fi
|
|
+.in -.5i
|
|
.LP
|
|
.B Under SunOS with nit or bpf:
|
|
To run
|
|
-.I tcpdump
|
|
+.I smbtcpdump
|
|
you must have read access to
|
|
.I /dev/nit
|
|
or
|
|
@@ -88,7 +96,7 @@
|
|
Once the super-user has enabled promiscuous-mode operation using
|
|
.IR pfconfig (8),
|
|
any user may run
|
|
-.BR tcpdump .
|
|
+.BR smbtcpdump .
|
|
.B Under BSD:
|
|
You must have read access to
|
|
.IR /dev/bpf* .
|
|
@@ -127,7 +135,7 @@
|
|
.TP
|
|
.B \-i
|
|
Listen on \fIinterface\fP.
|
|
-If unspecified, \fItcpdump\fP searches the system interface list for the
|
|
+If unspecified, \fIsmbtcpdump\fP searches the system interface list for the
|
|
lowest numbered, configured up interface (excluding loopback).
|
|
Ties are broken by choosing the earliest match.
|
|
.TP
|
|
@@ -135,15 +143,15 @@
|
|
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''.
|
|
+``smbtcpdump\ \ \-l\ \ |\ \ tee dat'' or
|
|
+``smbtcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''.
|
|
.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''
|
|
+if you give this flag then \fIsmbtcpdump\fP will print ``nic''
|
|
instead of ``nic.ddn.mil''.
|
|
.TP
|
|
.B \-O
|
|
@@ -467,7 +475,7 @@
|
|
.in -.5i
|
|
where \fIp\fR is one of the above protocols.
|
|
Note that
|
|
-\fItcpdump\fP does not currently know how to parse these protocols.
|
|
+\fIsmbtcpdump\fP does not currently know how to parse these protocols.
|
|
.IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
|
|
Abbreviations for:
|
|
.in +.5i
|
|
@@ -546,7 +554,7 @@
|
|
.fi
|
|
.in -.5i
|
|
.LP
|
|
-Expression arguments can be passed to tcpdump as either a single argument
|
|
+Expression arguments can be passed to smbtcpdump 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.
|
|
@@ -556,21 +564,21 @@
|
|
To print all packets arriving at or departing from \fIsundown\fP:
|
|
.RS
|
|
.nf
|
|
-\fBtcpdump host sundown\fP
|
|
+\fBsmbtcpdump 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
|
|
+\fBsmbtcpdump 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
|
|
+\fBsmbtcpdump ip host ace and not helios\fP
|
|
.fi
|
|
.RE
|
|
.LP
|
|
@@ -578,7 +586,7 @@
|
|
.RS
|
|
.nf
|
|
.B
|
|
-tcpdump net ucb-ether
|
|
+smbtcpdump net ucb-ether
|
|
.fi
|
|
.RE
|
|
.LP
|
|
@@ -588,7 +596,7 @@
|
|
.RS
|
|
.nf
|
|
.B
|
|
-tcpdump 'gateway snup and (port ftp or ftp-data)'
|
|
+smbtcpdump 'gateway snup and (port ftp or ftp-data)'
|
|
.fi
|
|
.RE
|
|
.LP
|
|
@@ -598,7 +606,7 @@
|
|
.RS
|
|
.nf
|
|
.B
|
|
-tcpdump ip and not net \fIlocalnet\fP
|
|
+smbtcpdump ip and not net \fIlocalnet\fP
|
|
.fi
|
|
.RE
|
|
.LP
|
|
@@ -607,7 +615,7 @@
|
|
.RS
|
|
.nf
|
|
.B
|
|
-tcpdump 'tcp[13] & 3 != 0 and not src and dst net \fIlocalnet\fP'
|
|
+smbtcpdump 'tcp[13] & 3 != 0 and not src and dst net \fIlocalnet\fP'
|
|
.fi
|
|
.RE
|
|
.LP
|
|
@@ -615,7 +623,7 @@
|
|
.RS
|
|
.nf
|
|
.B
|
|
-tcpdump 'gateway snup and ip[2:2] > 576'
|
|
+smbtcpdump 'gateway snup and ip[2:2] > 576'
|
|
.fi
|
|
.RE
|
|
.LP
|
|
@@ -625,7 +633,7 @@
|
|
.RS
|
|
.nf
|
|
.B
|
|
-tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
|
|
+smbtcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
|
|
.fi
|
|
.RE
|
|
.LP
|
|
@@ -634,12 +642,12 @@
|
|
.RS
|
|
.nf
|
|
.B
|
|
-tcpdump 'icmp[0] != 8 and icmp[0] != 0"
|
|
+smbtcpdump 'icmp[0] != 8 and icmp[0] != 0"
|
|
.fi
|
|
.RE
|
|
.SH OUTPUT FORMAT
|
|
.LP
|
|
-The output of \fItcpdump\fP is protocol dependent. The following
|
|
+The output of \fIsmbtcpdump\fP is protocol dependent. The following
|
|
gives a brief description and examples of most of the formats.
|
|
.de HD
|
|
.sp 1.5
|
|
@@ -652,7 +660,7 @@
|
|
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
|
|
+On FDDI networks, the '-e' option causes \fIsmbtcpdump\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
|
|
@@ -712,7 +720,7 @@
|
|
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 \fBtcpdump \-n\fP:
|
|
+This would look less redundant if we had done \fBsmbtcpdump \-n\fP:
|
|
.RS
|
|
.nf
|
|
.sp .5
|
|
@@ -721,7 +729,7 @@
|
|
.fi
|
|
.RE
|
|
.LP
|
|
-If we had done \fBtcpdump \-e\fP, the fact that the first packet is
|
|
+If we had done \fBsmbtcpdump \-e\fP, the fact that the first packet is
|
|
broadcast and the second is point-to-point would be visible:
|
|
.RS
|
|
.nf
|
|
@@ -739,7 +747,7 @@
|
|
.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 tcpdump will
|
|
+with the protocol, neither this description nor smbtcpdump will
|
|
be of much use to you.)\fP
|
|
.LP
|
|
The general format of a tcp protocol line is:
|
|
@@ -799,7 +807,7 @@
|
|
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 \fBtcpdump\fP sees a
|
|
+number is a small integer (1). The first time \fBsmbtcpdump\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
|
|
@@ -819,15 +827,15 @@
|
|
On the 8th and 9th lines,
|
|
csam sends two bytes of urgent, pushed data to rtsg.
|
|
.LP
|
|
-If the snapshot was small enough that \fBtcpdump\fP didn't capture
|
|
+If the snapshot was small enough that \fBsmbtcpdump\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), tcpdump reports
|
|
+that's either too small or beyond the end of the header), smbtcpdump 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, tcpdump reports it as ``[\fIbad hdr length\fP]''.
|
|
+options to actually be there, smbtcpdump reports it as ``[\fIbad hdr length\fP]''.
|
|
.HD
|
|
.B
|
|
UDP Packets
|
|
@@ -997,7 +1005,7 @@
|
|
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
|
|
+\fIsmbtcpdump\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
|
|
@@ -1178,7 +1186,7 @@
|
|
ethernet interface removed the packet from the wire and when the kernel
|
|
serviced the `new packet' interrupt.
|
|
.SH "SEE ALSO"
|
|
-traffic(1C), nit(4P), bpf(4), pcap(3)
|
|
+tcpdump(1), traffic(1C), nit(4P), bpf(4), pcap(3)
|
|
.SH AUTHORS
|
|
Van Jacobson,
|
|
Craig Leres and
|
|
@@ -1202,7 +1210,7 @@
|
|
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 tcpdump.
|
|
+prefer to fix the program generating them rather than smbtcpdump.
|
|
.LP
|
|
Apple Ethertalk DDP packets could be dumped as easily as KIP DDP
|
|
packets but aren't.
|