TCPDUMP(1) General Commands Manual TCPDUMP(1)

tcpdump - ضبط و تخلیه ترافیک در یک شبکه

tcpdump [ -AbdDefghHIJKlLnNOpqStuUvxX# ] [ -B buffer_size ]
[ -c count ] [ --count ] [ -C file_size ]
[ -E spi@ipaddr algo:secret,... ]
[ -F file ] [ -G rotate_seconds ] [ -i interface ]
[ --immediate-mode ] [ -j tstamp_type ] [ -m module ]
[ -M secret ] [ --number ] [ --print ] [ -Q in|out|inout ] [ -r file ] [ -s snaplen ] [ -T type ] [ --version ] [ -V file ] [ -w file ] [ -W filecount ]
[ -y datalinktype ] [ -z postrotate-command ] [ -Z user ]
[ --time-stamp-precision=tstamp_precision ] [ --micro ] [ --nano ]
[ expression ]

برنامه tcpdump توصیفی از محتوای بسته‌ها را در یک رابط شبکه که با expression بولی مطابقت دارند چاپ می‌کند (برای ساختار نحوی expression به pcap-filter(7) مراجعه کنید)؛ پیش از این توصیف یک برچسب زمانی قرار دارد که به‌طور پیش‌فرض به‌صورت ساعت، دقیقه، ثانیه و کسری از ثانیه از نیمه‌شب چاپ می‌شود. این برنامه همچنین می‌تواند با پرچم -w اجرا شود که موجب ذخیره داده‌های بسته‌ها در یک فایل برای تحلیل‌های بعدی می‌گردد، و/یا با پرچم -r که باعث می‌شود برنامه به‌جای خواندن بسته‌ها از یک رابط شبکه، آن‌ها را از یک فایل بسته‌ی ذخیره‌شده بخواند. همچنین می‌تواند با پرچم -V اجرا شود که فهرستی از فایل‌های بسته ذخیره‌شده را می‌خواند. در تمام موارد، تنها بسته‌هایی که با expression مطابقت داشته باشند توسط tcpdump پردازش خواهند شد.

چنانچه tcpdump بدون پرچم -c اجرا شود، به ضبط بسته‌ها ادامه می‌دهد تا زمانی که توسط یک سیگنال SIGINT (برای نمونه با فشردن نویسه وقفه، معمولاً control-C) یا یک سیگنال SIGTERM (معمولاً تولید شده با دستور kill(1)) متوقف شود؛ در صورت اجرا با پرچم -c ، تا زمانی که با سیگنال SIGINT یا SIGTERM متوقف شود یا تعداد بسته‌های مشخص‌شده پردازش شوند، به ضبط بسته‌ها ادامه خواهد داد.

هنگامی که tcpdump ضبط بسته‌ها را به پایان می‌رساند، گزارش‌هایی از شمارش موارد زیر ارائه می‌دهد:

بسته‌های “ضبط‌شده” (این تعداد بسته‌هایی است که tcpdump دریافت و پردازش کرده است)؛
بسته‌های “دریافت‌شده توسط فیلتر” (مفهوم این مورد به سیستم‌عاملی که tcpdump را روی آن اجرا می‌کنید و احتمالاً به نحوه پیکربندی سیستم‌عامل بستگی دارد - اگر فیلتری در خط فرمان مشخص شده باشد، در برخی سیستم‌عامل‌ها بدون توجه به اینکه آیا بسته‌ها با عبارت فیلتر مطابقت داشته‌اند یا خیر، و حتی در صورت تطابق، بدون در نظر گرفتن اینکه آیا tcpdump تاکنون آن‌ها را خوانده و پردازش کرده است یا خیر شمرده می‌شوند؛ در برخی دیگر از سیستم‌عامل‌ها تنها بسته‌هایی که با عبارت فیلتر مطابقت داشته‌اند بدون توجه به اینکه توسط tcpdump خوانده و پردازش شده‌اند یا نه شمرده می‌شوند؛ و در سیستم‌عامل‌های دیگر فقط بسته‌هایی شمرده می‌شوند که با عبارت فیلتر تطابق داشته و توسط tcpdump پردازش شده‌اند)؛
بسته‌های “دور انداخته‌شده توسط هسته” (این تعداد بسته‌هایی است که به دلیل کمبود فضای بافر، توسط سازوکار ضبط بسته در سیستم‌عاملی که tcpdump روی آن اجرا می‌شود دور انداخته شده‌اند، در صورتی که سیستم‌عامل این اطلاعات را به برنامه‌ها گزارش دهد؛ در غیر این صورت، این مقدار 0 گزارش خواهد شد).

در پلتفرم‌هایی که از سیگنال SIGINFO پشتیبانی می‌کنند، مانند اکثر سیستم‌های BSD (از جمله macOS) و Digital/Tru64 UNIX، برنامه با دریافت سیگنال SIGINFO (برای نمونه با فشردن نویسه وضعیت “status”، معمولاً control-T، اگرچه در برخی پلتفرم‌ها مانند macOS نویسه “status” به‌طور پیش‌فرض تنظیم نشده است و برای استفاده از آن باید با دستور stty(1) تنظیم شود) این آمار را گزارش داده و به ضبط بسته‌ها ادامه خواهد داد. در پلتفرم‌هایی که از سیگنال SIGINFO پشتیبانی نمی‌کنند، می‌توان با استفاده از سیگنال SIGUSR1 به همین نتیجه دست یافت.

استفاده از سیگنال SIGUSR2 به همراه پرچم -w بافر بسته‌ها را به‌صورت اجباری در فایل خروجی تخلیه (flush) می‌کند.

خواندن بسته‌ها از یک رابط شبکه ممکن است به امتیازات ویژه (دسترسی ریشه) نیاز داشته باشد؛ برای جزئیات به صفحه راهنمای pcap(3PCAP) مراجعه کنید. خواندن یک فایل بسته‌ی ذخیره‌شده نیازی به امتیازات ویژه ندارد..SH "گزینه‌ها (OPTIONS)"

چاپ هر بسته (بدون سرآیند لایهٔ پیوند آن) در قالب ASCII. برای ضبط و بررسی صفحات وب سودمند است. در صورت استفاده از گزینه‌های -x[x] یا -X[X] تأثیری ندارد.
چاپ شمارهٔ AS در بسته‌های BGP در نمادگذاری ASDOT به‌جای نمادگذاری ASPLAIN.
تنظیم اندازهٔ بافر ضبط سیستم‌عامل روی buffer_size، با واحد KiB (۱۰۲۴ بایت).
خروج پس از دریافت count بسته.
هنگام خواندن فایل(های) ضبط، به‌جای تجزیه یا چاپ بسته‌ها، تنها تعداد بسته‌ها را در stdout چاپ می‌کند. اگر فیلتری در خط فرمان مشخص شده باشد، tcpdump فقط بسته‌هایی را می‌شمارد که با عبارت فیلتر مطابقت داشته باشند.
پیش از نوشتن یک بستهٔ خام در فایل ذخیره، بررسی می‌کند که آیا فایل در حال حاضر بزرگ‌تر از file_size است یا خیر، و اگر چنین باشد، فایل ذخیرهٔ فعلی را می‌بندد و فایل جدیدی باز می‌کند. فایل‌های ذخیره پس از نخستین فایل، نامی را خواهند داشت که با پرچم -w تعیین شده است و عددی پس از آن قرار می‌گیرد که از ۱ شروع شده و رو به بالا ادامه می‌یابد. واحد پیش‌فرض file_size میلیون بایت (۱٬۰۰۰٬۰۰۰ بایت، نه ۱٬۰۴۸٬۵۷۶ بایت) است.
با افزودن پسوند k/K، m/M یا g/G به مقدار، واحد می‌تواند به ترتیب به ۱٬۰۲۴ (KiB)، ۱٬۰۴۸٬۵۷۶ (MiB) یا ۱٬۰۷۳٬۷۴۱٬۸۲۴ (GiB) تغییر یابد.
تخلیهٔ کد کامپایل‌شدهٔ تطبیق بسته در قالبی خوانا برای انسان در خروجی استاندارد و توقف برنامه.
توجه داشته باشید که گرچه کامپایل کد همیشه وابسته به DLT است، معمولاً مشخص کردن این‌که کدام DLT برای تخلیه استفاده شود غیرممکن (و غیرضروری) است، زیرا tcpdump یا از DLT فایل ورودی pcap مشخص‌شده با -r، یا از DLT پیش‌فرض رابط شبکهٔ مشخص‌شده با -i، یا از DLT خاص رابط شبکه که به ترتیب با -y و -i مشخص شده است استفاده می‌کند. در این موارد، خروجی دقیقاً همان کدی را نشان می‌دهد که بدون -d فایل ورودی یا رابط شبکه را فیلتر می‌کرد.
با این حال، هنگامی که نه -r و نه -i مشخص نشده باشند، تعیین -d مانع از آن می‌شود که tcpdump یک رابط شبکهٔ مناسب را حدس بزند (به -i مراجعه کنید). در این حالت DLT به‌طور پیش‌فرض روی EN10MB قرار می‌گیرد و می‌توان آن را به‌صورت دستی با -y به مقدار معتبر دیگری تنظیم کرد.
تخلیهٔ کد تطبیق بسته در قالب قطعه‌کدی از یک برنامهٔ C.
تخلیهٔ کد تطبیق بسته به‌صورت اعداد ده‌دهی (همراه با تعداد در ابتدای آن).
چاپ فهرستی از رابط‌های شبکهٔ موجود در سیستم که tcpdump می‌تواند بسته‌ها را روی آن‌ها ضبط کند. برای هر رابط شبکه، یک شماره و نام رابط چاپ می‌شود که ممکن است شرحی متنی از رابط نیز در ادامهٔ آن بیاید. نام رابط یا شماره را می‌توان به پرچم -i داد تا رابط مورد نظر برای ضبط بسته‌ها مشخص شود.
این گزینه می‌تواند در سیستم‌هایی که دستوری برای فهرست کردن رابط‌ها ندارند مفید باشد (مانند سیستم‌های Windows، یا سیستم‌های UNIX که فاقد ifconfig -a هستند)؛ این شماره در سیستم‌های Windows 2000 و بالاتر که در آن‌ها نام رابط رشته‌ای نسبتاً پیچیده است، می‌تواند کاربردی باشد.
اگر tcpdump با نسخهٔ قدیمی‌تری از libpcap ساخته شده باشد که فاقد تابع pcap_findalldevs(3PCAP) است، پرچم -D پشتیبانی نخواهد شد.
چاپ سرآیند لایهٔ پیوند در هر خط از خروجی. این قابلیت می‌تواند مثلاً برای چاپ آدرس‌های لایهٔ MAC در پروتکل‌هایی مانند Ethernet و IEEE 802.11 استفاده شود.
استفاده از spi@ipaddr algo:secret برای رمزگشایی بسته‌های IPsec ESP که مقصد آن‌ها addr است و حاوی مقدار نمایهٔ پارامتر امنیت (Security Parameter Index) یا spi هستند. این ترکیب می‌تواند با ویرگول یا خط جدید جدا شده و تکرار شود.
توجه داشته باشید که در حال حاضر تنظیم کلید محرمانه تنها برای بسته‌های IPv4 ESP پشتیبانی می‌شود.
الگوریتم‌ها می‌توانند شامل des-cbc، 3des-cbc، blowfish-cbc، rc3-cbc، cast128-cbc، یا none باشند. مقدار پیش‌فرض des-cbc است. قابلیت رمزگشایی بسته‌ها تنها زمانی وجود دارد که tcpdump با پشتیبانی از رمزنگاری کامپایل شده باشد.
مقدار secret متن ASCII کلید محرمانهٔ ESP است. اگر با 0x شروع شود، به‌عنوان یک مقدار هگزادسیمال خوانده می‌شود.
این گزینه استاندارد RFC 2406 ESP را در نظر می‌گیرد، نه RFC 1827 ESP. این گزینه صرفاً برای مقاصد اشکال‌زدایی است و استفاده از آن با یک کلید واقعاً «محرمانه» توصیه نمی‌شود. با ارائهٔ کلید محرمانهٔ IPsec در خط فرمان، آن را از طریق ps(1) و روش‌های دیگر در معرض دید سایرین قرار می‌دهید.
علاوه بر ساختار نحوی بالا، نحو file name می‌تواند به کار رود تا tcpdump فایل ارائه‌شده را بخواند. این فایل هنگام دریافت نخستین بستهٔ ESP باز می‌شود، بنابراین هرگونه دسترسی ویژه‌ای که احتمالاً به tcpdump اعطا شده، باید تا آن زمان سلب شده باشد.
چاپ عددی نشانی‌های IPv4 «خارجی» به‌جای نمادین (این گزینه به منظور دور زدن یک ایراد اساسی در کارساز NIS شرکت Sun طراحی شده است — معمولاً هنگام ترجمهٔ شماره‌های اینترنتی غیرمحلی برای همیشه معلق می‌ماند).
بررسی نشانی‌های IPv4 «خارجی» با استفاده از نشانی IPv4 و ماسک شبکهٔ (netmask) رابطی انجام می‌شود که ضبط روی آن در حال اجراست. اگر آن نشانی یا ماسک شبکه در دسترس نباشد، چه به این دلیل که رابط فاقد نشانی یا ماسک شبکه است و چه به این دلیل که شبه‌رابط "any" است (پرچم -i در زیر را ببینید)، این گزینه به‌درستی کار نخواهد کرد.
استفاده از file به‌عنوان ورودی برای عبارت فیلتر. عبارت اضافی ارائه‌شده در خط فرمان نادیده گرفته می‌شود.
عدم درج شکست خط پس از سرآیند IP در حالت پرگو (verbose).
در صورت تعیین، فایل ثبت بسته‌ها را که با گزینهٔ -w مشخص شده است هر rotate_seconds ثانیه می‌چرخاند (عوض می‌کند). فایل‌های ذخیره نامی را خواهند داشت که توسط -w مشخص شده و باید شامل قالبی از زمان طبق تعریف strftime(3) باشد. اگر هیچ قالب زمانی تعیین نشده باشد، هر فایل جدید روی فایل پیشین بازنویسی می‌شود. هر زمان که نام فایل تولیدشده یکتا نباشد، tcpdump داده‌های موجود قبلی را بازنویسی خواهد کرد؛ بنابراین ارائهٔ مشخصات زمانی با دقتی کمتر از دورهٔ ضبط توصیه نمی‌شود..IP در صورت استفاده به همراه گزینهٔ -C ، نام فایل‌ها به صورت «file<count>» خواهد بود.
رشته‌های نسخهٔ tcpdump و libpcap را چاپ کرده، پیام نحوهٔ استفاده را نمایش می‌دهد و خارج می‌شود.
رشته‌های نسخهٔ tcpdump و libpcap را چاپ کرده و خارج می‌شود.
تلاش برای تشخیص سرایندهای پیش‌نویس مش 802.11s. -i interface
شنود، گزارش فهرست انواع لایهٔ پیوند، گزارش فهرست انواع برچسب زمانی، یا گزارش نتایج کامپایل عبارت فیلتر روی interface. اگر مشخص نشود و پرچم -d داده نشده باشد، tcpdump فهرست رابط‌های سیستم را برای رابط پیکربندی‌شده و فعال (up) با کمترین شماره (به جز loopback) جستجو می‌کند که برای مثال ممکن است «eth0» باشد.
در تمام سیستم‌های لینوکس پشتیبانی‌شده، و همچنین در نسخه‌های اخیر macOS و Solaris، آرگومان interface با مقدار «any» به معنای یک شبه‌رابط ویژه است که بسته‌ها را از تمام رابط‌های شبکهٔ عادی سیستم‌عامل ضبط می‌کند. اینکه چه چیزی یک رابط شبکهٔ عادی در نظر گرفته شود جزئیات پیاده‌سازی سیستم‌عامل است (برای مثال، در لینوکس شامل دستگاه‌های SocketCAN می‌شود)، بنابراین بسته‌های ضبط‌شده روی شبه‌رابط «any» ممکن است پروتکل‌های شبکهٔ متنوع‌تری نسبت به حد انتظار را نشان دهند. همچنین تمام رابط‌های شبکهٔ عادی زیرمجموعه‌ای از تمام دستگاه‌های ضبط موجود هستند که توسط پرچم -D چاپ می‌شوند. مورد دوم همچنین ممکن است شامل دستگاه‌های ضبطی باشد که libpcap با روش‌هایی غیر از پشتهٔ شبکهٔ سیستم‌عامل پیاده‌سازی می‌کند: Bluetooth، DAG، D-Bus، SNF و USB. توجه داشته باشید که ضبط روی شبه‌رابط «any» در حالت بی‌پروا (promiscuous mode) انجام نخواهد شد.
اگر پرچم -D پشتیبانی شود، در صورتی که هیچ رابطی در سیستم آن شماره را به عنوان نام نداشته باشد، شمارهٔ رابط چاپ‌شده توسط آن پرچم می‌تواند به عنوان آرگومان interface استفاده شود.
قرار دادن رابط در «حالت پایش» (monitor mode)؛ این مورد فقط روی رابط‌های Wi-Fi بر پایهٔ IEEE 802.11 و تنها در برخی سیستم‌عامل‌ها پشتیبانی می‌شود.
توجه داشته باشید که در حالت پایش، ممکن است آداپتور ارتباط خود را با شبکه‌ای که با آن در ارتباط است قطع کند، به طوری که قادر به استفاده از هیچ شبکهٔ بی‌سیمی با آن آداپتور نخواهید بود. این امر در صورتی که در حالت پایش در حال ضبط باشید و با آداپتور دیگری به شبکهٔ دیگری متصل نباشید، می‌تواند مانع از دسترسی به فایل‌ها در یک سرور شبکه یا تحلیل نام‌های میزبان یا نشانی‌های شبکه شود.
این پرچم بر خروجی پرچم -L تأثیر می‌گذارد. اگر -I مشخص نشده باشد، فقط انواع لایهٔ پیوندی که در زمان خارج بودن از حالت پایش در دسترس هستند نشان داده خواهند شد؛ اگر -I مشخص شده باشد، فقط انواع لایهٔ پیوندی که در حالت پایش در دسترس هستند نشان داده خواهند شد.
ضبط در «حالت فوری» (immediate mode). در این حالت، بسته‌ها به محض دریافت به جای بافر شدن برای افزایش کارایی، مستقیماً به tcpdump تحویل داده می‌شوند. این حالت زمانی که بسته‌ها به جای ذخیره در یک «savefile»، روی ترمینال (و نه در یک فایل یا لوله) چاپ می‌شوند، پیش‌فرض است.
تنظیم نوع برچسب زمانی برای ضبط به tstamp_type. نام‌های مورد استفاده برای انواع برچسب زمانی در pcap-tstamp(7) آمده است؛ لزوماً تمام انواع فهرست‌شده در آنجا برای هر رابط مشخصی معتبر نخواهند بود.
فهرست کردن انواع برچسب زمانی پشتیبانی‌شده برای رابط و خروج. اگر نوع برچسب زمانی نتواند برای رابط تنظیم شود، هیچ نوع برچسب زمانی فهرست نخواهد شد.
هنگام ضبط، دقت برچسب زمانی برای ضبط را روی tstamp_precision تنظیم می‌کند. توجه داشته باشید که در دسترس بودن برچسب‌های زمانی با دقت بالا (نانوثانیه) و صحت واقعی آن‌ها به پلتفرم و سخت‌افزار وابسته است. همچنین توجه داشته باشید که هنگام ذخیرهٔ ضبط‌های انجام‌شده با دقت نانوثانیه‌ای در یک savefile، برچسب‌های زمانی با تفکیک‌پذیری نانوثانیه نوشته می‌شوند و فایل با یک عدد جادویی (magic number) متفاوت ذخیره می‌شود تا مشخص کند برچسب‌های زمانی بر حسب ثانیه و نانوثانیه هستند؛ همهٔ برنامه‌هایی که فایلهای ذخیرهٔ pcap را می‌خوانند قادر به خواندن این ضبط‌ها نخواهند بود.
هنگام خواندن یک savefile، برچسب‌های زمانی را به دقت مشخص‌شده توسط timestamp_precision تبدیل کرده و آن‌ها را با همان تفکیک‌پذیری نمایش می‌دهد. اگر دقت مشخص‌شده کمتر از دقت برچسب‌های زمانی درون فایل باشد، این تبدیل با افت دقت مواجه خواهد شد.
مقدارهای پشتیبانی‌شده برای timestamp_precision عبارت‌اند از micro برای تفکیک‌پذیری میکروثانیه و nano برای تفکیک‌پذیری نانوثانیه. پیش‌فرض، تفکیک‌پذیری میکروثانیه است.
میان‌برهایی برای --time-stamp-precision=micro یا --time-stamp-precision=nano، که دقت برچسب زمانی را بر این اساس تنظیم می‌کنند. هنگام خواندن بسته‌ها از یک savefile، در صورتی که savefile با دقت نانوثانیه ایجاد شده باشد، استفاده از --micro برچسب‌های زمانی را کوتاه می‌کند. در مقابل، یک savefile ایجادشده با دقت میکروثانیه، در صورت استفاده از --nano، صفرهای انتهایی به برچسب زمانی آن افزوده خواهد شد.
تلاشی برای اعتبارسنجی چکسام‌های IP، TCP یا UDP انجام نمی‌دهد. این گزینه برای رابط‌هایی که تمام یا بخشی از محاسبات چکسام را در سخت‌افزار انجام می‌دهند مفید است؛ در غیر این صورت، تمام چکسام‌های خروجی TCP به عنوان نامعتبر نشانه‌گذاری خواهند شد.
خروجی استاندارد (stdout) را به صورت خط‌بافر (line buffered) درمی‌آورد. در صورتی که بخواهید داده‌ها را هم‌زمان با ضبط آن‌ها مشاهده کنید، مفید است. به عنوان مثال:
tcpdump -l | tee dat
یا
tcpdump -l > dat & tail -f dat
توجه داشته باشید که در Windows، مفهوم «line buffered» به معنای «بدون بافر» (unbuffered) است، بنابراین اگر -l مشخص شود، WinDump هر نویسه را به صورت جداگانه می‌نویسد.
گزینهٔ -U در رفتار خود شبیه به -l است، اما خروجی را به حالت «packet-buffered» (بافربندی بر اساس بسته) درمی‌آورد، به طوری که خروجی در انتهای هر بسته به جای انتهای هر خط در stdout نوشته می‌شود؛ این بافربندی روی تمام پلتفرم‌ها، از جمله Windows، اعمال می‌شود..TP -L
انواع پیوند داده (data link) شناخته‌شده برای رابط شبکه را در حالت مشخص‌شده فهرست کرده و خارج می‌شود. فهرست انواع پیوند داده ممکن است به حالت مشخص‌شده وابسته باشد؛ برای نمونه، در برخی پلتفرم‌ها، یک رابط Wi-Fi ممکن است در حالتی غیر از مانیتور از یک دسته از انواع پیوند داده پشتیبانی کند (مثلاً تنها از هدرهای ساختگی Ethernet پشتیبانی کند، یا از هدرهای 802.11 بدون اطلاعات رادیویی پشتیبانی نماید) و در حالت مانیتور از دسته دیگری از انواع پیوند داده پشتیبانی کند (برای نمونه، تنها در حالت مانیتور از هدرهای 802.11 یا هدرهای 802.11 به همراه اطلاعات رادیویی پشتیبانی کند).
تعاریف ماژول SMI MIB را از فایل module بارگذاری می‌کند. این گزینه می‌تواند چندین بار برای بارگذاری چندین ماژول MIB در tcpdump استفاده شود.
از secret به عنوان یک راز مشترک (shared secret) برای اعتبارسنجی خلاصه‌ها در قطعه‌های TCP دارای گزینه TCP-MD5 (بر اساس RFC 2385)، در صورت وجود، استفاده می‌کند.
آدرس‌ها (مانند آدرس‌های میزبان، شماره درگاه‌ها و غیره) را به نام تبدیل نمی‌کند.
پسوند نام دامنه را برای نام میزبان‌ها چاپ نمی‌کند. برای نمونه، در صورت استفاده از این پرچم، tcpdump به جای ``nic.ddn.mil'' عبارت ``nic'' را چاپ خواهد کرد.
-#
شماره بسته را در ابتدای خط چاپ می‌کند.
بهینه‌ساز کد تطبیق بسته را اجرا نمی‌کند. این گزینه تنها در صورتی مفید است که به وجود اشکال (bug) در بهینه‌ساز مشکوک باشید.
رابط شبکه را در حالت بی‌قید (promiscuous mode) قرار نمی‌دهد. توجه داشته باشید که رابط ممکن است به دلایل دیگری از قبل در حالت بی‌قید باشد؛ بنابراین، `-p' نمی‌تواند به عنوان گزینه‌ای معادل با `ether host {local-hw-addr} or ether broadcast' استفاده شود.
خروجی بسته‌های تجزیه‌شده را چاپ می‌کند، حتی اگر بسته‌های خام با استفاده از پرچم -w در یک فایل ذخیره شوند.
جهت ارسال/دریافت (direction) را برای بسته‌هایی که باید ضبط شوند انتخاب می‌کند. مقادیر معتبر عبارتند از `in'، `out' و `inout'. این گزینه روی همه پلتفرم‌ها در دسترس نیست.
خروجی سریع (یا کم‌صدا؟). اطلاعات پروتکلی کمتری چاپ می‌کند تا خطوط خروجی کوتاه‌تر شوند.
بسته‌ها را از file (که با گزینه -w یا ابزارهای دیگر ایجادکننده فایل‌های pcap یا pcapng ساخته شده) می‌خواند. اگر file برابر با ``-'' باشد، از ورودی استاندارد استفاده می‌شود.
شماره‌های ترتیبی (sequence numbers) پروتکل TCP را به صورت مطلق و نه نسبی چاپ می‌کند.
به جای مقدار پیش‌فرض 262144 بایت، مقدار snaplen بایت از داده را از هر بسته ضبط می‌کند. بسته‌هایی که به دلیل محدودیت طول اسنپ‌شات بریده شده‌اند، در خروجی با ``[|proto]'' نشان داده می‌شوند، که در آن proto نام سطح پروتکلی است که برش در آن رخ داده است.
توجه داشته باشید که گرفتن اسنپ‌شات‌های بزرگ‌تر، هم زمان لازم برای پردازش بسته‌ها را افزایش می‌دهد و هم عملاً میزان بافرینگ بسته‌ها را کاهش می‌دهد. این امر ممکن است باعث از دست رفتن بسته‌ها شود. همچنین توجه داشته باشید که گرفتن اسنپ‌شات‌های کوچک‌تر، داده‌های پروتکل‌های بالاتر از لایه انتقال را دور می‌ریزد، که باعث از بین رفتن اطلاعات مهم می‌شود. برای نمونه، درخواست‌ها و پاسخ‌های NFS و AFS بسیار بزرگ هستند و در صورت انتخاب طول اسنپ‌شات بیش از حد کوتاه، بسیاری از جزئیات در دسترس نخواهند بود.
اگر لازم است اندازه اسنپ‌شات را به کمتر از مقدار پیش‌فرض کاهش دهید، باید snaplen را به کوچک‌ترین مقداری که اطلاعات پروتکل مورد نظر شما را ضبط می‌کند محدود کنید. تنظیم snaplen روی 0، آن را برای سازگاری با نسخه‌های پیشین tcpdump، روی مقدار پیش‌فرض 262144 قرار می‌دهد.
بسته‌های انتخاب‌شده توسط "expression" را مجبور می‌کند که به صورت نوعِ مشخص‌شده (type) تفسیر شوند. انواع شناخته‌شده در حال حاضر عبارتند از: aodv (پروتکل Ad-hoc On-demand Distance Vector)، carp (پروتکل Common Address Redundancy Protocol)، cnfp (پروتکل Cisco NetFlow)، domain (سامانه نام دامنه - Domain Name System)، lmp (پروتکل Link Management Protocol)، pgm (پروتکل Pragmatic General Multicast)، pgm_zmtp1 (پروتکل ZMTP/1.0 درون PGM/EPGM)، ptp (پروتکل Precision Time Protocol)، radius (پروتکل RADIUS)، resp (پروتکل REdis Serialization Protocol)، rpc (فراخوانی رویه از راه دور - Remote Procedure Call)، rtcp (پروتکل کنترلی Real-Time Applications)، rtp (پروتکل Real-Time Applications)، snmp (پروتکل Simple Network Management Protocol)، someip (پروتکل SOME/IP)، tftp (پروتکل Trivial File Transfer Protocol)، vat (ابزار Visual Audio Tool)، vxlan (شبکه Virtual eXtensible Local Area Network)، wb (تخته‌سفید توزیع‌شده - distributed White Board) و zmtp1 (پروتکل ZeroMQ Message Transport Protocol 1.0).
توجه داشته باشید که نوع pgm در بالا تنها بر تفسیر UDP تأثیر می‌گذارد؛ PGM بومی همواره به عنوان پروتکل IP شماره 113 شناخته می‌شود. PGM کپسوله‌شده در UDP اغلب "EPGM" یا "PGM/UDP" نامیده می‌شود.
توجه داشته باشید که نوع pgm_zmtp1 در بالا به طور همزمان بر تفسیر هر دو مورد PGM بومی و UDP تأثیر می‌گذارد. هنگام رمزگشایی PGM بومی، داده‌های لایه کاربرد یک بسته ODATA/RDATA به عنوان دیتاگرام ZeroMQ با فریم‌های ZMTP/1.0 رمزگشایی می‌شوند. علاوه بر آن، هنگام رمزگشایی UDP، هر بسته UDP به عنوان یک بسته PGM کپسوله‌شده در نظر گرفته می‌شود.
در هر خط خروجی برچسب زمانی (timestamp) چاپ نمی‌کند.
برچسب زمانی را بر حسب ثانیه‌های سپری‌شده از ۱ ژانویه ۱۹۷۰، ساعت 00:00:00 به وقت UTC و کسری از ثانیه پس از آن، در هر خط خروجی چاپ می‌کند.
اختلاف زمانی (با دقت میکروثانیه یا نانوثانیه بسته به گزینه --time-stamp-precision) را بین خط فعلی و خط پیشین در هر خط خروجی چاپ می‌کند. حالت پیش‌فرض، دقت میکروثانیه است.
برچسب زمانی را به صورت ساعت، دقیقه، ثانیه و کسری از ثانیه پس از نیمه‌شب، به همراه تاریخ پیش از آن، در هر خط خروجی چاپ می‌کند.
اختلاف زمانی (با دقت میکروثانیه یا نانوثانیه بسته به گزینه --time-stamp-precision) را بین خط فعلی و اولین خط در هر خط خروجی چاپ می‌کند. حالت پیش‌فرض، دقت میکروثانیه است..TP -u چاپ هندل‌های کدگشایی‌نشدهٔ NFS.
اگر گزینهٔ -w مشخص نشده باشد، یا اگر مشخص شده باشد اما پرچم --print نیز تعیین شده باشد، خروجی بسته‌های چاپ‌شده را «بسته‌به‌بسته میان‌گیر شده» (packet-buffered) می‌کند؛ یعنی هم‌زمان با چاپ شرح محتویات هر بسته، به‌جای اینکه (هنگام ننوشتن در ترمینال) فقط با پر شدن میان‌گیر خروجی نوشته شود، بلافاصله در خروجی استاندارد نوشته می‌شود.
اگر گزینهٔ -w مشخص شده باشد، خروجی بسته‌های خام ذخیره‌شده را «بسته‌به‌بسته میان‌گیر شده» می‌کند؛ یعنی با ذخیره شدن هر بسته، به‌جای اینکه فقط هنگام پر شدن میان‌گیر خروجی نوشته شود، در فایل خروجی نوشته می‌شود.
پرچم -U در صورتی که tcpdump با نسخه‌ای قدیمی‌تر از libpcap ساخته شده باشد که فاقد تابع pcap_dump_flush(3PCAP) است، پشتیبانی نخواهد شد.
هنگام تجزیه و چاپ، خروجی با جزئیات (کمی) بیشتر تولید می‌کند. برای مثال، time to live، شناسه (identification)، طول کل و گزینه‌ها در یک بستهٔ IP چاپ می‌شوند. همچنین بررسی‌های اعتبارسنجی تکمیلی بسته مانند راستی‌آزمایی چکسام (checksum) سرایند IP و ICMP را فعال می‌کند.
هنگام نوشتن در یک فایل با گزینهٔ -w و هم‌زمان نخواندن از یک فایل با گزینهٔ -r ، تعداد بسته‌های گرفته‌شده را ثانیه‌ای یک‌بار به stderr گزارش می‌دهد. در Solaris،‏ FreeBSD و احتمالاً دیگر سیستم‌های عامل، این به‌روزرسانی دوره‌ای در حال حاضر می‌تواند باعث از دست رفتن بسته‌های گرفته‌شده در مسیرشان از هسته به tcpdump شود.
خروجی حتی با جزئیات بیشتر. برای مثال، فیلدهای بیشتری از بسته‌های پاسخ NFS چاپ می‌شوند و بسته‌های SMB به‌طور کامل کدگشایی می‌شوند.
خروجی با بیشترین جزئیات ممکن. برای مثال، گزینه‌های telnet SB ... SE به‌طور کامل چاپ می‌شوند. با گزینهٔ -X گزینه‌های Telnet به‌صورت هگزادسیمال نیز چاپ می‌شوند.
خواندن فهرستی از نام‌های فایل از file. اگر file برابر با «-» باشد، از ورودی استاندارد استفاده می‌شود.
نوشتن بسته‌های خام در file به‌جای تجزیه و چاپ آن‌ها. این بسته‌ها را می‌توان بعداً با گزینهٔ -r چاپ کرد. اگر file برابر با «-» باشد، از خروجی استاندارد استفاده می‌شود.
این خروجی در صورت نوشته شدن در یک فایل یا لوله (pipe) میان‌گیر خواهد شد، بنابراین برنامه‌ای که از فایل یا لوله می‌خواند ممکن است برای مدت‌زمانی دلخواه پس از دریافت بسته‌ها، آن‌ها را نبیند. از پرچم -U استفاده کنید تا بسته‌ها به محض دریافت نوشته شوند.
نوع MIME با عنوان application/vnd.tcpdump.pcap در IANA برای فایل‌های pcap ثبت شده است. پسوند نام فایل .pcap به همراه .cap و .dmp پرکاربردترین‌ها به نظر می‌رسند. خود tcpdump هنگام خواندن فایل‌های ضبط‌شده پسوند را بررسی نمی‌کند و هنگام نوشتن آن‌ها نیز پسوندی اضافه نمی‌کند (به‌جای آن از اعداد جادویی در سرایند فایل استفاده می‌کند). با این حال، بسیاری از سیستم‌های عامل و برنامه‌ها در صورت وجود پسوند از آن استفاده می‌کنند و افزودن یک پسوند (مانند ‎.pcap) توصیه می‌شود.
برای شرح قالب فایل، pcap-savefile(5) را ببینید.
در صورت استفاده همراه با گزینهٔ -C ، تعداد فایل‌های ایجادشده را به مقدار مشخص‌شده محدود می‌کند و بازنویسی فایل‌ها را از ابتدا آغاز می‌نماید؛ در نتیجه یک میان‌گیر «چرخشی» (rotating) ایجاد می‌کند. علاوه بر این، فایل‌ها را با تعداد صفر آغازین کافی برای پشتیبانی از حداکثر تعداد فایل‌ها نام‌گذاری می‌کند تا امکان مرتب‌سازی درست آن‌ها فراهم شود.
در صورت استفاده همراه با گزینهٔ -G ، تعداد فایل‌های چرخانده‌شدهٔ ایجادشده را محدود می‌کند و هنگام رسیدن به این حد، با وضعیت خروج ۰ خارج می‌شود.
اگر هم‌زمان همراه با هر دو گزینهٔ -C و -G استفاده شود، گزینهٔ -W در حال حاضر نادیده گرفته خواهد شد و تنها بر نام فایل تأثیر می‌گذارد.
هنگام تجزیه و چاپ، علاوه بر چاپ سرایندهای هر بسته، داده‌های هر بسته (منهای سرایند لایهٔ پیوند دادهٔ آن) را به‌صورت هگزادسیمال چاپ می‌کند. مقدار کمتر از میان کل بسته یا snaplen بایت چاپ خواهد شد. توجه داشته باشید که این کل بستهٔ لایهٔ پیوند است؛ بنابراین برای لایه‌های پیوندی که لایهٔ فاصله (padding) اضافه می‌کنند (مانند Ethernet)، زمانی که بستهٔ لایهٔ بالاتر کوتاه‌تر از فاصلهٔ مورد نیاز باشد، بایت‌های لایی نیز چاپ خواهند شد. در پیاده‌سازی فعلی، اگر بسته کوتاه/بریده (truncated) شده باشد، این پرچم ممکن است اثری مشابه -xx داشته باشد. در صورت استفاده از گزینهٔ -X[X] اثری ندارد.
هنگام تجزیه و چاپ، علاوه بر چاپ سرایندهای هر بسته، داده‌های هر بسته را، شامل سرایند لایهٔ پیوند دادهٔ آن، به‌صورت هگزادسیمال چاپ می‌کند. در صورت استفاده از گزینهٔ -X[X] اثری ندارد.
هنگام تجزیه و چاپ، علاوه بر چاپ سرایندهای هر بسته، داده‌های هر بسته (منهای سرایند لایهٔ پیوند دادهٔ آن) را به‌صورت هگزادسیمال و ASCII چاپ می‌کند. این گزینه برای تحلیل پروتکل‌های جدید بسیار کاربردی است. در پیاده‌سازی فعلی، اگر بسته بریده (truncated) شده باشد، این پرچم ممکن است اثری مشابه -XX داشته باشد.
هنگام تجزیه و چاپ، علاوه بر چاپ سرایندهای هر بسته، داده‌های هر بسته را، شامل سرایند لایهٔ پیوند دادهٔ آن، به‌صورت هگزادسیمال و ASCII چاپ می‌کند.
تنظیم نوع پیوند داده (data link type) برای استفاده هنگام ضبط بسته‌ها (ببینید: -L) یا صرفاً هنگام کامپایل و استخراج کد تطبیق بسته (ببینید: -d) بر روی datalinktype.
در صورت استفاده همراه با گزینه‌های -C یا -G ، باعث می‌شود tcpdump دستور " postrotate-command file " را اجرا کند که در آن file همان فایل ذخیره‌شده‌ای است که پس از هر چرخش بسته می‌شود. برای مثال، تعیین -z gzip یا -z bzip2 هر فایل ذخیره‌شده را با استفاده از gzip یا bzip2 فشرده می‌کند..IP این گزینه تنها در صورتی قابل استفاده است که زیرفرایند fork پیاده‌سازی شده باشد (مثلاً در سیستم‌های Windows چنین نیست).
توجه داشته باشید که tcpdump دستور را به صورت موازی با ضبط ترافیک، با کمترین اولویت اجرا می‌کند تا در فرایند ضبط تداخلی ایجاد نشود.
و در صورتی که تمایل دارید از دستوری استفاده کنید که خود گزینه‌ها یا آرگومان‌های متفاوتی می‌گیرد، همواره می‌توانید یک اسکریپت شل بنویسید که نام savefile را به عنوان تنها آرگومان دریافت کند، چینش گزینه‌ها و آرگومان‌ها را انجام دهد و دستور مورد نظر شما را اجرا نماید.
اگر tcpdump با دسترسی ریشه (root) اجرا شود، پس از باز کردن دستگاه ضبط یا savefile ورودی، اما پیش از باز کردن هرگونه savefile برای خروجی، شناسه کاربری (user ID) را به user و شناسه گروهی (group ID) را به گروه اصلی user تغییر می‌دهد.
این رفتار می‌تواند در زمان کامپایل نیز به طور پیش‌فرض فعال شود.
مشخص می‌کند که کدام بسته‌ها استخراج خواهند شد. اگر هیچ expressionی داده نشود، تمام بسته‌های موجود در شبکه استخراج می‌شوند. در غیر این صورت، تنها بسته‌هایی که expression برای آن‌ها `true' باشد استخراج خواهند شد.

برای ساختار نحوی expression، ببینید: pcap-filter(7).

آرگومان expression می‌تواند بسته به راحتی، به صورت یک تک‌آرگومان Shell یا چندین آرگومان Shell به tcpdump داده شود. به طور کلی، اگر عبارت شامل فرانوسه‌های Shell باشد، مانند بک‌اسلش‌هایی که برای گریز دادن نام پروتکل‌ها به کار می‌روند، ارسال آن به صورت یک آرگومان محصور در علامت نقل‌قول (نقل‌قول‌شده)، آسان‌تر از اسکیپ کردن فرانوسه‌های Shell است. آرگومان‌های چندگانه پیش از تجزیه، با فاصله به یکدیگر متصل می‌شوند.

برای چاپ تمام بسته‌هایی که به sundown وارد یا از آن خارج می‌شوند:

tcpdump host sundown

برای چاپ ترافیک بین helios و یکی از دو میزبان hot یا ace:

tcpdump host helios and \( hot or ace \)

برای چاپ تمام بسته‌های IP میان ace و هر میزبانی به جز helios:

tcpdump ip host ace and not helios

برای چاپ تمام ترافیک بین میزبان‌های محلی و میزبان‌های مستقر در Berkeley:


tcpdump net ucb-ether

برای چاپ تمام ترافیک ftp عبوری از درگاه اینترنتی snup: (توجه داشته باشید که عبارت برای جلوگیری از تفسیر (نادرست) پرانتزها توسط Shell، درون علامت نقل‌قول قرار گرفته است):


tcpdump 'gateway snup and (port ftp or ftp-data)'

برای چاپ ترافیکی که مبدأ و مقصد آن میزبان‌های محلی نیستند (اگر به یک شبکه دیگر درگاه (gateway) باشید، این ترافیک هرگز نباید به شبکه محلی شما وارد شود):


tcpdump ip and not net localnet

برای چاپ بسته‌های آغاز و پایان (بسته‌های SYN و FIN) هر گفتگوی TCP که شامل یک میزبان غیرمحلی است:


tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'

برای چاپ بسته‌های TCP که هر دو پرچم RST و ACK در آن‌ها تنظیم شده است: (یعنی فقط پرچم‌های RST و ACK در فیلد پرچم‌ها انتخاب شوند و اگر نتیجه «تنظیم بودن هر دوی RST و ACK» بود، مطابقت داده شود):


tcpdump 'tcp[tcpflags] & (tcp-rst|tcp-ack) == (tcp-rst|tcp-ack)'

برای چاپ تمام بسته‌های IPv4 HTTP به و از درگاه 80، یعنی فقط چاپ بسته‌های حاوی داده، نه مثلاً بسته‌های SYN و FIN یا بسته‌های فقط شامل ACK (مورد IPv6 به عنوان تمرین به خواننده واگذار می‌شود):


tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

برای چاپ بسته‌های IP بزرگ‌تر از 576 بایت ارسال‌شده از طریق درگاه snup:


tcpdump 'gateway snup and ip[2:2] > 576'

برای چاپ بسته‌های broadcast یا multicast پروتکل IP که از طریق broadcast یا multicast پروتکل Ethernet ارسال نشده‌اند:


tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

برای چاپ تمام بسته‌های ICMP که درخواست/پاسخ echo نیستند (یعنی بسته‌های ping نیستند):


tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

خروجی tcpdump به پروتکل وابسته است. در ادامه شرح کوتاهی به همراه مثال‌هایی از بیشتر قالب‌ها ارائه شده است.

به‌طور پیش‌فرض، در ابتدای تمام خطوط خروجی یک برچسب زمانی قرار دارد. برچسب زمانی، زمان جاری ساعت سیستم در قالب زیر است:

hh:mm:ss.frac
و دقت آن به اندازهٔ دقت ساعت هسته (kernel) است. برچسب زمانی بیانگر زمانی است که هسته برچسب زمانی را روی بسته اعمال کرده است. هیچ کوششی برای محاسبهٔ اختلاف زمانی میان پایان دریافت بسته از شبکه توسط رابط شبکه و زمان اعمال برچسب زمانی به بسته توسط هسته صورت نمی‌گیرد؛ این اختلاف زمانی می‌تواند شامل تأخیر میان زمانی باشد که رابط شبکه دریافت بسته از شبکه را به پایان رسانده و زمانی که یک وقفه به هسته تحویل داده شده تا آن را به خواندن بسته وادارد، و همچنین تأخیر میان زمانی که هسته به وقفهٔ «بستهٔ جدید» رسیدگی کرده و زمانی که برچسب زمانی را بر روی بسته اعمال نموده است.

هنگامی که رابط any در زمان ضبط بسته انتخاب شود یا هنگام خواندن یک فایل ضبط از نوع پیوند LINUX_SLL2، نام رابط پس از برچسب زمانی چاپ می‌شود. این بخش با نوع بسته دنبال می‌شود که در آن In و Out به ترتیب نشان‌دهندهٔ بسته‌ای با مقصد این میزبان یا مبدأ این میزبان هستند. سایر مقادیر ممکن عبارت‌اند از B برای بسته‌های همگانی (broadcast)، M برای بسته‌های چندپخشی (multicast)، و P برای بسته‌هایی به مقصد سایر میزبان‌ها.

اگر گزینهٔ '-e' داده شود، سرآیند سطح پیوند چاپ می‌شود. روی اترنت، نشانی‌های مبدأ و مقصد، پروتکل، و طول بسته چاپ می‌شوند.

در شبکه‌های FDDI، گزینهٔ '-e' موجب می‌شود tcpdump فیلد «frame control»، نشانی‌های مبدأ و مقصد، و طول بسته را چاپ کند. (فیلد «frame control» نحوهٔ تفسیر ادامهٔ بسته را تعیین می‌کند. بسته‌های عادی (مانند آن‌هایی که حاوی دیتاگرام‌های IP هستند) بسته‌های «async» با اولویتی بین ۰ تا ۷ هستند؛ برای مثال «async4». فرض بر این است که چنین بسته‌هایی حاوی یک بستهٔ 802.2 Logical Link Control (LLC) هستند؛ اگر بسته یک دیتاگرام ISO یا یک به‌اصطلاح بستهٔ SNAP نباشد، سرآیند LLC چاپ می‌شود.

در شبکه‌های Token Ring، گزینهٔ '-e' باعث می‌شود tcpdump فیلدهای «access control» و «frame control»، نشانی‌های مبدأ و مقصد، و طول بسته را چاپ کند. همانند شبکه‌های FDDI، فرض بر این است که بسته‌ها حاوی یک بستهٔ LLC هستند. صرف‌نظر از اینکه گزینهٔ '-e' مشخص شده باشد یا خیر، اطلاعات مسیریابی مبدأ برای بسته‌های با مسیریابی مبدأ (source-routed) چاپ می‌شود.

در شبکه‌های 802.11، گزینهٔ '-e' باعث می‌شود tcpdump فیلدهای «frame control»، تمام نشانی‌های موجود در سرآیند 802.11، و طول بسته را چاپ کند. همانند شبکه‌های FDDI، فرض بر این است که بسته‌ها حاوی یک بستهٔ LLC هستند.

(توجه: توضیحات زیر بر فرض آشنایی با الگوریتم فشرده‌سازی SLIP که در RFC 1144 شرح داده شده، استوار است.)

در پیوندهای SLIP، یک نشانگر جهت (``I'' برای ورودی، ``O'' برای خروجی)، نوع بسته، و اطلاعات فشرده‌سازی چاپ می‌شوند. نوع بسته ابتدا چاپ می‌شود. سه نوع ممکن ip، utcp و ctcp هستند. برای بسته‌های ip هیچ اطلاعات پیوند دیگری چاپ نمی‌شود. برای بسته‌های TCP، شناسهٔ اتصال پس از نوع بسته چاپ می‌شود. اگر بسته فشرده شده باشد، سرآیند کُدگذاری‌شدهٔ آن چاپ می‌شود. حالت‌های خاص به‌صورت *S+n و *SA+n چاپ می‌شوند، که در آن‌ها n مقداری است که شمارهٔ ترتیب (یا شمارهٔ ترتیب و ack) تغییر کرده است. اگر یک حالت خاص نباشد، صفر یا چند تغییر چاپ می‌شوند. یک تغییر با U (اشاره‌گر فوری یا urgent pointer)، W (پنجره یا window)، A (تأییدیه یا ack)، S (شمارهٔ ترتیب یا sequence number)، و I (شناسهٔ بسته یا packet ID) نشان داده می‌شود که به دنبال آن یک مقدار تغییر (+n یا -n)، یا یک مقدار جدید (=n) می‌آید. در نهایت، مقدار داده‌های موجود در بسته و طول سرآیند فشرده‌شده چاپ می‌شوند.

برای نمونه، خط زیر یک بستهٔ فشرده‌شدهٔ TCP خروجی را با یک شناسهٔ اتصال ضمنی نشان می‌دهد؛ مقدار ack به میزان ۶، شمارهٔ ترتیب به میزان ۴۹، و شناسهٔ بسته به میزان ۶ تغییر کرده است؛ ۳ بایت داده و ۶ بایت سرآیند فشرده‌شده وجود دارد:

O ctcp * A+6 S+49 I+6 3 (6)

خروجی ARP/RARP نوع درخواست و آرگومان‌های آن را نشان می‌دهد. قالب آن به‌گونه‌ای طراحی شده است که خود‌توضیح باشد. در اینجا نمونه کوتاهی برگرفته از ابتدای یک “rlogin” از میزبان rtsg به میزبان csam آورده شده است:

arp who-has csam tell rtsg
arp reply csam is-at CSAM
خط نخست بیانگر این است که rtsg یک بسته ARP فرستاده و آدرس اترنت میزبان اینترنتی csam را جویا شده است. میزبان csam با آدرس اترنت خود پاسخ می‌دهد (در این مثال، آدرس‌های اترنت با حروف بزرگ و آدرس‌های اینترنتی با حروف کوچک آمده‌اند).

اگر دستور tcpdump -n را اجرا می‌کردیم، این خروجی کمتر تکراری به نظر می‌رسید:

arp 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

اگر دستور tcpdump -e را اجرا می‌کردیم، این واقعیت که بسته اول همگانی (broadcast) و بسته دوم نقطه‌به‌نقطه است، قابل مشاهده بود:

RTSG Broadcast 0806  64: arp who-has csam tell rtsg
CSAM RTSG 0806  64: arp reply csam is-at CSAM
برای بسته اول این خروجی نشان می‌دهد که آدرس مبدأ اترنت RTSG است، مقصد آدرس همگانی اترنت است، فیلد نوع حاوی مقدار هگز 0806 (نوع ETHER_ARP) بوده و طول کل ۶۴ بایت است.

اگر سرآیند لایه پیوند چاپ نشود، برای بسته‌های IPv4، عبارت IP پس از برچسب زمان چاپ می‌شود.

اگر پرچم -v مشخص شده باشد، اطلاعات سرآیند IPv4 درون پرانتز و پس از IP یا سرآیند لایه پیوند نمایش داده می‌شود. قالب کلی این اطلاعات به صورت زیر است:

tos tos, ttl ttl, id id, offset offset, flags [flags], proto proto, length length, options (options)
tos فیلد نوع خدمت (type of service) است؛ اگر بیت‌های ECN غیرصفر باشند، به صورت ECT(1)، ECT(0) یا CE گزارش می‌شوند. ttl زمان حیات (time-to-live) است؛ در صورتی که مقدار آن صفر باشد گزارش نمی‌شود. id فیلد شناسه IP است. offset فیلد انحراف قطعه (fragment offset) است؛ چه این بسته بخشی از یک دیتاگرام قطعه‌قطعه‌شده باشد چه نباشد، چاپ می‌شود. flags پرچم‌های MF و DF هستند؛ اگر MF تنظیم شده باشد + گزارش می‌شود، و اگر DF تنظیم شده باشد DF گزارش می‌شود. اگر هیچ‌کدام تنظیم نشده باشند، . گزارش می‌شود. proto فیلد شناسه پروتکل است. length فیلد طول کل است؛ اگر بسته به عنوان ارسال فرضی TSO (مخفف TCP Segmentation Offload) در نظر گرفته شود، مقدار [was 0, presumed TSO] گزارش می‌شود. options گزینه‌های IP در صورت وجود هستند.

سپس، برای بسته‌های TCP و UDP، آدرس‌های IP مبدأ و مقصد و درگاه‌های TCP یا UDP با یک نقطه بین هر آدرس IP و درگاه مربوط به آن، همراه با یک > برای جداسازی مبدأ و مقصد چاپ خواهند شد. برای سایر پروتکل‌ها، آدرس‌ها چاپ شده و یک > مبدأ و مقصد را جدا می‌کند. اطلاعات پروتکل‌های سطح بالاتر، در صورت وجود، پس از آن چاپ خواهد شد.

برای دیتاگرام‌های قطعه‌قطعه‌شده IP، قطعه اول حاوی سرآیند پروتکل سطح بالاتر است؛ قطعات پس از قطعه اول فاقد سرآیند پروتکل سطح بالاتر هستند. اطلاعات قطعه‌بندی تنها با پرچم -v و در اطلاعات سرآیند IP، همان‌گونه که در بالا شرح داده شد، چاپ خواهد شد..SS بسته‌های TCP (TCP Packets)

(توجه: توضیحات زیر بر این فرض است که شما با پروتکل TCP شرح داده‌شده در RFC 793 آشنایی دارید. اگر با این پروتکل آشنا نیستید، این توضیحات برایتان چندان کاربردی نخواهد بود.)

قالب کلی یک خط پروتکل TCP بدین صورت است:

src > dst: Flags [tcpflags], seq data-seqno, ack ackno, win window, urg urgent, options [opts], length len
Src و dst آدرس‌ها و درگاه‌های IP مبدأ و مقصد هستند. Tcpflags ترکیبی از پرچم‌های S (SYN)، F (FIN)، P (PSH)، R (RST)، U (URG)، W (CWR)، E (ECE) یا '.' (ACK)، یا در صورت تنظیم نبودن هیچ پرچمی 'none' است. Data-seqno بخشی از فضای شماره ترتیبی را که توسط داده‌های این بسته پوشش داده شده است توصیف می‌کند (مثال زیر را ببینید). Ackno شماره ترتیبی داده‌های بعدیِ مورد انتظار در جهت دیگر این اتصال است. Window تعداد بایت‌های فضای بافر دریافت است که در جهت دیگر این اتصال در دسترس است. Urg نشان می‌دهد که داده‌های فوری ('urgent') در بسته وجود دارد. Opts گزینه‌های TCP هستند (برای مثال mss 1024). Len طول داده‌های بار مفید (payload) است.

فیلدهای Iptype، Src، dst و flags همیشه حضور دارند. سایر فیلدها به محتویات سرآیند پروتکل TCP در بسته بستگی دارند و فقط در صورت لزوم نمایش داده می‌شوند.

در اینجا بخش آغازین یک ارتباط rlogin از میزبان rtsg به میزبان csam آورده شده است.

IP rtsg.1023 > csam.login: Flags [S], seq 768512:768512, win 4096, opts [mss 1024]
IP csam.login > rtsg.1023: Flags [S.], seq, 947648:947648, ack 768513, win 4096, opts [mss 1024]
IP rtsg.1023 > csam.login: Flags [.], ack 1, win 4096
IP rtsg.1023 > csam.login: Flags [P.], seq 1:2, ack 1, win 4096, length 1
IP csam.login > rtsg.1023: Flags [.], ack 2, win 4096
IP rtsg.1023 > csam.login: Flags [P.], seq 2:21, ack 1, win 4096, length 19
IP csam.login > rtsg.1023: Flags [P.], seq 1:2, ack 21, win 4077, length 1
IP csam.login > rtsg.1023: Flags [P.], seq 2:3, ack 21, win 4077, urg 1, length 1
IP csam.login > rtsg.1023: Flags [P.], seq 3:4, ack 21, win 4077, urg 1, length 1
خط نخست نشان می‌دهد که درگاه TCP شماره 1023 روی rtsg بسته‌ای را به درگاه login روی csam ارسال کرده است. حرف S نشان‌دهنده تنظیم بودن پرچم SYN است. شماره ترتیبی بسته 768512 بود و هیچ داده‌ای در بر نداشت. (نمادگذاری به صورت 'first:last' است که به معنای “شماره‌های ترتیبی first تا قبل از last (بدون احتساب آن)” می‌باشد.) هیچ ACK همراهی (piggy-backed) وجود نداشت، پنجره دریافت در دسترس 4096 بایت بود و گزینه max-segment-size درخواست MSS با مقدار 1024 بایت کرده بود.

میزبان csam با بسته‌ای مشابه پاسخ می‌دهد، با این تفاوت که شامل یک ACK همراه برای SYN متعلق به rtsg است. سپس rtsg بسته SYN میزبان csam را تأیید (ACK) می‌کند. علامت '.' نشان می‌دهد که پرچم ACK تنظیم شده است. این بسته شامل هیچ داده‌ای نبود، بنابراین شماره ترتیبی داده یا طول وجود ندارد. توجه داشته باشید که شماره ترتیبی ACK یک عدد صحیح کوچک (1) است. اولین باری که tcpdump یک «گفتگو» (conversation) از TCP را مشاهده می‌کند، شماره ترتیبی را از بسته چاپ می‌کند. در بسته‌های بعدی این گفتگو، تفاوت بین شماره ترتیبی بسته فعلی و این شماره ترتیبی اولیه چاپ می‌شود. این بدان معناست که شماره‌های ترتیبی پس از مورد اول می‌توانند به عنوان موقعیت‌های نسبی بایت در جریان داده‌های گفتگو تفسیر شوند (به طوری که اولین بایت داده در هر جهت برابر با '1' است). گزینه -S این رفتار را لغو کرده و باعث می‌شود شماره‌های ترتیبی اصلی در خروجی درج شوند.

در خط ششم، rtsg مقدار 19 بایت داده به csam ارسال می‌کند (بایت‌های 2 تا 20 در سمت rtsg → csam از گفتگو). پرچم PSH در این بسته تنظیم شده است. در خط هفتم، csam اعلام می‌کند داده‌های ارسالی توسط rtsg را تا قبل از بایت 21 دریافت کرده است. ظاهراً بخش عمده این داده‌ها در بافر سوکت (socket buffer) باقی مانده‌اند، چرا که پنجره دریافت csam به اندازه 19 بایت کوچک‌تر شده است. میزبان csam همچنین یک بایت داده در این بسته برای rtsg ارسال می‌کند. در خطوط هشتم و نهم، میزبان csam دو بایت داده فوری (urgent) و ارسال‌سریع (pushed) را به rtsg می‌فرستد.

اگر اندازه نمونه (snapshot) آن‌قدر کوچک بوده باشد که tcpdump نتواند سرآیند کامل TCP را ضبط کند، تا جایی از سرآیند را که بتواند تفسیر می‌کند و سپس “[|tcp]” را گزارش می‌دهد تا نشان دهد باقی‌مانده آن قابل تفسیر نبوده است. اگر سرآیند حاوی یک گزینه ساختگی یا نامعتبر باشد (گزینه‌ای با طولی که بیش از حد کوچک یا فراتر از انتهای سرآیند باشد)، tcpdump آن را به صورت “[bad opt]” گزارش می‌دهد و گزینه‌های بعدی را تفسیر نمی‌کند (زیرا تشخیص محل شروع آن‌ها غیرممکن است). اگر طول سرآیند نشان دهد که گزینه‌ها حضور دارند اما طول دیتاگرام IP برای وجود واقعی این گزینه‌ها کافی نباشد، tcpdump آن را به صورت “[bad hdr length]” گزارش می‌دهد..SS ترکیب‌های خاص پرچم‌های TCP (مانند SYN-ACK، URG-ACK و غیره)

در بخش بیت‌های کنترلی سرایند TCP، تعداد ۸ بیت وجود دارد:

CWR | ECE | URG | ACK | PSH | RST | SYN | FIN

فرض کنید می‌خواهیم بسته‌های مورد استفاده در برقراری یک اتصال TCP را رصد کنیم. به یاد آورید که TCP در هنگام راه‌اندازی یک اتصال جدید از پروتکل دست‌تکانی سه‌مرحله‌ای (3-way handshake) استفاده می‌کند؛ توالی برقراری اتصال با توجه به بیت‌های کنترلی TCP به این صورت است:

1) شروع‌کننده SYN را ارسال می‌کند
2) گیرنده با SYN, ACK پاسخ می‌دهد
3) شروع‌کننده ACK را ارسال می‌کند

اکنون می‌خواهیم بسته‌هایی را ثبت (capture) کنیم که تنها بیت SYN آن‌ها تنظیم (set) شده است (مرحله ۱). توجه داشته باشید که ما بسته‌های مرحله ۲ (SYN-ACK) را نمی‌خواهیم، بلکه فقط یک SYN اولیه ساده مد نظر است. آنچه نیاز داریم، یک عبارت فیلتر مناسب برای tcpdump است.

ساختار یک سرایند TCP بدون گزینه‌ها (options) را به یاد آورید:

 0                            15                              31
-----------------------------------------------------------------
|          source port          |       destination port        |
-----------------------------------------------------------------
|                        sequence number                        |
-----------------------------------------------------------------
|                     acknowledgment number                     |
-----------------------------------------------------------------
|  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
-----------------------------------------------------------------
|         TCP checksum          |       urgent pointer          |
-----------------------------------------------------------------

یک سرایند TCP معمولاً شامل ۲۰ بایت (octet) داده است، مگر اینکه گزینه‌ها موجود باشند. سطر اول نمودار شامل اکتت‌های ۰ تا ۳ است، سطر دوم اکتت‌های ۴ تا ۷ را نشان می‌دهد و به همین ترتیب.

با شروع شمارش از ۰، بیت‌های کنترلی مربوطه در TCP در اکتت ۱۳ قرار دارند:

 0             7|             15|             23|             31
----------------|---------------|---------------|----------------
|  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
----------------|---------------|---------------|----------------
|               |  13th octet   |               |               |

بیایید نگاه دقیق‌تری به اکتت شماره ۱۳ بیندازیم:

|               |
|---------------|
|C|E|U|A|P|R|S|F|
|---------------|
|7   5   3     0|

این‌ها بیت‌های کنترلی TCP هستند که به آن‌ها علاقه‌مندیم. ما بیت‌های این اکتت را از راست به چپ از ۰ تا ۷ شماره‌گذاری کرده‌ایم، بنابراین بیت PSH بیت شماره ۳ و بیت URG بیت شماره ۵ است.

به یاد داشته باشید که می‌خواهیم بسته‌هایی را ثبت کنیم که فقط بیت SYN در آن‌ها تنظیم شده باشد. بیایید ببینیم اگر یک دیتاگرام TCP با بیت SYN تنظیم‌شده در سرایند آن دریافت شود، چه بر سر اکتت ۱۳ می‌آید:

|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 0 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|

با نگاه به بخش بیت‌های کنترلی می‌بینیم که فقط بیت شماره ۱ (SYN) تنظیم شده است.

با فرض اینکه اکتت شماره ۱۳ یک عدد صحیح بدون علامت ۸ بیتی در ترتیب بایت شبکه (network byte order) باشد، مقدار دودویی (باینری) این اکتت برابر است با:

00000010

و نمایش ده‌دهی (دسیمال) آن عبارت است از:

   7     6     5     4     3     2     1     0
0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2  =  2

کار ما تقریباً تمام است، زیرا اکنون می‌دانیم که اگر فقط SYN تنظیم شده باشد، مقدار اکتت سیزدهم در سرایند TCP، وقتی به عنوان یک عدد صحیح بدون علامت ۸ بیتی در ترتیب بایت شبکه تفسیر شود، باید دقیقاً برابر با ۲ باشد.

این رابطه را می‌توان به صورت زیر بیان کرد:

tcp[13] == 2

می‌توانیم از این عبارت به عنوان فیلتر برای tcpdump استفاده کنیم تا بسته‌هایی را که فقط بیت SYN آن‌ها تنظیم شده است رصد کنیم:

tcpdump -i xl0 'tcp[13] == 2'

این عبارت می‌گوید «اکتت سیزدهم دیتاگرام TCP باید مقدار ده‌دهی ۲ را داشته باشد»، که دقیقاً همان چیزی است که می‌خواهیم.

اکنون فرض کنید نیاز داریم بسته‌های SYN را ثبت کنیم، اما برایمان اهمیتی ندارد که هم‌زمان بیت ACK یا هر بیت کنترلی دیگری از TCP نیز تنظیم شده باشد یا خیر. بیایید ببینیم وقتی یک دیتاگرام TCP با SYN-ACK تنظیم‌شده دریافت شود، چه بر سر اکتت ۱۳ می‌آید:

|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 1 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|

اکنون بیت‌های ۱ و ۴ در اکتت سیزدهم تنظیم شده‌اند. مقدار دودویی اکتت ۱۳ برابر است با:


00010010

که در مبنای ده‌دهی تبدیل می‌شود به:

   7     6     5     4     3     2     1     0
0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2   = 18

اکنون نمی‌توانیم صرفاً از 'tcp[13] == 18' در عبارت فیلتر tcpdump استفاده کنیم، زیرا این عبارت تنها بسته‌هایی را برمی‌گزیند که SYN-ACK در آن‌ها تنظیم شده است، نه آن‌هایی را که فقط SYN دارند. به یاد داشته باشید که تا زمانی که SYN تنظیم شده باشد، برای ما مهم نیست که ACK یا هر بیت کنترلی دیگری تنظیم شده باشد یا نه.

برای دستیابی به هدف خود، باید مقدار دودویی اکتت ۱۳ را با مقداری دیگر به صورت منطقی AND کنیم تا بیت SYN حفظ شود. می‌دانیم که در هر صورت می‌خواهیم SYN تنظیم باشد، بنابراین مقدار موجود در اکتت سیزدهم را با مقدار دودویی SYN به صورت منطقی AND می‌کنیم:

     00010010 SYN-ACK              00000010 SYN
AND  00000010 (we want SYN)   AND  00000010 (we want SYN)
     --------                      --------
=    00000010                 =    00000010

می‌بینیم که این عملیات AND، بدون توجه به اینکه ACK یا بیت کنترلی دیگری از TCP تنظیم شده باشد یا خیر، نتیجه یکسانی می‌دهد. نمایش ده‌دهی مقدار AND و همچنین نتیجه این عملیات ۲ (دودویی 00000010) است، بنابراین می‌دانیم برای بسته‌هایی با بیت SYN تنظیم‌شده، رابطه زیر باید برقرار باشد:

( ( value of octet 13 ) AND ( 2 ) ) == ( 2 ).PP این ما را به عبارت فیلتر tcpdump هدایت می‌کند:

tcpdump -i xl0 'tcp[13] & 2 == 2'

برخی آفست‌ها و مقادیر فیلدها ممکن است به جای مقادیر عددی، با نام بیان شوند. برای نمونه، tcp[13] می‌تواند با tcp[tcpflags] جایگزین شود. مقادیر فیلد پرچم‌های TCP زیر نیز در دسترس هستند: tcp-fin، tcp-syn، tcp-rst، tcp-push، tcp-ack، tcp-urg، tcp-ece و tcp-cwr.

این موضوع می‌تواند به صورت زیر نشان داده شود:


tcpdump -i xl0 'tcp[tcpflags] & tcp-push != 0'

توجه داشته باشید که باید در عبارت از نقل‌قول تکی یا یک بک‌اسلش برای پنهان کردن نویسه ویژه AND (') از شل استفاده کنید.

قالب UDP با این بسته rwho نشان داده شده است:

actinide.who > broadcast.who: udp 84
این بیانگر آن است که درگاه who روی میزبان actinide یک دیتاگرام UDP به درگاه who روی میزبان broadcast (نشانی پخش همگانی اینترنت) ارسال کرده است. بسته حاوی ۸۴ بایت داده کاربری بود.

برخی از سرویس‌های UDP (از روی شماره درگاه مبدأ یا مقصد) شناسایی شده و اطلاعات پروتکل سطح بالاتر چاپ می‌شود؛ به‌ویژه درخواست‌های سرویس نام دامنه (RFC 1034/1035) و فراخوانی‌های Sun RPC (RFC 1050) به NFS.

(توجه: توضیحات زیر فرض را بر آشنایی با پروتکل Domain Service توصیف‌شده در RFC 1035 قرار می‌دهد. اگر با این پروتکل آشنایی ندارید، توضیحات زیر به نظر می‌رسد که به زبان یونانی نوشته شده است.)

درخواست‌های کارساز نام به صورت زیر قالب‌بندی می‌شوند:

src > dst: id op? flags qtype qclass name (len)

h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
میزبان h2opolo از کارساز دامنه روی helios برای یک رکورد نشانی (qtype=A) مرتبط با نام ucbvax.berkeley.edu. پرس‌وجو کرد. شناسه پرس‌وجو `3' بود. علامت `+' نشان می‌دهد که پرچم recursion desired تنظیم شده بود. طول پرس‌وجو ۳۷ بایت بود، بدون احتساب سرایندهای پروتکل IP و TCP یا UDP. عملیات پرس‌وجو از نوع معمولی، یعنی Query بود، بنابراین فیلد op حذف شد. اگر op هر چیز دیگری بود، بین `3' و `+' چاپ می‌شد. به همین ترتیب، qclass از نوع معمولی، یعنی C_IN بود و حذف شد. هر qclass دیگری بلافاصله پس از `A' چاپ می‌شد.

چند ناهنجاری بررسی می‌شوند و ممکن است منجر به فیلدهای اضافی درون قلاب‌ها شوند: اگر یک پرس‌وجو شامل بخش پاسخ، رکوردهای مرجع یا رکوردهای اضافی باشد، ancount، nscount، یا arcount به صورت `[na]'، `[nn]' یا `[nau]' چاپ می‌شوند که در آن n تعداد مربوطه است. اگر هر یک از بیت‌های پاسخ تنظیم شده باشد (AA، RA یا rcode) یا هر یک از بیت‌های `must be zero' در بایت‌های دو و سه تنظیم شده باشد، `[b2&3=x]' چاپ می‌شود، که در آن x مقدار هگزادسیمال بایت‌های دو و سه سرایند است..SS پاسخ‌های کارساز نام TCP یا UDP (TCP or UDP Name Server Responses)

پاسخ‌های کارساز نام به این صورت قالب‌بندی می‌شوند:

src > dst:  id op rcode flags a/n/au type class data (len)

helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)
در مثال نخست، helios به پرسمان با شناسهٔ ۳ از h2opolo با ۳ رکورد پاسخ، ۳ رکورد کارساز نام و ۷ رکورد تکمیلی پاسخ می‌دهد. نخستین رکورد پاسخ از نوع A (نشانی) بوده و دادهٔ آن نشانی اینترنتی 128.32.137.3 است. اندازهٔ کلی پاسخ، بدون احتساب سرایندهای TCP یا UDP و IP، برابر با ۲۷۳ بایت بود. مقدار op (Query) و کد پاسخ (NoError)، و نیز کلاس (C_IN) مربوط به رکورد A از قلم افتاده‌اند.

