JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1 | .\" @(#) $Header: /tcpdump/master/tcpdump/tcpdump.1.in,v 1.2 2008-11-09 23:35:03 mcr Exp $ (LBL) |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 2 | .\" |
| 3 | .\" $NetBSD: tcpdump.8,v 1.9 2003/03/31 00:18:17 perry Exp $ |
| 4 | .\" |
| 5 | .\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997 |
| 6 | .\" The Regents of the University of California. All rights reserved. |
| 7 | .\" All rights reserved. |
| 8 | .\" |
| 9 | .\" Redistribution and use in source and binary forms, with or without |
| 10 | .\" modification, are permitted provided that: (1) source code distributions |
| 11 | .\" retain the above copyright notice and this paragraph in its entirety, (2) |
| 12 | .\" distributions including binary code include the above copyright notice and |
| 13 | .\" this paragraph in its entirety in the documentation or other materials |
| 14 | .\" provided with the distribution, and (3) all advertising materials mentioning |
| 15 | .\" features or use of this software display the following acknowledgement: |
| 16 | .\" ``This product includes software developed by the University of California, |
| 17 | .\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of |
| 18 | .\" the University nor the names of its contributors may be used to endorse |
| 19 | .\" or promote products derived from this software without specific prior |
| 20 | .\" written permission. |
| 21 | .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED |
| 22 | .\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF |
| 23 | .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. |
| 24 | .\" |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 25 | .TH TCPDUMP 1 "3 February 2014" |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 26 | .SH NAME |
| 27 | tcpdump \- dump traffic on a network |
| 28 | .SH SYNOPSIS |
| 29 | .na |
| 30 | .B tcpdump |
| 31 | [ |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 32 | .B \-AbdDefhHIJKlLnNOpqRStuUvxX |
| 33 | ] [ |
| 34 | .B \-B |
| 35 | .I buffer_size |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 36 | ] [ |
| 37 | .B \-c |
| 38 | .I count |
| 39 | ] |
| 40 | .br |
| 41 | .ti +8 |
| 42 | [ |
| 43 | .B \-C |
| 44 | .I file_size |
| 45 | ] [ |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 46 | .B \-G |
| 47 | .I rotate_seconds |
| 48 | ] [ |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 49 | .B \-F |
| 50 | .I file |
| 51 | ] |
| 52 | .br |
| 53 | .ti +8 |
| 54 | [ |
| 55 | .B \-i |
| 56 | .I interface |
| 57 | ] |
| 58 | [ |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 59 | .B \-j |
| 60 | .I tstamp_type |
| 61 | ] |
| 62 | [ |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 63 | .B \-m |
| 64 | .I module |
| 65 | ] |
| 66 | [ |
| 67 | .B \-M |
| 68 | .I secret |
| 69 | ] |
| 70 | .br |
| 71 | .ti +8 |
| 72 | [ |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 73 | .B \-Q |
| 74 | .I in|out|inout |
| 75 | ] |
| 76 | .ti +8 |
| 77 | [ |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 78 | .B \-r |
| 79 | .I file |
| 80 | ] |
| 81 | [ |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 82 | .B \-V |
| 83 | .I file |
| 84 | ] |
| 85 | [ |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 86 | .B \-s |
| 87 | .I snaplen |
| 88 | ] |
| 89 | [ |
| 90 | .B \-T |
| 91 | .I type |
| 92 | ] |
| 93 | [ |
| 94 | .B \-w |
| 95 | .I file |
| 96 | ] |
| 97 | .br |
| 98 | .ti +8 |
| 99 | [ |
| 100 | .B \-W |
| 101 | .I filecount |
| 102 | ] |
| 103 | .br |
| 104 | .ti +8 |
| 105 | [ |
| 106 | .B \-E |
| 107 | .I spi@ipaddr algo:secret,... |
| 108 | ] |
| 109 | .br |
| 110 | .ti +8 |
| 111 | [ |
| 112 | .B \-y |
| 113 | .I datalinktype |
| 114 | ] |
| 115 | [ |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 116 | .B \-z |
| 117 | .I postrotate-command |
| 118 | ] |
| 119 | [ |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 120 | .B \-Z |
| 121 | .I user |
| 122 | ] |
| 123 | .ti +8 |
| 124 | [ |
| 125 | .I expression |
| 126 | ] |
| 127 | .br |
| 128 | .ad |
| 129 | .SH DESCRIPTION |
| 130 | .LP |
| 131 | \fITcpdump\fP prints out a description of the contents of packets on a |
| 132 | network interface that match the boolean \fIexpression\fP. It can also |
| 133 | be run with the |
| 134 | .B \-w |
| 135 | flag, which causes it to save the packet data to a file for later |
| 136 | analysis, and/or with the |
| 137 | .B \-r |
| 138 | flag, which causes it to read from a saved packet file rather than to |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 139 | read packets from a network interface. It can also be run with the |
| 140 | .B \-V |
| 141 | flag, which causes it to read a list of saved packet files. In all cases, |
| 142 | only packets that match |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 143 | .I expression |
| 144 | will be processed by |
| 145 | .IR tcpdump . |
| 146 | .LP |
| 147 | .I Tcpdump |
| 148 | will, if not run with the |
| 149 | .B \-c |
| 150 | flag, continue capturing packets until it is interrupted by a SIGINT |
| 151 | signal (generated, for example, by typing your interrupt character, |
| 152 | typically control-C) or a SIGTERM signal (typically generated with the |
| 153 | .BR kill (1) |
| 154 | command); if run with the |
| 155 | .B \-c |
| 156 | flag, it will capture packets until it is interrupted by a SIGINT or |
| 157 | SIGTERM signal or the specified number of packets have been processed. |
| 158 | .LP |
| 159 | When |
| 160 | .I tcpdump |
| 161 | finishes capturing packets, it will report counts of: |
| 162 | .IP |
| 163 | packets ``captured'' (this is the number of packets that |
| 164 | .I tcpdump |
| 165 | has received and processed); |
| 166 | .IP |
| 167 | packets ``received by filter'' (the meaning of this depends on the OS on |
| 168 | which you're running |
| 169 | .IR tcpdump , |
| 170 | and possibly on the way the OS was configured - if a filter was |
| 171 | specified on the command line, on some OSes it counts packets regardless |
| 172 | of whether they were matched by the filter expression and, even if they |
| 173 | were matched by the filter expression, regardless of whether |
| 174 | .I tcpdump |
| 175 | has read and processed them yet, on other OSes it counts only packets that were |
| 176 | matched by the filter expression regardless of whether |
| 177 | .I tcpdump |
| 178 | has read and processed them yet, and on other OSes it counts only |
| 179 | packets that were matched by the filter expression and were processed by |
| 180 | .IR tcpdump ); |
| 181 | .IP |
| 182 | packets ``dropped by kernel'' (this is the number of packets that were |
| 183 | dropped, due to a lack of buffer space, by the packet capture mechanism |
| 184 | in the OS on which |
| 185 | .I tcpdump |
| 186 | is running, if the OS reports that information to applications; if not, |
| 187 | it will be reported as 0). |
| 188 | .LP |
| 189 | On platforms that support the SIGINFO signal, such as most BSDs |
| 190 | (including Mac OS X) and Digital/Tru64 UNIX, it will report those counts |
| 191 | when it receives a SIGINFO signal (generated, for example, by typing |
| 192 | your ``status'' character, typically control-T, although on some |
| 193 | platforms, such as Mac OS X, the ``status'' character is not set by |
| 194 | default, so you must set it with |
| 195 | .BR stty (1) |
| 196 | in order to use it) and will continue capturing packets. |
| 197 | .LP |
| 198 | Reading packets from a network interface may require that you have |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 199 | special privileges; see the |
| 200 | .B pcap (3PCAP) |
| 201 | man page for details. Reading a saved packet file doesn't require |
| 202 | special privileges. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 203 | .SH OPTIONS |
| 204 | .TP |
| 205 | .B \-A |
| 206 | Print each packet (minus its link level header) in ASCII. Handy for |
| 207 | capturing web pages. |
| 208 | .TP |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 209 | .B \-b |
| 210 | Print the AS number in BGP packets in ASDOT notation rather than ASPLAIN |
| 211 | notation. |
| 212 | .TP |
| 213 | .B \-B |
| 214 | Set the operating system capture buffer size to \fIbuffer_size\fP, in |
| 215 | units of KiB (1024 bytes). |
| 216 | .TP |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 217 | .B \-c |
| 218 | Exit after receiving \fIcount\fP packets. |
| 219 | .TP |
| 220 | .B \-C |
| 221 | Before writing a raw packet to a savefile, check whether the file is |
| 222 | currently larger than \fIfile_size\fP and, if so, close the current |
| 223 | savefile and open a new one. Savefiles after the first savefile will |
| 224 | have the name specified with the |
| 225 | .B \-w |
| 226 | flag, with a number after it, starting at 1 and continuing upward. |
| 227 | The units of \fIfile_size\fP are millions of bytes (1,000,000 bytes, |
| 228 | not 1,048,576 bytes). |
| 229 | .TP |
| 230 | .B \-d |
| 231 | Dump the compiled packet-matching code in a human readable form to |
| 232 | standard output and stop. |
| 233 | .TP |
| 234 | .B \-dd |
| 235 | Dump packet-matching code as a |
| 236 | .B C |
| 237 | program fragment. |
| 238 | .TP |
| 239 | .B \-ddd |
| 240 | Dump packet-matching code as decimal numbers (preceded with a count). |
| 241 | .TP |
| 242 | .B \-D |
| 243 | Print the list of the network interfaces available on the system and on |
| 244 | which |
| 245 | .I tcpdump |
| 246 | can capture packets. For each network interface, a number and an |
| 247 | interface name, possibly followed by a text description of the |
| 248 | interface, is printed. The interface name or the number can be supplied |
| 249 | to the |
| 250 | .B \-i |
| 251 | flag to specify an interface on which to capture. |
| 252 | .IP |
| 253 | This can be useful on systems that don't have a command to list them |
| 254 | (e.g., Windows systems, or UNIX systems lacking |
| 255 | .BR "ifconfig \-a" ); |
| 256 | the number can be useful on Windows 2000 and later systems, where the |
| 257 | interface name is a somewhat complex string. |
| 258 | .IP |
| 259 | The |
| 260 | .B \-D |
| 261 | flag will not be supported if |
| 262 | .I tcpdump |
| 263 | was built with an older version of |
| 264 | .I libpcap |
| 265 | that lacks the |
| 266 | .B pcap_findalldevs() |
| 267 | function. |
| 268 | .TP |
| 269 | .B \-e |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 270 | Print the link-level header on each dump line. This can be used, for |
| 271 | example, to print MAC layer addresses for protocols such as Ethernet and |
| 272 | IEEE 802.11. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 273 | .TP |
| 274 | .B \-E |
| 275 | Use \fIspi@ipaddr algo:secret\fP for decrypting IPsec ESP packets that |
| 276 | are addressed to \fIaddr\fP and contain Security Parameter Index value |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 277 | \fIspi\fP. This combination may be repeated with comma or newline separation. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 278 | .IP |
| 279 | Note that setting the secret for IPv4 ESP packets is supported at this time. |
| 280 | .IP |
| 281 | Algorithms may be |
| 282 | \fBdes-cbc\fP, |
| 283 | \fB3des-cbc\fP, |
| 284 | \fBblowfish-cbc\fP, |
| 285 | \fBrc3-cbc\fP, |
| 286 | \fBcast128-cbc\fP, or |
| 287 | \fBnone\fP. |
| 288 | The default is \fBdes-cbc\fP. |
| 289 | The ability to decrypt packets is only present if \fItcpdump\fP was compiled |
| 290 | with cryptography enabled. |
| 291 | .IP |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 292 | \fIsecret\fP is the ASCII text for ESP secret key. |
| 293 | If preceded by 0x, then a hex value will be read. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 294 | .IP |
| 295 | The option assumes RFC2406 ESP, not RFC1827 ESP. |
| 296 | The option is only for debugging purposes, and |
| 297 | the use of this option with a true `secret' key is discouraged. |
| 298 | By presenting IPsec secret key onto command line |
| 299 | you make it visible to others, via |
| 300 | .IR ps (1) |
| 301 | and other occasions. |
| 302 | .IP |
| 303 | In addition to the above syntax, the syntax \fIfile name\fP may be used |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 304 | to have tcpdump read the provided file in. The file is opened upon |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 305 | receiving the first ESP packet, so any special permissions that tcpdump |
| 306 | may have been given should already have been given up. |
| 307 | .TP |
| 308 | .B \-f |
| 309 | Print `foreign' IPv4 addresses numerically rather than symbolically |
| 310 | (this option is intended to get around serious brain damage in |
| 311 | Sun's NIS server \(em usually it hangs forever translating non-local |
| 312 | internet numbers). |
| 313 | .IP |
| 314 | The test for `foreign' IPv4 addresses is done using the IPv4 address and |
| 315 | netmask of the interface on which capture is being done. If that |
| 316 | address or netmask are not available, available, either because the |
| 317 | interface on which capture is being done has no address or netmask or |
| 318 | because the capture is being done on the Linux "any" interface, which |
| 319 | can capture on more than one interface, this option will not work |
| 320 | correctly. |
| 321 | .TP |
| 322 | .B \-F |
| 323 | Use \fIfile\fP as input for the filter expression. |
| 324 | An additional expression given on the command line is ignored. |
| 325 | .TP |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 326 | .B \-G |
| 327 | If specified, rotates the dump file specified with the |
| 328 | .B \-w |
| 329 | option every \fIrotate_seconds\fP seconds. |
| 330 | Savefiles will have the name specified by |
| 331 | .B \-w |
| 332 | which should include a time format as defined by |
| 333 | .BR strftime (3). |
| 334 | If no time format is specified, each new file will overwrite the previous. |
| 335 | .IP |
| 336 | If used in conjunction with the |
| 337 | .B \-C |
| 338 | option, filenames will take the form of `\fIfile\fP<count>'. |
| 339 | .TP |
| 340 | .B \-h |
| 341 | Print the tcpdump and libpcap version strings, print a usage message, |
| 342 | and exit. |
| 343 | .TP |
| 344 | .B \-H |
| 345 | Attempt to detect 802.11s draft mesh headers. |
| 346 | .TP |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 347 | .B \-i |
| 348 | Listen on \fIinterface\fP. |
| 349 | If unspecified, \fItcpdump\fP searches the system interface list for the |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 350 | lowest numbered, configured up interface (excluding loopback), which may turn |
| 351 | out to be, for example, ``eth0''. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 352 | .IP |
| 353 | On Linux systems with 2.2 or later kernels, an |
| 354 | .I interface |
| 355 | argument of ``any'' can be used to capture packets from all interfaces. |
| 356 | Note that captures on the ``any'' device will not be done in promiscuous |
| 357 | mode. |
| 358 | .IP |
| 359 | If the |
| 360 | .B \-D |
| 361 | flag is supported, an interface number as printed by that flag can be |
| 362 | used as the |
| 363 | .I interface |
| 364 | argument. |
| 365 | .TP |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 366 | .B \-I |
| 367 | Put the interface in "monitor mode"; this is supported only on IEEE |
| 368 | 802.11 Wi-Fi interfaces, and supported only on some operating systems. |
| 369 | .IP |
| 370 | Note that in monitor mode the adapter might disassociate from the |
| 371 | network with which it's associated, so that you will not be able to use |
| 372 | any wireless networks with that adapter. This could prevent accessing |
| 373 | files on a network server, or resolving host names or network addresses, |
| 374 | if you are capturing in monitor mode and are not connected to another |
| 375 | network with another adapter. |
| 376 | .IP |
| 377 | This flag will affect the output of the |
| 378 | .B \-L |
| 379 | flag. If |
| 380 | .B \-I |
| 381 | isn't specified, only those link-layer types available when not in |
| 382 | monitor mode will be shown; if |
| 383 | .B \-I |
| 384 | is specified, only those link-layer types available when in monitor mode |
| 385 | will be shown. |
| 386 | .TP |
| 387 | .B \-j |
| 388 | Set the time stamp type for the capture to \fItstamp_type\fP. The names |
| 389 | to use for the time stamp types are given in |
| 390 | .BR pcap-tstamp (@MAN_MISC_INFO@); |
| 391 | not all the types listed there will necessarily be valid for any given |
| 392 | interface. |
| 393 | .TP |
| 394 | .B \-J |
| 395 | List the supported time stamp types for the interface and exit. If the |
| 396 | time stamp type cannot be set for the interface, no time stamp types are |
| 397 | listed. |
| 398 | .TP |
| 399 | .B \-K |
| 400 | Don't attempt to verify IP, TCP, or UDP checksums. This is useful for |
| 401 | interfaces that perform some or all of those checksum calculation in |
| 402 | hardware; otherwise, all outgoing TCP checksums will be flagged as bad. |
| 403 | .TP |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 404 | .B \-l |
| 405 | Make stdout line buffered. |
| 406 | Useful if you want to see the data |
| 407 | while capturing it. |
| 408 | E.g., |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 409 | .IP |
| 410 | .RS |
| 411 | .RS |
| 412 | .nf |
| 413 | \fBtcpdump \-l | tee dat\fP |
| 414 | .fi |
| 415 | .RE |
| 416 | .RE |
| 417 | .IP |
| 418 | or |
| 419 | .IP |
| 420 | .RS |
| 421 | .RS |
| 422 | .nf |
| 423 | \fBtcpdump \-l > dat & tail \-f dat\fP |
| 424 | .fi |
| 425 | .RE |
| 426 | .RE |
| 427 | .IP |
| 428 | Note that on Windows,``line buffered'' means ``unbuffered'', so that |
| 429 | WinDump will write each character individually if |
| 430 | .B \-l |
| 431 | is specified. |
| 432 | .IP |
| 433 | .B \-U |
| 434 | is similar to |
| 435 | .B \-l |
| 436 | in its behavior, but it will cause output to be ``packet-buffered'', so |
| 437 | that the output is written to stdout at the end of each packet rather |
| 438 | than at the end of each line; this is buffered on all platforms, |
| 439 | including Windows. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 440 | .TP |
| 441 | .B \-L |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 442 | List the known data link types for the interface, in the specified mode, |
| 443 | and exit. The list of known data link types may be dependent on the |
| 444 | specified mode; for example, on some platforms, a Wi-Fi interface might |
| 445 | support one set of data link types when not in monitor mode (for |
| 446 | example, it might support only fake Ethernet headers, or might support |
| 447 | 802.11 headers but not support 802.11 headers with radio information) |
| 448 | and another set of data link types when in monitor mode (for example, it |
| 449 | might support 802.11 headers, or 802.11 headers with radio information, |
| 450 | only in monitor mode). |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 451 | .TP |
| 452 | .B \-m |
| 453 | Load SMI MIB module definitions from file \fImodule\fR. |
| 454 | This option |
| 455 | can be used several times to load several MIB modules into \fItcpdump\fP. |
| 456 | .TP |
| 457 | .B \-M |
| 458 | Use \fIsecret\fP as a shared secret for validating the digests found in |
| 459 | TCP segments with the TCP-MD5 option (RFC 2385), if present. |
| 460 | .TP |
| 461 | .B \-n |
| 462 | Don't convert addresses (i.e., host addresses, port numbers, etc.) to names. |
| 463 | .TP |
| 464 | .B \-N |
| 465 | Don't print domain name qualification of host names. |
| 466 | E.g., |
| 467 | if you give this flag then \fItcpdump\fP will print ``nic'' |
| 468 | instead of ``nic.ddn.mil''. |
| 469 | .TP |
| 470 | .B \-O |
| 471 | Do not run the packet-matching code optimizer. |
| 472 | This is useful only |
| 473 | if you suspect a bug in the optimizer. |
| 474 | .TP |
| 475 | .B \-p |
| 476 | \fIDon't\fP put the interface |
| 477 | into promiscuous mode. |
| 478 | Note that the interface might be in promiscuous |
| 479 | mode for some other reason; hence, `-p' cannot be used as an abbreviation for |
| 480 | `ether host {local-hw-addr} or ether broadcast'. |
| 481 | .TP |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 482 | .B \-Q |
| 483 | Choose send/receive direction \fIdirection\fR for which packets should be |
| 484 | captured. Possible values are `in', `out' and `inout'. Not available |
| 485 | on all platforms. |
| 486 | .TP |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 487 | .B \-q |
| 488 | Quick (quiet?) output. |
| 489 | Print less protocol information so output |
| 490 | lines are shorter. |
| 491 | .TP |
| 492 | .B \-R |
| 493 | Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829). |
| 494 | If specified, \fItcpdump\fP will not print replay prevention field. |
| 495 | Since there is no protocol version field in ESP/AH specification, |
| 496 | \fItcpdump\fP cannot deduce the version of ESP/AH protocol. |
| 497 | .TP |
| 498 | .B \-r |
| 499 | Read packets from \fIfile\fR (which was created with the |
| 500 | .B \-w |
| 501 | option). |
| 502 | Standard input is used if \fIfile\fR is ``-''. |
| 503 | .TP |
| 504 | .B \-S |
| 505 | Print absolute, rather than relative, TCP sequence numbers. |
| 506 | .TP |
| 507 | .B \-s |
| 508 | Snarf \fIsnaplen\fP bytes of data from each packet rather than the |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 509 | default of 65535 bytes. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 510 | Packets truncated because of a limited snapshot |
| 511 | are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP |
| 512 | is the name of the protocol level at which the truncation has occurred. |
| 513 | Note that taking larger snapshots both increases |
| 514 | the amount of time it takes to process packets and, effectively, |
| 515 | decreases the amount of packet buffering. |
| 516 | This may cause packets to be |
| 517 | lost. |
| 518 | You should limit \fIsnaplen\fP to the smallest number that will |
| 519 | capture the protocol information you're interested in. |
| 520 | Setting |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 521 | \fIsnaplen\fP to 0 sets it to the default of 65535, |
| 522 | for backwards compatibility with recent older versions of |
| 523 | .IR tcpdump . |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 524 | .TP |
| 525 | .B \-T |
| 526 | Force packets selected by "\fIexpression\fP" to be interpreted the |
| 527 | specified \fItype\fR. |
| 528 | Currently known types are |
| 529 | \fBaodv\fR (Ad-hoc On-demand Distance Vector protocol), |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 530 | \fBcarp\fR (Common Address Redundancy Protocol), |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 531 | \fBcnfp\fR (Cisco NetFlow protocol), |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 532 | \fBlmp\fR (Link Management Protocol), |
| 533 | \fBpgm\fR (Pragmatic General Multicast), |
| 534 | \fBpgm_zmtp1\fR (ZMTP/1.0 inside PGM/EPGM), |
| 535 | \fBradius\fR (RADIUS), |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 536 | \fBrpc\fR (Remote Procedure Call), |
| 537 | \fBrtp\fR (Real-Time Applications protocol), |
| 538 | \fBrtcp\fR (Real-Time Applications control protocol), |
| 539 | \fBsnmp\fR (Simple Network Management Protocol), |
| 540 | \fBtftp\fR (Trivial File Transfer Protocol), |
| 541 | \fBvat\fR (Visual Audio Tool), |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 542 | \fBwb\fR (distributed White Board), |
| 543 | \fBzmtp1\fR (ZeroMQ Message Transport Protocol 1.0) |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 544 | and |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 545 | \fBvxlan\fR (Virtual eXtensible Local Area Network). |
| 546 | .IP |
| 547 | Note that the \fBpgm\fR type above affects UDP interpretation only, the native |
| 548 | PGM is always recognised as IP protocol 113 regardless. UDP-encapsulated PGM is |
| 549 | often called "EPGM" or "PGM/UDP". |
| 550 | .IP |
| 551 | Note that the \fBpgm_zmtp1\fR type above affects interpretation of both native |
| 552 | PGM and UDP at once. During the native PGM decoding the application data of an |
| 553 | ODATA/RDATA packet would be decoded as a ZeroMQ datagram with ZMTP/1.0 frames. |
| 554 | During the UDP decoding in addition to that any UDP packet would be treated as |
| 555 | an encapsulated PGM packet. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 556 | .TP |
| 557 | .B \-t |
| 558 | \fIDon't\fP print a timestamp on each dump line. |
| 559 | .TP |
| 560 | .B \-tt |
| 561 | Print an unformatted timestamp on each dump line. |
| 562 | .TP |
| 563 | .B \-ttt |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 564 | Print a delta (micro-second resolution) between current and previous line |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 565 | on each dump line. |
| 566 | .TP |
| 567 | .B \-tttt |
| 568 | Print a timestamp in default format proceeded by date on each dump line. |
| 569 | .TP |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 570 | .B \-ttttt |
| 571 | Print a delta (micro-second resolution) between current and first line |
| 572 | on each dump line. |
| 573 | .TP |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 574 | .B \-u |
| 575 | Print undecoded NFS handles. |
| 576 | .TP |
| 577 | .B \-U |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 578 | If the |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 579 | .B \-w |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 580 | option is not specified, make the printed packet output |
| 581 | ``packet-buffered''; i.e., as the description of the contents of each |
| 582 | packet is printed, it will be written to the standard output, rather |
| 583 | than, when not writing to a terminal, being written only when the output |
| 584 | buffer fills. |
| 585 | .IP |
| 586 | If the |
| 587 | .B \-w |
| 588 | option is specified, make the saved raw packet output |
| 589 | ``packet-buffered''; i.e., as each packet is saved, it will be written |
| 590 | to the output file, rather than being written only when the output |
| 591 | buffer fills. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 592 | .IP |
| 593 | The |
| 594 | .B \-U |
| 595 | flag will not be supported if |
| 596 | .I tcpdump |
| 597 | was built with an older version of |
| 598 | .I libpcap |
| 599 | that lacks the |
| 600 | .B pcap_dump_flush() |
| 601 | function. |
| 602 | .TP |
| 603 | .B \-v |
| 604 | When parsing and printing, produce (slightly more) verbose output. |
| 605 | For example, the time to live, |
| 606 | identification, total length and options in an IP packet are printed. |
| 607 | Also enables additional packet integrity checks such as verifying the |
| 608 | IP and ICMP header checksum. |
| 609 | .IP |
| 610 | When writing to a file with the |
| 611 | .B \-w |
| 612 | option, report, every 10 seconds, the number of packets captured. |
| 613 | .TP |
| 614 | .B \-vv |
| 615 | Even more verbose output. |
| 616 | For example, additional fields are |
| 617 | printed from NFS reply packets, and SMB packets are fully decoded. |
| 618 | .TP |
| 619 | .B \-vvv |
| 620 | Even more verbose output. |
| 621 | For example, |
| 622 | telnet \fBSB\fP ... \fBSE\fP options |
| 623 | are printed in full. |
| 624 | With |
| 625 | .B \-X |
| 626 | Telnet options are printed in hex as well. |
| 627 | .TP |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 628 | .B \-V |
| 629 | Read a list of filenames from \fIfile\fR. Standard input is used |
| 630 | if \fIfile\fR is ``-''. |
| 631 | .TP |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 632 | .B \-w |
| 633 | Write the raw packets to \fIfile\fR rather than parsing and printing |
| 634 | them out. |
| 635 | They can later be printed with the \-r option. |
| 636 | Standard output is used if \fIfile\fR is ``-''. |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 637 | .IP |
| 638 | This output will be buffered if written to a file or pipe, so a program |
| 639 | reading from the file or pipe may not see packets for an arbitrary |
| 640 | amount of time after they are received. Use the |
| 641 | .B \-U |
| 642 | flag to cause packets to be written as soon as they are received. |
| 643 | .IP |
| 644 | The MIME type \fIapplication/vnd.tcpdump.pcap\fP has been registered |
| 645 | with IANA for \fIpcap\fP files. The filename extension \fI.pcap\fP |
| 646 | appears to be the most commonly used along with \fI.cap\fP and |
| 647 | \fI.dmp\fP. \fITcpdump\fP itself doesn't check the extension when |
| 648 | reading capture files and doesn't add an extension when writing them |
| 649 | (it uses magic numbers in the file header instead). However, many |
| 650 | operating systems and applications will use the extension if it is |
| 651 | present and adding one (e.g. .pcap) is recommended. |
| 652 | .IP |
| 653 | See |
| 654 | .BR pcap-savefile (@MAN_FILE_FORMATS@) |
| 655 | for a description of the file format. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 656 | .TP |
| 657 | .B \-W |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 658 | Used in conjunction with the |
| 659 | .B \-C |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 660 | option, this will limit the number |
| 661 | of files created to the specified number, and begin overwriting files |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 662 | from the beginning, thus creating a 'rotating' buffer. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 663 | In addition, it will name |
| 664 | the files with enough leading 0s to support the maximum number of |
| 665 | files, allowing them to sort correctly. |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 666 | .IP |
| 667 | Used in conjunction with the |
| 668 | .B \-G |
| 669 | option, this will limit the number of rotated dump files that get |
| 670 | created, exiting with status 0 when reaching the limit. If used with |
| 671 | .B \-C |
| 672 | as well, the behavior will result in cyclical files per timeslice. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 673 | .TP |
| 674 | .B \-x |
| 675 | When parsing and printing, |
| 676 | in addition to printing the headers of each packet, print the data of |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 677 | each packet (minus its link level header) in hex. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 678 | The smaller of the entire packet or |
| 679 | .I snaplen |
| 680 | bytes will be printed. Note that this is the entire link-layer |
| 681 | packet, so for link layers that pad (e.g. Ethernet), the padding bytes |
| 682 | will also be printed when the higher layer packet is shorter than the |
| 683 | required padding. |
| 684 | .TP |
| 685 | .B \-xx |
| 686 | When parsing and printing, |
| 687 | in addition to printing the headers of each packet, print the data of |
| 688 | each packet, |
| 689 | .I including |
| 690 | its link level header, in hex. |
| 691 | .TP |
| 692 | .B \-X |
| 693 | When parsing and printing, |
| 694 | in addition to printing the headers of each packet, print the data of |
| 695 | each packet (minus its link level header) in hex and ASCII. |
| 696 | This is very handy for analysing new protocols. |
| 697 | .TP |
| 698 | .B \-XX |
| 699 | When parsing and printing, |
| 700 | in addition to printing the headers of each packet, print the data of |
| 701 | each packet, |
| 702 | .I including |
| 703 | its link level header, in hex and ASCII. |
| 704 | .TP |
| 705 | .B \-y |
| 706 | Set the data link type to use while capturing packets to \fIdatalinktype\fP. |
| 707 | .TP |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 708 | .B \-z |
| 709 | Used in conjunction with the |
| 710 | .B -C |
| 711 | or |
| 712 | .B -G |
| 713 | options, this will make |
| 714 | .I tcpdump |
| 715 | run " |
| 716 | .I command file |
| 717 | " where |
| 718 | .I file |
| 719 | is the savefile being closed after each rotation. For example, specifying |
| 720 | .B \-z gzip |
| 721 | or |
| 722 | .B \-z bzip2 |
| 723 | will compress each savefile using gzip or bzip2. |
| 724 | .IP |
| 725 | Note that tcpdump will run the command in parallel to the capture, using |
| 726 | the lowest priority so that this doesn't disturb the capture process. |
| 727 | .IP |
| 728 | And in case you would like to use a command that itself takes flags or |
| 729 | different arguments, you can always write a shell script that will take the |
| 730 | savefile name as the only argument, make the flags & arguments arrangements |
| 731 | and execute the command that you want. |
| 732 | .TP |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 733 | .B \-Z |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 734 | If |
| 735 | .I tcpdump |
| 736 | is running as root, after opening the capture device or input savefile, |
| 737 | but before opening any savefiles for output, change the user ID to |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 738 | .I user |
| 739 | and the group ID to the primary group of |
| 740 | .IR user . |
| 741 | .IP |
| 742 | This behavior can also be enabled by default at compile time. |
| 743 | .IP "\fI expression\fP" |
| 744 | .RS |
| 745 | selects which packets will be dumped. |
| 746 | If no \fIexpression\fP |
| 747 | is given, all packets on the net will be dumped. |
| 748 | Otherwise, |
| 749 | only packets for which \fIexpression\fP is `true' will be dumped. |
| 750 | .LP |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 751 | For the \fIexpression\fP syntax, see |
| 752 | .BR pcap-filter (@MAN_MISC_INFO@). |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 753 | .LP |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 754 | The \fIexpression\fP argument can be passed to \fItcpdump\fP as either a single |
| 755 | Shell argument, or as multiple Shell arguments, whichever is more convenient. |
| 756 | Generally, if the expression contains Shell metacharacters, such as |
| 757 | backslashes used to escape protocol names, it is easier to pass it as |
| 758 | a single, quoted argument rather than to escape the Shell |
| 759 | metacharacters. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 760 | Multiple arguments are concatenated with spaces before being parsed. |
| 761 | .SH EXAMPLES |
| 762 | .LP |
| 763 | To print all packets arriving at or departing from \fIsundown\fP: |
| 764 | .RS |
| 765 | .nf |
| 766 | \fBtcpdump host sundown\fP |
| 767 | .fi |
| 768 | .RE |
| 769 | .LP |
| 770 | To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR: |
| 771 | .RS |
| 772 | .nf |
| 773 | \fBtcpdump host helios and \\( hot or ace \\)\fP |
| 774 | .fi |
| 775 | .RE |
| 776 | .LP |
| 777 | To print all IP packets between \fIace\fR and any host except \fIhelios\fR: |
| 778 | .RS |
| 779 | .nf |
| 780 | \fBtcpdump ip host ace and not helios\fP |
| 781 | .fi |
| 782 | .RE |
| 783 | .LP |
| 784 | To print all traffic between local hosts and hosts at Berkeley: |
| 785 | .RS |
| 786 | .nf |
| 787 | .B |
| 788 | tcpdump net ucb-ether |
| 789 | .fi |
| 790 | .RE |
| 791 | .LP |
| 792 | To print all ftp traffic through internet gateway \fIsnup\fP: |
| 793 | (note that the expression is quoted to prevent the shell from |
| 794 | (mis-)interpreting the parentheses): |
| 795 | .RS |
| 796 | .nf |
| 797 | .B |
| 798 | tcpdump 'gateway snup and (port ftp or ftp-data)' |
| 799 | .fi |
| 800 | .RE |
| 801 | .LP |
| 802 | To print traffic neither sourced from nor destined for local hosts |
| 803 | (if you gateway to one other net, this stuff should never make it |
| 804 | onto your local net). |
| 805 | .RS |
| 806 | .nf |
| 807 | .B |
| 808 | tcpdump ip and not net \fIlocalnet\fP |
| 809 | .fi |
| 810 | .RE |
| 811 | .LP |
| 812 | To print the start and end packets (the SYN and FIN packets) of each |
| 813 | TCP conversation that involves a non-local host. |
| 814 | .RS |
| 815 | .nf |
| 816 | .B |
| 817 | tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net \fIlocalnet\fP' |
| 818 | .fi |
| 819 | .RE |
| 820 | .LP |
| 821 | To print all IPv4 HTTP packets to and from port 80, i.e. print only |
| 822 | packets that contain data, not, for example, SYN and FIN packets and |
| 823 | ACK-only packets. (IPv6 is left as an exercise for the reader.) |
| 824 | .RS |
| 825 | .nf |
| 826 | .B |
| 827 | tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' |
| 828 | .fi |
| 829 | .RE |
| 830 | .LP |
| 831 | To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP: |
| 832 | .RS |
| 833 | .nf |
| 834 | .B |
| 835 | tcpdump 'gateway snup and ip[2:2] > 576' |
| 836 | .fi |
| 837 | .RE |
| 838 | .LP |
| 839 | To print IP broadcast or multicast packets that were |
| 840 | .I not |
| 841 | sent via Ethernet broadcast or multicast: |
| 842 | .RS |
| 843 | .nf |
| 844 | .B |
| 845 | tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224' |
| 846 | .fi |
| 847 | .RE |
| 848 | .LP |
| 849 | To print all ICMP packets that are not echo requests/replies (i.e., not |
| 850 | ping packets): |
| 851 | .RS |
| 852 | .nf |
| 853 | .B |
| 854 | tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply' |
| 855 | .fi |
| 856 | .RE |
| 857 | .SH OUTPUT FORMAT |
| 858 | .LP |
| 859 | The output of \fItcpdump\fP is protocol dependent. |
| 860 | The following |
| 861 | gives a brief description and examples of most of the formats. |
| 862 | .de HD |
| 863 | .sp 1.5 |
| 864 | .B |
| 865 | .. |
| 866 | .HD |
| 867 | Link Level Headers |
| 868 | .LP |
| 869 | If the '-e' option is given, the link level header is printed out. |
| 870 | On Ethernets, the source and destination addresses, protocol, |
| 871 | and packet length are printed. |
| 872 | .LP |
| 873 | On FDDI networks, the '-e' option causes \fItcpdump\fP to print |
| 874 | the `frame control' field, the source and destination addresses, |
| 875 | and the packet length. |
| 876 | (The `frame control' field governs the |
| 877 | interpretation of the rest of the packet. |
| 878 | Normal packets (such |
| 879 | as those containing IP datagrams) are `async' packets, with a priority |
| 880 | value between 0 and 7; for example, `\fBasync4\fR'. |
| 881 | Such packets |
| 882 | are assumed to contain an 802.2 Logical Link Control (LLC) packet; |
| 883 | the LLC header is printed if it is \fInot\fR an ISO datagram or a |
| 884 | so-called SNAP packet. |
| 885 | .LP |
| 886 | On Token Ring networks, the '-e' option causes \fItcpdump\fP to print |
| 887 | the `access control' and `frame control' fields, the source and |
| 888 | destination addresses, and the packet length. |
| 889 | As on FDDI networks, |
| 890 | packets are assumed to contain an LLC packet. |
| 891 | Regardless of whether |
| 892 | the '-e' option is specified or not, the source routing information is |
| 893 | printed for source-routed packets. |
| 894 | .LP |
| 895 | On 802.11 networks, the '-e' option causes \fItcpdump\fP to print |
| 896 | the `frame control' fields, all of the addresses in the 802.11 header, |
| 897 | and the packet length. |
| 898 | As on FDDI networks, |
| 899 | packets are assumed to contain an LLC packet. |
| 900 | .LP |
| 901 | \fI(N.B.: The following description assumes familiarity with |
| 902 | the SLIP compression algorithm described in RFC-1144.)\fP |
| 903 | .LP |
| 904 | On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound), |
| 905 | packet type, and compression information are printed out. |
| 906 | The packet type is printed first. |
| 907 | The three types are \fIip\fP, \fIutcp\fP, and \fIctcp\fP. |
| 908 | No further link information is printed for \fIip\fR packets. |
| 909 | For TCP packets, the connection identifier is printed following the type. |
| 910 | If the packet is compressed, its encoded header is printed out. |
| 911 | The special cases are printed out as |
| 912 | \fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR is the amount by which |
| 913 | the sequence number (or sequence number and ack) has changed. |
| 914 | If it is not a special case, |
| 915 | zero or more changes are printed. |
| 916 | A change is indicated by U (urgent pointer), W (window), A (ack), |
| 917 | S (sequence number), and I (packet ID), followed by a delta (+n or -n), |
| 918 | or a new value (=n). |
| 919 | Finally, the amount of data in the packet and compressed header length |
| 920 | are printed. |
| 921 | .LP |
| 922 | For example, the following line shows an outbound compressed TCP packet, |
| 923 | with an implicit connection identifier; the ack has changed by 6, |
| 924 | the sequence number by 49, and the packet ID by 6; there are 3 bytes of |
| 925 | data and 6 bytes of compressed header: |
| 926 | .RS |
| 927 | .nf |
| 928 | \fBO ctcp * A+6 S+49 I+6 3 (6)\fP |
| 929 | .fi |
| 930 | .RE |
| 931 | .HD |
| 932 | ARP/RARP Packets |
| 933 | .LP |
| 934 | Arp/rarp output shows the type of request and its arguments. |
| 935 | The |
| 936 | format is intended to be self explanatory. |
| 937 | Here is a short sample taken from the start of an `rlogin' from |
| 938 | host \fIrtsg\fP to host \fIcsam\fP: |
| 939 | .RS |
| 940 | .nf |
| 941 | .sp .5 |
| 942 | \f(CWarp who-has csam tell rtsg |
| 943 | arp reply csam is-at CSAM\fR |
| 944 | .sp .5 |
| 945 | .fi |
| 946 | .RE |
| 947 | The first line says that rtsg sent an arp packet asking |
| 948 | for the Ethernet address of internet host csam. |
| 949 | Csam |
| 950 | replies with its Ethernet address (in this example, Ethernet addresses |
| 951 | are in caps and internet addresses in lower case). |
| 952 | .LP |
| 953 | This would look less redundant if we had done \fItcpdump \-n\fP: |
| 954 | .RS |
| 955 | .nf |
| 956 | .sp .5 |
| 957 | \f(CWarp who-has 128.3.254.6 tell 128.3.254.68 |
| 958 | arp reply 128.3.254.6 is-at 02:07:01:00:01:c4\fP |
| 959 | .fi |
| 960 | .RE |
| 961 | .LP |
| 962 | If we had done \fItcpdump \-e\fP, the fact that the first packet is |
| 963 | broadcast and the second is point-to-point would be visible: |
| 964 | .RS |
| 965 | .nf |
| 966 | .sp .5 |
| 967 | \f(CWRTSG Broadcast 0806 64: arp who-has csam tell rtsg |
| 968 | CSAM RTSG 0806 64: arp reply csam is-at CSAM\fR |
| 969 | .sp .5 |
| 970 | .fi |
| 971 | .RE |
| 972 | For the first packet this says the Ethernet source address is RTSG, the |
| 973 | destination is the Ethernet broadcast address, the type field |
| 974 | contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes. |
| 975 | .HD |
| 976 | TCP Packets |
| 977 | .LP |
| 978 | \fI(N.B.:The following description assumes familiarity with |
| 979 | the TCP protocol described in RFC-793. |
| 980 | If you are not familiar |
| 981 | with the protocol, neither this description nor \fItcpdump\fP will |
| 982 | be of much use to you.)\fP |
| 983 | .LP |
| 984 | The general format of a tcp protocol line is: |
| 985 | .RS |
| 986 | .nf |
| 987 | .sp .5 |
| 988 | \fIsrc > dst: flags data-seqno ack window urgent options\fP |
| 989 | .sp .5 |
| 990 | .fi |
| 991 | .RE |
| 992 | \fISrc\fP and \fIdst\fP are the source and destination IP |
| 993 | addresses and ports. |
| 994 | \fIFlags\fP are some combination of S (SYN), |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 995 | F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Echo) or |
| 996 | `.' (ACK), or `none' if no flags are set. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 997 | \fIData-seqno\fP describes the portion of sequence space covered |
| 998 | by the data in this packet (see example below). |
| 999 | \fIAck\fP is sequence number of the next data expected the other |
| 1000 | direction on this connection. |
| 1001 | \fIWindow\fP is the number of bytes of receive buffer space available |
| 1002 | the other direction on this connection. |
| 1003 | \fIUrg\fP indicates there is `urgent' data in the packet. |
| 1004 | \fIOptions\fP are tcp options enclosed in angle brackets (e.g., <mss 1024>). |
| 1005 | .LP |
| 1006 | \fISrc, dst\fP and \fIflags\fP are always present. |
| 1007 | The other fields |
| 1008 | depend on the contents of the packet's tcp protocol header and |
| 1009 | are output only if appropriate. |
| 1010 | .LP |
| 1011 | Here is the opening portion of an rlogin from host \fIrtsg\fP to |
| 1012 | host \fIcsam\fP. |
| 1013 | .RS |
| 1014 | .nf |
| 1015 | .sp .5 |
| 1016 | \s-2\f(CWrtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024> |
| 1017 | csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024> |
| 1018 | rtsg.1023 > csam.login: . ack 1 win 4096 |
| 1019 | rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096 |
| 1020 | csam.login > rtsg.1023: . ack 2 win 4096 |
| 1021 | rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096 |
| 1022 | csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077 |
| 1023 | csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1 |
| 1024 | csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fR\s+2 |
| 1025 | .sp .5 |
| 1026 | .fi |
| 1027 | .RE |
| 1028 | The first line says that tcp port 1023 on rtsg sent a packet |
| 1029 | to port \fIlogin\fP |
| 1030 | on csam. |
| 1031 | The \fBS\fP indicates that the \fISYN\fP flag was set. |
| 1032 | The packet sequence number was 768512 and it contained no data. |
| 1033 | (The notation is `first:last(nbytes)' which means `sequence |
| 1034 | numbers \fIfirst\fP |
| 1035 | up to but not including \fIlast\fP which is \fInbytes\fP bytes of user data'.) |
| 1036 | There was no piggy-backed ack, the available receive window was 4096 |
| 1037 | bytes and there was a max-segment-size option requesting an mss of |
| 1038 | 1024 bytes. |
| 1039 | .LP |
| 1040 | Csam replies with a similar packet except it includes a piggy-backed |
| 1041 | ack for rtsg's SYN. |
| 1042 | Rtsg then acks csam's SYN. |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1043 | The `.' means the ACK flag was set. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1044 | The packet contained no data so there is no data sequence number. |
| 1045 | Note that the ack sequence |
| 1046 | number is a small integer (1). |
| 1047 | The first time \fItcpdump\fP sees a |
| 1048 | tcp `conversation', it prints the sequence number from the packet. |
| 1049 | On subsequent packets of the conversation, the difference between |
| 1050 | the current packet's sequence number and this initial sequence number |
| 1051 | is printed. |
| 1052 | This means that sequence numbers after the |
| 1053 | first can be interpreted |
| 1054 | as relative byte positions in the conversation's data stream (with the |
| 1055 | first data byte each direction being `1'). |
| 1056 | `-S' will override this |
| 1057 | feature, causing the original sequence numbers to be output. |
| 1058 | .LP |
| 1059 | On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20 |
| 1060 | in the rtsg \(-> csam side of the conversation). |
| 1061 | The PUSH flag is set in the packet. |
| 1062 | On the 7th line, csam says it's received data sent by rtsg up to |
| 1063 | but not including byte 21. |
| 1064 | Most of this data is apparently sitting in the |
| 1065 | socket buffer since csam's receive window has gotten 19 bytes smaller. |
| 1066 | Csam also sends one byte of data to rtsg in this packet. |
| 1067 | On the 8th and 9th lines, |
| 1068 | csam sends two bytes of urgent, pushed data to rtsg. |
| 1069 | .LP |
| 1070 | If the snapshot was small enough that \fItcpdump\fP didn't capture |
| 1071 | the full TCP header, it interprets as much of the header as it can |
| 1072 | and then reports ``[|\fItcp\fP]'' to indicate the remainder could not |
| 1073 | be interpreted. |
| 1074 | If the header contains a bogus option (one with a length |
| 1075 | that's either too small or beyond the end of the header), \fItcpdump\fP |
| 1076 | reports it as ``[\fIbad opt\fP]'' and does not interpret any further |
| 1077 | options (since it's impossible to tell where they start). |
| 1078 | If the header |
| 1079 | length indicates options are present but the IP datagram length is not |
| 1080 | long enough for the options to actually be there, \fItcpdump\fP reports |
| 1081 | it as ``[\fIbad hdr length\fP]''. |
| 1082 | .HD |
| 1083 | .B Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.) |
| 1084 | .PP |
| 1085 | There are 8 bits in the control bits section of the TCP header: |
| 1086 | .IP |
| 1087 | .I CWR | ECE | URG | ACK | PSH | RST | SYN | FIN |
| 1088 | .PP |
| 1089 | Let's assume that we want to watch packets used in establishing |
| 1090 | a TCP connection. |
| 1091 | Recall that TCP uses a 3-way handshake protocol |
| 1092 | when it initializes a new connection; the connection sequence with |
| 1093 | regard to the TCP control bits is |
| 1094 | .PP |
| 1095 | .RS |
| 1096 | 1) Caller sends SYN |
| 1097 | .RE |
| 1098 | .RS |
| 1099 | 2) Recipient responds with SYN, ACK |
| 1100 | .RE |
| 1101 | .RS |
| 1102 | 3) Caller sends ACK |
| 1103 | .RE |
| 1104 | .PP |
| 1105 | Now we're interested in capturing packets that have only the |
| 1106 | SYN bit set (Step 1). |
| 1107 | Note that we don't want packets from step 2 |
| 1108 | (SYN-ACK), just a plain initial SYN. |
| 1109 | What we need is a correct filter |
| 1110 | expression for \fItcpdump\fP. |
| 1111 | .PP |
| 1112 | Recall the structure of a TCP header without options: |
| 1113 | .PP |
| 1114 | .nf |
| 1115 | 0 15 31 |
| 1116 | ----------------------------------------------------------------- |
| 1117 | | source port | destination port | |
| 1118 | ----------------------------------------------------------------- |
| 1119 | | sequence number | |
| 1120 | ----------------------------------------------------------------- |
| 1121 | | acknowledgment number | |
| 1122 | ----------------------------------------------------------------- |
| 1123 | | HL | rsvd |C|E|U|A|P|R|S|F| window size | |
| 1124 | ----------------------------------------------------------------- |
| 1125 | | TCP checksum | urgent pointer | |
| 1126 | ----------------------------------------------------------------- |
| 1127 | .fi |
| 1128 | .PP |
| 1129 | A TCP header usually holds 20 octets of data, unless options are |
| 1130 | present. |
| 1131 | The first line of the graph contains octets 0 - 3, the |
| 1132 | second line shows octets 4 - 7 etc. |
| 1133 | .PP |
| 1134 | Starting to count with 0, the relevant TCP control bits are contained |
| 1135 | in octet 13: |
| 1136 | .PP |
| 1137 | .nf |
| 1138 | 0 7| 15| 23| 31 |
| 1139 | ----------------|---------------|---------------|---------------- |
| 1140 | | HL | rsvd |C|E|U|A|P|R|S|F| window size | |
| 1141 | ----------------|---------------|---------------|---------------- |
| 1142 | | | 13th octet | | | |
| 1143 | .fi |
| 1144 | .PP |
| 1145 | Let's have a closer look at octet no. 13: |
| 1146 | .PP |
| 1147 | .nf |
| 1148 | | | |
| 1149 | |---------------| |
| 1150 | |C|E|U|A|P|R|S|F| |
| 1151 | |---------------| |
| 1152 | |7 5 3 0| |
| 1153 | .fi |
| 1154 | .PP |
| 1155 | These are the TCP control bits we are interested |
| 1156 | in. |
| 1157 | We have numbered the bits in this octet from 0 to 7, right to |
| 1158 | left, so the PSH bit is bit number 3, while the URG bit is number 5. |
| 1159 | .PP |
| 1160 | Recall that we want to capture packets with only SYN set. |
| 1161 | Let's see what happens to octet 13 if a TCP datagram arrives |
| 1162 | with the SYN bit set in its header: |
| 1163 | .PP |
| 1164 | .nf |
| 1165 | |C|E|U|A|P|R|S|F| |
| 1166 | |---------------| |
| 1167 | |0 0 0 0 0 0 1 0| |
| 1168 | |---------------| |
| 1169 | |7 6 5 4 3 2 1 0| |
| 1170 | .fi |
| 1171 | .PP |
| 1172 | Looking at the |
| 1173 | control bits section we see that only bit number 1 (SYN) is set. |
| 1174 | .PP |
| 1175 | Assuming that octet number 13 is an 8-bit unsigned integer in |
| 1176 | network byte order, the binary value of this octet is |
| 1177 | .IP |
| 1178 | 00000010 |
| 1179 | .PP |
| 1180 | and its decimal representation is |
| 1181 | .PP |
| 1182 | .nf |
| 1183 | 7 6 5 4 3 2 1 0 |
| 1184 | 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2 = 2 |
| 1185 | .fi |
| 1186 | .PP |
| 1187 | We're almost done, because now we know that if only SYN is set, |
| 1188 | the value of the 13th octet in the TCP header, when interpreted |
| 1189 | as a 8-bit unsigned integer in network byte order, must be exactly 2. |
| 1190 | .PP |
| 1191 | This relationship can be expressed as |
| 1192 | .RS |
| 1193 | .B |
| 1194 | tcp[13] == 2 |
| 1195 | .RE |
| 1196 | .PP |
| 1197 | We can use this expression as the filter for \fItcpdump\fP in order |
| 1198 | to watch packets which have only SYN set: |
| 1199 | .RS |
| 1200 | .B |
| 1201 | tcpdump -i xl0 tcp[13] == 2 |
| 1202 | .RE |
| 1203 | .PP |
| 1204 | The expression says "let the 13th octet of a TCP datagram have |
| 1205 | the decimal value 2", which is exactly what we want. |
| 1206 | .PP |
| 1207 | Now, let's assume that we need to capture SYN packets, but we |
| 1208 | don't care if ACK or any other TCP control bit is set at the |
| 1209 | same time. |
| 1210 | Let's see what happens to octet 13 when a TCP datagram |
| 1211 | with SYN-ACK set arrives: |
| 1212 | .PP |
| 1213 | .nf |
| 1214 | |C|E|U|A|P|R|S|F| |
| 1215 | |---------------| |
| 1216 | |0 0 0 1 0 0 1 0| |
| 1217 | |---------------| |
| 1218 | |7 6 5 4 3 2 1 0| |
| 1219 | .fi |
| 1220 | .PP |
| 1221 | Now bits 1 and 4 are set in the 13th octet. |
| 1222 | The binary value of |
| 1223 | octet 13 is |
| 1224 | .IP |
| 1225 | 00010010 |
| 1226 | .PP |
| 1227 | which translates to decimal |
| 1228 | .PP |
| 1229 | .nf |
| 1230 | 7 6 5 4 3 2 1 0 |
| 1231 | 0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2 = 18 |
| 1232 | .fi |
| 1233 | .PP |
| 1234 | Now we can't just use 'tcp[13] == 18' in the \fItcpdump\fP filter |
| 1235 | expression, because that would select only those packets that have |
| 1236 | SYN-ACK set, but not those with only SYN set. |
| 1237 | Remember that we don't care |
| 1238 | if ACK or any other control bit is set as long as SYN is set. |
| 1239 | .PP |
| 1240 | In order to achieve our goal, we need to logically AND the |
| 1241 | binary value of octet 13 with some other value to preserve |
| 1242 | the SYN bit. |
| 1243 | We know that we want SYN to be set in any case, |
| 1244 | so we'll logically AND the value in the 13th octet with |
| 1245 | the binary value of a SYN: |
| 1246 | .PP |
| 1247 | .nf |
| 1248 | |
| 1249 | 00010010 SYN-ACK 00000010 SYN |
| 1250 | AND 00000010 (we want SYN) AND 00000010 (we want SYN) |
| 1251 | -------- -------- |
| 1252 | = 00000010 = 00000010 |
| 1253 | .fi |
| 1254 | .PP |
| 1255 | We see that this AND operation delivers the same result |
| 1256 | regardless whether ACK or another TCP control bit is set. |
| 1257 | The decimal representation of the AND value as well as |
| 1258 | the result of this operation is 2 (binary 00000010), |
| 1259 | so we know that for packets with SYN set the following |
| 1260 | relation must hold true: |
| 1261 | .IP |
| 1262 | ( ( value of octet 13 ) AND ( 2 ) ) == ( 2 ) |
| 1263 | .PP |
| 1264 | This points us to the \fItcpdump\fP filter expression |
| 1265 | .RS |
| 1266 | .B |
| 1267 | tcpdump -i xl0 'tcp[13] & 2 == 2' |
| 1268 | .RE |
| 1269 | .PP |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1270 | Some offsets and field values may be expressed as names |
| 1271 | rather than as numeric values. For example tcp[13] may |
| 1272 | be replaced with tcp[tcpflags]. The following TCP flag |
| 1273 | field values are also available: tcp-fin, tcp-syn, tcp-rst, |
| 1274 | tcp-push, tcp-act, tcp-urg. |
| 1275 | .PP |
| 1276 | This can be demonstrated as: |
| 1277 | .RS |
| 1278 | .B |
| 1279 | tcpdump -i xl0 'tcp[tcpflags] & tcp-push != 0' |
| 1280 | .RE |
| 1281 | .PP |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1282 | Note that you should use single quotes or a backslash |
| 1283 | in the expression to hide the AND ('&') special character |
| 1284 | from the shell. |
| 1285 | .HD |
| 1286 | .B |
| 1287 | UDP Packets |
| 1288 | .LP |
| 1289 | UDP format is illustrated by this rwho packet: |
| 1290 | .RS |
| 1291 | .nf |
| 1292 | .sp .5 |
| 1293 | \f(CWactinide.who > broadcast.who: udp 84\fP |
| 1294 | .sp .5 |
| 1295 | .fi |
| 1296 | .RE |
| 1297 | This says that port \fIwho\fP on host \fIactinide\fP sent a udp |
| 1298 | datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet |
| 1299 | broadcast address. |
| 1300 | The packet contained 84 bytes of user data. |
| 1301 | .LP |
| 1302 | Some UDP services are recognized (from the source or destination |
| 1303 | port number) and the higher level protocol information printed. |
| 1304 | In particular, Domain Name service requests (RFC-1034/1035) and Sun |
| 1305 | RPC calls (RFC-1050) to NFS. |
| 1306 | .HD |
| 1307 | UDP Name Server Requests |
| 1308 | .LP |
| 1309 | \fI(N.B.:The following description assumes familiarity with |
| 1310 | the Domain Service protocol described in RFC-1035. |
| 1311 | If you are not familiar |
| 1312 | with the protocol, the following description will appear to be written |
| 1313 | in greek.)\fP |
| 1314 | .LP |
| 1315 | Name server requests are formatted as |
| 1316 | .RS |
| 1317 | .nf |
| 1318 | .sp .5 |
| 1319 | \fIsrc > dst: id op? flags qtype qclass name (len)\fP |
| 1320 | .sp .5 |
| 1321 | \f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fR |
| 1322 | .sp .5 |
| 1323 | .fi |
| 1324 | .RE |
| 1325 | Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an |
| 1326 | address record (qtype=A) associated with the name \fIucbvax.berkeley.edu.\fP |
| 1327 | The query id was `3'. |
| 1328 | The `+' indicates the \fIrecursion desired\fP flag |
| 1329 | was set. |
| 1330 | The query length was 37 bytes, not including the UDP and |
| 1331 | IP protocol headers. |
| 1332 | The query operation was the normal one, \fIQuery\fP, |
| 1333 | so the op field was omitted. |
| 1334 | If the op had been anything else, it would |
| 1335 | have been printed between the `3' and the `+'. |
| 1336 | Similarly, the qclass was the normal one, |
| 1337 | \fIC_IN\fP, and omitted. |
| 1338 | Any other qclass would have been printed |
| 1339 | immediately after the `A'. |
| 1340 | .LP |
| 1341 | A few anomalies are checked and may result in extra fields enclosed in |
| 1342 | square brackets: If a query contains an answer, authority records or |
| 1343 | additional records section, |
| 1344 | .IR ancount , |
| 1345 | .IR nscount , |
| 1346 | or |
| 1347 | .I arcount |
| 1348 | are printed as `[\fIn\fPa]', `[\fIn\fPn]' or `[\fIn\fPau]' where \fIn\fP |
| 1349 | is the appropriate count. |
| 1350 | If any of the response bits are set (AA, RA or rcode) or any of the |
| 1351 | `must be zero' bits are set in bytes two and three, `[b2&3=\fIx\fP]' |
| 1352 | is printed, where \fIx\fP is the hex value of header bytes two and three. |
| 1353 | .HD |
| 1354 | UDP Name Server Responses |
| 1355 | .LP |
| 1356 | Name server responses are formatted as |
| 1357 | .RS |
| 1358 | .nf |
| 1359 | .sp .5 |
| 1360 | \fIsrc > dst: id op rcode flags a/n/au type class data (len)\fP |
| 1361 | .sp .5 |
| 1362 | \f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) |
| 1363 | helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fR |
| 1364 | .sp .5 |
| 1365 | .fi |
| 1366 | .RE |
| 1367 | In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP |
| 1368 | with 3 answer records, 3 name server records and 7 additional records. |
| 1369 | The first answer record is type A (address) and its data is internet |
| 1370 | address 128.32.137.3. |
| 1371 | The total size of the response was 273 bytes, |
| 1372 | excluding UDP and IP headers. |
| 1373 | The op (Query) and response code |
| 1374 | (NoError) were omitted, as was the class (C_IN) of the A record. |
| 1375 | .LP |
| 1376 | In the second example, \fIhelios\fP responds to query 2 with a |
| 1377 | response code of non-existent domain (NXDomain) with no answers, |
| 1378 | one name server and no authority records. |
| 1379 | The `*' indicates that |
| 1380 | the \fIauthoritative answer\fP bit was set. |
| 1381 | Since there were no |
| 1382 | answers, no type, class or data were printed. |
| 1383 | .LP |
| 1384 | Other flag characters that might appear are `\-' (recursion available, |
| 1385 | RA, \fInot\fP set) and `|' (truncated message, TC, set). |
| 1386 | If the |
| 1387 | `question' section doesn't contain exactly one entry, `[\fIn\fPq]' |
| 1388 | is printed. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1389 | .HD |
| 1390 | SMB/CIFS decoding |
| 1391 | .LP |
| 1392 | \fItcpdump\fP now includes fairly extensive SMB/CIFS/NBT decoding for data |
| 1393 | on UDP/137, UDP/138 and TCP/139. |
| 1394 | Some primitive decoding of IPX and |
| 1395 | NetBEUI SMB data is also done. |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1396 | .LP |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1397 | By default a fairly minimal decode is done, with a much more detailed |
| 1398 | decode done if -v is used. |
| 1399 | Be warned that with -v a single SMB packet |
| 1400 | may take up a page or more, so only use -v if you really want all the |
| 1401 | gory details. |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1402 | .LP |
| 1403 | For information on SMB packet formats and what all the fields mean see |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1404 | www.cifs.org or the pub/samba/specs/ directory on your favorite |
| 1405 | samba.org mirror site. |
| 1406 | The SMB patches were written by Andrew Tridgell |
| 1407 | (tridge@samba.org). |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1408 | .HD |
| 1409 | NFS Requests and Replies |
| 1410 | .LP |
| 1411 | Sun NFS (Network File System) requests and replies are printed as: |
| 1412 | .RS |
| 1413 | .nf |
| 1414 | .sp .5 |
| 1415 | \fIsrc.xid > dst.nfs: len op args\fP |
| 1416 | \fIsrc.nfs > dst.xid: reply stat len op results\fP |
| 1417 | .sp .5 |
| 1418 | \f(CW |
| 1419 | sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165 |
| 1420 | wrl.nfs > sushi.6709: reply ok 40 readlink "../var" |
| 1421 | sushi.201b > wrl.nfs: |
| 1422 | 144 lookup fh 9,74/4096.6878 "xcolors" |
| 1423 | wrl.nfs > sushi.201b: |
| 1424 | reply ok 128 lookup fh 9,74/4134.3150 |
| 1425 | \fR |
| 1426 | .sp .5 |
| 1427 | .fi |
| 1428 | .RE |
| 1429 | In the first line, host \fIsushi\fP sends a transaction with id \fI6709\fP |
| 1430 | to \fIwrl\fP (note that the number following the src host is a |
| 1431 | transaction id, \fInot\fP the source port). |
| 1432 | The request was 112 bytes, |
| 1433 | excluding the UDP and IP headers. |
| 1434 | The operation was a \fIreadlink\fP |
| 1435 | (read symbolic link) on file handle (\fIfh\fP) 21,24/10.731657119. |
| 1436 | (If one is lucky, as in this case, the file handle can be interpreted |
| 1437 | as a major,minor device number pair, followed by the inode number and |
| 1438 | generation number.) |
| 1439 | \fIWrl\fP replies `ok' with the contents of the link. |
| 1440 | .LP |
| 1441 | In the third line, \fIsushi\fP asks \fIwrl\fP to lookup the name |
| 1442 | `\fIxcolors\fP' in directory file 9,74/4096.6878. |
| 1443 | Note that the data printed |
| 1444 | depends on the operation type. |
| 1445 | The format is intended to be self |
| 1446 | explanatory if read in conjunction with |
| 1447 | an NFS protocol spec. |
| 1448 | .LP |
| 1449 | If the \-v (verbose) flag is given, additional information is printed. |
| 1450 | For example: |
| 1451 | .RS |
| 1452 | .nf |
| 1453 | .sp .5 |
| 1454 | \f(CW |
| 1455 | sushi.1372a > wrl.nfs: |
| 1456 | 148 read fh 21,11/12.195 8192 bytes @ 24576 |
| 1457 | wrl.nfs > sushi.1372a: |
| 1458 | reply ok 1472 read REG 100664 ids 417/0 sz 29388 |
| 1459 | \fP |
| 1460 | .sp .5 |
| 1461 | .fi |
| 1462 | .RE |
| 1463 | (\-v also prints the IP header TTL, ID, length, and fragmentation fields, |
| 1464 | which have been omitted from this example.) In the first line, |
| 1465 | \fIsushi\fP asks \fIwrl\fP to read 8192 bytes from file 21,11/12.195, |
| 1466 | at byte offset 24576. |
| 1467 | \fIWrl\fP replies `ok'; the packet shown on the |
| 1468 | second line is the first fragment of the reply, and hence is only 1472 |
| 1469 | bytes long (the other bytes will follow in subsequent fragments, but |
| 1470 | these fragments do not have NFS or even UDP headers and so might not be |
| 1471 | printed, depending on the filter expression used). |
| 1472 | Because the \-v flag |
| 1473 | is given, some of the file attributes (which are returned in addition |
| 1474 | to the file data) are printed: the file type (``REG'', for regular file), |
| 1475 | the file mode (in octal), the uid and gid, and the file size. |
| 1476 | .LP |
| 1477 | If the \-v flag is given more than once, even more details are printed. |
| 1478 | .LP |
| 1479 | Note that NFS requests are very large and much of the detail won't be printed |
| 1480 | unless \fIsnaplen\fP is increased. |
| 1481 | Try using `\fB\-s 192\fP' to watch |
| 1482 | NFS traffic. |
| 1483 | .LP |
| 1484 | NFS reply packets do not explicitly identify the RPC operation. |
| 1485 | Instead, |
| 1486 | \fItcpdump\fP keeps track of ``recent'' requests, and matches them to the |
| 1487 | replies using the transaction ID. |
| 1488 | If a reply does not closely follow the |
| 1489 | corresponding request, it might not be parsable. |
| 1490 | .HD |
| 1491 | AFS Requests and Replies |
| 1492 | .LP |
| 1493 | Transarc AFS (Andrew File System) requests and replies are printed |
| 1494 | as: |
| 1495 | .HD |
| 1496 | .RS |
| 1497 | .nf |
| 1498 | .sp .5 |
| 1499 | \fIsrc.sport > dst.dport: rx packet-type\fP |
| 1500 | \fIsrc.sport > dst.dport: rx packet-type service call call-name args\fP |
| 1501 | \fIsrc.sport > dst.dport: rx packet-type service reply call-name args\fP |
| 1502 | .sp .5 |
| 1503 | \f(CW |
| 1504 | elvis.7001 > pike.afsfs: |
| 1505 | rx data fs call rename old fid 536876964/1/1 ".newsrc.new" |
| 1506 | new fid 536876964/1/1 ".newsrc" |
| 1507 | pike.afsfs > elvis.7001: rx data fs reply rename |
| 1508 | \fR |
| 1509 | .sp .5 |
| 1510 | .fi |
| 1511 | .RE |
| 1512 | In the first line, host elvis sends a RX packet to pike. |
| 1513 | This was |
| 1514 | a RX data packet to the fs (fileserver) service, and is the start of |
| 1515 | an RPC call. |
| 1516 | The RPC call was a rename, with the old directory file id |
| 1517 | of 536876964/1/1 and an old filename of `.newsrc.new', and a new directory |
| 1518 | file id of 536876964/1/1 and a new filename of `.newsrc'. |
| 1519 | The host pike |
| 1520 | responds with a RPC reply to the rename call (which was successful, because |
| 1521 | it was a data packet and not an abort packet). |
| 1522 | .LP |
| 1523 | In general, all AFS RPCs are decoded at least by RPC call name. |
| 1524 | Most |
| 1525 | AFS RPCs have at least some of the arguments decoded (generally only |
| 1526 | the `interesting' arguments, for some definition of interesting). |
| 1527 | .LP |
| 1528 | The format is intended to be self-describing, but it will probably |
| 1529 | not be useful to people who are not familiar with the workings of |
| 1530 | AFS and RX. |
| 1531 | .LP |
| 1532 | If the -v (verbose) flag is given twice, acknowledgement packets and |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1533 | additional header information is printed, such as the RX call ID, |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1534 | call number, sequence number, serial number, and the RX packet flags. |
| 1535 | .LP |
| 1536 | If the -v flag is given twice, additional information is printed, |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1537 | such as the RX call ID, serial number, and the RX packet flags. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1538 | The MTU negotiation information is also printed from RX ack packets. |
| 1539 | .LP |
| 1540 | If the -v flag is given three times, the security index and service id |
| 1541 | are printed. |
| 1542 | .LP |
| 1543 | Error codes are printed for abort packets, with the exception of Ubik |
| 1544 | beacon packets (because abort packets are used to signify a yes vote |
| 1545 | for the Ubik protocol). |
| 1546 | .LP |
| 1547 | Note that AFS requests are very large and many of the arguments won't |
| 1548 | be printed unless \fIsnaplen\fP is increased. |
| 1549 | Try using `\fB-s 256\fP' |
| 1550 | to watch AFS traffic. |
| 1551 | .LP |
| 1552 | AFS reply packets do not explicitly identify the RPC operation. |
| 1553 | Instead, |
| 1554 | \fItcpdump\fP keeps track of ``recent'' requests, and matches them to the |
| 1555 | replies using the call number and service ID. |
| 1556 | If a reply does not closely |
| 1557 | follow the |
| 1558 | corresponding request, it might not be parsable. |
| 1559 | |
| 1560 | .HD |
| 1561 | KIP AppleTalk (DDP in UDP) |
| 1562 | .LP |
| 1563 | AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated |
| 1564 | and dumped as DDP packets (i.e., all the UDP header information is |
| 1565 | discarded). |
| 1566 | The file |
| 1567 | .I /etc/atalk.names |
| 1568 | is used to translate AppleTalk net and node numbers to names. |
| 1569 | Lines in this file have the form |
| 1570 | .RS |
| 1571 | .nf |
| 1572 | .sp .5 |
| 1573 | \fInumber name\fP |
| 1574 | |
| 1575 | \f(CW1.254 ether |
| 1576 | 16.1 icsd-net |
| 1577 | 1.254.110 ace\fR |
| 1578 | .sp .5 |
| 1579 | .fi |
| 1580 | .RE |
| 1581 | The first two lines give the names of AppleTalk networks. |
| 1582 | The third |
| 1583 | line gives the name of a particular host (a host is distinguished |
| 1584 | from a net by the 3rd octet in the number \- |
| 1585 | a net number \fImust\fP have two octets and a host number \fImust\fP |
| 1586 | have three octets.) The number and name should be separated by |
| 1587 | whitespace (blanks or tabs). |
| 1588 | The |
| 1589 | .I /etc/atalk.names |
| 1590 | file may contain blank lines or comment lines (lines starting with |
| 1591 | a `#'). |
| 1592 | .LP |
| 1593 | AppleTalk addresses are printed in the form |
| 1594 | .RS |
| 1595 | .nf |
| 1596 | .sp .5 |
| 1597 | \fInet.host.port\fP |
| 1598 | |
| 1599 | \f(CW144.1.209.2 > icsd-net.112.220 |
| 1600 | office.2 > icsd-net.112.220 |
| 1601 | jssmag.149.235 > icsd-net.2\fR |
| 1602 | .sp .5 |
| 1603 | .fi |
| 1604 | .RE |
| 1605 | (If the |
| 1606 | .I /etc/atalk.names |
| 1607 | doesn't exist or doesn't contain an entry for some AppleTalk |
| 1608 | host/net number, addresses are printed in numeric form.) |
| 1609 | In the first example, NBP (DDP port 2) on net 144.1 node 209 |
| 1610 | is sending to whatever is listening on port 220 of net icsd node 112. |
| 1611 | The second line is the same except the full name of the source node |
| 1612 | is known (`office'). |
| 1613 | The third line is a send from port 235 on |
| 1614 | net jssmag node 149 to broadcast on the icsd-net NBP port (note that |
| 1615 | the broadcast address (255) is indicated by a net name with no host |
| 1616 | number \- for this reason it's a good idea to keep node names and |
| 1617 | net names distinct in /etc/atalk.names). |
| 1618 | .LP |
| 1619 | NBP (name binding protocol) and ATP (AppleTalk transaction protocol) |
| 1620 | packets have their contents interpreted. |
| 1621 | Other protocols just dump |
| 1622 | the protocol name (or number if no name is registered for the |
| 1623 | protocol) and packet size. |
| 1624 | |
| 1625 | \fBNBP packets\fP are formatted like the following examples: |
| 1626 | .RS |
| 1627 | .nf |
| 1628 | .sp .5 |
| 1629 | \s-2\f(CWicsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*" |
| 1630 | jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250 |
| 1631 | techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fR\s+2 |
| 1632 | .sp .5 |
| 1633 | .fi |
| 1634 | .RE |
| 1635 | The first line is a name lookup request for laserwriters sent by net icsd host |
| 1636 | 112 and broadcast on net jssmag. |
| 1637 | The nbp id for the lookup is 190. |
| 1638 | The second line shows a reply for this request (note that it has the |
| 1639 | same id) from host jssmag.209 saying that it has a laserwriter |
| 1640 | resource named "RM1140" registered on port 250. |
| 1641 | The third line is |
| 1642 | another reply to the same request saying host techpit has laserwriter |
| 1643 | "techpit" registered on port 186. |
| 1644 | |
| 1645 | \fBATP packet\fP formatting is demonstrated by the following example: |
| 1646 | .RS |
| 1647 | .nf |
| 1648 | .sp .5 |
| 1649 | \s-2\f(CWjssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001 |
| 1650 | helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000 |
| 1651 | helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000 |
| 1652 | helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000 |
| 1653 | helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 |
| 1654 | helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000 |
| 1655 | helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 |
| 1656 | helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000 |
| 1657 | helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000 |
| 1658 | jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001 |
| 1659 | helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 |
| 1660 | helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 |
| 1661 | jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001 |
| 1662 | jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fR\s+2 |
| 1663 | .sp .5 |
| 1664 | .fi |
| 1665 | .RE |
| 1666 | Jssmag.209 initiates transaction id 12266 with host helios by requesting |
| 1667 | up to 8 packets (the `<0-7>'). |
| 1668 | The hex number at the end of the line |
| 1669 | is the value of the `userdata' field in the request. |
| 1670 | .LP |
| 1671 | Helios responds with 8 512-byte packets. |
| 1672 | The `:digit' following the |
| 1673 | transaction id gives the packet sequence number in the transaction |
| 1674 | and the number in parens is the amount of data in the packet, |
| 1675 | excluding the atp header. |
| 1676 | The `*' on packet 7 indicates that the |
| 1677 | EOM bit was set. |
| 1678 | .LP |
| 1679 | Jssmag.209 then requests that packets 3 & 5 be retransmitted. |
| 1680 | Helios |
| 1681 | resends them then jssmag.209 releases the transaction. |
| 1682 | Finally, |
| 1683 | jssmag.209 initiates the next request. |
| 1684 | The `*' on the request |
| 1685 | indicates that XO (`exactly once') was \fInot\fP set. |
| 1686 | |
| 1687 | .HD |
| 1688 | IP Fragmentation |
| 1689 | .LP |
| 1690 | Fragmented Internet datagrams are printed as |
| 1691 | .RS |
| 1692 | .nf |
| 1693 | .sp .5 |
| 1694 | \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR |
| 1695 | \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR |
| 1696 | .sp .5 |
| 1697 | .fi |
| 1698 | .RE |
| 1699 | (The first form indicates there are more fragments. |
| 1700 | The second |
| 1701 | indicates this is the last fragment.) |
| 1702 | .LP |
| 1703 | \fIId\fP is the fragment id. |
| 1704 | \fISize\fP is the fragment |
| 1705 | size (in bytes) excluding the IP header. |
| 1706 | \fIOffset\fP is this |
| 1707 | fragment's offset (in bytes) in the original datagram. |
| 1708 | .LP |
| 1709 | The fragment information is output for each fragment. |
| 1710 | The first |
| 1711 | fragment contains the higher level protocol header and the frag |
| 1712 | info is printed after the protocol info. |
| 1713 | Fragments |
| 1714 | after the first contain no higher level protocol header and the |
| 1715 | frag info is printed after the source and destination addresses. |
| 1716 | For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa |
| 1717 | over a CSNET connection that doesn't appear to handle 576 byte datagrams: |
| 1718 | .RS |
| 1719 | .nf |
| 1720 | .sp .5 |
| 1721 | \s-2\f(CWarizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+) |
| 1722 | arizona > rtsg: (frag 595a:204@328) |
| 1723 | rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560\fP\s+2 |
| 1724 | .sp .5 |
| 1725 | .fi |
| 1726 | .RE |
| 1727 | There are a couple of things to note here: First, addresses in the |
| 1728 | 2nd line don't include port numbers. |
| 1729 | This is because the TCP |
| 1730 | protocol information is all in the first fragment and we have no idea |
| 1731 | what the port or sequence numbers are when we print the later fragments. |
| 1732 | Second, the tcp sequence information in the first line is printed as if there |
| 1733 | were 308 bytes of user data when, in fact, there are 512 bytes (308 in |
| 1734 | the first frag and 204 in the second). |
| 1735 | If you are looking for holes |
| 1736 | in the sequence space or trying to match up acks |
| 1737 | with packets, this can fool you. |
| 1738 | .LP |
| 1739 | A packet with the IP \fIdon't fragment\fP flag is marked with a |
| 1740 | trailing \fB(DF)\fP. |
| 1741 | .HD |
| 1742 | Timestamps |
| 1743 | .LP |
| 1744 | By default, all output lines are preceded by a timestamp. |
| 1745 | The timestamp |
| 1746 | is the current clock time in the form |
| 1747 | .RS |
| 1748 | .nf |
| 1749 | \fIhh:mm:ss.frac\fP |
| 1750 | .fi |
| 1751 | .RE |
| 1752 | and is as accurate as the kernel's clock. |
| 1753 | The timestamp reflects the time the kernel first saw the packet. |
| 1754 | No attempt |
| 1755 | is made to account for the time lag between when the |
| 1756 | Ethernet interface removed the packet from the wire and when the kernel |
| 1757 | serviced the `new packet' interrupt. |
| 1758 | .SH "SEE ALSO" |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1759 | stty(1), pcap(3PCAP), bpf(4), nit(4P), pcap-savefile(@MAN_FILE_FORMATS@), |
| 1760 | pcap-filter(@MAN_MISC_INFO@), pcap-tstamp(@MAN_MISC_INFO@) |
| 1761 | .LP |
| 1762 | .RS |
| 1763 | .I http://www.iana.org/assignments/media-types/application/vnd.tcpdump.pcap |
| 1764 | .RE |
| 1765 | .LP |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1766 | .SH AUTHORS |
| 1767 | The original authors are: |
| 1768 | .LP |
| 1769 | Van Jacobson, |
| 1770 | Craig Leres and |
| 1771 | Steven McCanne, all of the |
| 1772 | Lawrence Berkeley National Laboratory, University of California, Berkeley, CA. |
| 1773 | .LP |
| 1774 | It is currently being maintained by tcpdump.org. |
| 1775 | .LP |
| 1776 | The current version is available via http: |
| 1777 | .LP |
| 1778 | .RS |
| 1779 | .I http://www.tcpdump.org/ |
| 1780 | .RE |
| 1781 | .LP |
| 1782 | The original distribution is available via anonymous ftp: |
| 1783 | .LP |
| 1784 | .RS |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1785 | .I ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1786 | .RE |
| 1787 | .LP |
| 1788 | IPv6/IPsec support is added by WIDE/KAME project. |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1789 | This program uses Eric Young's SSLeay library, under specific configurations. |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1790 | .SH BUGS |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1791 | Please send problems, bugs, questions, desirable enhancements, patches |
| 1792 | etc. to: |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1793 | .LP |
| 1794 | .RS |
JP Abgrall | 53f17a9 | 2014-02-12 14:02:41 -0800 | [diff] [blame] | 1795 | tcpdump-workers@lists.tcpdump.org |
The Android Open Source Project | 2949f58 | 2009-03-03 19:30:46 -0800 | [diff] [blame] | 1796 | .RE |
| 1797 | .LP |
| 1798 | NIT doesn't let you watch your own outbound traffic, BPF will. |
| 1799 | We recommend that you use the latter. |
| 1800 | .LP |
| 1801 | On Linux systems with 2.0[.x] kernels: |
| 1802 | .IP |
| 1803 | packets on the loopback device will be seen twice; |
| 1804 | .IP |
| 1805 | packet filtering cannot be done in the kernel, so that all packets must |
| 1806 | be copied from the kernel in order to be filtered in user mode; |
| 1807 | .IP |
| 1808 | all of a packet, not just the part that's within the snapshot length, |
| 1809 | will be copied from the kernel (the 2.0[.x] packet capture mechanism, if |
| 1810 | asked to copy only part of a packet to userland, will not report the |
| 1811 | true length of the packet; this would cause most IP packets to get an |
| 1812 | error from |
| 1813 | .BR tcpdump ); |
| 1814 | .IP |
| 1815 | capturing on some PPP devices won't work correctly. |
| 1816 | .LP |
| 1817 | We recommend that you upgrade to a 2.2 or later kernel. |
| 1818 | .LP |
| 1819 | Some attempt should be made to reassemble IP fragments or, at least |
| 1820 | to compute the right length for the higher level protocol. |
| 1821 | .LP |
| 1822 | Name server inverse queries are not dumped correctly: the (empty) |
| 1823 | question section is printed rather than real query in the answer |
| 1824 | section. |
| 1825 | Some believe that inverse queries are themselves a bug and |
| 1826 | prefer to fix the program generating them rather than \fItcpdump\fP. |
| 1827 | .LP |
| 1828 | A packet trace that crosses a daylight savings time change will give |
| 1829 | skewed time stamps (the time change is ignored). |
| 1830 | .LP |
| 1831 | Filter expressions on fields other than those in Token Ring headers will |
| 1832 | not correctly handle source-routed Token Ring packets. |
| 1833 | .LP |
| 1834 | Filter expressions on fields other than those in 802.11 headers will not |
| 1835 | correctly handle 802.11 data packets with both To DS and From DS set. |
| 1836 | .LP |
| 1837 | .BR "ip6 proto" |
| 1838 | should chase header chain, but at this moment it does not. |
| 1839 | .BR "ip6 protochain" |
| 1840 | is supplied for this behavior. |
| 1841 | .LP |
| 1842 | Arithmetic expression against transport layer headers, like \fBtcp[0]\fP, |
| 1843 | does not work against IPv6 packets. |
| 1844 | It only looks at IPv4 packets. |