.\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997
.\"     The Regents of the University of California.  All rights reserved.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that: (1) source code distributions
.\" retain the above copyright notice and this paragraph in its entirety, (2)
.\" distributions including binary code include the above copyright notice and
.\" this paragraph in its entirety in the documentation or other materials
.\" provided with the distribution, and (3) all advertising materials mentioning
.\" features or use of this software display the following acknowledgement:
.\" ``This product includes software developed by the University of California,
.\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
.\" the University nor the names of its contributors may be used to endorse
.\" or promote products derived from this software without specific prior
.\" written permission.
.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\"
.TH TCPDUMP 8 "30 June 1997"
.SH "نام (NAME)"
tcpdump \- ابزار تجزیه و تحلیل و شنود بستههای ترافیک شبکه
.SH "خلاصه دستور (SYNOPSIS)"
.na
.B tcpdump
[
.B \-adeflnNOpqStvx
] [
.B \-c
.I count
] [
.B \-F
.I file
]
.br
.ti +8
[
.B \-i
.I interface
] [
.B \-r
.I file
]
[
.B \-s
.I snaplen
]
.br
.ti +8
[
.B \-T
.I type
]
[
.B \-w
.I file
]
[
.I expression
]
.br
.ad
.SH "توضیحات (DESCRIPTION)"
.LP
دستور
\fItcpdump\fP
هدرهای بسته‌های روی یک رابط شبکه را که با عبارت بولی
\fIexpression\fP
مطابقت دارند چاپ می‌کند.
.LP
.B "در SunOS با رابط nit یا bpf:"
برای اجرای
.IR tcpdump ،
باید دسترسی خواندن به
.I /dev/nit
یا
.IR /dev/bpf*
داشته باشید.

.B "در Solaris با dlpi:"
باید دسترسی خواندن به دستگاه شبه‌شبکه (network pseudo device) مانند
.IR /dev/le
داشته باشید.

.B "در HP-UX با dlpi:"
باید کاربر ریشه (root) باشید یا برنامه به‌صورت setuid برای root نصب شده باشد.

.B "در IRIX با snoop:"
باید کاربر ریشه (root) باشید یا برنامه به‌صورت setuid برای root نصب شده باشد.

.B "در Linux:"
باید کاربر ریشه (root) باشید یا برنامه به‌صورت setuid برای root نصب شده باشد.

.B "در Ultrix و Digital UNIX:"
هنگامی که کاربر ارشد با استفاده از
.IR pfconfig (8)
حالت بی‌قیدوشرط (promiscuous-mode) را فعال کند، هر کاربری می‌تواند
.B tcpdump
را اجرا کند.

.B "در BSD:"
باید دسترسی خواندن به
.IR /dev/bpf*
داشته باشید.