در مثال دوم، helios به پرسمان ۲ با کد پاسخ دامنهٔ ناموجود (NXDomain) همراه با صفر پاسخ، یک کارساز نام و بدون رکورد متولی پاسخ می‌دهد. علامت `*' نشان می‌دهد که بیت authoritative answer (پاسخ موثق) تنظیم شده بود. از آنجا که پاسخی وجود نداشت، هیچ نوع، کلاس یا داده‌ای چاپ نشد.

دیگر نویسه‌های پرچم که ممکن است نمایان شوند عبارتند از `-' (دسترس‌پذیری بازگشتی یا RA، تنظیم نشده) و `|' (پیام ناقص‌شده یا TC، تنظیم شده). اگر بخش «question» دقیقاً شامل یک ورودی نباشد، عبارت `[nq]' چاپ می‌شود.

ابزار tcpdump اکنون شامل رمزگشایی نسبتاً گستردهٔ SMB/CIFS/NBT برای داده‌ها روی پورت‌های UDP/137، UDP/138 و TCP/139 است. همچنین مقداری رمزگشایی اولیه از داده‌های SMB مربوط به IPX و NetBEUI انجام می‌گیرد.

به‌طور پیش‌فرض رمزگشایی نسبتاً کمینه‌ای انجام می‌شود، و در صورت استفاده از -v، رمزگشایی با جزئیات بسیار بیشتری صورت می‌گیرد. هشدار داده می‌شود که با گزینهٔ -v یک بستهٔ منفرد SMB ممکن است یک صفحه یا بیشتر فضا بگیرد، بنابراین تنها در صورتی از -v استفاده کنید که واقعاً خواهان تمام جزئیات ریز و دقیق باشید.

برای آگاهی از قالب بسته‌های SMB و معنای همهٔ فیلدها، https://download.samba.org/pub/samba/specs و دیگر منابع برخط را ببینید. وصله‌های SMB توسط Andrew Tridgell (tridge@samba.org) نوشته شده‌اند.

درخواست‌ها و پاسخ‌های پروتکل Sun NFS (سیستم فایل شبکه‌ای) به صورت زیر چاپ می‌شوند:

src.sport > dst.nfs: NFS request xid xid len op args
src.nfs > dst.dport: NFS reply xid xid reply stat len op results


sushi.1023 > wrl.nfs: NFS request xid 26377
	112 readlink fh 21,24/10.73165
wrl.nfs > sushi.1023: NFS reply xid 26377
	reply ok 40 readlink "../var"
sushi.1022 > wrl.nfs: NFS request xid 8219
	144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.1022: NFS reply xid 8219
	reply ok 128 lookup fh 9,74/4134.3150
در سطر نخست، میزبان sushi تراکنشی با شناسهٔ 26377 به wrl می‌فرستد. اندازهٔ درخواست بدون احتساب سرایندهای UDP و IP برابر با ۱۱۲ بایت بود. عملیات یک readlink (خواندن پیوند نمادین) روی دستگیرهٔ فایل (fh) با مقدار 21,24/10.731657119 بود. (اگر بخت یار باشد، همان‌طور که در این مورد است، دستگیرهٔ فایل را می‌توان به صورت جفت شماره‌های دستگاه major,minor و در ادامه شمارهٔ inode و شمارهٔ نسل تفسیر کرد.) در سطر دوم، wrl با همان شناسهٔ تراکنش و محتوای پیوند، مقدار `ok' را برمی‌گرداند.

