Commit | Line | Data |
---|---|---|
c2714ef5 | 1 | .\" @(#) $Header: /a/cvs/386BSD/src/contrib/tcpdump/tcpdump/tcpdump.1,v 1.2 1994/04/24 01:19:05 jkh Exp $ (LBL) |
15637ed4 RG |
2 | .\" |
3 | .\" Copyright (c) 1988, 1989, 1990, 1991, 1992 | |
4 | .\" The Regents of the University of California. | |
5 | .\" All rights reserved. | |
6 | .\" | |
7 | .\" Redistribution and use in source and binary forms, with or without | |
8 | .\" modification, are permitted provided that: (1) source code distributions | |
9 | .\" retain the above copyright notice and this paragraph in its entirety, (2) | |
10 | .\" distributions including binary code include the above copyright notice and | |
11 | .\" this paragraph in its entirety in the documentation or other materials | |
12 | .\" provided with the distribution, and (3) all advertising materials mentioning | |
13 | .\" features or use of this software display the following acknowledgement: | |
14 | .\" ``This product includes software developed by the University of California, | |
15 | .\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of | |
16 | .\" the University nor the names of its contributors may be used to endorse | |
17 | .\" or promote products derived from this software without specific prior | |
18 | .\" written permission. | |
19 | .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED | |
20 | .\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF | |
21 | .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. | |
22 | .\" | |
23 | .TH TCPDUMP 1 "4 Jan 1992" | |
24 | .SH NAME | |
25 | tcpdump \- dump traffic on a network | |
26 | .SH SYNOPSIS | |
27 | .na | |
28 | .B tcpdump | |
29 | [ | |
30 | .B \-deflnNOpqStvx | |
31 | ] [ | |
32 | .B \-c | |
33 | .I count | |
34 | ] [ | |
35 | .B \-F | |
36 | .I file | |
37 | ] | |
38 | .br | |
39 | .ti +8 | |
40 | [ | |
41 | .B \-i | |
42 | .I interface | |
43 | ] [ | |
44 | .B \-r | |
45 | .I file | |
46 | ] | |
47 | [ | |
48 | .B \-s | |
49 | .I snaplen | |
50 | ] | |
51 | .br | |
52 | .ti +8 | |
53 | [ | |
54 | .B \-w | |
55 | .I file | |
56 | ] | |
57 | .I expression | |
58 | .br | |
59 | .ad | |
60 | .SH DESCRIPTION | |
61 | .LP | |
62 | \fITcpdump\fP prints out the headers of packets on a network interface | |
63 | that match the boolean \fIexpression\fP. | |
64 | .B Under SunOS: | |
65 | You must be root to invoke \fItcpdump\fP or it must be installed | |
66 | setuid to root. | |
67 | .B Under Ultrix: | |
68 | Any user can invoke \fItcpdump\fP once the super-user has enabled | |
69 | promiscuous-mode operation using | |
70 | .IR pfconfig (8). | |
71 | .B Under BSD: | |
72 | Access is controlled by the permissions on | |
73 | .I /dev/bpf0, | |
74 | etc. | |
75 | .SH OPTIONS | |
76 | .TP | |
77 | .B \-c | |
78 | Exit after receiving \fIcount\fP packets. | |
79 | .TP | |
80 | .B \-d | |
81 | Dump the compiled packet-matching code to standard output and stop. | |
82 | .TP | |
83 | .B \-e | |
84 | Print the link-level header on each dump line. | |
85 | .TP | |
86 | .B \-f | |
87 | Print `foreign' internet addresses numerically rather than symbolically | |
88 | (this option is intended to get around serious brain damage in | |
89 | Sun's yp server \(em usually it hangs forever translating non-local | |
90 | internet numbers). | |
91 | .TP | |
92 | .B \-F | |
93 | Use \fIfile\fP as input for the filter expression. | |
94 | An additional expression given on the command line is ignored. | |
95 | .TP | |
96 | .B \-i | |
97 | Listen on \fIinterface\fP. | |
98 | If unspecified, \fItcpdump\fP searches the system interface list for the | |
99 | lowest numbered, configured up interface (excluding loopback). | |
100 | Ties are broken by choosing the earliest match. | |
101 | .TP | |
102 | .B \-l | |
103 | Make stdout line buffered. Useful if you want to see the data | |
104 | while capturing it. E.g., | |
105 | .br | |
106 | ``tcpdump\ \ \-l\ \ |\ \ tee dat'' or | |
107 | ``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''. | |
108 | .TP | |
109 | .B \-n | |
110 | Don't convert addresses (i.e., host addresses, port numbers, etc.) to names. | |
111 | .TP | |
112 | .B \-N | |
113 | Don't print domain name qualification of host names. E.g., | |
114 | if you give this flag then \fItcpdump\fP will print ``nic'' | |
115 | instead of ``nic.ddn.mil''. | |
116 | .TP | |
117 | .B \-O | |
118 | Do not run the packet-matching code optimizer. This is useful only | |
119 | if you suspect a bug in the optimizer. | |
120 | .TP | |
121 | .B \-p | |
122 | \fIDon't\fP put the interface | |
123 | into promiscuous mode. Note that the interface might be in promiscuous | |
124 | for some other reason; hence, `-p' cannot be used as an abbreviation for | |
125 | `ether host {localhost} or broadcast'. | |
126 | .TP | |
127 | .B \-q | |
128 | Quick (quiet?) output. Print less protocol information so output | |
129 | lines are shorter. | |
130 | .TP | |
131 | .B \-r | |
132 | Read packets from \fIfile\fR (which was created with the -w option). | |
133 | Standard input is used if \fIfile\fR is ``-''. | |
134 | .TP | |
135 | .B \-s | |
136 | Snarf \fIsnaplen\fP bytes of data from each packet rather than the | |
137 | default of 68 (with NIT, the minimum is actually 96). | |
138 | 68 bytes is adequate for IP, ICMP, TCP | |
139 | and UDP but may truncate protocol information from name server and NFS | |
140 | packets (see below). Packets truncated because of a limited snapshot | |
141 | are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP | |
c2714ef5 | 142 | is the name of the protocol level at which the truncation has occurred. |
15637ed4 RG |
143 | Note that taking larger snapshots both increases |
144 | the amount of time it takes to process packets and, effectively, | |
145 | decreases the amount of packet buffering. This may cause packets to be | |
146 | lost. You should limit \fIsnaplen\fP to the smallest number that will | |
147 | capture the protocol information you're interested in. | |
148 | .TP | |
149 | .B \-S | |
150 | Print absolute, rather than relative, TCP sequence numbers. | |
151 | .TP | |
152 | .B \-t | |
153 | \fIDon't\fP print a timestamp on each dump line. | |
154 | .TP | |
155 | .B \-tt | |
156 | Print an unformatted timestamp on each dump line. | |
157 | .TP | |
158 | .B \-v | |
159 | (Slightly more) verbose output. For example, the time to live | |
160 | and type of service information in an IP packet is printed. | |
161 | .TP | |
162 | .B \-w | |
163 | Write the raw packets to \fIfile\fR rather than parsing and printing | |
164 | them out. They can later be printed with the \-r option. | |
165 | Standard output is used if \fIfile\fR is ``-''. | |
166 | .TP | |
167 | .B \-x | |
168 | Print each packet (minus its link level header) in hex. | |
169 | The smaller of the entire packet or | |
170 | .I snaplen | |
171 | bytes will be printed. | |
172 | .IP "\fI expression\fP" | |
173 | .RS | |
174 | selects which packets will be dumped. If no \fIexpression\fP | |
175 | is given, all packets on the net will be dumped. Otherwise, | |
176 | only packets for which \fIexpression\fP is `true' will be dumped. | |
177 | .LP | |
178 | The \fIexpression\fP consists of one or more | |
179 | .I primitives. | |
180 | Primitives usually consist of an | |
181 | .I id | |
182 | (name or number) preceded by one or more qualifiers. There are three | |
183 | different kinds of qualifier: | |
184 | .IP \fItype\fP | |
185 | qualifiers say what kind of thing the id name or number refers to. | |
186 | Possible types are | |
187 | .BR host , | |
188 | .B net | |
189 | and | |
190 | .BR port . | |
191 | E.g., `host foo', `net 128.3', `port 20'. If there is no type | |
192 | qualifier, | |
193 | .B host | |
194 | is assumed. | |
195 | .IP \fIdir\fP | |
196 | qualifiers specify a particular tranfer direction to and/or from | |
197 | .I id. | |
198 | Possible directions are | |
199 | .BR src , | |
200 | .BR dst , | |
201 | .B "src or dst" | |
202 | and | |
203 | .BR "src and dst" . | |
204 | E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'. If | |
205 | there is no dir qualifier, | |
206 | .B "src or dst" | |
207 | is assumed. | |
208 | .IP \fIproto\fP | |
209 | qualifiers restrict the match to a particular protocol. Possible | |
210 | protos are: | |
211 | .BR ether , | |
212 | .BR ip , | |
213 | .BR arp , | |
214 | .BR rarp , | |
215 | .B tcp | |
216 | and | |
217 | .BR udp . | |
218 | E.g., `ether src foo', `arp net 128.3', `tcp port 21'. If there is | |
219 | no proto qualifier, all protocols consistent with the type are | |
220 | assumed. E.g., `src foo' means `(ip or arp or rarp) src foo' | |
221 | (except the latter is not legal syntax), `net bar' means `(ip or | |
222 | arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'. | |
223 | .LP | |
224 | In addition to the above, there are some special `primitive' keywords | |
225 | that don't follow the pattern: | |
226 | .BR gateway , | |
227 | .BR broadcast , | |
228 | .BR less , | |
229 | .B greater | |
230 | and arithmetic expressions. All of these are described below. | |
231 | .LP | |
232 | More complex filter expressions are built up by using the words | |
233 | .BR and , | |
234 | .B or | |
235 | and | |
236 | .B not | |
237 | to combine primitives. E.g., `host foo and not port ftp and not port ftp-data'. | |
238 | To save typing, identical qualifier lists can be omitted. E.g., | |
239 | `tcp dst port ftp or ftp-data or domain' is exactly the same as | |
240 | `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'. | |
241 | .LP | |
242 | Allowable primitives are: | |
243 | .IP "\fBdst host \fIhost\fR" | |
244 | True if the IP destination field of the packet is \fIhost\fP, | |
245 | which may be either an address or a name. | |
246 | .IP "\fBsrc host \fIhost\fR" | |
247 | True if the IP source field of the packet is \fIhost\fP. | |
248 | .IP "\fBhost \fIhost\fP | |
249 | True if either the IP source or destination of the packet is \fIhost\fP. | |
250 | Any of the above host expressions can be prepended with the keywords, | |
251 | \fBip\fP, \fBarp\fP, or \fBrarp\fP as in: | |
252 | .in +.5i | |
253 | .nf | |
254 | \fBip host \fIhost\fR | |
255 | .fi | |
256 | .in -.5i | |
257 | which is equivalent to: | |
258 | .in +.5i | |
259 | .nf | |
260 | \fBether proto \fI\\ip\fB and host \fIhost\fR | |
261 | .fi | |
262 | .in -.5i | |
263 | If \fIhost\fR is a name with multiple IP addresses, each address will | |
264 | be checked for a match. | |
265 | .IP "\fBether dst \fIehost\fP | |
266 | True if the ethernet destination address is \fIehost\fP. \fIEhost\fP | |
267 | may be either a name from /etc/ethers or a number (see | |
268 | .IR ethers (3N) | |
269 | for numeric format). | |
270 | .IP "\fBether src \fIehost\fP | |
271 | True if the ethernet source address is \fIehost\fP. | |
272 | .IP "\fBether host \fIehost\fP | |
273 | True if either the ethernet source or destination address is \fIehost\fP. | |
274 | .IP "\fBgateway\fP \fIhost\fP | |
275 | True if the packet used \fIhost\fP as a gateway. I.e., the ethernet | |
276 | source or destination address was \fIhost\fP but neither the IP source | |
277 | nor the IP destination was \fIhost\fP. \fIHost\fP must be a name and | |
278 | must be found in both /etc/hosts and /etc/ethers. (An equivalent | |
279 | expression is | |
280 | .in +.5i | |
281 | .nf | |
282 | \fBether host \fIehost \fBand not host \fIhost\fR | |
283 | .fi | |
284 | .in -.5i | |
285 | which can be used with either names or numbers for \fIhost / ehost\fP.) | |
286 | .IP "\fBdst net \fInet\fR" | |
287 | True if the IP destination address of the packet has a network | |
288 | number of \fInet\fP, which may be either an address or a name. | |
289 | .IP "\fBsrc net \fInet\fR" | |
290 | True if the IP source address of the packet has a network | |
291 | number of \fInet\fP. | |
292 | .IP "\fBnet \fInet\fR" | |
293 | True if either the IP source or destination address of the packet has a network | |
294 | number of \fInet\fP. | |
295 | .IP "\fBdst port \fIport\fR" | |
296 | True if the packet is ip/tcp or ip/udp and has a | |
297 | destination port value of \fIport\fP. | |
298 | The \fIport\fP can be a number or a name used in /etc/services (see | |
299 | .IR tcp (4P) | |
300 | and | |
301 | .IR udp (4P)). | |
302 | If a name is used, both the port | |
303 | number and protocol are checked. If a number or ambiguous name is used, | |
304 | only the port number is checked (e.g., \fBdst port 513\fR will print both | |
305 | tcp/login traffic and udp/who traffic, and \fBport domain\fR will print | |
306 | both tcp/domain and udp/domain traffic). | |
307 | .IP "\fBsrc port \fIport\fR" | |
308 | True if the packet has a source port value of \fIport\fP. | |
309 | .IP "\fBport \fIport\fR" | |
310 | True if either the source or destination port of the packet is \fIport\fP. | |
311 | Any of the above port expressions can be prepended with the keywords, | |
312 | \fBtcp\fP or \fBudp\fP, as in: | |
313 | .in +.5i | |
314 | .nf | |
315 | \fBtcp src port \fIport\fR | |
316 | .fi | |
317 | .in -.5i | |
318 | which matches only tcp packets. | |
319 | .IP "\fBless \fIlength\fR" | |
320 | True if the packet has a length less than or equal to \fIlength\fP. | |
321 | This is equivalent to: | |
322 | .in +.5i | |
323 | .nf | |
324 | \fBlen <= \fIlength\fP. | |
325 | .fi | |
326 | .in -.5i | |
327 | .IP "\fBgreater \fIlength\fR" | |
328 | True if the packet has a length greater than or equal to \fIlength\fP. | |
329 | This is equivalent to: | |
330 | .in +.5i | |
331 | .nf | |
332 | \fBlen >= \fIlength\fP. | |
333 | .fi | |
334 | .in -.5i | |
335 | .IP "\fBip proto \fIprotocol\fR" | |
336 | True if the packet is an ip packet (see | |
337 | .IR ip (4P)) | |
338 | of protocol type \fIprotocol\fP. | |
339 | \fIProtocol\fP can be a number or one of the names | |
340 | \fIicmp\fP, \fIudp\fP, \fInd\fP, or \fItcp\fP. | |
341 | Note that the identifiers \fItcp\fP, \fIudp\fP, and \fIicmp\fP are also | |
342 | keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell. | |
343 | .IP "\fBether broadcast\fR" | |
344 | True if the packet is an ethernet broadcast packet. The \fIether\fP | |
345 | keyword is optional. | |
346 | .IP "\fBip broadcast\fR" | |
347 | True if the packet is an IP broadcast packet. It checks for both | |
348 | the all-zeroes and all-ones broadcast conventions, and looks up | |
349 | the local subnet mask. | |
350 | .IP "\fBether multicast\fR" | |
351 | True if the packet is an ethernet multicast packet. The \fIether\fP | |
352 | keyword is optional. | |
353 | This is shorthand for `\fBether[0] & 1 != 0\fP'. | |
354 | .IP "\fBip multicast\fR" | |
355 | True if the packet is an IP multicast packet. | |
356 | .IP "\fBether proto \fIprotocol\fR" | |
357 | True if the packet is of ether type \fIprotocol\fR. | |
358 | \fIProtocol\fP can be a number or a name like | |
359 | \fIip\fP, \fIarp\fP, or \fIrarp\fP. | |
360 | Note these identifiers are also keywords | |
361 | and must be escaped via backslash (\\). | |
362 | .IP "\fBip\fR, \fBarp\fR, \fBrarp\fR" | |
363 | Abbreviations for: | |
364 | .in +.5i | |
365 | .nf | |
366 | \fBether proto \fIp\fR | |
367 | .fi | |
368 | .in -.5i | |
369 | where \fIp\fR is one of the above protocols. | |
370 | .IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR" | |
371 | Abbreviations for: | |
372 | .in +.5i | |
373 | .nf | |
374 | \fBip proto \fIp\fR | |
375 | .fi | |
376 | .in -.5i | |
377 | where \fIp\fR is one of the above protocols. | |
378 | .IP "\fIexpr relop expr\fR" | |
379 | True if the relation holds, where \fIrelop\fR is one of >, <, >=, <=, =, !=, | |
380 | and \fIexpr\fR is an arithmetic expression composed of integer constants | |
381 | (expressed in standard C syntax), the normal binary operators | |
382 | [+, -, *, /, &, |], a length operator, and special packet data accessors. | |
383 | To access | |
384 | data inside the packet, use the following syntax: | |
385 | .in +.5i | |
386 | .nf | |
387 | \fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR | |
388 | .fi | |
389 | .in -.5i | |
390 | \fIProto\fR is one of \fBether, ip, arp, rarp, tcp, udp, \fRor \fBicmp\fR, and | |
391 | indicates the protocol layer for the index operation. | |
392 | The byte offset, relative to the indicated protocol layer, is | |
393 | given by \fIexpr\fR. | |
394 | \fISize\fR is optional and indicates the number of bytes in the | |
395 | field of interest; it can be either one, two, or four, and defaults to one. | |
396 | The length operator, indicated by the keyword \fBlen\fP, gives the | |
397 | length of the packet. | |
398 | ||
399 | For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic. | |
400 | The expression `\fBip[0] & 0xf != 5\fP' | |
401 | catches all IP packets with options. The expression | |
402 | `\fBip[2:2] & 0x1fff = 0\fP' | |
403 | catches only unfragmented datagrams and frag zero of fragmented datagrams. | |
404 | This check is implicitly applied to the \fBtcp\fP and \fBudp\fP | |
405 | index opertations. | |
406 | For instance, \fBtcp[0]\fP always means the first | |
407 | byte of the TCP \fIheader\fP, and never means the first byte of an | |
408 | intervening fragment. | |
409 | .LP | |
410 | Primitives may be combined using: | |
411 | .IP | |
412 | A parenthesized group of primitives and operators | |
413 | (parentheses are special to the Shell and must be escaped). | |
414 | .IP | |
415 | Negation (`\fB!\fP' or `\fBnot\fP'). | |
416 | .IP | |
417 | Concatenation (`\fBand\fP'). | |
418 | .IP | |
419 | Alternation (`\fBor\fP'). | |
420 | .LP | |
421 | Negation has highest precedence. | |
422 | Alternation and concatenation have equal precedence and associate | |
423 | left to right. Note that explicit \fBand\fR tokens, not juxtaposition, | |
424 | are now required for concatenation. | |
425 | .LP | |
426 | If an identifier is given without a keyword, the most recent keyword | |
427 | is assumed. | |
428 | For example, | |
429 | .in +.5i | |
430 | .nf | |
431 | \fBnot host vs and ace\fR | |
432 | .fi | |
433 | .in -.5i | |
434 | is short for | |
435 | .in +.5i | |
436 | .nf | |
437 | \fBnot host vs and host ace\fR | |
438 | .fi | |
439 | .in -.5i | |
440 | which should not be confused with | |
441 | .in +.5i | |
442 | .nf | |
443 | \fBnot ( host vs or ace )\fR | |
444 | .fi | |
445 | .in -.5i | |
446 | .LP | |
447 | Expression arguments can be passed to tcpdump as either a single argument | |
448 | or as multiple arguments, whichever is more convenient. | |
449 | Generally, if the expression contains Shell metacharacters, it is | |
450 | easier to pass it as a single, quoted argument. | |
451 | Multiple arguments are concatenated with spaces before being parsed. | |
452 | .SH EXAMPLES | |
453 | .LP | |
454 | To print all packets arriving at or departing from \fIsundown\fP: | |
455 | .RS | |
456 | .nf | |
457 | \fBtcpdump host sundown\fP | |
458 | .fi | |
459 | .RE | |
460 | .LP | |
461 | To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR: | |
462 | .RS | |
463 | .nf | |
464 | \fBtcpdump host helios and \\( hot or ace \\)\fP | |
465 | .fi | |
466 | .RE | |
467 | .LP | |
468 | To print all IP packets between \fIace\fR and any host except \fIhelios\fR: | |
469 | .RS | |
470 | .nf | |
471 | \fBtcpdump ip host ace and not helios\fP | |
472 | .fi | |
473 | .RE | |
474 | .LP | |
475 | To print all traffic between local hosts and hosts at Berkeley: | |
476 | .RS | |
477 | .nf | |
478 | .B | |
479 | tcpdump net ucb-ether | |
480 | .fi | |
481 | .RE | |
482 | .LP | |
483 | To print all ftp traffic through internet gateway \fIsnup\fP: | |
484 | (note that the expression is quoted to prevent the shell from | |
485 | (mis-)interpreting the parentheses): | |
486 | .RS | |
487 | .nf | |
488 | .B | |
489 | tcpdump 'gateway snup and (port ftp or ftp-data)' | |
490 | .fi | |
491 | .RE | |
492 | .LP | |
493 | To print traffic neither sourced from nor destined for local hosts | |
494 | (if you gateway to one other net, this stuff should never make it | |
495 | onto your local net). | |
496 | .RS | |
497 | .nf | |
498 | .B | |
499 | tcpdump ip and not net \fIlocalnet\fP | |
500 | .fi | |
501 | .RE | |
502 | .LP | |
503 | To print the start and end packets (the SYN and FIN packets) of each | |
504 | TCP conversation that involves a non-local host. | |
505 | .RS | |
506 | .nf | |
507 | .B | |
508 | tcpdump 'tcp[13] & 3 != 0 and not src and dst net \fIlocalnet\fP' | |
509 | .fi | |
510 | .RE | |
511 | .LP | |
512 | To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP: | |
513 | .RS | |
514 | .nf | |
515 | .B | |
516 | tcpdump 'gateway snup and ip[2:2] > 576' | |
517 | .fi | |
518 | .RE | |
519 | .LP | |
520 | To print IP broadcast or multicast packets that were | |
521 | .I not | |
522 | sent via ethernet broadcast or multicast: | |
523 | .RS | |
524 | .nf | |
525 | .B | |
526 | tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224' | |
527 | .fi | |
528 | .RE | |
529 | .LP | |
530 | To print all ICMP packets that are not echo requests/replies (i.e., not | |
531 | ping packets): | |
532 | .RS | |
533 | .nf | |
534 | .B | |
535 | tcpdump 'icmp[0] != 8 and icmp[0] != 0" | |
536 | .fi | |
537 | .RE | |
538 | .SH OUTPUT FORMAT | |
539 | .LP | |
540 | The output of \fItcpdump\fP is protocol dependent. The following | |
541 | gives a brief description and examples of most of the formats. | |
542 | .de HD | |
543 | .sp 1.5 | |
544 | .B | |
545 | .. | |
546 | .HD | |
547 | Link Level Headers | |
548 | .LP | |
549 | If the '-e' option is given, the link level header is printed out. | |
550 | On ethernets, the source and destination addresses, protocol, | |
551 | and packet length are printed. | |
552 | .LP | |
553 | \fI(N.B.: The following description assumes familiarity with | |
554 | the SLIP compression algorithm described in RFC-1144.)\fP | |
555 | .LP | |
556 | On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound), | |
557 | packet type, and compression information are printed out. | |
558 | The packet type is printed first. | |
559 | The three types are \fIip\fP, \fIutcp\fP, and \fIctcp\fP. | |
560 | No further link information is printed for \fIip\fR packets. | |
561 | For TCP packets, the connection identifier is printed following the type. | |
562 | If the packet is compressed, its encoded header is printed out. | |
563 | The special cases are printed out as | |
564 | \fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR is the amount by which | |
565 | the sequence number (or sequence number and ack) has changed. | |
566 | If it is not a special case, | |
567 | zero or more changes are printed. | |
568 | A change is indicated by U (urgent pointer), W (window), A (ack), | |
569 | S (sequence number), and I (packet ID), followed by a delta (+n or -n), | |
570 | or a new value (=n). | |
571 | Finally, the amount of data in the packet and compressed header length | |
572 | are printed. | |
573 | .LP | |
574 | For example, the following line shows an outbound compressed TCP packet, | |
575 | with an implicit connection identifier; the ack has changed by 6, | |
576 | the sequence number by 49, and the packet ID by 6; there are 3 bytes of | |
577 | data and 6 bytes of compressed header: | |
578 | .RS | |
579 | .nf | |
580 | \fBO ctcp * A+6 S+49 I+6 3 (6)\fP | |
581 | .fi | |
582 | .RE | |
583 | .HD | |
584 | ARP/RARP Packets | |
585 | .LP | |
586 | Arp/rarp output shows the type of request and its arguments. The | |
587 | format is intended to be self explanatory. | |
588 | Here is a short sample taken from the start of an `rlogin' from | |
589 | host \fIrtsg\fP to host \fIcsam\fP: | |
590 | .RS | |
591 | .nf | |
592 | .sp .5 | |
593 | \f(CWarp who-has csam tell rtsg | |
594 | arp reply csam is-at CSAM\fP | |
595 | .sp .5 | |
596 | .fi | |
597 | .RE | |
598 | The first line says that rtsg sent an arp packet asking | |
599 | for the ethernet address of internet host csam. Csam | |
600 | replies with its ethernet address (in this example, ethernet addresses | |
601 | are in caps and internet addresses in lower case). | |
602 | .LP | |
603 | This would look less redundant if we had done \fBtcpdump \-n\fP: | |
604 | .RS | |
605 | .nf | |
606 | .sp .5 | |
607 | \f(CWarp who-has 128.3.254.6 tell 128.3.254.68 | |
608 | arp reply 128.3.254.6 is-at 02:07:01:00:01:c4\fP | |
609 | .fi | |
610 | .RE | |
611 | .LP | |
612 | If we had done \fBtcpdump \-e\fP, the fact that the first packet is | |
613 | broadcast and the second is point-to-point would be visible: | |
614 | .RS | |
615 | .nf | |
616 | .sp .5 | |
617 | \f(CWRTSG Broadcast 0806 64: arp who-has csam tell rtsg | |
618 | CSAM RTSG 0806 64: arp reply csam is-at CSAM\fP | |
619 | .sp .5 | |
620 | .fi | |
621 | .RE | |
622 | For the first packet this says the ethernet source address is RTSG, the | |
623 | destination is the broadcast address, the type field | |
624 | contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes. | |
625 | .HD | |
626 | TCP Packets | |
627 | .LP | |
628 | \fI(N.B.:The following description assumes familiarity with | |
629 | the TCP protocol described in RFC-793. If you are not familiar | |
630 | with the protocol, neither this description nor tcpdump will | |
631 | be of much use to you.)\fP | |
632 | .LP | |
633 | The general format of a tcp protocol line is: | |
634 | .RS | |
635 | .nf | |
636 | .sp .5 | |
637 | \fIsrc > dst: flags data-seqno ack window urgent options\fP | |
638 | .sp .5 | |
639 | .fi | |
640 | .RE | |
641 | \fISrc\fP and \fIdst\fP are the source and destination IP | |
642 | addresses and ports. \fIFlags\fP are some combination of S (SYN), | |
643 | F (FIN), P (PUSH) or R (RST) or a single `.' (no flags). | |
644 | \fIData-seqno\fP describes the portion of sequence space covered | |
645 | by the data in this packet (see example below). | |
646 | \fIAck\fP is sequence number of the next data expected the other | |
647 | direction on this connection. | |
648 | \fIWindow\fP is the number of bytes of receive buffer space available | |
649 | the other direction on this connection. | |
650 | \fIUrg\fP indicates there is `urgent' data in the packet. | |
651 | \fIOptions\fP are tcp options enclosed in angle brackets (e.g., <mss 1024>). | |
652 | .LP | |
653 | \fISrc, dst\fP and \fIflags\fP are always present. The other fields | |
654 | depend on the contents of the packet's tcp protocol header and | |
655 | are output only if appropriate. | |
656 | .LP | |
657 | Here is the opening portion of an rlogin from host \fIrtsg\fP to | |
658 | host \fIcsam\fP. | |
659 | .RS | |
660 | .nf | |
661 | .sp .5 | |
662 | \s-2\f(CWrtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024> | |
663 | csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024> | |
664 | rtsg.1023 > csam.login: . ack 1 win 4096 | |
665 | rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096 | |
666 | csam.login > rtsg.1023: . ack 2 win 4096 | |
667 | rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096 | |
668 | csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077 | |
669 | csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1 | |
670 | csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fP\s+2 | |
671 | .sp .5 | |
672 | .fi | |
673 | .RE | |
674 | The first line says that tcp port 1023 on rtsg sent a packet | |
675 | to port \fIlogin\fP | |
676 | on csam. The \fBS\fP indicates that the \fISYN\fP flag was set. | |
677 | The packet sequence number was 768512 and it contained no data. | |
678 | (The notation is `first:last(nbytes)' which means `sequence | |
679 | numbers \fIfirst\fP | |
680 | up to but not including \fIlast\fP which is \fInbytes\fP bytes of user data'.) | |
681 | There was no piggy-backed ack, the available receive window was 4096 | |
682 | bytes and there was a max-segment-size option requesting an mss of | |
683 | 1024 bytes. | |
684 | .LP | |
685 | Csam replies with a similar packet except it includes a piggy-backed | |
686 | ack for rtsg's SYN. Rtsg then acks csam's SYN. The `.' means no | |
687 | flags were set. | |
688 | The packet contained no data so there is no data sequence number. | |
689 | Note that the ack sequence | |
690 | number is a small integer (1). The first time \fBtcpdump\fP sees a | |
691 | tcp `conversation', it prints the sequence number from the packet. | |
692 | On subsequent packets of the conversation, the difference between | |
693 | the current packet's sequence number and this initial sequence number | |
694 | is printed. This means that sequence numbers after the | |
695 | first can be interpreted | |
696 | as relative byte positions in the conversation's data stream (with the | |
697 | first data byte each direction being `1'). `-S' will override this | |
698 | feature, causing the original sequence numbers to be output. | |
699 | .LP | |
700 | On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20 | |
701 | in the rtsg \(-> csam side of the conversation). | |
702 | The PUSH flag is set in the packet. | |
703 | On the 7th line, csam says it's received data sent by rtsg up to | |
704 | but not including byte 21. Most of this data is apparently sitting in the | |
705 | socket buffer since csam's receive window has gotten 19 bytes smaller. | |
706 | Csam also sends one byte of data to rtsg in this packet. | |
707 | On the 8th and 9th lines, | |
708 | csam sends two bytes of urgent, pushed data to rtsg. | |
709 | .HD | |
710 | .B | |
711 | UDP Packets | |
712 | .LP | |
713 | UDP format is illustrated by this rwho packet: | |
714 | .RS | |
715 | .nf | |
716 | .sp .5 | |
717 | \f(CWactinide.who > broadcast.who: udp 84\fP | |
718 | .sp .5 | |
719 | .fi | |
720 | .RE | |
721 | This says that port \fIwho\fP on host \fIactinide\fP sent a udp | |
722 | datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet | |
723 | broadcast address. The packet contained 84 bytes of user data. | |
724 | .LP | |
725 | Some UDP services are recognized (from the source or destination | |
726 | port number) and the higher level protocol information printed. | |
727 | In particular, Domain Name service requests (RFC-1034/1035) and Sun | |
728 | RPC calls (RFC-1050) to NFS. | |
729 | .HD | |
730 | UDP Name Server Requests | |
731 | .LP | |
732 | \fI(N.B.:The following description assumes familiarity with | |
733 | the Domain Service protocol described in RFC-1035. If you are not familiar | |
734 | with the protocol, the following description will appear to be written | |
735 | in greek.)\fP | |
736 | .LP | |
737 | Name server requests are formatted as | |
738 | .RS | |
739 | .nf | |
740 | .sp .5 | |
741 | \fIsrc > dst: id op? flags qtype qclass name (len)\fP | |
742 | .sp .5 | |
743 | \f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fP | |
744 | .sp .5 | |
745 | .fi | |
746 | .RE | |
747 | Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an | |
748 | address record (qtype=A) associated with the name \fIucbvax.berkeley.edu.\fP | |
749 | The query id was `3'. The `+' indicates the \fIrecursion desired\fP flag | |
750 | was set. The query length was 37 bytes, not including the UDP and | |
751 | IP protocol headers. The query operation was the normal one, \fIQuery\fP, | |
752 | so the op field was omitted. If the op had been anything else, it would | |
753 | have been printed between the `3' and the `+'. | |
754 | Similarly, the qclass was the normal one, | |
755 | \fIC_IN\fP, and omitted. Any other qclass would have been printed | |
756 | immediately after the `A'. | |
757 | .LP | |
758 | A few anomalies are checked and may result in extra fields enclosed in | |
759 | square brackets: If a query contains an answer, name server or | |
760 | authority section, | |
761 | .IR ancount , | |
762 | .IR nscount , | |
763 | or | |
764 | .I arcount | |
765 | are printed as `[\fIn\fPa]', `[\fIn\fPn]' or `[\fIn\fPau]' where \fIn\fP | |
766 | is the appropriate count. | |
767 | If any of the response bits are set (AA, RA or rcode) or any of the | |
768 | `must be zero' bits are set in bytes two and three, `[b2&3=\fIx\fP]' | |
769 | is printed, where \fIx\fP is the hex value of header bytes two and three. | |
770 | .HD | |
771 | UDP Name Server Responses | |
772 | .LP | |
773 | Name server responses are formatted as | |
774 | .RS | |
775 | .nf | |
776 | .sp .5 | |
777 | \fIsrc > dst: id op rcode flags a/n/au type class data (len)\fP | |
778 | .sp .5 | |
779 | \f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) | |
780 | helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fP | |
781 | .sp .5 | |
782 | .fi | |
783 | .RE | |
784 | In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP | |
785 | with 3 answer records, 3 name server records and 7 authority records. | |
786 | The first answer record is type A (address) and its data is internet | |
787 | address 128.32.137.3. The total size of the response was 273 bytes, | |
788 | excluding UDP and IP headers. The op (Query) and response code | |
789 | (NoError) were omitted, as was the class (C_IN) of the A record. | |
790 | .LP | |
791 | In the second example, \fIhelios\fP responds to query 2 with a | |
792 | response code of non-existent domain (NXDomain) with no answers, | |
793 | one name server and no authority records. The `*' indicates that | |
794 | the \fIauthoritative answer\fP bit was set. Since there were no | |
795 | answers, no type, class or data were printed. | |
796 | .LP | |
797 | Other flag characters that might appear are `\-' (recursion available, | |
798 | RA, \fInot\fP set) and `|' (truncated message, TC, set). If the | |
799 | `question' section doesn't contain exactly one entry, `[\fIn\fPq]' | |
800 | is printed. | |
801 | .LP | |
802 | Note that name server requests and responses tend to be large and the | |
803 | default \fIsnaplen\fP of 96 bytes may not capture enough of the packet | |
804 | to print. Use the \fB\-s\fP flag to increase the snaplen if you | |
805 | need to seriously investigate name server traffic. `\fB\-s 128\fP' | |
806 | has worked well for me. | |
807 | ||
808 | .HD | |
809 | NFS Requests | |
810 | .LP | |
811 | Sun NFS (Network File System) requests and replies are printed as: | |
812 | .RS | |
813 | .nf | |
814 | .sp .5 | |
815 | \fIsrc.xid > dst.nfs: len op args\fP | |
816 | \fIsrc.nfs > dst.xid: reply stat len\fP | |
817 | .sp .5 | |
818 | \f(CWvs.e2766 > helios.nfs: 136 readdir fh 6.5197 8192 bytes @ 0 | |
819 | helios.nfs > vs.e2766: reply ok 384 | |
820 | vs.e2767 > helios.nfs: 136 lookup fh 6.5197 `RCS'\fP | |
821 | .sp .5 | |
822 | .fi | |
823 | .RE | |
824 | In the first line, host \fIvs\fP sends a transaction with id \fIe2766\fP | |
825 | to \fIhelios\fP (note that the number following the src host is a | |
826 | transaction id, \fInot\fP the source port). The request was 136 bytes, | |
827 | excluding the UDP and IP headers. The operation was a \fIreaddir\fP | |
828 | (read directory) on file handle (\fIfh\fP) 6.5197. 8192 bytes are | |
829 | read, starting at offset 0. \fIHelios\fP replies `ok' with 384 | |
830 | bytes of data. (The design of Sun's RPC protocol makes it difficult to | |
831 | interpret replies. I don't bother.) | |
832 | .LP | |
833 | In the third line, \fIvs\fP asks \fIhelios\fP to lookup the name | |
834 | `\fIRCS\fP' in directory file 6.5197. Note that the data printed | |
835 | depends on the operation type. The format is intended to be self | |
836 | explanatory (at least, to me) if read in conjunction with | |
837 | an NFS protocol spec. | |
838 | .LP | |
839 | Note that NFS requests are very large and the above won't be printed | |
840 | unless \fIsnaplen\fP is increased. I use `\fB\-s 192\fP' to watch | |
841 | NFS traffic. | |
842 | ||
843 | .HD | |
844 | KIP Appletalk (DDP in UDP) | |
845 | .LP | |
846 | Appletalk DDP packets encapsulated in UDP datagrams are de-encapsulated | |
847 | and dumped as DDP packets (i.e., all the UDP header information is | |
848 | discarded). The file | |
849 | .I /etc/atalk.names | |
850 | is used to translate appletalk net and node numbers to names. | |
851 | Lines in this file have the form | |
852 | .RS | |
853 | .nf | |
854 | .sp .5 | |
855 | \fInumber name\fP | |
856 | ||
857 | \f(CW1.254 ether | |
858 | 16.1 icsd-net | |
859 | 1.254.110 ace\fP | |
860 | .sp .5 | |
861 | .fi | |
862 | .RE | |
863 | The first two lines give the names of appletalk networks. The third | |
864 | line gives the name of a particular host (a host is distinguished | |
865 | from a net by the 3rd octet in the number \- | |
866 | a net number \fImust\fP have two octets and a host number \fImust\fP | |
867 | have three octets.) The number and name should be separated by | |
868 | whitespace (blanks or tabs). | |
869 | The | |
870 | .I /etc/atalk.names | |
871 | file may contain blank lines or comment lines (lines starting with | |
872 | a `#'). | |
873 | .LP | |
874 | Appletalk addresses are printed in the form | |
875 | .RS | |
876 | .nf | |
877 | .sp .5 | |
878 | \fInet.host.port\fP | |
879 | ||
880 | \f(CW144.1.209.2 > icsd-net.112.220 | |
881 | office.2 > icsd-net.112.220 | |
882 | jssmag.149.235 > icsd-net.2\fP | |
883 | .sp .5 | |
884 | .fi | |
885 | .RE | |
886 | (If the | |
887 | .I /etc/atalk.names | |
888 | doesn't exist or doesn't contain an entry for some appletalk | |
889 | host/net number, addresses are printed in numeric form.) | |
890 | In the first example, NBP (DDP port 2) on net 144.1 node 209 | |
891 | is sending to whatever is listening on port 220 of net icsd node 112. | |
892 | The second line is the same except the full name of the source node | |
893 | is known (`office'). The third line is a send from port 235 on | |
894 | net jssmag node 149 to broadcast on the icsd-net NBP port (note that | |
895 | the broadcast address (255) is indicated by a net name with no host | |
896 | number \- for this reason it's a good idea to keep node names and | |
897 | net names distinct in /etc/atalk.names). | |
898 | .LP | |
899 | NBP (name binding protocol) and ATP (Appletalk transaction protocol) | |
900 | packets have their contents interpreted. Other protocols just dump | |
901 | the protocol name (or number if no name is registered for the | |
902 | protocol) and packet size. | |
903 | ||
904 | \fBNBP packets\fP are formatted like the following examples: | |
905 | .RS | |
906 | .nf | |
907 | .sp .5 | |
908 | \s-2\f(CWicsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*" | |
909 | jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250 | |
910 | techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fP\s+2 | |
911 | .sp .5 | |
912 | .fi | |
913 | .RE | |
914 | The first line is a name lookup request for laserwriters sent by net icsd host | |
915 | 112 and broadcast on net jssmag. The nbp id for the lookup is 190. | |
916 | The second line shows a reply for this request (note that it has the | |
917 | same id) from host jssmag.209 saying that it has a laserwriter | |
918 | resource named "RM1140" registered on port 250. The third line is | |
919 | another reply to the same request saying host techpit has laserwriter | |
920 | "techpit" registered on port 186. | |
921 | ||
922 | \fBATP packet\fP formatting is demonstrated by the following example: | |
923 | .RS | |
924 | .nf | |
925 | .sp .5 | |
926 | \s-2\f(CWjssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001 | |
927 | helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000 | |
928 | helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000 | |
929 | helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000 | |
930 | helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 | |
931 | helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000 | |
932 | helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 | |
933 | helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000 | |
934 | helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000 | |
935 | jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001 | |
936 | helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 | |
937 | helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 | |
938 | jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001 | |
939 | jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fP\s+2 | |
940 | .sp .5 | |
941 | .fi | |
942 | .RE | |
943 | Jssmag.209 initiates transaction id 12266 with host helios by requesting | |
944 | up to 8 packets (the `<0-7>'). The hex number at the end of the line | |
945 | is the value of the `userdata' field in the request. | |
946 | .LP | |
947 | Helios responds with 8 512-byte packets. The `:digit' following the | |
948 | transaction id gives the packet sequence number in the transaction | |
949 | and the number in parens is the amount of data in the packet, | |
950 | excluding the atp header. The `*' on packet 7 indicates that the | |
951 | EOM bit was set. | |
952 | .LP | |
953 | Jssmag.209 then requests that packets 3 & 5 be retransmitted. Helios | |
954 | resends them then jssmag.209 releases the transaction. Finally, | |
955 | jssmag.209 initiates the next request. The `*' on the request | |
956 | indicates that XO (`exactly once') was \fInot\fP set. | |
957 | ||
958 | .HD | |
959 | IP Fragmentation | |
960 | .LP | |
961 | Fragmented Internet datagrams are printed as | |
962 | .RS | |
963 | .nf | |
964 | .sp .5 | |
965 | \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR | |
966 | \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR | |
967 | .sp .5 | |
968 | .fi | |
969 | .RE | |
970 | (The first form indicates there are more fragments. The second | |
971 | indicates this is the last fragment.) | |
972 | .LP | |
973 | \fIId\fP is the fragment id. \fISize\fP is the fragment | |
974 | size (in bytes) excluding the IP header. \fIOffset\fP is this | |
975 | fragment's offset (in bytes) in the original datagram. | |
976 | .LP | |
977 | The fragment information is output for each fragment. The first | |
978 | fragment contains the higher level protocol header and the frag | |
979 | info is printed after the protocol info. Fragments | |
980 | after the first contain no higher level protocol header and the | |
981 | frag info is printed after the source and destination addresses. | |
982 | For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa | |
983 | over a CSNET connection that doesn't appear to handle 576 byte datagrams: | |
984 | .RS | |
985 | .nf | |
986 | .sp .5 | |
987 | \s-2\f(CWarizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+) | |
988 | arizona > rtsg: (frag 595a:204@328) | |
989 | rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560\fP\s+2 | |
990 | .sp .5 | |
991 | .fi | |
992 | .RE | |
993 | There are a couple of things to note here: First, addresses in the | |
994 | 2nd line don't include port numbers. This is because the TCP | |
995 | protocol information is all in the first fragment and we have no idea | |
996 | what the port or sequence numbers are when we print the later fragments. | |
997 | Second, the tcp sequence information in the first line is printed as if there | |
998 | were 308 bytes of user data when, in fact, there are 512 bytes (308 in | |
999 | the first frag and 204 in the second). If you are looking for holes | |
1000 | in the sequence space or trying to match up acks | |
1001 | with packets, this can fool you. | |
1002 | .LP | |
1003 | A packet with the IP \fIdon't fragment\fP flag is marked with a | |
1004 | trailing \fB(DF)\fP. | |
1005 | .HD | |
1006 | Timestamps | |
1007 | .LP | |
1008 | By default, all output lines are preceded by a timestamp. The timestamp | |
1009 | is the current clock time in the form | |
1010 | .RS | |
1011 | .nf | |
1012 | \fIhh:mm:ss.frac\fP | |
1013 | .fi | |
1014 | .RE | |
1015 | and is as accurate as the kernel's clock (e.g., \(+-10ms on a Sun-3). | |
1016 | The timestamp reflects the time the kernel first saw the packet. No attempt | |
1017 | is made to account for the time lag between when the | |
1018 | ethernet interface removed the packet from the wire and when the kernel | |
1019 | serviced the `new packet' interrupt (of course, | |
1020 | with Sun's lousy clock resolution this time lag is negligible.) | |
1021 | .SH "SEE ALSO" | |
1022 | traffic(1C), nit(4P), bpf(4) | |
1023 | .SH AUTHORS | |
1024 | Van Jacobson (van@helios.ee.lbl.gov), | |
1025 | Craig Leres (leres@helios.ee.lbl.gov) and | |
1026 | Steven McCanne (mccanne@helios.ee.lbl.gov), all of | |
1027 | Lawrence Berkeley Laboratory, University of California, Berkeley, CA. | |
1028 | .SH BUGS | |
1029 | The clock resolution on most Suns is pathetic (20ms). | |
1030 | If you want to use the timestamp to generate some of the important | |
1031 | performance distributions (like packet interarrival time) it's best | |
1032 | to watch something that generates packets slowly (like an Arpanet | |
1033 | gateway or a MicroVax running VMS). | |
1034 | .LP | |
1035 | NIT doesn't let you watch your own outbound traffic, BPF will. | |
1036 | We recommend that you use the latter. | |
1037 | .LP | |
1038 | \fItcpdump\fP for Ultrix requires Ultrix version 4.0 or later; the kernel | |
1039 | has to have been built with the \fIpacketfilter\fP pseudo-device driver | |
1040 | (see | |
1041 | .IR packetfilter (4)). | |
1042 | As of this writing, Ultrix does not let you | |
1043 | watch either your own outbound or inbound traffic. | |
1044 | .LP | |
1045 | Under SunOS 4.1, the packet capture code (or Streams NIT) is not what | |
1046 | you'd call efficient. Don't plan on doing much with your Sun while | |
1047 | you're monitoring a busy network. | |
1048 | .LP | |
1049 | On Sun systems prior to release 3.2, NIT is very buggy. | |
1050 | If run on an old system, tcpdump may crash the machine. | |
1051 | .LP | |
1052 | Some attempt should be made to reassemble IP fragments or, at least | |
1053 | to compute the right length for the higher level protocol. | |
1054 | .LP | |
1055 | Name server inverse queries are not dumped correctly: The (empty) | |
1056 | question section is printed rather than real query in the answer | |
1057 | section. Some believe that inverse queries are themselves a bug and | |
1058 | prefer to fix the program generating them rather than tcpdump. | |
1059 | .LP | |
1060 | Apple Ethertalk DDP packets could be dumped as easily as KIP DDP | |
1061 | packets but aren't. | |
1062 | Even if we were inclined to do anything to promote the use of | |
1063 | Ethertalk (we aren't), LBL doesn't allow Ethertalk on any of its | |
1064 | networks so we'd would have no way of testing this code. | |
1065 | .LP | |
1066 | A packet trace that crosses a daylight savings time change will give | |
1067 | skewed time stamps (the time change is ignored). |