.SH "گزینه‌ها (OPTIONS)"
.TP
.B \-a
تلاش برای تبدیل آدرس‌های شبکه و پخش همگانی (broadcast) به نام‌ها.
.TP
.B \-c
خروج پس از دریافت
.I count
بسته.
.TP
.B \-d
کد کامپایل‌شدهٔ تطبیق بسته (packet-matching code) را به شکلی خوانا برای انسان به خروجی استاندارد ریخته و متوقف می‌شود.
.TP
.B \-dd
کد تطبیق بسته (packet-matching code) را در قالب قطعه‌کدی از زبان
.B C
خروجی می‌دهد.
.TP
.B \-ddd
کد تطبیق بسته (packet-matching code) را به‌صورت اعداد ده‌دهی (همراه با تعداد در ابتدا) خروجی می‌دهد.
.TP
.B \-e
چاپ هدر لایهٔ پیوند داده (link-level header) در هر سطر خروجی.
.TP
.B \-f
آدرس‌های اینترنتی «خارجی» را به‌جای نمادین، به‌صورت عددی چاپ می‌کند (این گزینه برای دور زدن مشکل اساسی سرور yp شرکت Sun به کار می‌رود \(em که معمولاً هنگام ترجمهٔ شماره‌های شبکهٔ محلی برای همیشه معلق می‌ماند).
.TP
.B \-F
استفاده از محتوای
\fIfile\fP
به‌عنوان عبارت فیلتر. عبارتی که در خط فرمان وارد شده باشد نادیده گرفته می‌شود.
.TP
.B \-i
شنود روی رابط شبکهٔ
\fIinterface\fP.
اگر رابطی مشخص نشود،
\fItcpdump\fP
در فهرست رابط‌های سیستم، رابط فعال و پیکربندی‌شده با کمترین شماره (به‌جز loopback) را جستجو می‌کند. در صورت وجود گزینه‌های هم‌رتبه، نخستین مورد انتخاب می‌شود.
.TP
.B \-l
بافر کردن سطری خروجی استاندارد. زمانی که می‌خواهید داده‌ها را هم‌زمان با ضبط مشاهده کنید کاربرد دارد؛ برای نمونه:
.br
``tcpdump\ \ \-l\ \ |\ \ tee dat'' یا
``tcpdump\ \ \-l\ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''.
.TP
.B \-n
عدم تبدیل آدرس‌ها (مانند آدرس‌های میزبان، شماره پورت‌ها و غیره) به نام.
.TP
.B \-N
عدم چاپ بخش دامنه در نام‌های میزبان. برای نمونه، با فعال بودن این گزینه،
\fItcpdump\fP
به‌جای ``nic.ddn.mil'' عبارت ``nic'' را چاپ می‌کند.
.TP
.B \-O
عدم اجرای بهینه‌ساز کد تطبیق بسته. این گزینه تنها زمانی کاربرد دارد که به وجود اشکالی در بهینه‌ساز مشکوک باشید.
.TP
.B \-p
\fIعدم\fP قرار دادن رابط شبکه در حالت بی‌قیدوشرط (promiscuous mode). توجه داشته باشید که ممکن است رابط شبکه به دلایل دیگری در این حالت باشد؛ بنابراین، گزینهٔ
.B \-p
نمی‌تواند به‌عنوان مخففی برای
`ether host {local-hw-addr} or ether broadcast'
به کار رود.
.TP
.B \-q
خروجی سریع و کوتاه؛ اطلاعات کمتری از پروتکل‌ها چاپ می‌شود تا سطرهای خروجی کوتاه‌تر باشند.
.TP
.B \-r
خواندن بسته‌ها از
\fIfile\fR
(که پیش‌تر با گزینهٔ \-w ایجاد شده است). اگر مقدار
\fIfile\fR
برابر ``-'' باشد، داده‌ها از ورودی استاندارد خوانده می‌شوند.
.TP
.B \-s
دریافت
\fIsnaplen\fP
بایت داده از هر بسته به‌جای مقدار پیش‌فرض ۶۸ بایت (در NIT سیستم‌عامل SunOS، حداقل مقدار در عمل ۹۶ است). مقدار ۶۸ بایت برای پروتکل‌های IP، ICMP، TCP و UDP کافی است، اما ممکن است اطلاعات پروتکل مربوط به سرورهای نام (DNS) و بسته‌های NFS را ناقص کند (به بخش‌های بعد مراجعه کنید). بسته‌هایی که به دلیل عکس‌برداری محدود بریده شده‌اند، در خروجی با علامت
``[|\fIproto\fP]''
مشخص می‌شوند که در آن
\fIproto\fP
نام لایهٔ پروتکلی است که برش در آن رخ داده است. توجه داشته باشید که بزرگ‌تر کردن اندازهٔ ضبط، هم زمان پردازش بسته‌ها را افزایش می‌دهد و هم بافرینگ بسته‌ها را کاهش می‌دهد که ممکن است باعث از دست رفتن بسته‌ها شود. شما باید
\fIsnaplen\fP
را تا حد امکان کوچک انتخاب کنید، به طوری که تنها اطلاعات پروتکل مورد نیاز شما را در بر گیرد.
.TP
.B \-T
وادار ساختن بسته‌های انتخاب‌شده توسط
"\fIexpression\fP"
به تفسیر به عنوان نوع مشخص‌شدهٔ
\fItype\fR.
انواع شناخته‌شده در حال حاضر عبارتند از:
\fBrpc\fR
(فراخوانی رویه از راه دور - Remote Procedure Call)،
\fBrtp\fR
(پروتکل کاربردهای بی‌درنگ - Real-Time Applications protocol)،
\fBrtcp\fR
(پروتکل کنترل کاربردهای بی‌درنگ - Real-Time Applications control protocol)،
\fBvat\fR
(ابزار صوتی تصویری - Visual Audio Tool)
و
\fBwb\fR
(تخته‌سفید توزیع‌شده - distributed White Board).
.TP
.B \-S
نمایش شماره توالی‌های مطلق به جای شماره توالی‌های نسبی TCP.
.TP
.B \-t
\fIعدم\fP چاپ برچسب زمانی روی هر سطر خروجی.
.TP
.B \-tt
چاپ برچسب زمانی بدون قالب‌بندی (ثانیه‌های خام) روی هر سطر خروجی.
.TP
.B \-v
خروجی با جزئیات بیشتر (verbose). برای نمونه، زمان حیات (TTL) و نوع سرویس (TOS) در بستهٔ IP نمایش داده می‌شوند.
.TP
.B \-vv
خروجی با جزئیات حتی بیشتر. برای نمونه، فیلدهای اضافی بسته‌های پاسخ NFS چاپ می‌شوند.
.TP
.B \-w
نوشتن بسته‌های خام در
\fIfile\fR
به‌جای تجزیه و نمایش آن‌ها. بعداً می‌توان آن‌ها را با گزینهٔ \-r نمایش داد. اگر مقدار
\fIfile\fR
برابر ``-'' باشد، بسته‌ها در خروجی استاندارد نوشته می‌شوند.
.TP
.B \-x
چاپ هر بسته (منهای هدر لایهٔ پیوند آن) به صورت هگزادسیمال. مقدار کمتر بین کل بسته یا
.I snaplen
بایت چاپ خواهد شد.
.IP "\fIexpression\fP"
.RS
بسته‌هایی را که باید ضبط شوند انتخاب می‌کند. اگر
\fIexpression\fP
مشخص نشود، تمام بسته‌های روی شبکه ثبت می‌شوند. در غیر این صورت، تنها بسته‌هایی ثبت می‌شوند که عبارت
\fIexpression\fP
برای آن‌ها مقدار 'درست' (true) داشته باشد.
.LP
عبارت
\fIexpression\fP
از یک یا چند
.I شناسه اولیه (primitive)
تشکیل شده است. یک شناسه اولیه معمولاً از یک
.I شناسه (id)
(نام یا شماره)، و یک یا چند توصیف‌کننده (qualifier) پیش از آن تشکیل می‌شود. سه نوع مختلف توصیف‌کننده وجود دارد:
.IP \fItype\fP
توصیف‌کننده‌های نوع (type) مشخص می‌کنند که نام یا شمارهٔ شناسه به چه چیزی اشاره دارد. انواع ممکن عبارتند از:
.BR host ،
.B net
و
.BR port .
برای نمونه: `host foo'، `net 128.3'، `port 20'. اگر توصیف‌کنندهٔ نوع مشخص نشود، مقدار پیش‌فرض
.B host
در نظر گرفته می‌شود.

.IP \fIdir\fP
توصیف‌کننده‌های جهت (dir) جهت انتقال داده را نسبت به
.B شناسه
مشخص می‌کنند (اینکه داده به سمت شناسه می‌رود یا از آن می‌آید). جهت‌های ممکن عبارتند از:
.BR src ،
.BR dst ،
.B "src or dst"
و
.B "src and"
.BR dst .
برای نمونه: `src foo'، `dst net 128.3'، `src or dst port ftp-data'.
اگر توصیف‌کنندهٔ جهت مشخص نشود، مقدار پیش‌فرض
.B "src or dst"
است.
برای لایه‌های پیوند «تهی» (null) (مانند پروتکل‌های نقطه‌به‌نقطه نظیر slip)، توصیف‌کننده‌های
.B inbound
و
.B outbound
جهت انتقال مورد نظر را مشخص می‌کنند.
.IP \fIproto\fP
توصیف‌کننده‌های پروتکل (proto) تطبیق را به یک پروتکل خاص محدود می‌کنند. پروتکل‌های ممکن عبارتند از:
.BR ether ،
.BR fddi ،
.BR ip ،
.BR arp ،
.BR rarp ،
.BR decnet ،
.BR lat ،
.BR sca ،
.BR moprc ،
.BR mopdl ،
.B tcp
و
.BR udp .
برای نمونه: `ether src foo'، `arp net 128.3'، `tcp port 21'. اگر توصیف‌کنندهٔ پروتکل مشخص نشود، تمام پروتکل‌های سازگار با آن نوع فرض می‌شوند؛ برای نمونه: `src foo' به معنای
`(ip or arp or rarp) src foo'
است (توجه کنید که این نمونه برای نشان دادن مفهوم است و از نظر دستوری معتبر نیست)،
`net bar'
به معنای
`(ip or arp or rarp) net bar'
و
`port 53'
به معنای
`(tcp or udp) port 53'
است.
.LP
[\fBfddi\fP در واقع یک نام مستعار برای \fBether\fP است؛ تحلیل‌گر با هر دو به‌صورت یکسان به عنوان «لایهٔ پیوند دادهٔ مورد استفاده در رابط شبکهٔ مشخص‌شده» رفتار می‌کند. هدرهای FDDI شامل آدرس‌های مبدأ و مقصد مشابه اترنت هستند و معمولاً انواع بسته‌ای مشابه اترنت دارند، بنابراین می‌توانید روی این فیلدهای FDDI درست مانند فیلدهای اترنت فیلتر بگذارید. هدرهای FDDI شامل فیلدهای دیگری نیز هستند، اما نمی‌توانید آن‌ها را به‌طور صریح در عبارت فیلتر نام ببرید.]

.LP
علاوه بر موارد فوق، کلمات کلیدی ویژه‌ای برای «شناسه‌های اولیه» وجود دارند:
.BR gateway ،
.BR broadcast ،
.BR less ،
.B greater
و عبارات ریاضی.
این موارد از الگوی بالا پیروی نمی‌کنند و در ادامه شرح داده شده‌اند.
.LP
عبارات فیلتر پیچیده‌تر را می‌توان با ترکیب شناسه‌های اولیه با استفاده از کلمات
.BR and ،
.B or
و
.B not
ایجاد کرد؛ برای نمونه: `host foo and not port ftp and not port ftp-data'.
برای کاهش تایپ، می‌توان توصیف‌کننده‌های تکراری را حذف کرد؛ برای نمونه:
`tcp dst port ftp or ftp-data or domain'
دقیقاً معادل است با:
`tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.
.LP
شناسه‌های اولیه مجاز عبارتند از:
.IP "\fBdst host \fIhost\fR"
اگر فیلد مقصد IP بسته برابر با \fIhost\fP باشد، نتیجه درست است. \fIhost\fP می‌تواند یک آدرس یا یک نام میزبان باشد.
.IP "\fBsrc host \fIhost\fR"
اگر فیلد مبدأ IP بسته برابر با \fIhost\fP باشد، نتیجه درست است.
.IP "\fBhost \fIhost\fP"
اگر مبدأ یا مقصد IP بسته برابر با \fIhost\fP باشد، نتیجه درست است.
به هر یک از عبارات host بالا می‌توان پیشوند کلمات کلیدی
\fBip\fP، \fBarp\fP یا \fBrarp\fP
را اضافه کرد، مانند:
.in +.5i
.nf
\fBip host \fIhost\fR
.fi
.in -.5i
که معادل است با:
.in +.5i
.nf
\fBether proto \fI\\ip\fB and host \fIhost\fR
.fi
.in -.5i
اگر \fIhost\fR نام میزبانی با چندین آدرس IP باشد، هر یک از آدرس‌های آن بررسی می‌شود.

.IP "\fBether dst \fIehost\fP"
اگر آدرس اترنت مقصد بسته برابر با \fIehost\fP باشد، نتیجه درست است. \fIEhost\fP می‌تواند یک نام (از فایل /etc/ethers) یا یک شماره باشد (برای ساختار شماره‌ها به
.IR ethers (3N)
مراجعه کنید).
.IP "\fBether src \fIehost\fP"
اگر آدرس اترنت مبدأ بسته برابر با \fIehost\fP باشد، نتیجه درست است.
.IP "\fBether host \fIehost\fP"
اگر آدرس اترنت مبدأ یا مقصد بسته برابر با \fIehost\fP باشد، نتیجه درست است.
.IP "\fBgateway\fP \fIhost\fP"
اگر بسته از \fIhost\fP به‌عنوان دروازه (gateway) استفاده کرده باشد، نتیجه درست است؛ به این معنی که آدرس اترنت مبدأ یا مقصد بسته برابر با \fIhost\fP است، اما هیچ‌یک از آدرس‌های IP مبدأ یا مقصد \fIhost\fP نیستند. \fIhost\fP باید یک نام میزبان باشد و باید در هر دو فایل /etc/hosts و /etc/ethers موجود باشد (یک عبارت معادل:
.in +.5i
.nf
\fBether host \fIehost \fBand not host \fIhost\fR
.fi
.in -.5i
است که در آن \fIhost / ehost\fP می‌تواند نام یا شماره باشد).
.IP "\fBdst net \fInet\fR"
اگر آدرس IP مقصد بسته متعلق به شبکهٔ \fInet\fP باشد، نتیجه درست است. \fInet\fP می‌تواند یک نام (از /etc/networks) یا یک شماره شبکه باشد (برای جزئیات به
.IR networks (4)
مراجعه کنید).
.IP "\fBsrc net \fInet\fR"
اگر آدرس IP مبدأ بسته متعلق به شبکهٔ \fInet\fP باشد، نتیجه درست است.
.IP "\fBnet \fInet\fR"
اگر آدرس IP مبدأ یا مقصد بسته متعلق به شبکهٔ \fInet\fP باشد، نتیجه درست است.
.IP "\fBnet \fInet\fR \fBmask \fImask\fR"
اگر آدرس IP با ماسک شبکهٔ مشخص‌شده در \fInet\fR مطابقت داشته باشد، نتیجه درست است.
می‌توان این شناسه را با
\fBsrc\fR
یا
\fBdst\fR
ترکیب کرد.
.IP "\fBnet \fInet\fR/\fIlen\fR"
اگر آدرس IP با ماسک شبکهٔ با طول \fIlen\fR بیت از \fInet\fR مطابقت داشته باشد، نتیجه درست است.
می‌توان این شناسه را با
\fBsrc\fR
یا
\fBdst\fR
ترکیب کرد.
.IP "\fBdst port \fIport\fR"
اگر بسته از نوع ip/tcp یا ip/udp بوده و پورت مقصد آن \fIport\fP باشد، نتیجه درست است.
\fIport\fP می‌تواند یک عدد یا نام مشخص‌شده در /etc/services باشد (به
.IR tcp (4P)
و
.IR udp (4P)
مراجعه کنید).
اگر از یک نام استفاده شود، هم شماره پورت و هم پروتکل بررسی می‌شوند. اگر از یک عدد یا یک نام دارای ابهام استفاده شود، تنها شماره پورت بررسی می‌شود (برای نمونه، \fBdst port 513\fR داده‌های tcp/login و udp/who را نمایش می‌دهد، و \fBport domain\fR داده‌های tcp/domain و udp/domain را نمایش می‌دهد).
.IP "\fBsrc port \fIport\fR"
اگر شماره پورت مبدأ بسته برابر با \fIport\fP باشد، نتیجه درست است.
.IP "\fBport \fIport\fR"
اگر پورت مبدأ یا مقصد بسته برابر با \fIport\fP باشد، نتیجه درست است.
هر یک از عبارات پورت بالا می‌توانند با کلمات کلیدی
\fBtcp\fP
یا
\fBudp\fP
پیشوندگذاری شوند، مانند:
.in +.5i
.nf
\fBtcp src port \fIport\fR
.fi
.in -.5i
که تنها با بسته‌های TCP با پورت مبدأ \fIport\fP مطابقت دارد.
.IP "\fBless \fIlength\fR"
اگر طول بسته کمتر یا مساوی \fIlength\fP باشد، نتیجه درست است؛ معادل با:
.in +.5i
.nf
\fBlen <= \fIlength\fP.
.fi
.in -.5i
.IP "\fBgreater \fIlength\fR"
اگر طول بسته بزرگتر یا مساوی \fIlength\fP باشد، نتیجه درست است؛ معادل با:
.in +.5i
.nf
\fBlen >= \fIlength\fP.
.fi
.in -.5i
.IP "\fBip proto \fIprotocol\fR"
اگر بسته یک بستهٔ IP باشد (به
.IR ip (4P)
مراجعه کنید) که نوع پروتکل آن \fIprotocol\fP است، نتیجه درست است.
\fIProtocol\fP می‌تواند یک عدد یا یکی از نام‌های زیر باشد:
\fIicmp\fP، \fIigrp\fP، \fIudp\fP، \fInd\fP یا \fItcp\fP.
توجه داشته باشید که شناسه‌های \fItcp\fP، \fIudp\fP و \fIicmp\fP همچنین کلمات کلیدی هستند، بنابراین باید با یک بک‌اسلش (\\) اسکیپ شوند، که در C-shell باید به‌صورت \\\\ باشد.
.IP "\fBether broadcast\fR"
اگر بسته یک بستهٔ پخش همگانی اترنت باشد، نتیجه درست است. کلمهٔ کلیدی \fIether\fP اختیاری است.
.IP "\fBip broadcast\fR"
اگر بسته یک بستهٔ پخش همگانی IP باشد، نتیجه درست است. دستور Tcpdump قراردادهای پخش همگانی همه‌صفر و همه‌یک را بررسی کرده و ماسک زیرشبکهٔ محلی را نیز اعمال می‌کند.
.IP "\fBether multicast\fR"
اگر بسته یک بستهٔ چندپخشی اترنت (multicast) باشد، نتیجه درست است. کلمهٔ کلیدی \fIether\fP اختیاری است؛ این عبارت در واقع کوتاه‌شدهٔ
`\fBether[0] & 1 != 0\fP'
است.
.IP "\fBip multicast\fR"
اگر بسته یک بستهٔ چندپخشی IP باشد، نتیجه درست است.
.IP "\fBether proto \fIprotocol\fR"
اگر پروتکل بسته متعلق به نوع اترنت \fIprotocol\fR باشد، نتیجه درست است.
\fIProtocol\fP می‌تواند یک عدد یا یک نام مانند
\fIip\fP، \fIarp\fP یا \fIrarp\fP
باشد.
توجه داشته باشید که این شناسه‌ها کلمات کلیدی نیز هستند، بنابراین باید با یک بک‌اسلش (\\) اسکیپ شوند.
[در صورت استفاده از FDDI (مانند `\fBfddi protocol arp\fR')، شناسایی پروتکل از هدر کنترل پیوند منطقی 802.2 (LLC) ناشی می‌شود که معمولاً در بالای هدر FDDI قرار دارد. هنگام فیلتر کردن بسته‌ها بر اساس شناسهٔ پروتکل،
\fItcpdump\fP
فرض می‌کند که تمام بسته‌های FDDI شامل هدر LLC هستند و این هدر در قالب SNAP است.]