در سطر سوم، sushi (با استفاده از یک شناسهٔ تراکنش جدید) از wrl می‌خواهد که نام `xcolors' را در فایل دایرکتوری 9,74/4096.6878 جستجو کند (lookup). در سطر چهارم، wrl پاسخی با شناسهٔ تراکنش مربوطه ارسال می‌کند.

توجه داشته باشید که داده‌های چاپ‌شده به نوع عملیات بستگی دارد. قالب خروجی به گونه‌ای طراحی شده است که اگر همراه با مشخصات پروتکل NFS خوانده شود، خودگویا و مفهوم باشد. همچنین توجه داشته باشید که نگارش‌های قدیمی‌تر tcpdump بسته‌های NFS را با قالبی کمی متفاوت چاپ می‌کردند: شناسهٔ تراکنش (xid) به جای شماره پورت غیر NFS بسته چاپ می‌شد.

اگر پرچم -v (پُرگو) داده شود، اطلاعات اضافی چاپ می‌شود. برای نمونه:


sushi.1023 > wrl.nfs: NFS request xid 79658
	148 read fh 21,11/12.195 8192 bytes @ 24576
wrl.nfs > sushi.1023: NFS reply xid 79658
	reply ok 1472 read REG 100664 ids 417/0 sz 29388
(پرچم -v همچنین فیلدهای TTL، ID، طول و قطعه‌بندی سرایند IP را نیز چاپ می‌کند که در این مثال حذف شده‌اند.) در سطر نخست، sushi از wrl می‌خواهد که ۸۱۹۲ بایت را از فایل 21,11/12.195 در آفست بایتی ۲۴۵۷۶ بخواند. میزبان Wrl پاسخ `ok' می‌دهد؛ بستهٔ نشان داده‌شده در سطر دوم نخستین قطعه از پاسخ است و از این رو تنها ۱۴۷۲ بایت طول دارد (سایر بایت‌ها در قطعه‌های بعدی ارسال خواهند شد، ولی این قطعه‌ها سرایند NFS یا حتی UDP ندارند و بنابراین بسته به عبارت پالایشی استفاده‌شده ممکن است چاپ نشوند). به دلیل داده شدن پرچم -v، برخی از مشخصه‌های فایل (که علاوه بر داده‌های فایل بازگردانده می‌شوند) چاپ می‌شوند: نوع فایل (``REG''، برای فایل عادی)، حالت فایل (در مبنای هشت)، شناسه‌های UID و GID، و اندازهٔ فایل.

