TCPDUMP(8) System Manager's Manual TCPDUMP(8)

tcpdump - ابزار تجزیه و تحلیل و شنود بستههای ترافیک شبکه

tcpdump [ -adeflnNOpqStvx ] [ -c count ] [ -F file ]
[ -i interface ] [ -r file ] [ -s snaplen ]
[ -T type ] [ -w file ] [ expression ]

دستور tcpdump هدرهای بسته‌های روی یک رابط شبکه را که با عبارت بولی expression مطابقت دارند چاپ می‌کند.

در SunOS با رابط nit یا bpf: برای اجرای tcpdump، باید دسترسی خواندن به /dev/nit یا /dev/bpf* داشته باشید.

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

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

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

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

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

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

تلاش برای تبدیل آدرس‌های شبکه و پخش همگانی (broadcast) به نام‌ها.
خروج پس از دریافت count بسته.
کد کامپایل‌شدهٔ تطبیق بسته (packet-matching code) را به شکلی خوانا برای انسان به خروجی استاندارد ریخته و متوقف می‌شود.
کد تطبیق بسته (packet-matching code) را در قالب قطعه‌کدی از زبان C خروجی می‌دهد.
کد تطبیق بسته (packet-matching code) را به‌صورت اعداد ده‌دهی (همراه با تعداد در ابتدا) خروجی می‌دهد.
چاپ هدر لایهٔ پیوند داده (link-level header) در هر سطر خروجی.
آدرس‌های اینترنتی «خارجی» را به‌جای نمادین، به‌صورت عددی چاپ می‌کند (این گزینه برای دور زدن مشکل اساسی سرور yp شرکت Sun به کار می‌رود — که معمولاً هنگام ترجمهٔ شماره‌های شبکهٔ محلی برای همیشه معلق می‌ماند).
استفاده از محتوای file به‌عنوان عبارت فیلتر. عبارتی که در خط فرمان وارد شده باشد نادیده گرفته می‌شود.
شنود روی رابط شبکهٔ interface. اگر رابطی مشخص نشود، tcpdump در فهرست رابط‌های سیستم، رابط فعال و پیکربندی‌شده با کمترین شماره (به‌جز loopback) را جستجو می‌کند. در صورت وجود گزینه‌های هم‌رتبه، نخستین مورد انتخاب می‌شود.
بافر کردن سطری خروجی استاندارد. زمانی که می‌خواهید داده‌ها را هم‌زمان با ضبط مشاهده کنید کاربرد دارد؛ برای نمونه:
``tcpdump  -l  |  tee dat'' یا ``tcpdump  -l  > dat  &  tail  -f  dat''.
عدم تبدیل آدرس‌ها (مانند آدرس‌های میزبان، شماره پورت‌ها و غیره) به نام.
عدم چاپ بخش دامنه در نام‌های میزبان. برای نمونه، با فعال بودن این گزینه، tcpdump به‌جای ``nic.ddn.mil'' عبارت ``nic'' را چاپ می‌کند.
عدم اجرای بهینه‌ساز کد تطبیق بسته. این گزینه تنها زمانی کاربرد دارد که به وجود اشکالی در بهینه‌ساز مشکوک باشید.
عدم قرار دادن رابط شبکه در حالت بی‌قیدوشرط (promiscuous mode). توجه داشته باشید که ممکن است رابط شبکه به دلایل دیگری در این حالت باشد؛ بنابراین، گزینهٔ -p نمی‌تواند به‌عنوان مخففی برای `ether host {local-hw-addr} or ether broadcast' به کار رود.
خروجی سریع و کوتاه؛ اطلاعات کمتری از پروتکل‌ها چاپ می‌شود تا سطرهای خروجی کوتاه‌تر باشند.
خواندن بسته‌ها از file (که پیش‌تر با گزینهٔ -w ایجاد شده است). اگر مقدار file برابر ``-'' باشد، داده‌ها از ورودی استاندارد خوانده می‌شوند.
دریافت snaplen بایت داده از هر بسته به‌جای مقدار پیش‌فرض ۶۸ بایت (در NIT سیستم‌عامل SunOS، حداقل مقدار در عمل ۹۶ است). مقدار ۶۸ بایت برای پروتکل‌های IP، ICMP، TCP و UDP کافی است، اما ممکن است اطلاعات پروتکل مربوط به سرورهای نام (DNS) و بسته‌های NFS را ناقص کند (به بخش‌های بعد مراجعه کنید). بسته‌هایی که به دلیل عکس‌برداری محدود بریده شده‌اند، در خروجی با علامت ``[|proto]'' مشخص می‌شوند که در آن proto نام لایهٔ پروتکلی است که برش در آن رخ داده است. توجه داشته باشید که بزرگ‌تر کردن اندازهٔ ضبط، هم زمان پردازش بسته‌ها را افزایش می‌دهد و هم بافرینگ بسته‌ها را کاهش می‌دهد که ممکن است باعث از دست رفتن بسته‌ها شود. شما باید snaplen را تا حد امکان کوچک انتخاب کنید، به طوری که تنها اطلاعات پروتکل مورد نیاز شما را در بر گیرد.
وادار ساختن بسته‌های انتخاب‌شده توسط "expression" به تفسیر به عنوان نوع مشخص‌شدهٔ type. انواع شناخته‌شده در حال حاضر عبارتند از: rpc (فراخوانی رویه از راه دور - Remote Procedure Call)، rtp (پروتکل کاربردهای بی‌درنگ - Real-Time Applications protocol)، rtcp (پروتکل کنترل کاربردهای بی‌درنگ - Real-Time Applications control protocol)، vat (ابزار صوتی تصویری - Visual Audio Tool) و wb (تخته‌سفید توزیع‌شده - distributed White Board).
نمایش شماره توالی‌های مطلق به جای شماره توالی‌های نسبی TCP.
عدم چاپ برچسب زمانی روی هر سطر خروجی.
چاپ برچسب زمانی بدون قالب‌بندی (ثانیه‌های خام) روی هر سطر خروجی.
خروجی با جزئیات بیشتر (verbose). برای نمونه، زمان حیات (TTL) و نوع سرویس (TOS) در بستهٔ IP نمایش داده می‌شوند.
خروجی با جزئیات حتی بیشتر. برای نمونه، فیلدهای اضافی بسته‌های پاسخ NFS چاپ می‌شوند.
نوشتن بسته‌های خام در file به‌جای تجزیه و نمایش آن‌ها. بعداً می‌توان آن‌ها را با گزینهٔ -r نمایش داد. اگر مقدار file برابر ``-'' باشد، بسته‌ها در خروجی استاندارد نوشته می‌شوند.
چاپ هر بسته (منهای هدر لایهٔ پیوند آن) به صورت هگزادسیمال. مقدار کمتر بین کل بسته یا snaplen بایت چاپ خواهد شد.
بسته‌هایی را که باید ضبط شوند انتخاب می‌کند. اگر expression مشخص نشود، تمام بسته‌های روی شبکه ثبت می‌شوند. در غیر این صورت، تنها بسته‌هایی ثبت می‌شوند که عبارت expression برای آن‌ها مقدار 'درست' (true) داشته باشد.

عبارت expression از یک یا چند شناسه اولیه (primitive) تشکیل شده است. یک شناسه اولیه معمولاً از یک شناسه (id) (نام یا شماره)، و یک یا چند توصیف‌کننده (qualifier) پیش از آن تشکیل می‌شود. سه نوع مختلف توصیف‌کننده وجود دارد:

توصیف‌کننده‌های نوع (type) مشخص می‌کنند که نام یا شمارهٔ شناسه به چه چیزی اشاره دارد. انواع ممکن عبارتند از: host، net و port. برای نمونه: `host foo'، `net 128.3'، `port 20'. اگر توصیف‌کنندهٔ نوع مشخص نشود، مقدار پیش‌فرض host در نظر گرفته می‌شود.
توصیف‌کننده‌های جهت (dir) جهت انتقال داده را نسبت به شناسه مشخص می‌کنند (اینکه داده به سمت شناسه می‌رود یا از آن می‌آید). جهت‌های ممکن عبارتند از: src، dst، src or dst و src and dst. برای نمونه: `src foo'، `dst net 128.3'، `src or dst port ftp-data'. اگر توصیف‌کنندهٔ جهت مشخص نشود، مقدار پیش‌فرض src or dst است. برای لایه‌های پیوند «تهی» (null) (مانند پروتکل‌های نقطه‌به‌نقطه نظیر slip)، توصیف‌کننده‌های inbound و outbound جهت انتقال مورد نظر را مشخص می‌کنند.
توصیف‌کننده‌های پروتکل (proto) تطبیق را به یک پروتکل خاص محدود می‌کنند. پروتکل‌های ممکن عبارتند از: ether، fddi، ip، arp، rarp، decnet، lat، sca، moprc، mopdl، tcp و 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' است.

[fddi در واقع یک نام مستعار برای ether است؛ تحلیل‌گر با هر دو به‌صورت یکسان به عنوان «لایهٔ پیوند دادهٔ مورد استفاده در رابط شبکهٔ مشخص‌شده» رفتار می‌کند. هدرهای FDDI شامل آدرس‌های مبدأ و مقصد مشابه اترنت هستند و معمولاً انواع بسته‌ای مشابه اترنت دارند، بنابراین می‌توانید روی این فیلدهای FDDI درست مانند فیلدهای اترنت فیلتر بگذارید. هدرهای FDDI شامل فیلدهای دیگری نیز هستند، اما نمی‌توانید آن‌ها را به‌طور صریح در عبارت فیلتر نام ببرید.]

علاوه بر موارد فوق، کلمات کلیدی ویژه‌ای برای «شناسه‌های اولیه» وجود دارند: gateway، broadcast، less، greater و عبارات ریاضی. این موارد از الگوی بالا پیروی نمی‌کنند و در ادامه شرح داده شده‌اند.

عبارات فیلتر پیچیده‌تر را می‌توان با ترکیب شناسه‌های اولیه با استفاده از کلمات and، or و 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'.

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

اگر فیلد مقصد IP بسته برابر با host باشد، نتیجه درست است. host می‌تواند یک آدرس یا یک نام میزبان باشد.
اگر فیلد مبدأ IP بسته برابر با host باشد، نتیجه درست است.
اگر مبدأ یا مقصد IP بسته برابر با host باشد، نتیجه درست است. به هر یک از عبارات host بالا می‌توان پیشوند کلمات کلیدی ip، arp یا rarp را اضافه کرد، مانند: 
ip host host

که معادل است با: 
ether proto \ip and host host

اگر host نام میزبانی با چندین آدرس IP باشد، هر یک از آدرس‌های آن بررسی می‌شود.
اگر آدرس اترنت مقصد بسته برابر با ehost باشد، نتیجه درست است. Ehost می‌تواند یک نام (از فایل /etc/ethers) یا یک شماره باشد (برای ساختار شماره‌ها به ethers(3N) مراجعه کنید).
اگر آدرس اترنت مبدأ بسته برابر با ehost باشد، نتیجه درست است.
اگر آدرس اترنت مبدأ یا مقصد بسته برابر با ehost باشد، نتیجه درست است.
اگر بسته از host به‌عنوان دروازه (gateway) استفاده کرده باشد، نتیجه درست است؛ به این معنی که آدرس اترنت مبدأ یا مقصد بسته برابر با host است، اما هیچ‌یک از آدرس‌های IP مبدأ یا مقصد host نیستند. host باید یک نام میزبان باشد و باید در هر دو فایل /etc/hosts و /etc/ethers موجود باشد (یک عبارت معادل: 
ether host ehost and not host host

است که در آن host / ehost می‌تواند نام یا شماره باشد).
اگر آدرس IP مقصد بسته متعلق به شبکهٔ net باشد، نتیجه درست است. net می‌تواند یک نام (از /etc/networks) یا یک شماره شبکه باشد (برای جزئیات به networks(4) مراجعه کنید).
اگر آدرس IP مبدأ بسته متعلق به شبکهٔ net باشد، نتیجه درست است.
اگر آدرس IP مبدأ یا مقصد بسته متعلق به شبکهٔ net باشد، نتیجه درست است.
اگر آدرس IP با ماسک شبکهٔ مشخص‌شده در net مطابقت داشته باشد، نتیجه درست است. می‌توان این شناسه را با src یا dst ترکیب کرد.
اگر آدرس IP با ماسک شبکهٔ با طول len بیت از net مطابقت داشته باشد، نتیجه درست است. می‌توان این شناسه را با src یا dst ترکیب کرد.
اگر بسته از نوع ip/tcp یا ip/udp بوده و پورت مقصد آن port باشد، نتیجه درست است. port می‌تواند یک عدد یا نام مشخص‌شده در /etc/services باشد (به tcp(4P) و udp(4P) مراجعه کنید). اگر از یک نام استفاده شود، هم شماره پورت و هم پروتکل بررسی می‌شوند. اگر از یک عدد یا یک نام دارای ابهام استفاده شود، تنها شماره پورت بررسی می‌شود (برای نمونه، dst port 513 داده‌های tcp/login و udp/who را نمایش می‌دهد، و port domain داده‌های tcp/domain و udp/domain را نمایش می‌دهد).
اگر شماره پورت مبدأ بسته برابر با port باشد، نتیجه درست است.
اگر پورت مبدأ یا مقصد بسته برابر با port باشد، نتیجه درست است. هر یک از عبارات پورت بالا می‌توانند با کلمات کلیدی tcp یا udp پیشوندگذاری شوند، مانند: 
tcp src port port

که تنها با بسته‌های TCP با پورت مبدأ port مطابقت دارد.
اگر طول بسته کمتر یا مساوی length باشد، نتیجه درست است؛ معادل با: 
len <= length.

اگر طول بسته بزرگتر یا مساوی length باشد، نتیجه درست است؛ معادل با: 
len >= length.

اگر بسته یک بستهٔ IP باشد (به ip(4P) مراجعه کنید) که نوع پروتکل آن protocol است، نتیجه درست است. Protocol می‌تواند یک عدد یا یکی از نام‌های زیر باشد: icmp، igrp، udp، nd یا tcp. توجه داشته باشید که شناسه‌های tcp، udp و icmp همچنین کلمات کلیدی هستند، بنابراین باید با یک بک‌اسلش (\) اسکیپ شوند، که در C-shell باید به‌صورت \\ باشد.
اگر بسته یک بستهٔ پخش همگانی اترنت باشد، نتیجه درست است. کلمهٔ کلیدی ether اختیاری است.
اگر بسته یک بستهٔ پخش همگانی IP باشد، نتیجه درست است. دستور Tcpdump قراردادهای پخش همگانی همه‌صفر و همه‌یک را بررسی کرده و ماسک زیرشبکهٔ محلی را نیز اعمال می‌کند.
اگر بسته یک بستهٔ چندپخشی اترنت (multicast) باشد، نتیجه درست است. کلمهٔ کلیدی ether اختیاری است؛ این عبارت در واقع کوتاه‌شدهٔ `ether[0] & 1 != 0' است.
اگر بسته یک بستهٔ چندپخشی IP باشد، نتیجه درست است.
اگر پروتکل بسته متعلق به نوع اترنت protocol باشد، نتیجه درست است. Protocol می‌تواند یک عدد یا یک نام مانند ip، arp یا rarp باشد. توجه داشته باشید که این شناسه‌ها کلمات کلیدی نیز هستند، بنابراین باید با یک بک‌اسلش (\) اسکیپ شوند. [در صورت استفاده از FDDI (مانند `fddi protocol arp')، شناسایی پروتکل از هدر کنترل پیوند منطقی 802.2 (LLC) ناشی می‌شود که معمولاً در بالای هدر FDDI قرار دارد. هنگام فیلتر کردن بسته‌ها بر اساس شناسهٔ پروتکل، tcpdump فرض می‌کند که تمام بسته‌های FDDI شامل هدر LLC هستند و این هدر در قالب SNAP است.]
اگر آدرس مبدأ DECNET برابر با host باشد، نتیجه درست است؛ که ممکن است به شکل ``10.123'' یا یک نام میزبان DECNET باشد. [تنها سیستم‌های Ultrix که برای اجرای DECNET پیکربندی شده‌اند از نام‌های میزبان DECNET پشتیبانی می‌کنند.]
اگر آدرس مقصد DECNET برابر با host باشد، نتیجه درست است.
اگر آدرس مبدأ یا مقصد DECNET برابر با host باشد، نتیجه درست است.
کوتاه‌شدهٔ عبارت: 
ether proto p

است که در آن p یکی از پروتکل‌های یادشده است.
کوتاه‌شدهٔ عبارت: 
ether proto p

است که در آن p یکی از پروتکل‌های یادشده است. توجه داشته باشید که tcpdump در حال حاضر نحوهٔ تجزیه و تحلیل این پروتکل‌ها را نمی‌داند.
کوتاه‌شدهٔ عبارت: 
ip proto p

است که در آن p یکی از پروتکل‌های یادشده است.
اگر این رابطه برقرار باشد، نتیجه درست است؛ که در آن relop یکی از عملگرهای >، <، >=، <=، =، != است و expr یک عبارت محاسباتی تشکیل‌شده از ثابت‌های صحیح (به قالب استاندارد C)، عملگرهای دودویی معمول [+, -, *, /, &, |]، یک عملگر طول بسته، و عملگرهای دسترسی به داده‌های بسته است. برای دسترسی به داده‌های درون بسته، از ساختار نحوی زیر استفاده کنید: 
proto [ expr : size ]

که در آن proto یکی از موارد ether, fddi, ip, arp, rarp, tcp, udp, یا icmp است و لایهٔ پروتکل برای عملیات اندیس‌گذاری را مشخص می‌کند. expr آفست بایت را نسبت به لایهٔ پروتکل مشخص‌شده نشان می‌دهد. size اختیاری است و تعداد بایت‌های مورد نظر را مشخص می‌کند؛ می‌تواند 1، 2 یا 4 باشد و پیش‌فرض آن 1 بایت است. عملگر طول که با کلمهٔ کلیدی len مشخص می‌شود، طول کل بسته را نشان می‌دهد.

برای نمونه، `ether[0] & 1 != 0' تمامی بسته‌های چندپخشی را دریافت می‌کند. عبارت `ip[0] & 0xf != 5' تمام بسته‌های IP دارای فیلدهای اختیاری را دریافت می‌کند. عبارت `ip[6:2] & 0x1fff = 0' تنها داده‌های قطعه‌بندی‌نشده و بسته‌های با آفست قطعه صفر را دریافت می‌کند. این بررسی به‌طور ضمنی در عملیات اندیس‌گذاری tcp و udp اعمال می‌شود؛ برای نمونه، tcp[0] همیشه نخستین بایت از هدر TCP است و هرگز اولین بایت یک قطعهٔ IP میانی نیست.

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

گروهی از شناسه‌ها و عملگرها محصور در پرانتز (پرانتزها در پوسته کاراکترهای ویژه هستند، بنابراین باید اسکیپ شوند).
عمل نقیض (`!' یا `not').
عمل عطف منطقی (`&&' یا `and').
عمل فصل منطقی (`||' یا `or').

عمل نقیض بالاترین اولویت را دارد. عمل فصل و عمل عطف اولویت یکسانی دارند و ارزیابی آن‌ها از چپ به راست انجام می‌شود. توجه داشته باشید که عمل عطف نیاز به عملگر صریح and دارد و قرار گرفتن در کنار هم کافی نیست.

اگر شناسه‌ای بدون کلمهٔ کلیدی وارد شود، کلمهٔ کلیدی اخیراً استفاده‌شده فرض می‌شود؛ برای نمونه: 

not host vs and ace
کوتاه‌شدهٔ عبارت: 
not host vs and host ace
است، و نباید با عبارت: 
not ( host vs or ace )
اشتباه گرفته شود.

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

نمایش تمامی بسته‌های ورودی یا خروجی از میزبان 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 (توجه داشته باشید که این عبارت برای جلوگیری از تفسیر پرانتزها توسط پوسته، در نقل‌قول تکی محصور شده است):


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

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


tcpdump ip and not net localnet

نمایش بسته‌های شروع و پایان هر نشست TCP (بسته‌های SYN و FIN) که یکی از طرفین آن یک میزبان دوردست باشد:


tcpdump 'tcp[13] & 3 != 0 and not src and dst net localnet'

نمایش بسته‌های IP عبوری از دروازهٔ snup که بزرگتر از ۵۷۶ بایت هستند:


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

نمایش بسته‌های پخش همگانی یا چندپخشی IP که نه به‌صورت پخش همگانی اترنت و نه چندپخشی اترنت ارسال شده‌اند:


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

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


tcpdump 'icmp[0] != 8 and icmp[0] != 0'

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

هدرهای لایه پیوند (Link Level Headers)

اگر گزینهٔ '-e' مشخص شود، هدرهای لایهٔ پیوند چاپ می‌شوند.

روی اترنت، آدرس‌های مبدأ و مقصد، پروتکل و طول بسته نمایش داده می‌شوند.

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

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

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

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

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

بسته‌های ARP/RARP

خروجی بسته‌های 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) بوده و طول کل بسته ۶۴ بایت است.

بسته‌های TCP

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

به‌طور کلی، قالب خروجی پروتکل tcp به صورت زیر است:

src > dst: flags data-seqno ack window urgent options
فیلدهای src و dst آدرس‌ها و پورت‌های مبدأ و مقصد IP هستند. Flags شامل یکی از پرچم‌های S (SYN)، F (FIN)، P (PUSH) یا R (RST) یا یک `.' تنها (بدون پرچم)، یا ترکیبی از آن‌ها است. Data-seqno موقعیت داده‌های این بسته را در شماره توالی جریان مشخص می‌کند (به مثال زیر مراجعه کنید). Ack شماره توالی بایت بعدی است که این منبع انتظار دریافت آن را روی این اتصال دارد. Window اندازهٔ بافر دریافت منبع بر حسب بایت روی این اتصال است. Urg نشان می‌دهد که داده‌های `فوری (urgent)' درون بسته وجود دارد. Options گزینه‌های tcp هستند که در پرانتزهای شکسته محصور شده‌اند (مانند <mss 1024>).

فیلدهای src, dst و flags همواره وجود دارند. سایر فیلدها بسته به محتوای هدر tcp بسته، تنها در صورت نیاز چاپ می‌شوند.

در ادامه بخش ابتدایی یک اتصال rlogin از میزبان rtsg به میزبان csam آورده شده است:

rtsg.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
سطر نخست نشان می‌دهد که از پورت ۱۰۲۳ پروتکل tcp در rtsg به پورت login در csam بسته‌ای ارسال شده است. پرچم S نشان می‌دهد که پرچم SYN تنظیم شده است. شماره توالی بسته ۷۶۸۵۱۲ است و فاقد داده می‌باشد (این به صورت `first:last(nbytes)' نوشته می‌شود، به این معنی که `از شماره توالی first تا last، بدون دربرگرفتن last، به میزان nbytes بایت دادهٔ کاربری وجود دارد'). در این لحظه تأییدیهٔ سوارشده (piggy-backed ack) وجود ندارد، پنجرهٔ دریافت معتبر ۴۰۹۶ بایت است، و گزینهٔ بیشینه اندازهٔ بخش (max-segment-size) درخواست تنظیم mss به ۱۰۲۴ بایت را دارد.

میزبان Csam پاسخی با قالبی مشابه می‌دهد، با این تفاوت که یک تأییدیهٔ سوارشده برای SYN مربوط به rtsg به آن اضافه شده است. سپس Rtsg بستهٔ SYN مربوط به csam را تأیید می‌کند. علامت `.' به معنی عدم تنظیم هیچ پرچمی است. این بسته حاوی داده نیست، بنابراین فاقد شماره توالی داده است. توجه داشته باشید که این شماره توالی تأییدیه یک عدد صحیح کوچک (1) است. هنگامی که tcpdump برای نخستین بار یک گفتگوی tcp را می‌بیند، شماره توالی موجود در بسته را نمایش می‌دهد. در بسته‌های بعدی همان گفتگو، تفاوت شماره توالی بستهٔ فعلی با آن بستهٔ نخستین را چاپ می‌کند. این به این معنی است که از بستهٔ اول به بعد، شماره توالی‌ها را می‌توان به عنوان آفست نسبی در جریان داده در نظر گرفت (که در آن نخستین بایت دادهٔ هر گفتگو از عدد '1' شماره‌گذاری می‌شود). گزینهٔ `-S' این رفتار را تغییر داده و شماره توالی‌های خام را مستقیماً چاپ می‌کند.

در سطر ششم، rtsg مقدار ۱۹ بایت داده (بایت‌های ۲ تا ۲۰) را به csam ارسال می‌کند. پرچم PUSH در بسته تنظیم شده است. در سطر هفتم csam اعلام می‌کند که داده‌های ارسال‌شده توسط rtsg را تا بایت ۲۱ دریافت کرده است، اما خود بایت ۲۱ را شامل نمی‌شود. بیشتر داده‌ها آشکارا در بافر سوکت قرار دارند، زیرا اندازهٔ پنجرهٔ دریافت csam کمتر از ۱۹ بایت شده است. هم‌زمان csam یک بایت داده برای rtsg می‌فرستد. سطرهای هشتم و نهم نشان می‌دهند که csam دو بایت دادهٔ فوری را برای rtsg ارسال می‌کند.

اگر محدودهٔ ضبط آن‌قدر کوچک تنظیم شده باشد که tcpdump نتواند هدر کامل TCP را ضبط کند، تا حد امکان بخش ضبط‌شده را تفسیر کرده و سپس ``[|tcp]'' را نمایش می‌دهد تا نشان دهد باقی‌مانده قابل تفسیر نیست. اگر هدر حاوی گزینه‌ای نادرست باشد (طول گزینه بسیار کوچک باشد یا از محدودهٔ هدر فراتر رود)، tcpdump عبارت ``[bad opt]'' را نمایش داده و تفسیر گزینه‌های بعدی را متوقف می‌کند. اگر طول هدر نشان‌دهندهٔ وجود گزینه‌ها باشد اما طول دیتاگرام IP برای نگهداری واقعی گزینه‌ها کافی نباشد، عبارت ``[bad hdr length]'' نمایش داده می‌شود.

بسته‌های UDP

قالب UDP مانند نمونهٔ زیر از یک بستهٔ rwho است:

actinide.who > broadcast.who: udp 84
این خروجی نشان می‌دهد که یک بستهٔ دیتاگرام udp از پورت who در میزبان actinide به پورت who در broadcast، آدرس پخش همگانی اینترنت، فرستاده شده است. این بسته شامل ۸۴ بایت دادهٔ کاربری است.

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

درخواست‌های سرویس‌دهنده نام UDP (Name Server Requests)

(توجه: در توضیحات زیر فرض می‌شود که با پروتکل سرویس‌دهندهٔ نام شرح داده شده در 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) تنظیم شده است. طول پرس‌وجو ۳۷ بایت است، بدون احتساب هدرهای UDP و IP. عملیات پرس‌وجو از نوع استاندارد Query است، بنابراین فیلد op حذف شده است. اگر op چیز دیگری تنظیم شده بود، بین `3' و `+' نمایش داده می‌شد. به‌طور مشابه، qclass از نوع معمولی C_IN است و حذف شده است؛ سایر انواع qclass پس از `A' نمایش داده می‌شوند.

دستور Tcpdump برخی شرایط غیرعادی را بررسی می‌کند و نتایج مربوطه را درون کروشه‌ها نمایش می‌دهد: اگر یک پرس‌وجو شامل بخش‌های پاسخ، سرویس‌دهندهٔ نام یا اختیارات باشد، فیلدهای ancount، nscount یا arcount به صورت `[na]'، `[nn]' یا `[nau]' نمایش داده می‌شوند که در آن‌ها n تعداد مربوطه است. اگر در بایت‌های دوم و سوم، هر یک از بیت‌های پاسخ (AA، RA یا rcode) یا هر یک از بیت‌های «باید صفر باشد» تنظیم شده باشند، عبارت `[b2&3=x]' نمایش داده می‌شود که در آن x مقدار هگزادسیمال بایت‌های دوم و سوم هدر است.

پاسخ‌های سرویس‌دهنده نام UDP

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

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 است. طول کل پاسخ ۲۷۳ بایت است، بدون احتساب هدرهای UDP و IP. برای رکورد A با کلاس C_IN، فیلدهای op (پرس‌وجو) و rcode (بدون خطا) حذف شده‌اند.

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

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

توجه داشته باشید که پرس‌وجوها و پاسخ‌های سرویس‌دهندهٔ نام معمولاً بزرگ هستند و ممکن است مقدار پیش‌فرض ۶۸ بایت برای snaplen نتواند محتوای کافی از بسته را ضبط کند. اگر قصد بررسی دقیق ترافیک سرویس‌دهندهٔ نام را دارید، از گزینهٔ -s برای افزایش بافر ضبط استفاده کنید؛ گزینهٔ `-s 128' مناسب خواهد بود.

درخواست‌ها و پاسخ‌های NFS

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

src.xid > dst.nfs: len op args
src.nfs > dst.xid: reply stat len op results


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
در سطر اول، میزبان sushi یک نشست تعاملی با شناسهٔ 6709 به wrl ارسال می‌کند (توجه داشته باشید که عدد پس از میزبان مبدأ، شناسهٔ تراکنش است و نه شماره پورت). این درخواست ۱۱۲ بایت طول دارد، بدون احتساب هدرهای UDP و IP. این عملیات روی دستگیرهٔ فایل (fh) با مقدار 21,24/10.731657119 و از نوع readlink (خواندن پیوند نمادین) است (در صورت مساعد بودن شرایط، مانند این مورد، دستگیرهٔ فایل را می‌توان به ترتیب به شماره‌های دستگاه اصلی و فرعی، شماره inode، و شماره نسل ترجمه کرد). میزبان Wrl با `ok' و محتوای پیوند پاسخ می‌دهد.

در سطر سوم، sushi از wrl می‌خواهد که فایل `xcolors' را در دایرکتوری با دستگیرهٔ 9,74/4096.6878 جستجو کند. توجه داشته باشید که قالب داده‌ها به نوع عملیات بستگی دارد و ساختار آن خودتوضیح است.

مشخص کردن گزینهٔ -v (پرگویی) اطلاعات تکمیلی را نمایش می‌دهد؛ برای نمونه:


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
(گزینهٔ -v همچنین باعث می‌شود فیلدهای TTL، ID و قطعه‌بندی در هدر IP نمایش داده شوند که در این مثال حذف شده‌اند). در سطر اول، sushi از wrl می‌خواهد که از آفست ۲۴۵۷۶ فایل 21,11/12.195، مقدار ۸۱۹۲ بایت را بخواند. Wrl با `ok' پاسخ می‌دهد؛ بستهٔ نمایش‌داده‌شده در سطر دوم نخستین قطعه از پاسخ است، بنابراین تنها ۱۴۷۲ بایت طول دارد (بقیهٔ داده‌ها در قطعات بعدی منتقل می‌شوند، اما چون آن قطعات فاقد هدر NFS یا حتی UDP هستند، بسته به عبارت فیلتر به کار رفته ممکن است نمایش داده نشوند). گزینهٔ -v همچنین برخی از ویژگی‌های فایل را نمایش می‌دهد (که همراه با داده‌های فایل بازگردانده می‌شوند): نوع فایل (فایل معمولی ``REG'')، حالت دسترسی (به هشت‌هشتی)، uid و gid، و اندازهٔ فایل.

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

توجه داشته باشید که داده‌های درخواست‌های NFS بسیار حجیم هستند و اگر مقدار snaplen افزایش نیابد، بسیاری از جزئیات نمایش داده نخواهند شد؛ گزینهٔ `-s 192' را امتحان کنید.

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

پروتکل KIP Appletalk (پروتکل DDP روی UDP)

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

number       name
1.254              ether
16.1            icsd-net
1.254.110       ace
دو سطر نخست نام شبکه‌های appletalk را مشخص می‌کنند. سطر سوم نام یک میزبان مشخص را تعیین می‌کند (میزبان‌ها و شبکه‌ها بر اساس بخش سوم شماره متمایز می‌شوند - شماره شبکه الزاماً دو بخش و شماره میزبان الزاماً سه بخش است). شماره و نام با نویسه‌های فاصله یا تب از هم جدا می‌شوند. فایل /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 وجود نداشته باشد، یا فاقد مدخل‌های معتبر باشد، آدرس‌ها به‌صورت عددی چاپ می‌شوند). در مثال اول، پورت NBP (پورت ۲ پروتکل DDP) از گره ۲۰۹ در شبکهٔ 144.1 داده‌ها را به پورت ۲۲۰ از گره ۱۱۲ در شبکهٔ icsd می‌فرستد. سطر دوم مشابه سطر پیشین است با این تفاوت که نام کامل گره مبدأ (`office') مشخص است. سطر سوم یک پخش همگانی از پورت ۲۳۵ از گره ۱۴۹ در شبکهٔ jssmag به پورت NBP در icsd-net است (توجه داشته باشید که آدرس پخش همگانی (255) به‌طور ضمنی در نام شبکه‌ای که شمارهٔ میزبان ندارد مستتر است - بنابراین تفکیک نام گره و نام شبکه در /etc/atalk.names ایدهٔ خوبی است).

دستور Tcpdump می‌تواند محتوای بسته‌های NBP (پروتکل اتصال نام) و ATP (پروتکل تراکنش Appletalk) را ترجمه کند. برای سایر پروتکل‌ها تنها نام پروتکل (یا شماره آن در صورتی که نامی برای آن ثبت نشده باشد) و اندازهٔ بسته چاپ می‌شود.

قالب خروجی بسته‌های 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
سطر اول یک پخش همگانی توسط میزبان ۱۱۲ از شبکهٔ icsd روی شبکهٔ jssmag برای جستجوی نام laserwriter است. شناسهٔ nbp این درخواست ۱۹۰ است. سطر دوم پاسخی به این درخواست را نشان می‌دهد (توجه کنید که هر دو دارای شناسهٔ یکسانی هستند)؛ میزبان jssmag.209 اعلام می‌کند که روی پورت ۲۵۰ منبعی به نام "RM1140" برای laserwriter ثبت کرده است. سطر سوم پاسخ دیگری به همین درخواست است که در آن میزبان techpit روی پورت ۱۸۶ منبعی به نام "techpit" برای laserwriter دارد.

قالب بسته‌های 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 یک تراکنش با شمارهٔ ۱۲۲۶۶ با میزبان helios آغاز کرده و درخواست ۸ بسته را می‌دهد (`<0-7>'). عدد هگزادسیمال در انتهای سطر، مقدار فیلد `userdata' در درخواست است.

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

سپس Jssmag.209 درخواست ارسال مجدد بسته‌های ۳ و ۵ را می‌کند. پس از ارسال مجدد توسط helios، میزبان jssmag.209 این تراکنش را خاتمه می‌دهد. در نهایت، jssmag.209 درخواست تراکنش بعدی را ارسال می‌کند. علامت `*' در درخواست نشان می‌دهد که بیت XO (دقیقاً یک‌بار - exactly once) تنظیم نشده است.

قطعه‌بندی IP (IP Fragmentation)

دیتاگرام‌های قطعه‌بندی‌شدهٔ اینترنت به صورت زیر نمایش داده می‌شوند:

(frag id:size@offset+)
(frag id:size@offset)
(حالت اول نشان می‌دهد که قطعات بیشتری وجود دارد؛ حالت دوم نشان می‌دهد که این آخرین قطعه است).

فیلد id شناسهٔ قطعه است. size اندازهٔ قطعه (بر حسب بایت) بدون احتساب هدر IP است. offset آفست این قطعه (بر حسب بایت) در دیتاگرام اصلی است.

اطلاعات مربوط به هر قطعه چاپ می‌شود. قطعهٔ نخست شامل هدرهای پروتکل سطح بالاتر است، بنابراین پس از اطلاعات پروتکل، اطلاعات قطعه چاپ می‌شود. قطعات پس از قطعهٔ نخست فاقد هدرهای پروتکل‌های سطح بالا هستند، بنابراین پس از آدرس‌های مبدأ و مقصد تنها اطلاعات قطعه نمایش داده می‌شود. برای نمونه، در ادامه بخشی از یک انتقال ftp از arizona.edu به lbl-rtsg.arpa آورده شده است که به نظر می‌رسد CSNET در مسیر قادر به مدیریت دیتاگرام‌های ۵۷۶ بایتی نبوده است:

arizona.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
در اینجا چند نکته قابل توجه است: نخست اینکه آدرس‌های سطر دوم فاقد شماره پورت هستند؛ زیرا اطلاعات پروتکل TCP به‌طور کامل درون قطعهٔ نخست قرار داشته و بنابراین هنگام نمایش قطعات بعدی، پورت‌ها یا شماره توالی‌ها ناشناخته هستند. دوم اینکه به نظر می‌رسد بخش شماره توالی tcp در سطر نخست دارای ۳۰۸ بایت دادهٔ کاربری است، در حالی که در واقع ۵۱۲ بایت است (۳۰۸ بایت در قطعهٔ نخست و ۲۰۴ بایت در قطعهٔ دوم). اگر به دنبال حفره‌هایی در شماره توالی‌ها باشید یا سعی در تطبیق تأییدیه‌ها (ack) با بسته‌ها داشته باشید، ممکن است به اشتباه بیفتید.

اگر بسته دارای پرچم IP قطعه‌بندی نشود (Don't Fragment) باشد، عبارت (DF) در انتهای سطر چاپ می‌شود.

برچسب‌های زمانی (Timestamps)

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

hh:mm:ss.frac
دقت آن برابر با ساعت هسته است. برچسب زمانی نشان‌دهندهٔ زمانی است که هسته بسته را دریافت کرده است. تأخیر بین زمانی که رابط اترنت بسته را دریافت می‌کند تا زمانی که هسته به وقفهٔ «بسته آماده است» پاسخ می‌دهد، در نظر گرفته نمی‌شود.

traffic(1C), nit(4P), bpf(4), pcap(3)

Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.

نسخهٔ فعلی را می‌توان از طریق ftp ناشناس دریافت کرد:

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

لطفاً گزارش اشکالات را به آدرس tcpdump@ee.lbl.gov ارسال کنید.

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

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

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

بسته‌های Apple Ethertalk DDP باید به همان آسانی بسته‌های KIP DDP چاپ شوند، اما در واقع چنین نیست. حتی اگر می‌خواستیم کاری برای ترویج Ethertalk انجام دهیم (که قصدی نداریم)، LBL اجازهٔ حضور Ethertalk را روی هیچ‌یک از شبکه‌های خود نمی‌دهد، بنابراین راهی برای آزمایش این کدها نداریم.

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

عبارات فیلتر مربوط به هدرهای FDDI فرض می‌کنند که تمامی بسته‌های FDDI درون بسته‌های اترنت کپسوله‌سازی شده‌اند. این موضوع بدون شک برای IP، ARP و DECNET Phase IV درست است، اما برای برخی پروتکل‌ها مانند ISO CLNS صادق نیست؛ بنابراین فیلتر ممکن است به‌طور ناخواسته بسته‌هایی را بپذیرد که در واقعیت با عبارت فیلتر مطابقت ندارند.

30 June 1997