.IP "\fBdecnet src \fIhost\fR"
اگر آدرس مبدأ DECNET برابر با
.IR host
باشد، نتیجه درست است؛ که ممکن است به شکل ``10.123'' یا یک نام میزبان DECNET باشد. [تنها سیستم‌های Ultrix که برای اجرای DECNET پیکربندی شده‌اند از نام‌های میزبان DECNET پشتیبانی می‌کنند.]
.IP "\fBdecnet dst \fIhost\fR"
اگر آدرس مقصد DECNET برابر با
.IR host
باشد، نتیجه درست است.
.IP "\fBdecnet host \fIhost\fR"
اگر آدرس مبدأ یا مقصد DECNET برابر با
.IR host
باشد، نتیجه درست است.
.IP "\fBip\fR, \fBarp\fR, \fBrarp\fR, \fBdecnet\fR"
کوتاه‌شدهٔ عبارت:
.in +.5i
.nf
\fBether proto \fIp\fR
.fi
.in -.5i
است که در آن \fIp\fR یکی از پروتکل‌های یادشده است.
.IP "\fBlat\fR, \fBmoprc\fR, \fBmopdl\fR"
کوتاه‌شدهٔ عبارت:
.in +.5i
.nf
\fBether proto \fIp\fR
.fi
.in -.5i
است که در آن \fIp\fR یکی از پروتکل‌های یادشده است. توجه داشته باشید که
\fItcpdump\fP
در حال حاضر نحوهٔ تجزیه و تحلیل این پروتکل‌ها را نمی‌داند.
.IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
کوتاه‌شدهٔ عبارت:
.in +.5i
.nf
\fBip proto \fIp\fR
.fi
.in -.5i
است که در آن \fIp\fR یکی از پروتکل‌های یادشده است.
.IP "\fIexpr relop expr\fR"
اگر این رابطه برقرار باشد، نتیجه درست است؛ که در آن \fIrelop\fR یکی از عملگرهای >، <، >=، <=، =، != است و \fIexpr\fR یک عبارت محاسباتی تشکیل‌شده از ثابت‌های صحیح (به قالب استاندارد C)، عملگرهای دودویی معمول [+, -, *, /, &, |]، یک عملگر طول بسته، و عملگرهای دسترسی به داده‌های بسته است. برای دسترسی به داده‌های درون بسته، از ساختار نحوی زیر استفاده کنید:
.in +.5i
.nf
\fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
.fi
.in -.5i
که در آن \fIproto\fR یکی از موارد
\fBether, fddi, ip, arp, rarp, tcp, udp, \fRیا \fBicmp\fR
است و لایهٔ پروتکل برای عملیات اندیس‌گذاری را مشخص می‌کند. \fIexpr\fR آفست بایت را نسبت به لایهٔ پروتکل مشخص‌شده نشان می‌دهد. \fIsize\fR اختیاری است و تعداد بایت‌های مورد نظر را مشخص می‌کند؛ می‌تواند 1، 2 یا 4 باشد و پیش‌فرض آن 1 بایت است. عملگر طول که با کلمهٔ کلیدی
\fBlen\fP
مشخص می‌شود، طول کل بسته را نشان می‌دهد.