اگر پرچم -v بیش از یک بار داده شود، جزئیات حتی بیشتری چاپ می‌شود.

بسته‌های پاسخ NFS عملیات RPC را به صورت صریح مشخص نمی‌کنند. در عوض، tcpdump درخواست‌های «اخیر» را دنبال می‌کند و با استفاده از شناسهٔ تراکنش (transaction ID)، آن‌ها را با پاسخ‌ها مطابقت می‌دهد. اگر پاسخی بلافاصله پس از درخواست متناظرش نیاید، ممکن است قابل تجزیه نباشد..SS "درخواست‌ها و پاسخ‌های AFS (AFS Requests and Replies)"

درخواست‌ها و پاسخ‌های Transarc AFS (سامانه فایل اندرو) به این صورت چاپ می‌شوند:

src.sport > dst.dport: rx packet-type
src.sport > dst.dport: rx packet-type service call call-name args
src.sport > dst.dport: rx packet-type service reply call-name args


elvis.7001 > pike.afsfs:
	rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
	new fid 536876964/1/1 ".newsrc"
pike.afsfs > elvis.7001: rx data fs reply rename
در خط نخست، میزبان elvis یک بستهٔ RX به pike ارسال می‌کند. این یک بستهٔ data از نوع RX به سرویس fs (سرور فایل) و آغاز یک فراخوانی RPC است. این فراخوانی RPC یک تغییر نام (rename) بود، با شناسهٔ فایل (fid) دایرکتوری قدیمیِ 536876964/1/1 و نام فایل قدیمیِ “.newsrc.new”، و شناسهٔ فایل دایرکتوری جدیدِ 536876964/1/1 و نام فایل جدیدِ “.newsrc”. میزبان pike با یک پاسخ RPC به فراخوانی rename پاسخ می‌دهد (که موفقیت‌آمیز بود، زیرا یک بستهٔ data بود و نه یک بستهٔ abort).

