名稱
tcpdump - 轉儲網絡上的流量
概要
tcpdump [ -adeflnNOpqRStuvxX ] [ -c 計數 ]
[ -C file_size ] [ -F 文件 ]
[ -i 界面 ] [ -m 模塊 ] [ -r 文件 ]
[ -s snaplen ] [ -T 類型 ] [ -U 用戶 ] [ -w 文件 ]
[ -E algo：秘密 ] [ 表達 ]
描述
Tcpdump在網絡接口上打印出與布爾表達式匹配的數據包標題。 它也可以用-w標誌運行，這會導致它將分組數據保存到一個文件中供以後分析，和/或使用-r標誌，這會導致它從保存的分組文件中讀取數據，而不是讀取數據包來自網絡界面。 在所有情況下，只有匹配表達式的數據包才會被tcpdump處理。
如果不用-c標誌運行， Tcpdump將繼續捕獲數據包，直到它被一個SIGINT信號中斷（例如，通過鍵入中斷字符，通常為control-C）或SIGTERM信號（通常由kill （1）命令）; 如果使用-c標誌運行，它將捕獲數據包，直到它被SIGINT或SIGTERM信號中斷或指定數量的數據包已被處理。
當tcpdump完成捕獲數據包時，它會報告計數：
數據包由過濾器接收'（其含義取決於運行tcpdump的操作系統，並且可能在操作系統配置的方式上 - 如果在命令行中指定了過濾器，則在某些操作系統上它會進行計數而不管它們是否與過濾器表達式匹配，並且在其他操作系統上，它只計算由過濾器表達式匹配並由tcpdump處理的數據包;
數據包“由內核丟棄”（這是由於缺少緩衝區空間而被丟棄的數據包數量，如果操作系統將該信息報告給應用程序，那麼運行tcpdump的操作系統中的數據包捕獲機制;如果不是，則報告為0）。
在支持SIGINFO信號的平台上，比如大多數BSD，它會在接收到一個SIGINFO信號（例如，通過輸入你的“狀態”字符，通常是control-T生成）來報告這些計數，並且將繼續捕獲數據包。
從網絡接口讀取數據包可能需要您具有特殊權限：
在帶有NIT或BPF的SunOS 3.x或4.x下：
您必須具有對/ dev / nit或/ dev / bpf *的讀取權限。
在帶有DLPI的Solaris下：
您必須具有對網絡偽設備的讀/寫訪問權限，例如/ dev / le 。 但是，至少在某些版本的Solaris上，這不足以允許tcpdump以混雜模式捕獲; 在這些版本的Solaris上，您必須是root用戶，或者tcpdump必須安裝setuid到root用戶才能以混雜模式進行捕獲。 請注意，在許多（也許是全部）接口上，如果不以混雜模式捕獲，則不會看到任何傳出數據包，因此捕獲未在混雜模式下完成可能不是很有用。
在具有DLPI的HP-UX下：
您必須是root或tcpdump，必須將setuid安裝到root用戶。
在IRIX下用snoop：
您必須是root或tcpdump，必須將setuid安裝到root用戶。
在Linux下：
您必須是root或tcpdump，必須將setuid安裝到root用戶。
在Ultrix和Digital UNIX / Tru64 UNIX下：
任何用戶都可以使用tcpdump捕獲網絡流量。 但是，除非超級用戶使用pfconfig （8）在該接口上啟用了混雜模式操作，否則用戶（甚至超級用戶）都不能在混合模式下捕獲界面，並且沒有用戶（甚至不是超級用戶）可以捕獲接口上接收或由接口發送的單播流量，除非超級用戶使用pfconfig在該接口上啟用了全部複製模式操作，因此接口上的有用數據包捕獲可能需要混合模式或複制 - 所有模式操作或兩種操作模式都可在該界面上啟用。
根據BSD：
您必須具有對/ dev / bpf *的讀取權限。
讀取保存的數據包文件不需要特殊權限。
OPTIONS
-一個
嘗試將網絡和廣播地址轉換為名稱。
-C
收到計數包後退出。
-C
在將原始數據包寫入保存文件之前，請檢查該文件當前是否大於file_size ，如果是，請關閉當前保存文件並打開一個新文件。 第一個保存文件後的保存文件將具有用-w標誌指定的名稱，後面跟著一個數字，從2開始並繼續向上。 file_size的單位是數百萬字節（1,000,000字節，而不是1,048,576字節）。
-d
將已編譯的數據包匹配代碼以人類可讀形式轉儲到標準輸出並停止。
-dd
將數據包匹配代碼轉儲為C程序片段。
滴滴滴
將數據包匹配代碼轉儲為十進制數（以count開頭）。
-e
在每個轉儲線上打印鏈接級別標題。
-E
使用algo：secret來解密IPsec ESP數據包。 算法可能是des-cbc ， 3des-cbc ， blowfish-cbc ， rc3-cbc ， cast128-cbc或none 。 缺省值是des-cbc 。 只有在啟用加密的情況下編譯tcpdump時才能解密數據包。 秘密 ESP密鑰的ascii文本。 我們現在不能採取任意的二進制值。 該選項假定RFC2406 ESP，而不是RFC1827 ESP。 該選項僅用於調試目的，並且不鼓勵使用具有真正“秘密”密鑰的此選項。 通過在命令行上顯示IPsec密鑰，您可以通過ps （1）和其他場合讓其他人看到它。
-F
以數字方式打印“外國”互聯網地址而不是像徵性地（這個選項是為了解決Sun的yp服務器中嚴重的腦損傷---通常它會永久性地翻譯非本地互聯網號碼）。
-F
使用文件作為過濾器表達式的輸入。 在命令行上給出的附加表達式將被忽略。
-一世
在界面上傾聽。 如果未指定，則tcpdump會在系統接口列表中搜索編號最小的已配置up接口（不包括環回）。 選擇最早的比賽會打破關係。
在具有2.2或更高版本內核的Linux系統上，可以使用接口參數“any”來捕獲所有接口的數據包。 請注意，“任何”設備上的捕捉不會在混雜模式下完成。
-l
使stdout行緩衝。 如果你想在捕捉數據的時候看到數據，這很有用。 例如，
``tcpdump -l | tee dat“或”tcpdump -l> dat＆tail -f dat“。
-m
從文件模塊加載SMI MIB模塊定義。 該選項可以多次用於將多個MIB模塊加載到tcpdump中 。
-n
不要將主機地址轉換為名稱。 這可以用來避免DNS查找。
-NN
不要將協議和端口號等轉換為名稱。
-N
不要打印主機名的域名限定。 例如，如果你給這個標誌，那麼tcpdump將打印“nic”而不是“nic.ddn.mil”。
-O
不要運行分組匹配代碼優化器。 這只有在懷疑優化器中存在錯誤時才有用。
-p
不要將界面置於混雜模式。 請注意，出於某種其他原因，接口可能處於混雜模式; 因此，`-p'不能用作`ether host {local-hw-addr}或ether broadcast'的縮寫。
-q
快速（安靜？）輸出。 打印較少的協議信息，因此輸出行較短。
-R
假設ESP / AH數據包基於舊規範（RFC1825至RFC1829）。 如果指定， tcpdump將不打印重播預防字段。 由於ESP / AH規範中沒有協議版本字段，因此tcpdump無法推導出ESP / AH協議的版本。
-r
從文件讀取數據包（使用-w選項創建）。 如果文件是“ - ”，則使用標準輸入。
-S
打印絕對的，而不是相對的TCP序列號。
-s
Snarf從每個數據包中取出數據字節，而不是默認的68（使用SunOS的NIT，最小值實際上是96）。 對於IP，ICMP，TCP和UDP，68字節是足夠的，但可能會截斷來自名稱服務器和NFS數據包的協議信息（請參見下文）。 由於快照有限而截斷的數據包在輸出中用``[| proto ]''，其中proto是發生截斷的協議級別的名稱。 請注意，拍攝較大的快照既增加了處理數據包所需的時間，也有效地減少了數據包緩衝量。 這可能會導致數據包丟失。 您應該將snaplen限制為捕獲您感興趣的協議信息的最小數量。將snaplen設置為0表示使用所需長度捕獲整個數據包。
-T
由“ 表達式 ”選擇的強制數據包被解釋為指定的類型 。 目前已知的類型是cnfp （Cisco NetFlow協議）， rpc （遠程過程調用）， rtp （實時應用協議）， rtcp （實時應用控制協議）， snmp （簡單網絡管理協議）， vat （可視音頻工具）和wb （分佈式白板）。
-t
不要在每個轉儲線上打印時間戳。
-tt
在每個轉儲線上打印未格式化的時間戳。
-U
刪除root用戶權限並將用戶標識更改為用戶和組標識到主要用戶組。
注意！ 如果沒有其他指定，Red Hat Linux會自動將權限下降到用戶``pcap''。
-ttt
在每個轉儲線上打印當前行和前一行之間的增量（以微秒為單位）。
-tttt
在每個轉儲線上按日期打印默認格式的時間戳。
-u
打印未解碼的NFS句柄。
-v
（略多）詳細輸出。 例如，打印IP包中的生存時間，標識，總長度和選項。 還啟用其他數據包完整性檢查，例如驗證IP和ICMP頭校驗和。
-vv
更詳細的輸出。 例如，從NFS回複數據包打印附加字段，SMB數據包完全解碼。
-vvv
更詳細的輸出。 例如，telnet SB ... SE選項全部打印。 使用-X telnet選項也以十六進制打印。
-w
將原始數據包寫入文件而不是解析並打印出來。 他們以後可以用-r選項打印。 如果文件是“ - ”，則使用標準輸出。
-X
以十六進制打印每個數據包（減去其鏈接級別標題）。 整個數據包或snaplen字節中的較小者將被打印。 請注意，這是整個鏈路層數據包，因此對於填充的鏈接層（例如以太網），當高層數據包比所需填充數據短時，填充字節也將被打印。
-X
打印十六進制時，也要打印ascii。 因此，如果還設置了-x ，則數據包將以十六進制/ ASCII格式打印。 這對分析新協議非常方便。 即使未設置-x ，某些數據包的某些部分也可能以十六進制/ ASCII格式打印。
表達
選擇將轉儲哪些數據包。 如果沒有給出表達式 ，網絡上的所有數據包都將被轉儲。 否則，只有表達式為“真”的數據包才會被丟棄。
該表達式由一個或多個基元組成。 圖元通常由一個id （名字或數字）組成，前面有一個或多個限定符。 有三種不同的限定符：
類型
限定符說明id名稱或數字指的是什麼類型的東西。 可能的類型是主機 ， 網絡和端口 。 例如，“主機富”，“網絡128.3”，“端口20”。 如果沒有類型限定符，則假定為主機 。
DIR
限定符指定了和/或來自id的特定傳送方向。 可能的方向是src ， dst ， src或dst以及src和 dst 。 例如`src foo'，`dst net 128.3'，`src或dst port ftp-data'。 如果沒有dir限定符，則假定為src或dst 。 對於'空'鏈接層（即點對點協議，如滑）， 入站和出站限定符可用於指定所需的方向。
原
限定符將匹配限制為特定的協議。 可能的原型是： ether ， fddi ， tr ， ip ， ip6 ， arp ， rarp ， decnet ， tcp和udp 。 例如`ether src foo'，`arp net 128.3'，`tcp port 21'。 如果沒有proto限定符，則假定與該類型一致的所有協議。 例如`src foo'表示`（ip或者arp或者rarp）src foo'（除了後者不是合法語法），`net bar'表示`（ip或者arp或者rarp）net bar'和`端口53'意味著`（tcp或udp）端口53'。
[`fddi'實際上是`ether'的別名; 解析器將它們理解為“在指定網絡接口上使用的數據鏈路級別”。FDDI標頭包含類似以太網的源地址和目標地址，並且通常包含類似以太網的數據包類型，因此您可以過濾這些FDDI字段就像類似的以太網領域一樣。 FDDI頭還包含其他字段，但不能在過濾器表達式中明確指定它們。
同樣，`tr'是'ether'的別名; 上一段關於FDDI頭部的陳述也適用於令牌環頭部。]
除上述之外，還有一些特殊的`原始'關鍵字不符合模式： 網關 ， 廣播 ， 更少 ， 更大和算術表達式。 所有這些都在下面描述。
更複雜的過濾器表達式是通過使用單詞和 或者而不是將基元組合來構建的。 例如，`主機foo而不是端口ftp而不是端口ftp-data'。 為了保存輸入，可以省略相同的限定符列表。 例如，`tcp dst port ftp或ftp-data或domain'與'tcp dst port ftp或tcp dst port ftp-data或tcp dst port domain'完全相同。
允許的原語是：
dst主機 主機
如果數據包的IPv4 / v6目標字段是主機 （可能是地址或名稱），則為true。
src主機 主機
如果數據包的IPv4 / v6源字段是主機，則為true。
主機 主機
如果數據包的IPv4 / v6源或目標是主機，則為true。 任何上述主機表達式都可以使用關鍵字ip ， arp ， rarp或ip6作為前綴：
IP主機 主機相當於：
ether proto \ ip 和主機 主機如果主機是具有多個IP地址的名稱，則會檢查每個地址是否匹配。
以太網dst ehost
如果以太網目標地址是ehost，則為真。 Ehost可以是/ etc / ethers中的名稱或數字（參見ethers （3N）中的數字格式）。
醚src ehost
如果以太網源地址是ehost，則為真。
以太主機 ehost
如果以太網源或目標地址是ehost，則為真。
網關 主機
如果數據包使用主機作為網關，則為真。 即，以太網源或目標地址是主機，但IP源和IP目標都不是主機 。 主機必須是名稱，並且必須通過機器的主機名稱到IP地址解析機制（主機名稱文件，DNS，NIS等）以及機器的主機名稱到以太網地址解析機制（/ etc / ethers等）。 （等價的表達式是
以太主機 ehost 而不是主機 主機它可以與host / ehost的名稱或數字一起使用。）此語法在此時不支持啟用IPv6的配置。
dst淨 網
如果數據包的IPv4 / v6目標地址具有網絡的網絡號，則為true。 Net可以是/ etc / networks中的名稱或網絡號（詳情請參閱網絡（4） ）。
src 網絡
如果數據包的IPv4 / v6源地址具有網絡的網絡號，則為true。
淨 網
如果數據包的IPv4 / v6源地址或目標地址具有網絡的網絡號，則為true。
net net mask netmask
如果IP地址與特定網絡掩碼相匹配，則為真。 可能會被src或dst限定。 請注意，此語法對於IPv6 網絡無效。
淨 淨 / len
如果IPv4 / v6地址與netmask len位寬相匹配，則為真。 可能會被src或dst限定。
dst端口 端口
如果數據包為ip / tcp，ip / udp，ip6 / tcp或ip6 / udp，並且具有端口的目標端口值，則為真。 端口可以是/ etc / services中使用的數字或名稱（請參閱tcp （4P）和udp （4P））。 如果使用名稱，則檢查端口號和協議。 如果使用數字或模糊名稱，則僅檢查端口號（例如， dst端口513將打印tcp / login流量和udp / who流量，並且端口域將打印tcp / domain和udp / domain流量）。
src端口 端口
如果數據包具有端口的源端口值，則為真。
端口 端口
如果數據包的源端口或目標端口是端口，則為true。 任何上述端口表達式都可以用關鍵字tcp或udp作為前綴，如下所示：
tcp src端口 端口它僅匹配其源端口是端口的 tcp數據包。
更少的 長度
如果數據包的長度小於或等於長度，則為真。 這相當於：
len <= 長度 。更大的 長度
如果數據包的長度大於或等於長度，則為真。 這相當於：
len> = 長度 。ip 協議
如果數據包是協議類型協議的IP數據包（請參閱ip （4P）），則為真。 協議可以是數字或名稱icmp ， icmp6 ， igmp ， igrp ， pim ， ah ， esp ， vrrp ， udp或tcp中的一個 。 請注意，標識符tcp ， udp和icmp也是關鍵字，必須通過反斜杠（\）進行轉義，該反斜杠在\ C \ shell中是\\。 請注意，此原語不會追逐協議標題鏈。
ip6 協議
如果數據包是協議類型協議的IPv6數據包，則為真。 請注意，此原語不會追逐協議標題鏈。
ip6 protochain 協議
如果數據包是IPv6數據包，並且在其協議標題鏈中包含協議標頭和類型協議 ，則為真。 例如，
ip6前傳6匹配任何IPv6數據包與協議標題鏈中的TCP協議標頭。 該數據包可以包含例如IPv6報頭和TCP報頭之間的認證報頭，路由報頭或逐跳選項報頭。 該原語發出的BPF代碼很複雜，並且不能通過tcpdump中的BPF優化程序代碼進行優化，所以這可能有點慢。
ip protochain 協議
相當於ip6 protochain 協議 ，但是這是針對IPv4的。
以太播出
如果數據包是以太網廣播數據包，則為真。 ether關鍵字是可選的。
ip廣播
如果數據包是IP廣播數據包，則為真。 它檢查全零和全1廣播約定，並查找本地子網掩碼。
以太網組播
如果數據包是以太網多播數據包，則為真。 ether關鍵字是可選的。 這是` ether [0]＆1！= 0 '的簡寫。
ip組播
如果數據包是IP多播數據包，則為真。
ip6組播
如果數據包是IPv6多播數據包，則為真。
乙醚原始 協議
如果數據包是以太類型協議，則為真。 協議可以是ip ， ip6 ， arp ， rarp ， atalk ， aarp ， decnet ， sca ， lat ， mopdl ， moprc ， iso ， stp ， ipx或netbeui中的一個或多個名稱。 請注意，這些標識符也是關鍵字，必須通過反斜杠（\）進行轉義。
[在FDDI（例如` fddi協議arp '）和令牌環（例如` tr protocol arp '））的情況下，對於大多數這些協議，協議標識來自802.2邏輯鏈路控制（LLC）報頭，通常分層在FDDI或令牌環標頭之上。
當在FDDI或令牌環上過濾大多數協議標識符時， tcpdump僅以封裝的以太網的組織單元標識符（OUI）為0x000000，以所謂的SNAP格式檢查LLC頭的協議ID字段; 它不檢查數據包是否為OUI為0x000000的SNAP格式。
例外是iso ，為此它檢查LLC頭， stp和netbeui的DSAP（目的服務訪問點）和SSAP（源服務訪問點）字段，它在那裡檢查LLC頭的DSAP，以及atalk ，它在哪裡檢查OUI為0x080007和Appletalk etype的SNAP格式數據包。
在以太網的情況下， tcpdump檢查大多數這些協議的以太網類型字段; 例外的是iso ， sap和netbeui ，它檢查802.3幀，然後檢查LLC標題，就像它為FDDI和令牌環atalk一樣檢查LLC標題，在這裡它檢查以太網幀中的Appletalk etype和SNAP格式的數據包，就像它為FDDI和令牌環aarp所做的那樣，它在一個以太網幀或一個OUI為0x000000的802.2 SNAP幀中檢查Appletalk ARP etype，在ipx中檢查IPX etype一個以太網幀，LLC頭中的IPX DSAP，802.3，沒有IPX的LLC頭封裝，以及SNAP幀中的IPX etype。]
decnet src 主機
如果DECNET源地址是主機 （可能是“10.123”形式的地址）或DECNET主機名，則為真。 [DECNET主機名支持僅在配置為運行DECNET的Ultrix系統上可用。]
decnet dst 主機
如果DECNET目標地址是主機，則為真。
decnet主機 主機
如果DECNET源地址或目標地址是主機，則為真。
ip ， ip6 ， arp ， rarp ， atalk ， aarp ， decnet ， iso ， stp ， ipx ， netbeui
縮寫：
乙醚原蛋白其中p是上述協議之一。
lat ， moprc ， mopdl
縮寫：
乙醚原蛋白其中p是上述協議之一。 請注意， tcpdump目前不知道如何解析這些協議。
vlan [vlan_id]
如果數據包是IEEE 802.1Q VLAN數據包，則為真。 如果指定了[vlan_id] ，則只有該數據包具有指定的vlan_id 。 請注意， 表達式中遇到的第一個vlan關鍵字在假設數據包是VLAN數據包的情況下會更改表達式的其餘部分的解碼偏移量。
tcp ， udp ， icmp
縮寫：
ip proto p 或ip6 proto p其中p是上述協議之一。
iso 協議
如果數據包是協議類型協議的OSI數據包，則為真。 協議可以是數字或名稱clnp ， esis或isis中的一個 。
clnp ， esis ， isis
縮寫：
iso proto p其中p是上述協議之一。 請注意， tcpdump沒有完成解析這些協議的工作。
expr relop expr
如果關係成立，則rel為真，其中relop是>，<，> =，<=，=，！=中的一個，而expr是由整數常量組成的算術表達式（用標準C語法表示） ， - ，*，/，＆，|]，長度運算符和特殊數據包數據訪問器。 要訪問數據包內的數據，請使用以下語法：
原型 [ expr ： size ]Proto是ether，fddi，tr，ppp，slip，link，ip，arp，rarp，tcp，udp，icmp或ip6之一 ，並指示索引操作的協議層。 （ ether，fddi，tr，ppp，slip和link都是指鏈路層）注意， tcp，udp和其他上層協議類型僅適用於IPv4，而不適用於IPv6（這將在未來進行修復）。 相對於所指示的協議層的字節偏移由expr給出。 大小是可選的並且表示感興趣的字段中的字節數; 它可以是一個，兩個或四個，默認為一個。 長度運算符（用關鍵字len表示）給出了數據包的長度。
例如，` ether [0]＆1！= 0 '捕獲所有多點傳送流量。 表達式' ip [0]＆0xf！= 5 '捕獲所有帶有選項的IP數據包。 表達式' ip [6：2]＆0x1fff = 0 '僅捕獲片段化數據報的未分片數據報和碎片零。 此檢查隱式應用於tcp和udp索引操作。 例如， tcp [0]總是表示TCP 標頭的第一個字節，並不意味著介入片段的第一個字節。
一些偏移量和字段值可以表示為名稱而不是數值。 以下協議頭字段偏移量可用： icmptype （ICMP類型字段）， icmpcode （ICMP代碼字段）和tcpflags （TCP標誌字段）。
以下ICMP類型字段值可用： icmp-echoreply ， icmp-unreach ， icmp- sourcequench ， icmp-redirect ， icmp-echo ， icmp-routeradvert ， icmp-routersolicit ， icmp-timxceed ， icmp-paramprob ， icmp -tstamp ， icmp -tstampreply ， icmp-ireq ， icmp-ireqreply ， icmp-maskreq ， icmp-maskreply 。
以下TCP標誌字段值可用： tcp-fin ， tcp-syn ， tcp-rst ， tcp-push ， tcp-push ， tcp-ack ， tcp-urg 。
基元可以使用以下方式進行組合：
帶圓括號的原語和操作符組（圓括號對Shell來說是特殊的，必須轉義）。
否定（' ！ '或' not '）。
連接（` && '或` 和 '）。
交替（' || '或' or '）。
否定的優先級最高。 交替和級聯具有相同的優先級並從左到右相關聯。 請注意，串聯現在需要顯式和標記，而不是並置。
如果給定標識符沒有關鍵字，則假定最近的關鍵字。 例如，
不是主機vs和ace是簡短的
不是主機vs和主機王牌這不應與此混淆
不（主持人vs或王牌）表達式參數可以作為單個參數或多個參數傳遞給tcpdump ，無論哪種方式更為方便。 通常，如果表達式包含Shell元字符，則將其作為單引號引用傳遞會更容易。 在解析之前，多個參數與空格連接在一起。
例子
打印所有到達或離開日落的數據包：
tcpdump主機日落打印helios和hot或ace之間的流量：
tcpdump主機helios和\（hot或ace \）打印ace和除helios之外的任何主機之間的所有IP數據包：
tcpdump ip主機王牌而不是helios在伯克利打印本地主機和主機之間的所有流量：
tcpdump net ucb-ether要通過Internet網關snup打印所有ftp流量：（注意表達式被引用以防止shell從（錯誤）解釋括號）：
tcpdump'網關snup和（端口ftp或ftp-data）'要打印既不是來自本地主機也不是本地主機的流量（如果您通過其他網絡訪問，則這些內容不應該進入本地網絡）。
tcpdump ip而不是net netnet打印涉及非本地主機的每個TCP會話的開始和結束數據包（SYN和FIN數據包）。
tcpdump'tcp [tcpflags]＆（tcp-syn | tcp-fin）！= 0而不是src和dst net localnet '打印通過網關snup發送的長度超過576字節的IP數據包：
tcpdump'網關snup和ip [2：2]> 576'要打印未通過以太網廣播或多播發送的IP廣播或多播數據包：
tcpdump'ether [0]＆1 = 0和ip [16]> = 224'要打印所有不是回應請求/回复的ICMP數據包（即不是ping數據包）：
tcpdump'icmp [icmptype]！= icmp-echo和icmp [icmptype]！= icmp-echoreply'輸出格式
tcpdump的輸出是依賴於協議的。 以下給出了大多數格式的簡要說明和示例。
鏈接級別標題
如果給出'-e'選項，則會打印鏈接級別標題。 在以太網上，打印源和目標地址，協議和數據包長度。
在FDDI網絡上，'-e'選項使tcpdump打印'幀控制'字段，源地址和目標地址以及數據包長度。 （'frame control'字段控制對數據包其餘部分的解釋，普通數據包（例如包含IP數據報的數據包）是'異步'數據包，優先級值在0到7之間;例如` async4 '。假設數據包包含802.2邏輯鏈路控制（LLC）數據包;如果LLC數據包不是 ISO數據報或所謂的SNAP數據包，則會打印LLC標頭。
在令牌環網絡上，'-e'選項會使tcpdump打印'訪問控制'和'幀控制'字段，源地址和目標地址以及數據包長度。 與在FDDI網絡上一樣，數據包被假定為包含LLC數據包。 無論是否指定'-e'選項，都會為源路由數據包打印源路由信息。
（注意：以下描述假定熟悉RFC-1144中描述的SLIP壓縮算法。）
在SLIP鏈接上，打印出方向指示符（“入站”I，出站“O”），數據包類型和壓縮信息。 數據包類型首先被打印。 這三種類型是ip ， utcp和ctcp 。 沒有進一步的鏈接信息打印ip數據包。 對於TCP數據包，連接標識符將按照類型打印。 如果數據包是壓縮的，它的編碼頭將被打印出來。 特殊情況打印為* S + n和* SA + n ，其中n是序列號（或序列號和ack）發生變化的量。 如果不是特殊情況，則打印零個或多個更改。 U（緊急指針），W（窗口），A（ack），S（序列號）和I（數據包ID）指示更改，後跟delta（+ n或-n）或新值（= N）。 最後，打印數據包中的數據量和壓縮的標題長度。
例如，下面的行顯示了一個帶有隱式連接標識符的出站壓縮TCP數據包; ack改變了6，序列號改變了49，並且數據包ID減少了6; 有3個字節的數據和6個字節的壓縮報頭：
O ctcp * A + 6 S + 49 I + 6 3（6）ARP / RARP包
Arp / rarp輸出顯示請求的類型及其參數。 格式旨在自我解釋。 以下是從主機rtsg到主機csam的“rlogin”開頭的一個簡短示例：
arp who-csam告訴rtsg arp回复csam是 - 在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 ，第一個數據包被廣播，第二個數據包點對點的事實將是可見的：
RTSG Broadcast 0806 64：arp who-has csam tell rtsg CSAM RTSG 0806 64：arp reply csam is-at CSAM對於第一個數據包來說，以太網源地址是RTSG，目的地是以太網廣播地址，類型字段包含十六進制0806（類型ETHER_ARP），總長度為64字節。
TCP數據包
（注意：下面的描述假定你熟悉RFC-793中描述的TCP協議，如果你不熟悉協議，那麼這個描述和tcpdump都不會對你有太大用處。）
一個tcp協議的一般格式是：
src> dst：flags data-seqno ack窗口緊急選項 Src和dst是源和目標IP地址和端口。 標誌是S（SYN），F（FIN），P（PUSH）或R（RST）或單個'。'的組合。 （沒有標誌）。 Data-seqno描述了數據包中數據覆蓋的部分序列空間（參見下面的示例）。 Ack是此連接上預期的另一個方向的下一個數據的序列號。 窗口是在此連接上可用的接收緩衝區空間的另一個方向的字節數。 Urg表示數據包中有'緊急'數據。 選項是用尖括號括起來的tcp選項（例如，
Src，dst和標誌總是存在。 其他字段取決於數據包的TCP協議頭的內容，只有在適當的情況下才會輸出。
這是從主機rtsg到主機csam的rlogin的開頭部分。
rtsg.1023> csam.login：S 768512：768512（0）win 4096第一行表示rtsg上的tcp端口1023向csam上的端口登錄發送了一個數據包。 S表示已設置SYN標誌。 數據包序列號是768512，它不包含數據。 （符號是'first：last（nbytes）'，意思是“序列號先到達，但不包括最後一個是用戶數據的nbytes字節”）。沒有捎帶的ack，可用的接收窗口是4096字節，有一個最大段大小的選項請求1024字節的mss。
Csam會回復一個類似的數據包，但它包含rtsg的SYN的背馱式確認。 Rtsg然後贊成csam的SYN。 '。' 意味著沒有設置標誌。 數據包不包含數據，因此沒有數據序列號。 請注意，確認序列號是一個小整數（1）。 tcpdump第一次看到一個tcp“對話”時，它會打印來自數據包的序列號。 在會話的後續數據包中，將打印當前數據包的序列號與此初始序列號之間的差異。 這意味著第一個之後的序列號可以被解釋為對話數據流中的相對字節位置（每個方向的第一個數據字節為'1'）。 `-S'將覆蓋此功能，導致輸出原始序列號。
在第6行，rtsg發送csam 19個字節的數據（在對話的rtsg - > csam側的字節2到20）。 PUSH標誌在數據包中設置。 在第7行，csam表示它收到了由rtsg發送的數據，但不包括字節21.大部分數據顯然都位於套接字緩衝區中，因為csam的接收窗口已經減少了19個字節。 Csam還在這個數據包中發送一個字節的數據給rtsg。 在第8行和第9行，csam發送兩個字節的緊急數據到rtsg。
如果快照足夠小以至於tcpdump沒有捕獲完整的TCP報頭，它會盡可能多地解釋報頭，然後報告“[| tcp ]''來表示余數不能被解釋。 如果頭部包含一個虛假選項（一個長度太小或超出頭部末尾）， tcpdump會將其報告為“[ bad opt ]”，並不會解釋任何其他選項（因為無法分辨他們在哪裡開始）。 如果標題長度指示存在選項，但IP數據報長度不足以使選項實際存在，則tcpdump將其報告為“[ bad hdr length ]”。
捕獲具有特定標誌組合的TCP數據包（SYN-ACK，URG-ACK等）
TCP報頭的控制位部分有8位：
CWR | ECE | URG | ACK | PSH | RST | SYN | 鰭
假設我們想要觀察用於建立TCP連接的數據包。 回想一下，TCP在初始化一個新的連接時使用3次握手協議; 關於TCP控制位的連接順序是
1）呼叫者發送SYN
2）收件人用SYN，ACK進行響應
3）主叫方發送ACK
現在我們對捕獲僅包含SYN位的數據包感興趣（步驟1）。 請注意，我們不希望步驟2（SYN-ACK）的數據包，只是一個普通的初始SYN。 我們需要的是tcpdump的正確過濾表達式。
回想一下沒有選項的TCP頭的結構：
0 15 31 ----------------------------------------------- ------------------ | 源端口| 目標端口| -------------------------------------------------- --------------- | 序號| -------------------------------------------------- --------------- | 確認號碼 -------------------------------------------------- --------------- | HL | rsvd | C | E | U | A | P | R | S | F | 窗口大小| -------------------------------------------------- --------------- | TCP校驗和| 緊急指針| -------------------------------------------------- ---------------除非有選項，否則TCP頭通常會保存20個八位字節的數據。 圖的第一行包含八位字節0 - 3，第二行顯示八位字節4 - 7等。
從0開始計數，相關的TCP控制位包含在八位組13中：
0 7 | 15 | 23 | 31 ---------------- | --------------- | --------------- | ---------------- | HL | rsvd | C | E | U | A | P | R | S | F | 窗口大小| ---------------- | --------------- | --------------- | - --------------- | | 第13個八位字節| | |讓我們仔細看看八位字節號。 13：
| | | --------------- | | C | E | U |甲| P | R | S | F | | --------------- | | 7 5 3 0 |這些是我們感興趣的TCP控制位。我們對這個八位位組中的位從0到7，從右到左編號，所以PSH位是位編號3，而URG位是編號5。
回想一下，我們想要捕獲只有SYN集的數據包。 讓我們來看看如果一個TCP數據報到達並且在其頭部設置了SYN位，會發生什麼情況？
| C | E | U |甲| P | R | S | F | | --------------- | | 0 0 0 0 0 0 1 0 | | --------------- | | 7 6 5 4 3 2 1 0 |看看控制位部分，我們看到只有位1（SYN）被設置。
假定八位字節編號13是網絡字節順序中的8位無符號整數，則該八位字節的二進制值是
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頭中的第13個八位字節的值在網絡字節順序中解釋為8位無符號整數時，必須恰好為2。
這種關係可以表示為
tcp [13] == 2
我們可以使用這個表達式作為tcpdump的過濾器，以便觀察只有SYN集合的數據包：
tcpdump -i xl0 tcp [13] == 2
表達式表示“讓TCP數據報的第13個八位字節具有十進制值2”，這正是我們想要的。
現在，我們假設我們需要捕獲SYN數據包，但我們並不在乎ACK或任何其他TCP控制位是否同時被設置。 讓我們來看看帶有SYN-ACK集合的TCP數據報到達時發生的八位組13：
| C | E | U |甲| P | R | S | F | | --------------- | | 0 0 0 1 0 0 1 0 | | --------------- | | 7 6 5 4 3 2 1 0 |現在比特1和4被設置在第13個八位字節中。 八位字節13的二進制值是
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現在我們不能僅僅在tcpdump過濾器表達式中使用'tcp [13] == 18'，因為那樣只會選擇那些設置了SYN-ACK的數據包，而不是那些只有SYN設置的數據包。 請記住，只要設置了SYN，我們就不在乎是否設置了ACK或任何其他控制位。
為了實現我們的目標，我們需要將八位組13的二進制值與其他值進行邏輯與，以保留SYN位。 我們知道我們希望在任何情況下都設置SYN，所以我們將第13個字節中的值與SYN的二進制值進行邏輯與：
00010010 SYN-ACK 00000010 SYN和00000010（我們需要SYN）和00000010（我們需要SYN）-------- -------- = 00000010 = 00000010我們看到，無論是否設置了ACK或另一個TCP控制位，此AND操作都會提供相同的結果。 AND值的十進製表示以及此操作的結果是2（二進制00000010），所以我們知道對於設置了SYN的數據包，以下關係必須為真：
（（八位字節13的值）AND（2））==（2）
這將我們引向tcpdump過濾器表達式
tcpdump -i xl0'tcp [13]＆2 == 2'
請注意，您應該在表達式中使用單引號或反斜杠來從shell中隱藏AND（'＆'）特殊字符。
UDP數據包
UDP格式由這個rwho數據包說明：
actinide.who> broadcast.who：udp 84這就是說，主機上的港口發送了一個udp數據報給主機廣播端口上的互聯網廣播地址。 數據包包含84個字節的用戶數據。
一些UDP服務被識別（來自源或目標端口號）和打印更高級別的協議信息。 特別是，NFS的域名服務請求（RFC-1034/1035）和Sun RPC調用（RFC-1050）。
UDP名稱服務器請求
（注意：以下描述假定您熟悉RFC-1035中描述的域服務協議，如果您不熟悉該協議，下面的描述將顯示為希臘語。）
名稱服務器請求格式為
src> dst：id op？ flags qtype qclass name（len） h2opolo.1538> helios.domain：3+ A？ ucbvax.berkeley.edu。 （37）主機h2opolo向helios的域名服務器詢問與名稱ucbvax.berkeley.edu相關的地址記錄（qtype = A） 。 查詢ID是'3'。 '+'表示已設置遞歸期望標誌。 查詢長度為37個字節，不包括UDP和IP協議頭。 查詢操作是正常的查詢操作，因此操作字段被省略。 如果該操作是其他任何操作，則會在“3”和“+”之間打印。 類似地，qclass是正常的， C_IN ，並且被省略。 任何其他qclass將在“A”後立即打印。
檢查了一些異常，並可能導致在方括號中包含額外的字段：如果查詢包含答案，授權記錄或附加記錄部分， 則將ancount ， nscount或arcount打印為`[ n a]'，`[ n n ]'或`[ n au]'，其中n是適當的數量。 如果設置了任何響應位（AA，RA或rcode）或任何'必須為零'位以字節2和3設置，則打印`[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的查詢id 3， 其中有3個答案記錄，3個名稱服務器記錄和7個附加記錄。 第一個答案記錄是A型（地址），其數據是互聯網地址128.32.137.3。 響應的總大小為273字節，不包括UDP和IP標頭。 op（查詢）和響應代碼（NoError）被忽略，A記錄的類（C_IN）也被忽略。
在第二個例子中， helios以不存在答案的不存在域（NXDomain）的響應代碼，一個名稱服務器和無權限記錄對查詢2作出響應。 “*”表示權威答案位已設置。 由於沒有答案，沒有打印任何類型，類別或數據。
可能出現的其他標誌字符是“ - ”（遞歸可用，RA， 未設置）和“|” （截斷消息，TC，集合）。 如果“問題”部分不包含一個條目，則會打印“[ n q]”。
請注意，名稱服務器請求和響應通常很大，並且68字節的缺省snaplen可能無法捕獲足夠的數據包進行打印。 如果您需要認真調查名稱服務器流量，請使用-s標誌來增加snaplen。 ` -s 128 '對我來說效果很好。
SMB / CIFS解碼
tcpdump現在包含針對UDP / 137，UDP / 138和TCP / 139上的數據的相當廣泛的SMB / CIFS / NBT解碼。 IPX和NetBEUI SMB數據的一些原始解碼也已完成。
默認情況下，完成一個相當小的解碼，如果使用-v，則執行更詳細的解碼。 要注意的是，使用-va單個SMB數據包可能佔用一頁或更多頁面，所以只有使用-v時，如果你真的想要所有的細節。
如果您正在解碼包含unicode字符串的SMB會話，那麼您可能希望將環境變量USE_UNICODE設置為1.自動檢測unicode srings的補丁將受到歡迎。
有關SMB數據包格式的信息以及所有te字段的含義，請參閱www.cifs.org或您最喜愛的samba.org鏡像站點上的pub / samba / specs /目錄。 SMB補丁由Andrew Tridgell（tridge@samba.org）撰寫。
NFS請求和回复
Sun NFS（網絡文件系統）請求和答复打印為：
src.xid> dst.nfs：len op args src.nfs> dst.xid：回复stat len操作結果 sushi.6709> wrl.nfs：112 readlink fh 21,24 / 10.73165 wrl.nfs> sushi.6709：回復正常40 readlink“../var”sushi.201b> wrl.nfs：144查找fh 9,74 / 4096.6878“xcolors”wrl.nfs> sushi.201b：回复ok 128查找fh 9,74 / 4134.3150在第一行中，主持人sushi發送一個id為6709的事務給wrl （請注意，src主機後面的數字是一個事務id， 而不是源端口）。 該請求是112個字節，不包括UDP和IP標頭。 該操作是文件句柄（ fh ）21,24 / 10.731657119上的readlink （讀取符號鏈接）。 （如果幸運的話，就像在這種情況下一樣，文件句柄可以被解釋為主要次要設備號碼對，後面跟著inode號碼和世代號。） Wrl用鏈接的內容回答'ok'。
在第三行中， 壽司要求在目錄文件9,74 / 4096.6878中查找名稱“ xcolors ”。 請注意，打印的數據取決於操作類型。 如果與NFS協議規範一起閱讀，該格式旨在自我解釋。
如果給出-v（詳細）標誌，則會打印附加信息。 例如：
sushi.1372a> wrl.nfs：148讀取fh 21,11 / 12.195 8192字節@ 24576 wrl.nfs> sushi.1372a：回复ok 1472讀取REG 100664 id 417/0 sz 29388（-v還打印IP頭TTL，ID，長度和分段字段，在本例中省略了這些字段）。在第一行中， 壽司要求wrl從字節偏移量21,11 / 12.195中讀取8192個字節24515.Wrl回复'ok'; 第二行顯示的數據包是答复的第一個片段，因此只有1472字節長（其他字節將在隨後的片段中出現，但這些片段沒有NFS甚至UDP頭，因此可能不會打印，取決於所使用的過濾器表達式）。 因為-v標誌被給出，所以會打印一些文件屬性（除了文件數據外還有其他文件屬性）：文件類型（“REG”，常規文件），文件模式（八進制）， uid和gid以及文件大小。
如果給出-v標誌不止一次，則會打印更多詳細信息。
請注意，NFS請求非常大，除非增加snaplen，否則不會打印大部分細節。 嘗試使用` -s 192 '來觀察NFS流量。
NFS回複數據包不明確識別RPC操作。 相反， tcpdump會跟踪“最近”的請求，並將它們與使用事務ID的回復相匹配。 如果回复沒有嚴格遵循相應的請求，則可能無法解析。
AFS請求和答复
Transarc AFS（Andrew文件系統）請求和答复打印為：
src.sport> dst.dport：rx數據包類型 src.sport> dst.dport：rx數據包類型服務調用call-name args src.sport> dst.dport：rx數據包類型服務回复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數據包給派克。 這是一個到fs（fileserver）服務的RX數據包，並且是RPC調用的開始。 RPC調用是重命名，舊的目錄文件ID為536876964/1/1，舊的文件名為.newsrc.new，新的目錄文件ID為536876964/1/1，文件名為。 newsrc“。 主機pike響應重命名調用的RPC回复（這是成功的，因為它是一個數據包而不是中止包）。
一般來說，所有的AFS RPC至少被RPC調用名稱解碼。 大多數AFS RPC至少有一些解碼的參數（通常只有“有趣的”參數，對於一些有趣的定義）。
該格式旨在自我描述，但對於不熟悉AFS和RX的工作的人可能沒有用處。
如果-v（詳細）標誌被賦予兩次，則會打印確認包和附加標頭信息，例如RX呼叫ID，呼叫號碼，序列號，序列號和RX包標誌。
如果給出-v標誌兩次，則會打印附加信息，例如RX呼叫ID，序列號和RX包標誌。 MTU協商信息也從RX ack數據包打印。
如果-v標誌被給出三次，則打印安全索引和服務標識。
錯誤代碼被打印用於中止數據包，但Ubik信標數據包除外（因為中止數據包用於表示對Ubik協議是肯定的投票）。
請注意，AFS請求非常大，除非增加snaplen，否則許多參數不會被打印。 嘗試使用` -s 256 '來觀看AFS流量。
AFS應答數據包不明確識別RPC操作。 相反， tcpdump會跟踪“最近”的請求，並將它們與使用電話號碼和服務ID的回復進行匹配。 如果回复沒有嚴格遵循相應的請求，則可能無法解析。
KIP Appletalk（UDP中的DDP）
封裝在UDP數據報中的Appletalk DDP數據包被解封裝並作為DDP數據包轉儲（即所有的UDP頭信息都被丟棄）。 文件/etc/atalk.names用於將appletalk網絡和節點號碼轉換為名稱。 此文件中的行具有表單
編號名稱 1.254乙醚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不存在或不包含某個appletalk主機/網絡號的條目，則地址以數字形式打印。）在第一個示例中，網絡上的NBP（DDP端口2）144.1節點209正在向正在監聽網絡icsd節點112的端口220上的任何節點發送。除了已知源節點的全名（“辦公室”）之外，第二行是相同的。 第三行是從網絡jssmag節點149上的端口235發送到icsd-net NBP端口上廣播（請注意，廣播地址（255）由沒有主機號碼的網絡名稱指示 - 因此，這是一個好主意保持/etc/atalk.names中的節點名稱和網絡名稱不同）。
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第一行是由net icsd主機112發送並在net jssmag上廣播的激光寫入器的名稱查找請求。 第二行顯示來自主機jssmag.209的對該請求的回复（注意它具有相同的ID），表示它具有在端口250上註冊的名為“RM1140”的激光打字機資源。第三行line是對同一請求的另一個回复，稱主機techpit有在186端口上註冊的laserwriter“techpit”。
以下示例演示了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- （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> 0xae030002Jssmag.209通過請求多達8個數據包（`<0-7>'）來啟動與主機helios的事務ID 12266。 行尾的十六進制數字是請求中`userdata'字段的值。
Helios響應8個512字節的數據包。 事務id後面的`：digit'給出了事務中的包序號，parens中的數字是包中的數據量，不包括atp頭。 數據包7上的'*'表示EOM位已設置。
然後Jssmag.209請求重傳包3和5。 Helios重新發送它們，然後jssmag.209釋放事務。 最後，jssmag.209發起下一個請求。 請求中的'*'表示XO（'只有一次'） 沒有設置。
IP碎片
碎片化的Internet數據報打印為
（frag id ： size @ offset +） （frag id ： size @ offset ）（第一種形式表示有更多的片段，第二種表示這是最後一個片段。）
Id是片段ID。 大小是除IP標頭外的片段大小（以字節為單位）。 偏移量是原始數據報中該片段的偏移量（以字節為單位）。
片段信息為每個片段輸出。 第一個片段包含更高級別的協議頭，並且在協議信息之後打印片段信息。 第一個片段之後的片段不包含更高級別的協議頭，並且在源地址和目標地址之後打印片段信息。 例如，下面是一個從arizona.edu到lbl-rtsg.arpa的ftp的一部分，它通過CSNET連接看起來並不處理576字節的數據報：
arizona.ftp-data> rtsg.1170：。 1024：1332（308）ack 1 win 4096（frag 595a：328 @ 0 +）亞利桑那州> rtsg：（frag 595a：204 @ 328）rtsg.1170> arizona.ftp-data：。 1536勝2560在這裡需要注意幾點：首先，第二行的地址不包含端口號。 這是因為TCP協議信息都在第一個片段中，我們不知道打印後面的片段時端口或序列號是什麼。 其次，打印第一行的tcp序列信息時，如果有308字節的用戶數據，實際上有512個字節（第一個碎片中的308個，第二個中的204個）打印出來。 如果您正在尋找序列空間中的空洞或嘗試將數據包與數據包進行匹配，這可能會欺騙您。
具有IP 不分段標誌的數據包標有尾隨（DF） 。
時間戳
默認情況下，所有輸出行前面都有一個時間戳。 時間戳是表單中的當前時鐘時間
HH：MM：ss.frac並且與內核的時鐘一樣精確。 時間戳反映內核第一次看到數據包的時間。 沒有嘗試去考慮以太網接口從數據包中刪除數據包與內核服務於“新數據包”中斷之間的時間差。
也可以看看
流量（1C），nit（4P），bpf（4），pcap（3）
重要提示：使用man命令（ ％man ）查看特定計算機上的命令使用方式。