برای نمونه، `\fBether[0] & 1 != 0\fP' تمامی بسته‌های چندپخشی را دریافت می‌کند. عبارت `\fBip[0] & 0xf != 5\fP' تمام بسته‌های IP دارای فیلدهای اختیاری را دریافت می‌کند. عبارت `\fBip[6:2] & 0x1fff = 0\fP' تنها داده‌های قطعه‌بندی‌نشده و بسته‌های با آفست قطعه صفر را دریافت می‌کند. این بررسی به‌طور ضمنی در عملیات اندیس‌گذاری \fBtcp\fP و \fBudp\fP اعمال می‌شود؛ برای نمونه، \fBtcp[0]\fP همیشه نخستین بایت از \fIهدر\fP TCP است و هرگز اولین بایت یک قطعهٔ IP میانی نیست.
.LP
شناسه‌های اولیه را می‌توان با روش‌های زیر ترکیب کرد:
.IP
گروهی از شناسه‌ها و عملگرها محصور در پرانتز (پرانتزها در پوسته کاراکترهای ویژه هستند، بنابراین باید اسکیپ شوند).
.IP
عمل نقیض (`\fB!\fP' یا `\fBnot\fP').
.IP
عمل عطف منطقی (`\fB&&\fP' یا `\fBand\fP').
.IP
عمل فصل منطقی (`\fB||\fP' یا `\fBor\fP').
.LP
عمل نقیض بالاترین اولویت را دارد. عمل فصل و عمل عطف اولویت یکسانی دارند و ارزیابی آن‌ها از چپ به راست انجام می‌شود. توجه داشته باشید که عمل عطف نیاز به عملگر صریح \fBand\fR دارد و قرار گرفتن در کنار هم کافی نیست.
.LP
اگر شناسه‌ای بدون کلمهٔ کلیدی وارد شود، کلمهٔ کلیدی اخیراً استفاده‌شده فرض می‌شود؛ برای نمونه:
.in +.5i
.nf
\fBnot host vs and ace\fR
.fi
.in -.5i
کوتاه‌شدهٔ عبارت:
.in +.5i
.nf
\fBnot host vs and host ace\fR
.fi
.in -.5i
است، و نباید با عبارت:
.in +.5i
.nf
\fBnot ( host vs or ace )\fR
.fi
.in -.5i
اشتباه گرفته شود.
.LP
آرگومان‌های عبارت فیلتر را می‌توان به‌صورت یک آرگومان منفرد یا به‌صورت چند آرگومان به tcpdump ارسال کرد که دومی معمولاً راحت‌تر است. به‌طور کلی، اگر عبارت شامل نویسه‌های کنترلی (metacharacters) پوسته باشد، ارسال آن به‌عنوان یک آرگومان محصور در نقل‌قول ساده‌تر خواهد بود. چند آرگومان پیش از تجزیه، با فاصله به هم متصل می‌شوند.

.SH "مثال‌ها (EXAMPLES)"
.LP
نمایش تمامی بسته‌های ورودی یا خروجی از میزبان \fIsundown\fP:
.RS
.nf
\fBtcpdump host sundown\fP
.fi
.RE
.LP
نمایش ترافیک بین \fIhelios\fR و هر یک از میزبان‌های \fIhot\fR یا \fIace\fR:
.RS
.nf
\fBtcpdump host helios and \\( hot or ace \\)\fP
.fi
.RE
.LP
نمایش تمامی بسته‌های IP بین \fIace\fR و همهٔ میزبان‌ها به‌جز \fIhelios\fR:
.RS
.nf
\fBtcpdump ip host ace and not helios\fP
.fi
.RE
.LP
نمایش تمامی داده‌های شبکه بین میزبان‌های محلی و میزبان‌های Berkeley:
.RS
.nf
.B
tcpdump net ucb-ether
.fi
.RE
.LP
نمایش تمامی بسته‌های ftp عبوری از دروازهٔ \fIsnup\fP
(توجه داشته باشید که این عبارت برای جلوگیری از تفسیر پرانتزها توسط پوسته، در نقل‌قول تکی محصور شده است):
.RS
.nf
.B
tcpdump 'gateway snup and (port ftp or ftp-data)'
.fi
.RE
.LP
نمایش ترافیکی که نه از میزبان محلی نشأت گرفته و نه به مقصد آن ارسال می‌شود
(اگر بسته‌ها از طریق یک دروازه وارد شبکهٔ دیگری شوند، هرگز به شبکهٔ محلی شما نخواهند رسید):
.RS
.nf
.B
tcpdump ip and not net \fIlocalnet\fP
.fi
.RE
.LP
نمایش بسته‌های شروع و پایان هر نشست TCP (بسته‌های SYN و FIN) که یکی از طرفین آن یک میزبان دوردست باشد:
.RS
.nf
.B
tcpdump 'tcp[13] & 3 != 0 and not src and dst net \fIlocalnet\fP'
.fi
.RE
.LP
نمایش بسته‌های IP عبوری از دروازهٔ \fIsnup\fP که بزرگتر از ۵۷۶ بایت هستند:
.RS
.nf
.B
tcpdump 'gateway snup and ip[2:2] > 576'
.fi
.RE
.LP
نمایش بسته‌های پخش همگانی یا چندپخشی IP که
.I نه
به‌صورت پخش همگانی اترنت و نه چندپخشی اترنت ارسال شده‌اند:
.RS
.nf
.B
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
.fi
.RE
.LP
نمایش تمامی بسته‌های ICMP که از نوع درخواست/پاسخ echo نیستند (یعنی بسته‌های پینگ نیستند):
.RS
.nf
.B
tcpdump 'icmp[0] != 8 and icmp[0] != 0'
.fi
.RE
.SH "قالب خروجی (OUTPUT FORMAT)"
.LP
قالب خروجی
\fItcpdump\fP
به پروتکل بستگی دارد. در ادامه شرح کوتاهی از بیشتر قالب‌ها و مثال‌هایی از آن‌ها آورده شده است.
.de HD
.sp 1.5
.B
..
.HD
هدرهای لایه پیوند (Link Level Headers)
.LP
اگر گزینهٔ '\-e' مشخص شود، هدرهای لایهٔ پیوند چاپ می‌شوند.

روی اترنت، آدرس‌های مبدأ و مقصد، پروتکل و طول بسته نمایش داده می‌شوند.
.LP
روی شبکه‌های FDDI، گزینهٔ '\-e' باعث می‌شود که \fItcpdump\fP فیلد «کنترل فریم (frame control)»، آدرس‌های مبدأ و مقصد و طول بسته را نمایش دهد (فیلد «کنترل فریم» تفسیر بخش‌های باقی‌ماندهٔ بسته را تعیین می‌کند. بسته‌های معمولی، مانند آن‌هایی که حامل داده‌های IP هستند، بسته‌های «ناهمگام (async)» با اولویت بین ۰ تا ۷ هستند؛ برای نمونه: `\fBasync4\fR`. فرض می‌شود که این بسته‌ها حامل بستهٔ کنترل پیوند منطقی 802.2 (LLC) هستند؛ اگر بسته‌ها داده‌های ISO یا به‌اصطلاح بستهٔ SNAP \fIنباشند\fR، هدر LLC نمایش داده می‌شود).
.LP
\fI(توجه: در توضیحات زیر فرض می‌شود که با الگوریتم فشرده‌سازی SLIP شرح داده شده در RFC-1144 آشنایی دارید.)\fP
.LP
روی پیوندهای SLIP، دستور \fItcpdump\fP جهت ارسال (``I'' برای ورودی یا inbound، و ``O'' برای خروجی یا outbound)، نوع بسته و اطلاعات فشرده‌سازی را چاپ می‌کند. ابتدا نوع بسته چاپ می‌شود؛ سه نوع بسته وجود دارد:
\fIip\fP، \fIutcp\fP و \fIctcp\fP.
برای بسته‌های
\fIip\fR
اطلاعات پیوند بیشتری نمایش داده نمی‌شود. برای بسته‌های TCP، پس از نوع، شناسهٔ اتصال چاپ می‌شود. اگر بسته فشرده شده باشد، هدر کدگذاری‌شدهٔ آن نمایش داده می‌شود. این حالت‌های ویژه به شکل
\fB*S+\fIn\fR
و
\fB*SA+\fIn\fR
نمایش داده می‌شوند که در آن‌ها
\fIn\fR
میزان کل تغییر در شماره توالی (یا شماره توالی و ack) است. اگر حالت ویژه‌ای نباشد، صفر یا چند تغییر نمایش داده می‌شود. تغییر با یکی از حروف U (اشاره‌گر فوری)، W (پنجره)، A (تأییدیه یا ack)، S (شماره توالی) و I (شناسه بسته) مشخص شده و پس از آن یک مقدار تغییر (+n یا -n) یا یک مقدار جدید (=n) قرار می‌گیرد. در پایان، مقدار کل داده‌های درون بسته و طول هدر فشرده نمایش داده می‌شود.
.LP
برای نمونه، سطر زیر یک بستهٔ فشردهٔ خروجی TCP را با شناسهٔ اتصال ضمنی نشان می‌دهد؛ تغییر مقدار تأییدیه (ack) برابر با ۶ است، شماره توالی ۴۹ واحد و شناسه بسته ۶ واحد افزایش یافته است؛ سه بایت داده و شش بایت هدر فشرده وجود دارد:
.RS
.nf
\fBO ctcp * A+6 S+49 I+6 3 (6)\fP
.fi
.RE
.HD
بسته‌های ARP/RARP
.LP
خروجی بسته‌های arp/rarp شامل نوع درخواست و پارامترهای آن است. قالب خروجی تا حد زیادی خودتوضیح است. در اینجا نمونهٔ ساده‌ای از شروع یک نشست 'rlogin' از میزبان \fIrtsg\fP به میزبان \fIcsam\fP آورده شده است:
.RS
.nf
.sp .5
\f(CWarp who-has csam tell rtsg
arp reply csam is-at CSAM\fP
.sp .5
.fi
.RE
سطر نخست نشان می‌دهد که rtsg یک بستهٔ arp فرستاده و آدرس اترنت میزبان اینترنتی csam را جویا شده است. Csam با آدرس اترنت خود پاسخ می‌دهد (در این مثال، آدرس‌های اترنت با حروف بزرگ و آدرس‌های اینترنتی با حروف کوچک هستند).
.LP
اگر با \fBtcpdump \-n\fP مشاهده شود، خروجی واضح‌تر خواهد بود:
.RS
.nf
.sp .5
\f(CWarp who-has 128.3.254.6 tell 128.3.254.68
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4\fP
.fi
.RE
.LP
اگر از \fBtcpdump \-e\fP استفاده شود، مشخص می‌شود که بستهٔ اول یک پخش همگانی (broadcast) و بستهٔ دوم نقطه‌به‌نقطه است:
.RS
.nf
.sp .5
\f(CWRTSG Broadcast 0806  64: arp who-has csam tell rtsg
CSAM RTSG 0806  64: arp reply csam is-at CSAM\fP
.sp .5
.fi
.RE
در اینجا بستهٔ نخست نشان می‌دهد که آدرس مبدأ اترنت RTSG است، مقصد آدرس پخش همگانی اترنت است، فیلد نوع برابر با عدد هگزادسیمال 0806 (نوع ETHER_ARP) بوده و طول کل بسته ۶۴ بایت است.
.HD
بسته‌های TCP
.LP
\fI(توجه: در توضیحات زیر فرض می‌شود که با پروتکل TCP شرح داده شده در RFC-793 آشنایی دارید؛ اگر با این پروتکل آشنا نیستید، نه این متن و نه tcpdump فایدهٔ چندانی برای شما نخواهند داشت.)\fP
.LP
به‌طور کلی، قالب خروجی پروتکل tcp به صورت زیر است:
.RS
.nf
.sp .5
\fIsrc > dst: flags data-seqno ack window urgent options\fP
.sp .5
.fi
.RE
فیلدهای \fIsrc\fP و \fIdst\fP آدرس‌ها و پورت‌های مبدأ و مقصد IP هستند. \fIFlags\fP شامل یکی از پرچم‌های S (SYN)، F (FIN)، P (PUSH) یا R (RST) یا یک `.' تنها (بدون پرچم)، یا ترکیبی از آن‌ها است. \fIData-seqno\fP موقعیت داده‌های این بسته را در شماره توالی جریان مشخص می‌کند (به مثال زیر مراجعه کنید). \fIAck\fP شماره توالی بایت بعدی است که این منبع انتظار دریافت آن را روی این اتصال دارد. \fIWindow\fP اندازهٔ بافر دریافت منبع بر حسب بایت روی این اتصال است. \fIUrg\fP نشان می‌دهد که داده‌های `فوری (urgent)' درون بسته وجود دارد. \fIOptions\fP گزینه‌های tcp هستند که در پرانتزهای شکسته محصور شده‌اند (مانند <mss 1024>).
.LP
فیلدهای \fIsrc, dst\fP و \fIflags\fP همواره وجود دارند. سایر فیلدها بسته به محتوای هدر tcp بسته، تنها در صورت نیاز چاپ می‌شوند.
.LP
در ادامه بخش ابتدایی یک اتصال rlogin از میزبان \fIrtsg\fP به میزبان \fIcsam\fP آورده شده است:
.RS
.nf
.sp .5
\s-2\f(CWrtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fP\s+2
.sp .5
.fi
.RE
سطر نخست نشان می‌دهد که از پورت ۱۰۲۳ پروتکل tcp در rtsg به پورت \fIlogin\fP در csam بسته‌ای ارسال شده است. پرچم \fBS\fP نشان می‌دهد که پرچم \fISYN\fP تنظیم شده است. شماره توالی بسته ۷۶۸۵۱۲ است و فاقد داده می‌باشد (این به صورت `first:last(nbytes)' نوشته می‌شود، به این معنی که `از شماره توالی \fIfirst\fP تا \fIlast\fP، بدون دربرگرفتن \fIlast\fP، به میزان \fInbytes\fP بایت دادهٔ کاربری وجود دارد'). در این لحظه تأییدیهٔ سوارشده (piggy-backed ack) وجود ندارد، پنجرهٔ دریافت معتبر ۴۰۹۶ بایت است، و گزینهٔ بیشینه اندازهٔ بخش (max-segment-size) درخواست تنظیم mss به ۱۰۲۴ بایت را دارد.
.LP
میزبان Csam پاسخی با قالبی مشابه می‌دهد، با این تفاوت که یک تأییدیهٔ سوارشده برای SYN مربوط به rtsg به آن اضافه شده است. سپس Rtsg بستهٔ SYN مربوط به csam را تأیید می‌کند. علامت `.' به معنی عدم تنظیم هیچ پرچمی است. این بسته حاوی داده نیست، بنابراین فاقد شماره توالی داده است. توجه داشته باشید که این شماره توالی تأییدیه یک عدد صحیح کوچک (1) است. هنگامی که \fBtcpdump\fP برای نخستین بار یک گفتگوی tcp را می‌بیند، شماره توالی موجود در بسته را نمایش می‌دهد. در بسته‌های بعدی همان گفتگو، تفاوت شماره توالی بستهٔ فعلی با آن بستهٔ نخستین را چاپ می‌کند. این به این معنی است که از بستهٔ اول به بعد، شماره توالی‌ها را می‌توان به عنوان آفست نسبی در جریان داده در نظر گرفت (که در آن نخستین بایت دادهٔ هر گفتگو از عدد '1' شماره‌گذاری می‌شود). گزینهٔ `\-S' این رفتار را تغییر داده و شماره توالی‌های خام را مستقیماً چاپ می‌کند.
.LP
در سطر ششم، rtsg مقدار ۱۹ بایت داده (بایت‌های ۲ تا ۲۰) را به csam ارسال می‌کند. پرچم PUSH در بسته تنظیم شده است. در سطر هفتم csam اعلام می‌کند که داده‌های ارسال‌شده توسط rtsg را تا بایت ۲۱ دریافت کرده است، اما خود بایت ۲۱ را شامل نمی‌شود. بیشتر داده‌ها آشکارا در بافر سوکت قرار دارند، زیرا اندازهٔ پنجرهٔ دریافت csam کمتر از ۱۹ بایت شده است. هم‌زمان csam یک بایت داده برای rtsg می‌فرستد. سطرهای هشتم و نهم نشان می‌دهند که csam دو بایت دادهٔ فوری را برای rtsg ارسال می‌کند.
.LP
اگر محدودهٔ ضبط آن‌قدر کوچک تنظیم شده باشد که \fBtcpdump\fP نتواند هدر کامل TCP را ضبط کند، تا حد امکان بخش ضبط‌شده را تفسیر کرده و سپس ``[|\fItcp\fP]'' را نمایش می‌دهد تا نشان دهد باقی‌مانده قابل تفسیر نیست. اگر هدر حاوی گزینه‌ای نادرست باشد (طول گزینه بسیار کوچک باشد یا از محدودهٔ هدر فراتر رود)، tcpdump عبارت ``[\fIbad opt\fP]'' را نمایش داده و تفسیر گزینه‌های بعدی را متوقف می‌کند. اگر طول هدر نشان‌دهندهٔ وجود گزینه‌ها باشد اما طول دیتاگرام IP برای نگهداری واقعی گزینه‌ها کافی نباشد، عبارت ``[\fIbad hdr length\fP]'' نمایش داده می‌شود.
.HD
.B
بسته‌های UDP
.LP
قالب UDP مانند نمونهٔ زیر از یک بستهٔ rwho است:
.RS
.nf
.sp .5
\f(CWactinide.who > broadcast.who: udp 84\fP
.sp .5
.fi
.RE
این خروجی نشان می‌دهد که یک بستهٔ دیتاگرام udp از پورت \fIwho\fP در میزبان \fIactinide\fP به پورت \fIwho\fP در \fIbroadcast\fP، آدرس پخش همگانی اینترنت، فرستاده شده است. این بسته شامل ۸۴ بایت دادهٔ کاربری است.
.LP
برخی از سرویس‌های UDP را می‌توان (از روی شماره پورت‌های مبدأ یا مقصد) شناسایی کرد و اطلاعات پروتکل‌های لایه‌های بالاتر را نمایش داد؛ به‌ویژه درخواست‌های سرویس‌دهندهٔ نام دامنه (RFC-1034/1035) و فراخوانی‌های RPC برای NFS (RFC-1050).
.HD
درخواست‌های سرویس‌دهنده نام UDP (Name Server Requests)
.LP
\fI(توجه: در توضیحات زیر فرض می‌شود که با پروتکل سرویس‌دهندهٔ نام شرح داده شده در RFC-1035 آشنایی دارید. اگر با این پروتکل آشنا نیستید، مطالب زیر ممکن است نامفهوم به نظر برسند.)\fP
.LP
قالب درخواست‌های سرویس‌دهندهٔ نام به صورت زیر است:
.RS
.nf
.sp .5
\fIsrc > dst: id op? flags qtype qclass name (len)\fP
.sp .5
\f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fP
.sp .5
.fi
.RE
میزبان \fIh2opolo\fP به سرویس‌دهندهٔ نام روی \fIhelios\fP مراجعه کرده و دربارهٔ رکورد آدرس (qtype=A) مرتبط با \fIucbvax.berkeley.edu.\fP پرس‌وجو می‌کند. شمارهٔ پرس‌وجو `3' است. علامت `+' نشان می‌دهد که پرچم \fIدرخواست بازگشتی (recursion desired)\fP تنظیم شده است. طول پرس‌وجو ۳۷ بایت است، بدون احتساب هدرهای UDP و IP. عملیات پرس‌وجو از نوع استاندارد \fIQuery\fP است، بنابراین فیلد op حذف شده است. اگر op چیز دیگری تنظیم شده بود، بین `3' و `+' نمایش داده می‌شد. به‌طور مشابه، qclass از نوع معمولی \fIC_IN\fP است و حذف شده است؛ سایر انواع qclass پس از `A' نمایش داده می‌شوند.
.LP
دستور Tcpdump برخی شرایط غیرعادی را بررسی می‌کند و نتایج مربوطه را درون کروشه‌ها نمایش می‌دهد: اگر یک پرس‌وجو شامل بخش‌های پاسخ، سرویس‌دهندهٔ نام یا اختیارات باشد، فیلدهای
.IR ancount ،
.IR nscount
یا
.I arcount
به صورت `[\fIn\fPa]'، `[\fIn\fPn]' یا `[\fIn\fPau]' نمایش داده می‌شوند که در آن‌ها \fIn\fP تعداد مربوطه است. اگر در بایت‌های دوم و سوم، هر یک از بیت‌های پاسخ (AA، RA یا rcode) یا هر یک از بیت‌های «باید صفر باشد» تنظیم شده باشند، عبارت `[b2&3=\fIx\fP]' نمایش داده می‌شود که در آن \fIx\fP مقدار هگزادسیمال بایت‌های دوم و سوم هدر است.
.HD
پاسخ‌های سرویس‌دهنده نام UDP
.LP
قالب پاسخ‌های سرویس‌دهندهٔ نام به صورت زیر است:
.RS
.nf
.sp .5
\fIsrc > dst:  id op rcode flags a/n/au type class data (len)\fP
.sp .5
\f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fP
.sp .5
.fi
.RE
در مثال نخست، \fIhelios\fP به پرس‌وجوی شناسهٔ ۳ از \fIh2opolo\fP با ۳ رکورد پاسخ، ۳ رکورد سرویس‌دهندهٔ نام و ۷ رکورد اختیارات پاسخ می‌دهد. نوع نخستین رکورد پاسخ A (آدرس) است و دادهٔ آن آدرس اینترنتی 128.32.137.3 است. طول کل پاسخ ۲۷۳ بایت است، بدون احتساب هدرهای UDP و IP. برای رکورد A با کلاس C_IN، فیلدهای op (پرس‌وجو) و rcode (بدون خطا) حذف شده‌اند.
.LP
در مثال دوم، \fIhelios\fP به پرس‌وجوی شناسهٔ ۲ با وضعیت دامنه وجود ندارد (NXDomain)، بدون هیچ رکورد پاسخ، ۱ رکورد سرویس‌دهندهٔ نام، و بدون رکورد اختیارات پاسخ می‌دهد. علامت `*' نشان می‌دهد که پرچم \fIپاسخ معتبر (authoritative answer)\fP تنظیم شده است. به دلیل عدم وجود رکورد پاسخ، فیلدهای type، class و data نمایش داده نمی‌شوند.
.LP
سایر نویسه‌های پرچم می‌توانند به صورت `\-' (\fIعدم\fP تنظیم بازگشت در دسترس است - RA) و `|' (تنظیم برش پیام - TC) نمایش داده شوند. اگر بخش «سوال» فاقد محتوای معتبر باشد، عبارت `[\fIn\fPq]' چاپ می‌شود.
.LP
توجه داشته باشید که پرس‌وجوها و پاسخ‌های سرویس‌دهندهٔ نام معمولاً بزرگ هستند و ممکن است مقدار پیش‌فرض ۶۸ بایت برای \fIsnaplen\fP نتواند محتوای کافی از بسته را ضبط کند. اگر قصد بررسی دقیق ترافیک سرویس‌دهندهٔ نام را دارید، از گزینهٔ \fB\-s\fP برای افزایش بافر ضبط استفاده کنید؛ گزینهٔ `\fB\-s 128\fP' مناسب خواهد بود.

.HD
درخواست‌ها و پاسخ‌های NFS
.LP
قالب نمایش درخواست‌ها و پاسخ‌های Sun NFS (سیستم فایل شبکه‌ای) به صورت زیر است:
.RS
.nf
.sp .5
\fIsrc.xid > dst.nfs: len op args\fP
\fIsrc.nfs > dst.xid: reply stat len op results\fP
.sp .5
\f(CW
sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
sushi.201b > wrl.nfs:
        144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.201b:
        reply ok 128 lookup fh 9,74/4134.3150
\fP
.sp .5
.fi
.RE
در سطر اول، میزبان \fIsushi\fP یک نشست تعاملی با شناسهٔ \fI6709\fP به \fIwrl\fP ارسال می‌کند (توجه داشته باشید که عدد پس از میزبان مبدأ، شناسهٔ تراکنش است و \fIنه\fP شماره پورت). این درخواست ۱۱۲ بایت طول دارد، بدون احتساب هدرهای UDP و IP. این عملیات روی دستگیرهٔ فایل (\fIfh\fP) با مقدار 21,24/10.731657119 و از نوع \fIreadlink\fP (خواندن پیوند نمادین) است (در صورت مساعد بودن شرایط، مانند این مورد، دستگیرهٔ فایل را می‌توان به ترتیب به شماره‌های دستگاه اصلی و فرعی، شماره inode، و شماره نسل ترجمه کرد). میزبان \fIWrl\fP با `ok' و محتوای پیوند پاسخ می‌دهد.
.LP
در سطر سوم، \fIsushi\fP از \fIwrl\fP می‌خواهد که فایل `\fIxcolors\fP' را در دایرکتوری با دستگیرهٔ 9,74/4096.6878 جستجو کند. توجه داشته باشید که قالب داده‌ها به نوع عملیات بستگی دارد و ساختار آن خودتوضیح است.
.LP
مشخص کردن گزینهٔ \-v (پرگویی) اطلاعات تکمیلی را نمایش می‌دهد؛ برای نمونه:
.RS
.nf
.sp .5
\f(CW
sushi.1372a > wrl.nfs:
        148 read fh 21,11/12.195 8192 bytes @ 24576
wrl.nfs > sushi.1372a:
        reply ok 1472 read REG 100664 ids 417/0 sz 29388
\fP
.sp .5
.fi
.RE
(گزینهٔ \-v همچنین باعث می‌شود فیلدهای TTL، ID و قطعه‌بندی در هدر IP نمایش داده شوند که در این مثال حذف شده‌اند). در سطر اول، \fIsushi\fP از \fIwrl\fP می‌خواهد که از آفست ۲۴۵۷۶ فایل 21,11/12.195، مقدار ۸۱۹۲ بایت را بخواند. \fIWrl\fP با `ok' پاسخ می‌دهد؛ بستهٔ نمایش‌داده‌شده در سطر دوم نخستین قطعه از پاسخ است، بنابراین تنها ۱۴۷۲ بایت طول دارد (بقیهٔ داده‌ها در قطعات بعدی منتقل می‌شوند، اما چون آن قطعات فاقد هدر NFS یا حتی UDP هستند، بسته به عبارت فیلتر به کار رفته ممکن است نمایش داده نشوند). گزینهٔ \-v همچنین برخی از ویژگی‌های فایل را نمایش می‌دهد (که همراه با داده‌های فایل بازگردانده می‌شوند): نوع فایل (فایل معمولی ``REG'')، حالت دسترسی (به هشت‌هشتی)، uid و gid، و اندازهٔ فایل.
.LP
اگر یک گزینهٔ \-v دیگر نیز داده شود (\-vv)، جزئیات حتی بیشتری چاپ می‌شود.
.LP
توجه داشته باشید که داده‌های درخواست‌های NFS بسیار حجیم هستند و اگر مقدار \fIsnaplen\fP افزایش نیابد، بسیاری از جزئیات نمایش داده نخواهند شد؛ گزینهٔ `\fB\-s 192\fP' را امتحان کنید.
.LP
بسته‌های پاسخ NFS به‌طور صریح نوع عملیات RPC را مشخص نمی‌کنند. بنابراین، \fItcpdump\fP رکوردی از درخواست‌های «اخیر» را نگه می‌دارد و بر اساس شناسهٔ تراکنش، پاسخ‌ها را با درخواست‌ها تطبیق می‌دهد. اگر بستهٔ پاسخی فاقد بستهٔ درخواست متناظر باشد، امکان تجزیه و تحلیل آن وجود نخواهد داشت.
.HD
پروتکل KIP Appletalk (پروتکل DDP روی UDP)
.LP
بسته‌های Appletalk DDP درون دیتاگرام‌های UDP بسته‌بندی می‌شوند و پس از خارج شدن از بسته، مانند بسته‌های DDP چاپ می‌شوند (یعنی تمام اطلاعات هدر UDP نادیده گرفته می‌شود). فایل
.I /etc/atalk.names
برای ترجمهٔ شماره‌های شبکه و گره appletalk به نام‌ها به کار می‌رود. قالب سطرهای این فایل به صورت زیر است:
.RS
.nf
.sp .5
\fInumber       name\fP

\f(CW1.254              ether
16.1            icsd-net
1.254.110       ace\fP
.sp .5
.fi
.RE
دو سطر نخست نام شبکه‌های appletalk را مشخص می‌کنند. سطر سوم نام یک میزبان مشخص را تعیین می‌کند (میزبان‌ها و شبکه‌ها بر اساس بخش سوم شماره متمایز می‌شوند \- شماره شبکه \fIالزاماً\fP دو بخش و شماره میزبان \fIالزاماً\fP سه بخش است). شماره و نام با نویسه‌های فاصله یا تب از هم جدا می‌شوند. فایل
.I /etc/atalk.names
می‌تواند شامل سطرهای خالی یا سطرهای توضیحات (که با '#' آغاز می‌شوند) باشد.
.LP
آدرس‌های Appletalk با این قالب نمایش داده می‌شوند:
.RS
.nf
.sp .5
\fInet.host.port\fP

\f(CW144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2\fP
.sp .5
.fi
.RE
(اگر فایل
.I /etc/atalk.names
وجود نداشته باشد، یا فاقد مدخل‌های معتبر باشد، آدرس‌ها به‌صورت عددی چاپ می‌شوند). در مثال اول، پورت NBP (پورت ۲ پروتکل DDP) از گره ۲۰۹ در شبکهٔ 144.1 داده‌ها را به پورت ۲۲۰ از گره ۱۱۲ در شبکهٔ icsd می‌فرستد. سطر دوم مشابه سطر پیشین است با این تفاوت که نام کامل گره مبدأ (`office') مشخص است. سطر سوم یک پخش همگانی از پورت ۲۳۵ از گره ۱۴۹ در شبکهٔ jssmag به پورت NBP در icsd-net است (توجه داشته باشید که آدرس پخش همگانی (255) به‌طور ضمنی در نام شبکه‌ای که شمارهٔ میزبان ندارد مستتر است \- بنابراین تفکیک نام گره و نام شبکه در /etc/atalk.names ایدهٔ خوبی است).
.LP
دستور Tcpdump می‌تواند محتوای بسته‌های NBP (پروتکل اتصال نام) و ATP (پروتکل تراکنش Appletalk) را ترجمه کند. برای سایر پروتکل‌ها تنها نام پروتکل (یا شماره آن در صورتی که نامی برای آن ثبت نشده باشد) و اندازهٔ بسته چاپ می‌شود.

قالب خروجی \fBبسته‌های NBP\fP شبیه به نمونه‌های زیر است:
.RS
.nf
.sp .5
\s-2\f(CWicsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fP\s+2
.sp .5
.fi
.RE
سطر اول یک پخش همگانی توسط میزبان ۱۱۲ از شبکهٔ icsd روی شبکهٔ jssmag برای جستجوی نام laserwriter است. شناسهٔ nbp این درخواست ۱۹۰ است. سطر دوم پاسخی به این درخواست را نشان می‌دهد (توجه کنید که هر دو دارای شناسهٔ یکسانی هستند)؛ میزبان jssmag.209 اعلام می‌کند که روی پورت ۲۵۰ منبعی به نام "RM1140" برای laserwriter ثبت کرده است. سطر سوم پاسخ دیگری به همین درخواست است که در آن میزبان techpit روی پورت ۱۸۶ منبعی به نام "techpit" برای laserwriter دارد.

قالب \fBبسته‌های ATP\fP در مثال زیر نشان داده شده است:
.RS
.nf
.sp .5
\s-2\f(CWjssmag.209.165 > helios.132: atp-req  12266<0-7> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
jssmag.209.165 > helios.132: atp-req  12266<3,5> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
jssmag.209.165 > helios.132: atp-rel  12266<0-7> 0xae030001
jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fP\s+2
.sp .5
.fi
.RE
میزبان Jssmag.209 یک تراکنش با شمارهٔ ۱۲۲۶۶ با میزبان helios آغاز کرده و درخواست ۸ بسته را می‌دهد (`<0-7>'). عدد هگزادسیمال در انتهای سطر، مقدار فیلد `userdata' در درخواست است.
.LP
میزبان Helios با ۸ بستهٔ ۵۱۲ بایتی پاسخ می‌دهد. مقدار `:digit' که پس از شمارهٔ تراکنش می‌آید، شماره توالی بسته در تراکنش را نشان می‌دهد، و عدد داخل پرانتز مقدار داده‌های بسته بدون احتساب هدر atp است. علامت `*' در بستهٔ ۷ نشان می‌دهد که بیت EOM تنظیم شده است.
.LP
سپس Jssmag.209 درخواست ارسال مجدد بسته‌های ۳ و ۵ را می‌کند. پس از ارسال مجدد توسط helios، میزبان jssmag.209 این تراکنش را خاتمه می‌دهد. در نهایت، jssmag.209 درخواست تراکنش بعدی را ارسال می‌کند. علامت `*' در درخواست نشان می‌دهد که بیت XO (دقیقاً یک‌بار - exactly once) تنظیم \fIنشده\fP است.

.HD
قطعه‌بندی IP (IP Fragmentation)
.LP
دیتاگرام‌های قطعه‌بندی‌شدهٔ اینترنت به صورت زیر نمایش داده می‌شوند:
.RS
.nf
.sp .5
\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR
\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR
.sp .5
.fi
.RE
(حالت اول نشان می‌دهد که قطعات بیشتری وجود دارد؛ حالت دوم نشان می‌دهد که این آخرین قطعه است).
.LP
فیلد \fIid\fP شناسهٔ قطعه است. \fIsize\fP اندازهٔ قطعه (بر حسب بایت) بدون احتساب هدر IP است. \fIoffset\fP آفست این قطعه (بر حسب بایت) در دیتاگرام اصلی است.
.LP
اطلاعات مربوط به هر قطعه چاپ می‌شود. قطعهٔ نخست شامل هدرهای پروتکل سطح بالاتر است، بنابراین پس از اطلاعات پروتکل، اطلاعات قطعه چاپ می‌شود. قطعات پس از قطعهٔ نخست فاقد هدرهای پروتکل‌های سطح بالا هستند، بنابراین پس از آدرس‌های مبدأ و مقصد تنها اطلاعات قطعه نمایش داده می‌شود. برای نمونه، در ادامه بخشی از یک انتقال ftp از arizona.edu به lbl-rtsg.arpa آورده شده است که به نظر می‌رسد CSNET در مسیر قادر به مدیریت دیتاگرام‌های ۵۷۶ بایتی نبوده است:
.RS
.nf
.sp .5
\s-2\f(CWarizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560\fP\s+2
.sp .5
.fi
.RE
در اینجا چند نکته قابل توجه است: نخست اینکه آدرس‌های سطر دوم فاقد شماره پورت هستند؛ زیرا اطلاعات پروتکل TCP به‌طور کامل درون قطعهٔ نخست قرار داشته و بنابراین هنگام نمایش قطعات بعدی، پورت‌ها یا شماره توالی‌ها ناشناخته هستند. دوم اینکه به نظر می‌رسد بخش شماره توالی tcp در سطر نخست دارای ۳۰۸ بایت دادهٔ کاربری است، در حالی که در واقع ۵۱۲ بایت است (۳۰۸ بایت در قطعهٔ نخست و ۲۰۴ بایت در قطعهٔ دوم). اگر به دنبال حفره‌هایی در شماره توالی‌ها باشید یا سعی در تطبیق تأییدیه‌ها (ack) با بسته‌ها داشته باشید، ممکن است به اشتباه بیفتید.
.LP
اگر بسته دارای پرچم IP \fIقطعه‌بندی نشود (Don't Fragment)\fP باشد، عبارت \fB(DF)\fP در انتهای سطر چاپ می‌شود.
.HD
برچسب‌های زمانی (Timestamps)
.LP
به‌طور پیش‌فرض، پیش از تمام سطرهای خروجی یک برچسب زمانی درج می‌شود. برچسب زمانی همان زمان فعلی است و قالب نمایش آن به صورت زیر است:
.RS
.nf
\fIhh:mm:ss.frac\fP
.fi
.RE
دقت آن برابر با ساعت هسته است. برچسب زمانی نشان‌دهندهٔ زمانی است که هسته بسته را دریافت کرده است. تأخیر بین زمانی که رابط اترنت بسته را دریافت می‌کند تا زمانی که هسته به وقفهٔ «بسته آماده است» پاسخ می‌دهد، در نظر گرفته نمی‌شود.

.SH "همچنین ببینید (SEE ALSO)"
.BR traffic (1C),
.BR nit (4P),
.BR bpf (4),
.BR pcap (3)

.SH "نویسندگان (AUTHORS)"
.LP
Van Jacobson,
Craig Leres and
Steven McCanne, all of the
Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
.LP
نسخهٔ فعلی را می‌توان از طریق ftp ناشناس دریافت کرد:
.LP
.RS
.I ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
.RE

.SH "باگ‌ها (BUGS)"
.LP
لطفاً گزارش اشکالات را به آدرس
tcpdump@ee.lbl.gov
ارسال کنید.
.LP
رابط NIT اجازه نمی‌دهد ترافیک خروجی خودتان را شنود کنید، اما BPF این امکان را می‌دهد. ما استفاده از دومی را پیشنهاد می‌کنیم.
.LP
باید تلاشی برای بازترکیب (reassemble) قطعات IP انجام شود، یا حداقل طول صحیح برای پروتکل‌های لایه‌های بالاتر محاسبه شود.
.LP
پرس‌وجوهای معکوس سرویس‌دهندهٔ نام به‌درستی چاپ نمی‌شوند: بخش پرسش (خالی) چاپ می‌شود، در حالی که پرس‌وجوی واقعی در بخش پاسخ قرار دارد. برخی بر این باورند که این پرس‌وجوهای معکوس خود یک اشکال هستند و برنامه‌ای که آن‌ها را ایجاد می‌کند باید اصلاح شود، نه tcpdump.
.LP
بسته‌های Apple Ethertalk DDP باید به همان آسانی بسته‌های KIP DDP چاپ شوند، اما در واقع چنین نیست. حتی اگر می‌خواستیم کاری برای ترویج Ethertalk انجام دهیم (که قصدی نداریم)، LBL اجازهٔ حضور Ethertalk را روی هیچ‌یک از شبکه‌های خود نمی‌دهد، بنابراین راهی برای آزمایش این کدها نداریم.
.LP
تغییرات ساعت تابستانی در مسیر عبور بسته‌ها ممکن است باعث ناهماهنگی در برچسب‌های زمانی شود (این تغییر زمانی نادیده گرفته می‌شود).
.LP
عبارات فیلتر مربوط به هدرهای FDDI فرض می‌کنند که تمامی بسته‌های FDDI درون بسته‌های اترنت کپسوله‌سازی شده‌اند. این موضوع بدون شک برای IP، ARP و DECNET Phase IV درست است، اما برای برخی پروتکل‌ها مانند ISO CLNS صادق نیست؛ بنابراین فیلتر ممکن است به‌طور ناخواسته بسته‌هایی را بپذیرد که در واقعیت با عبارت فیلتر مطابقت ندارند.