به طور کلی، تمام فراخوانی‌های RPC در AFS دست‌کم با نام فراخوانی RPC رمزگشایی می‌شوند. بیشتر فراخوانی‌های RPC در AFS دست‌کم بخشی از آرگومان‌هایشان رمزگشایی می‌شود (عموماً تنها آرگومان‌های «مهم»، بر اساس تعریف خاصی از اهمیت).

قالب به‌گونه‌ای طراحی شده است که خودتوضیح باشد، اما احتمالاً برای افرادی که با سازوکار AFS و RX آشنا نیستند مفید نخواهد بود.

اگر گزینهٔ -v (پُرگویی) دو بار مشخص شود، بسته‌های تصدیق (acknowledgement) و اطلاعات تکمیلی سرآیند چاپ می‌شوند، مانند شناسهٔ فراخوانی RX (یا RX call ID)، شمارهٔ فراخوانی، شمارهٔ توالی (sequence number)، شمارهٔ سریال، و پرچم‌های بستهٔ RX.

اگر گزینهٔ -v دو بار مشخص شود، اطلاعات بیشتری مانند شناسهٔ فراخوانی RX، شمارهٔ سریال و پرچم‌های بستهٔ RX چاپ می‌شوند. اطلاعات مذاکرهٔ MTU نیز از بسته‌های RX ack چاپ می‌شود.

اگر گزینهٔ -v سه بار مشخص شود، شاخص امنیت (security index) و service id چاپ می‌شوند.

کدهای خطا برای بسته‌های abort چاپ می‌شوند، به‌استثنای بسته‌های beacon مربوط به Ubik (زیرا بسته‌های abort برای نشان دادن رأی موافق در پروتکل Ubik به کار می‌روند).

بسته‌های پاسخ AFS به‌طور صریح نوع عملیات RPC را مشخص نمی‌کنند. در عوض، tcpdump درخواست‌های «اخیر» را دنبال کرده و با استفاده از شمارهٔ فراخوانی و شناسهٔ سرویس (service ID)، آن‌ها را با پاسخ‌ها مطابقت می‌دهد. اگر پاسخی در فاصلهٔ نزدیکی پس از درخواست متناظر خود نیاید، ممکن است قابل تجزیه نباشد.

بسته‌های AppleTalk DDP کپسوله‌شده در دیتاگرام‌های UDP، از کپسول خارج شده و به‌صورت بسته‌های DDP تخلیه (dump) می‌شوند (یعنی تمامی اطلاعات سرآیند UDP نادیده گرفته می‌شود). فایل /etc/atalk.names برای ترجمهٔ شماره‌های شبکه و گرهٔ AppleTalk به نام‌ها استفاده می‌شود. خطوط این فایل ساختار زیر را دارند:

number	name
1.254		ether
16.1		icsd-net
1.254.110	ace
دو خط نخست، نام‌های شبکه‌های AppleTalk را مشخص می‌کنند. خط سوم نام یک میزبان مشخص را ارائه می‌دهد (یک میزبان به‌وسیلهٔ اوکتت سوم در شماره از یک شبکه متمایز می‌شود - شمارهٔ شبکه باید دارای دو اوکتت و شمارهٔ میزبان باید دارای سه اوکتت باشد). شماره و نام باید با فاصلهٔ خالی (فاصله یا tab) از یکدیگر جدا شوند. فایل /etc/atalk.names می‌تواند شامل خطوط خالی یا خطوط توضیح (خطوطی که با '#' آغاز می‌شوند) باشد.

آدرس‌های AppleTalk در قالب زیر چاپ می‌شوند:

net.host.port
144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2
(اگر /etc/atalk.names وجود نداشته باشد یا شامل مدخلی برای شمارهٔ میزبان/شبکهٔ AppleTalk نباشد، آدرس‌ها به‌صورت عددی چاپ می‌شوند.) در مثال نخست، NBP (درگاه DDP شمارهٔ 2) روی شبکهٔ 144.1 و گرهٔ 209 در حال ارسال به هر چیزی است که روی درگاه 220 از شبکهٔ icsd و گرهٔ 112 گوش می‌دهد. خط دوم نیز مشابه است با این تفاوت که نام کامل گرهٔ مبدأ شناخته شده است (“office”). خط سوم یک ارسال از درگاه 235 روی شبکهٔ jssmag و گرهٔ 149 به نشانی پخش همگانی (broadcast) روی درگاه NBP در icsd-net است (توجه داشته باشید که نشانی پخش همگانی (255) با نام شبکه بدون شمارهٔ میزبان نشان داده می‌شود - به همین دلیل، ایدهٔ خوبی است که نام‌های گره و نام‌های شبکه را در /etc/atalk.names متمایز نگه دارید).

محتوای بسته‌های NBP (پروتکل پیوند نام) و ATP (پروتکل تراکنش AppleTalk) تفسیر می‌شود. سایر پروتکل‌ها تنها نام پروتکل (یا شمارهٔ آن، در صورتی که نامی برای پروتکل ثبت نشده باشد) و اندازهٔ بسته را چاپ می‌کنند..SS "بسته‌های NBP (NBP Packets)" بسته‌های NBP مانند مثال‌های زیر قالب‌بندی می‌شوند:

icsd-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
سطر نخست، یک درخواست جستجوی نام (name lookup) برای laserwriterها است که توسط میزبان 112 از شبکهٔ icsd ارسال شده و روی شبکهٔ jssmag همه‌پخشی (broadcast) شده است. شناسهٔ nbp برای این جستجو 190 است. سطر دوم پاسخی را برای این درخواست نشان می‌دهد (توجه داشته باشید که همان شناسه را دارد) از سوی میزبان jssmag.209 مبنی بر اینکه یک منبع laserwriter با نام "RM1140" ثبت‌شده روی درگاه 250 دارد. سطر سوم پاسخ دیگری به همان درخواست است مبنی بر اینکه میزبان techpit دارای laserwriter با نام "techpit" ثبت‌شده روی درگاه 186 است.

قالب‌بندی بسته‌های ATP در مثال زیر نشان داده شده است:

jssmag.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
میزبان Jssmag.209 تراکنشی با شناسهٔ 12266 را با میزبان helios از طریق درخواست تا حداکثر ۸ بسته (بخش `<0-7>`) آغاز می‌کند. عدد شانزده‌شانزدهی در انتهای سطر، مقدار فیلد `userdata` در درخواست است.

میزبان Helios با ۸ بستهٔ ۵۱۲ بایتی پاسخ می‌دهد. عبارت `:digit` پس از شناسهٔ تراکنش، شماره توالی بسته در تراکنش را مشخص می‌کند و عدد داخل پرانتز مقدار دادهٔ موجود در بسته بدون احتساب سرآیند ATP است. علامت `*` روی بستهٔ 7 نشان می‌دهد که بیت EOM تنظیم شده است.

سپس Jssmag.209 درخواست ارسال مجدد بسته‌های 3 و 5 را ارسال می‌کند. میزبان Helios آن‌ها را مجدداً ارسال کرده و سپس jssmag.209 تراکنش را آزاد می‌کند. در نهایت، jssmag.209 درخواست بعدی را آغاز می‌کند. علامت `*` روی درخواست نشان می‌دهد که XO (سرواژهٔ `exactly once` یا دقیقاً یک‌بار) تنظیم نشده بود.

نام پرچم‌های TCP شامل tcp-ece و tcp-cwr هنگام پیوند با libpcap نسخهٔ 1.9.0 یا بالاتر در دسترس قرار گرفتند.

stty(1), pcap(3PCAP), bpf(4), nit(4P), pcap-savefile(5), pcap-filter(7), pcap-tstamp(7)

https://www.iana.org/assignments/media-types/application/vnd.tcpdump.pcap
نویسندگان اصلی عبارتند از:

Van Jacobson، Craig Leres و Steven McCanne، همگی از Lawrence Berkeley National Laboratory، University of California، Berkeley، CA.

این پروژه در حال حاضر توسط The Tcpdump Group نگهداری می‌شود.

نسخهٔ فعلی از طریق HTTPS در دسترس است:

https://www.tcpdump.org

توزیع اصلی از طریق ftp ناشناس در دسترس است:

ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z

پشتیبانی از IPv6/IPsec توسط پروژهٔ WIDE/KAME افزوده شده است. این برنامه در پیکربندی‌های خاصی از OpenSSL/LibreSSL استفاده می‌کند.

برای گزارش یک مشکل امنیتی، لطفاً یک رایانامه به security@tcpdump.org ارسال کنید.

برای گزارش باگ‌ها و مشکلات دیگر، مشارکت با وصله‌ها، درخواست یک قابلیت، ارائهٔ بازخوردهای عمومی و غیره لطفاً فایل CONTRIBUTING.md را در ریشهٔ درخت کد منبع tcpdump مشاهده کنید.

NIT اجازه نمی‌دهد ترافیک خروجی خود را مشاهده کنید، اما BPF این اجازه را می‌دهد. توصیه می‌کنیم از دومی استفاده کنید.

باید تلاشی برای سرهم‌بندی مجدد قطعات IP یا دست‌کم محاسبهٔ طول صحیح برای پروتکل سطح بالاتر انجام شود.

پرس‌وجوهای معکوس کارگزار نام به درستی تخلیه نمی‌شوند: بخش پرسش (خالی) به جای پرس‌وجوی واقعی در بخش پاسخ چاپ می‌شود. برخی بر این باورند که پرس‌وجوهای معکوس خود یک باگ هستند و ترجیح می‌دهند برنامه‌ای را که آن‌ها را تولید می‌کند اصلاح کنند تا tcpdump.

ردگیری بسته‌ای که با تغییر ساعت تابستانی تلاقی کند، برچسب‌های زمانی نادقیقی به دست خواهد داد (تغییر ساعت نادیده گرفته می‌شود).

عبارت‌های فیلتر روی فیلدهایی غیر از موارد موجود در سرآمدهای Token Ring، بسته‌های Token Ring دارای مسیریابی مبدأ (source-routed) را به درستی پردازش نمی‌کنند.

عبارت‌های فیلتر روی فیلدهایی غیر از موارد موجود در سرآمدهای 802.11، بسته‌های دادهٔ 802.11 که هر دو مورد To DS و From DS در آن‌ها تنظیم شده است را به درستی پردازش نخواهند کرد.

ip6 proto باید زنجیرهٔ سرآمد را دنبال کند، اما در حال حاضر این کار را انجام نمی‌دهد. ip6 protochain برای این رفتار فراهم شده است.

عبارت محاسباتی روی سرآمدهای لایهٔ انتقال، مانند tcp[0]، روی بسته‌های IPv6 کار نمی‌کند. این عبارت تنها بسته‌های IPv4 را بررسی می‌کند.

30 June 2025