簡介

用簡單的話來定義tcpdump，就是：dump the traffic on a network，根據使用者的定義對網路上的資料包進行截獲的包分析工具。 tcpdump可以將網路中傳送的資料包的“頭”完全截獲下來提供分析。它支援針對網路層、協議、主機、網路或埠的過濾，並提供and、or、not等邏輯語句來幫助你去掉無用的資訊。

實用命令例項

預設啟動

普通情況下，直接啟動tcpdump將監視第一個網路介面上所有流過的資料包。

監視指定網路介面的資料包

如果不指定網路卡，預設tcpdump只會監視第一個網路介面，一般是eth0，下面的例子都沒有指定網路介面。

監視指定主機的資料包

列印所有進入或離開sundown的資料包.

也可以指定ip，例如截獲所有210.27.48.1 的主機收到的和發出的所有的資料包

列印helios 與 hot 或者與 ace 之間通訊的資料包

截獲主機210.27.48.1 和主機210.27.48.2 或210.27.48.3的通訊

列印ace與任何其他主機之間通訊的IP 資料包， 但不包括與helios之間的資料包.

如果想要獲取主機210.27.48.1除了和主機210.27.48.2之外所有主機通訊的ip包，使用命令：

截獲主機hostname傳送的所有資料

監視所有送到主機hostname的資料包

監視指定主機和埠的資料包

如果想要獲取主機210.27.48.1接收或發出的telnet包，使用如下命令

對本機的udp 123 埠進行監視 123 為ntp的服務埠

監視指定網路的資料包

列印本地主機與Berkeley網路上的主機之間的所有通訊資料包(nt: ucb-ether， 此處可理解為’Berkeley網路’的網路地址，此表示式最原始的含義可表達為: 列印網路地址為ucb-ether的所有資料包)

列印所有通過閘道器snup的ftp資料包(注意， 表示式被單引號括起來了， 這可以防止shell對其中的括號進行錯誤解析)

列印所有源地址或目標地址是本地主機的IP資料包

(如果本地網路通過閘道器連到了另一網路， 則另一網路並不能算作本地網路.(nt: 此句翻譯曲折，需補充).localnet 實際使用時要真正替換成本地網路的名字)

監視指定協議的資料包

列印TCP會話中的的開始和結束資料包， 並且資料包的源或目的不是本地網路上的主機.(nt: localnet， 實際使用時要真正替換成本地網路的名字))

列印所有源或目的埠是80， 網路層協議為IPv4， 並且含有資料，而不是SYN，FIN以及ACK-only等不含資料的資料包.(ipv6的版本的表示式可做練習)

(nt: 可理解為， ip[2:2]表示整個ip資料包的長度， (ip[0]&0xf)

成位元組數需要乘以4，　即左移2.　(tcp[12]&0xf0)>>4 表示tcp頭的長度， 此域的單位也是32bit，　換算成位元數為 ((tcp[12]&0xf0) >> 4)　即 ((tcp[12]&0xf0)>>2).　((ip[2:2] – ((ip[0]&0xf)>2)) != 0　表示: 整個ip資料包的長度減去ip頭的長度，再減去
tcp頭的長度不為0， 這就意味著， ip資料包中確實是有資料.對於ipv6版本只需考慮ipv6頭中的’Payload Length’ 與 ‘tcp頭的長度’的差值， 並且其中表達方式’ip[]’需換成’ip6[]’.)

列印長度超過576位元組， 並且閘道器地址是snup的IP資料包

列印所有IP層廣播或多播的資料包， 但不是物理乙太網層的廣播或多播資料包

列印除’echo request’或者’echo reply’型別以外的ICMP資料包( 比如，需要列印所有非ping 程式產生的資料包時可用到此表示式 .
(nt: ‘echo reuqest’ 與 ‘echo reply’ 這兩種型別的ICMP資料包通常由ping程式產生))

tcpdump 與wireshark

Wireshark(以前是ethereal)是Windows下非常簡單易用的抓包工具。但在Linux下很難找到一個好用的圖形化抓包工具。
還好有Tcpdump。我們可以用Tcpdump + Wireshark 的完美組合實現：在 Linux 裡抓包，然後在Windows 裡分析包。

(1)tcp: ip icmp arp rarp 和 tcp、udp、icmp這些選項等都要放到第一個引數的位置，用來過濾資料包的型別
(2)-i eth1 : 只抓經過介面eth1的包
(3)-t : 不顯示時間戳
(4)-s 0 : 抓取資料包時預設抓取長度為68位元組。加上-S 0 後可以抓到完整的資料包
(5)-c 100 : 只抓取100個資料包
(6)dst port ! 22 : 不抓取目標埠是22的資料包
(7)src net 192.168.1.0/24 : 資料包的源網路地址為192.168.1.0/24
(8)-w ./target.cap : 儲存成cap檔案，方便用ethereal(即wireshark)分析

使用tcpdump抓取HTTP包

0x4745 為”GET”前兩個字母”GE”，0x4854 為”HTTP”前兩個字母”HT”。

tcpdump 對截獲的資料並沒有進行徹底解碼，資料包內的大部分內容是使用十六進位制的形式直接列印輸出的。顯然這不利於分析網路故障，通常的解決辦法是先使用帶-w引數的tcpdump 截獲資料並儲存到檔案中，然後再使用其他程式(如Wireshark)進行解碼分析。當然也應該定義過濾規則，以避免捕獲的資料包填滿整個硬碟。

輸出資訊含義

首先我們注意一下，基本上tcpdump總的的輸出格式為：系統時間 來源主機.埠 > 目標主機.埠 資料包引數

tcpdump 的輸出格式與協議有關.以下簡要描述了大部分常用的格式及相關例子.

鏈路層頭

對於FDDI網路， ‘-e’ 使tcpdump列印出指定資料包的’frame control’ 域， 源和目的地址， 以及包的長度.(frame control域
控制對包中其他域的解析). 一般的包(比如那些IP datagrams)都是帶有’async'(非同步標誌)的資料包，並且有取值0到7的優先順序;
比如 ‘async4’就代表此包為非同步資料包，並且優先順序別為4. 通常認為，這些包們會內含一個 LLC包(邏輯鏈路控制包); 這時，如果此包
不是一個ISO datagram或所謂的SNAP包，其LLC頭部將會被列印(nt:應該是指此包內含的 LLC包的包頭).

對於Token Ring網路(令牌環網路)， ‘-e’ 使tcpdump列印出指定資料包的’frame control’和’access control’域， 以及源和目的地址，
外加包的長度. 與FDDI網路類似， 此資料包通常內含LLC資料包. 不管 是否有’-e’選項.對於此網路上的’source-routed’型別資料包(nt:
意譯為:源地址被追蹤的資料包，具體含義未知，需補充)， 其包的源路由資訊總會被列印.

對於802.11網路(WLAN，即wireless local area network)， ‘-e’ 使tcpdump列印出指定資料包的’frame control域，
包頭中包含的所有地址， 以及包的長度.與FDDI網路類似， 此資料包通常內含LLC資料包.

(注意: 以下的描述會假設你熟悉SLIP壓縮演算法 (nt:SLIP為Serial Line Internet Protocol.)， 這個演算法可以在
RFC-1144中找到相關的蛛絲馬跡.)

對於SLIP網路(nt:SLIP links， 可理解為一個網路， 即通過序列線路建立的連線， 而一個簡單的連線也可看成一個網路)，
資料包的’direction indicator'(‘方向指示標誌’)(“I”表示入， “O”表示出)， 型別以及壓縮資訊將會被列印. 包型別會被首先列印.

型別分為ip， utcp以及ctcp(nt:未知， 需補充). 對於ip包，連線資訊將不被列印(nt:SLIP連線上，ip包的連線資訊可能無用或沒有定義.
reconfirm).對於TCP資料包， 連線標識緊接著型別表示被列印. 如果此包被壓縮， 其被編碼過的頭部將被列印.
此時對於特殊的壓縮包，會如下顯示:
*S+n 或者 *SA+n， 其中n代表包的(順序號或(順序號和應答號))增加或減少的數目(nt | rt:S，SA拗口， 需再譯).
對於非特殊的壓縮包，0個或更多的’改變’將會被列印.’改變’被列印時格式如下:
‘標誌’+/-/=n 包資料的長度 壓縮的頭部長度.
其中’標誌’可以取以下值:
U(代表緊急指標)， W(指緩衝視窗)， A(應答)， S(序列號)， I(包ID)，而增量表達’=n’表示被賦予新的值， +/-表示增加或減少.

比如， 以下顯示了對一個外發壓縮TCP資料包的列印， 這個資料包隱含一個連線標識(connection identifier); 應答號增加了6，
順序號增加了49， 包ID號增加了6; 包資料長度為3位元組(octect)， 壓縮頭部為6位元組.(nt:如此看來這應該不是一個特殊的壓縮資料包).

ARP/RARP 資料包

tcpdump對Arp/rarp包的輸出資訊中會包含請求型別及該請求對應的引數. 顯示格式簡潔明瞭. 以下是從主機rtsg到主機csam的’rlogin’
(遠端登入)過程開始階段的資料包樣例:

第一行表示:rtsg傳送了一個arp資料包(nt:向全網段傳送，arp資料包）以詢問csam的乙太網地址
Csam（nt:可從下文看出來， 是Csam）以她自己的乙太網地址做了回應(在這個例子中， 乙太網地址以大寫的名字標識， 而internet
地址(即ip地址)以全部的小寫名字標識).

如果使用tcpdump -n， 可以清晰看到乙太網以及ip地址而不是名字標識:
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
第一個資料包表明:以arp包的源以太地址是RTSG， 目標地址是全乙太網段， type域的值為16進位制0806(表示ETHER_ARP(nt:arp包的型別標識))，
包的總長度為64位元組.

TCP 資料包

(注意:以下將會假定你對 RFC-793所描述的TCP熟悉. 如果不熟， 以下描述以及tcpdump程式可能對你幫助不大.(nt:警告可忽略，
只需繼續看， 不熟悉的地方可回頭再看.).

通常tcpdump對tcp資料包的顯示格式如下:
src > dst: flags data-seqno ack window urgent options

src 和 dst 是源和目的IP地址以及相應的埠. flags 標誌由S(SYN)， F(FIN)， P(PUSH， R(RST)，
W(ECN CWT(nt | rep:未知， 需補充))或者 E(ECN-Echo(nt | rep:未知，　需補充))組成，
單獨一個’.’表示沒有flags標識. 資料段順序號(Data-seqno)描述了此包中資料所對應序列號空間中的一個位置(nt:整個資料被分段，
每段有一個順序號， 所有的順序號構成一個序列號空間)(可參考以下例子). Ack 描述的是同一個連線，同一個方向，下一個本端應該接收的
(對方應該傳送的)資料片段的順序號. Window是本端可用的資料接收緩衝區的大小(也是對方傳送資料時需根據這個大小來組織資料).
Urg(urgent) 表示資料包中有緊急的資料. options 描述了tcp的一些選項， 這些選項都用尖括號來表示(如 ).

src， dst 和 flags 這三個域總是會被顯示. 其他域的顯示與否依賴於tcp協議頭裡的資訊.

這是一個從trsg到csam的一個rlogin應用登入的開始階段.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096
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
第一行表示有一個資料包從rtsg主機的tcp埠1023傳送到了csam主機的tcp埠login上(nt:udp協議的埠和tcp協議的端
口是分別的兩個空間， 雖然取值範圍一致). S表示設定了SYN標誌. 包的順序號是768512， 並且沒有包含資料.(表示格式
為:’first:last(nbytes)’， 其含義是’此包中資料的順序號從first開始直到last結束，不包括last. 並且總共包含nbytes的
使用者資料’.) 沒有捎帶應答(nt:從下文來看，第二行才是有捎帶應答的資料包)， 可用的接受視窗的大小為4096bytes， 並且請求端(rtsg)
的最大可接受的資料段大小是1024位元組(nt:這個資訊作為請求發向應答端csam， 以便雙方進一步的協商).

Csam 向rtsg 回覆了基本相同的SYN資料包， 其區別只是多了一個’ piggy-backed ack'(nt:捎帶回的ack應答， 針對rtsg的SYN資料包).

rtsg 同樣針對csam的SYN資料包回覆了一ACK資料包作為應答. ‘.’的含義就是此包中沒有標誌被設定. 由於此應答包中不含有資料， 所以
包中也沒有資料段序列號. 提醒! 此ACK資料包的順序號只是一個小整數1. 有如下解釋:tcpdump對於一個tcp連線上的會話， 只列印會話兩端的
初始資料包的序列號，其後相應資料包只列印出與初始包序列號的差異.即初始序列號之後的序列號，　可被看作此會話上當前所傳資料片段在整個
要傳輸的資料中的’相對位元組’位置(nt:雙方的第一個位置都是1， 即’相對位元組’的開始編號).　’-Ｓ’將覆蓋這個功能，
使資料包的原始順序號被列印出來.

第六行的含義為:rtsg 向 csam傳送了19位元組的資料(位元組的編號為2到20，傳送方向為rtsg到csam). 包中設定了PUSH標誌. 在第7行，
csam 喊到， 她已經從rtsg中收到了21以下的位元組， 但不包括21編號的位元組. 這些位元組存放在csam的socket的接收緩衝中， 相應地，
csam的接收緩衝視窗大小會減少19位元組(nt:可以從第5行和第7行win屬性值的變化看出來). csam在第7行這個包中也向rtsg傳送了一個
位元組. 在第8行和第9行， csam 繼續向rtsg 分別傳送了兩個只包含一個位元組的資料包， 並且這個資料包帶PUSH標誌.

如果所抓到的tcp包(nt:即這裡的snapshot)太小了，以至tcpdump無法完整得到其頭部資料， 這時， tcpdump會盡量解析這個不完整的頭，
並把剩下不能解析的部分顯示為'[|tcp]’. 如果頭部含有虛假的屬性資訊(比如其長度屬性其實比頭部實際長度長或短)， tcpdump會為該頭部
顯示'[bad opt]’. 如果頭部的長度告訴我們某些選項(nt | rt:從下文來看， 指tcp包的頭部中針對ip包的一些選項， 回頭再翻)會在此包中，
而真正的IP(資料包的長度又不夠容納這些選項， tcpdump會顯示'[bad hdr length]’.

抓取帶有特殊標誌的的TCP包(如SYN-ACK標誌， URG-ACK標誌等).

在TCP的頭部中， 有8位元(bit)用作控制位區域， 其取值為:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
(nt | rt:從表達方式上可推斷:這8個位是用或的方式來組合的， 可回頭再翻)

現假設我們想要監控建立一個TCP連線整個過程中所產生的資料包. 可回憶如下:TCP使用3次握手協議來建立一個新的連線; 其與此三次握手
連線順序對應，並帶有相應TCP控制標誌的資料包如下:
1) 連線發起方(nt:Caller)傳送SYN標誌的資料包
2) 接收方(nt:Recipient)用帶有SYN和ACK標誌的資料包進行回應
3) 發起方收到接收方回應後再傳送帶有ACK標誌的資料包進行回應

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頭部，在不包含選項資料的情況下通常佔用20個位元組(nt | rt:options 理解為選項資料，需回譯). 第一行包含0到3編號的位元組，
第二行包含編號4-7的位元組.

如果編號從0開始算， TCP控制標誌位於13位元組(nt:第四行左半部分).

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

讓我們仔細看看編號13的位元組:

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

這裡有我們感興趣的控制標誌位. 從右往左這些位被依次編號為0到7， 從而 PSH位在3號， 而URG位在5號.

提醒一下自己， 我們只是要得到包含SYN標誌的資料包. 讓我們看看在一個包的包頭中， 如果SYN位被設定， 到底
在13號位元組發生了什麼:

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

在控制段的資料中， 只有位元1(bit number 1)被置位.

假設編號為13的位元組是一個8位的無符號字元型，並且按照網路位元組號排序(nt:對於一個位元組來說，網路位元組序等同於主機位元組序)， 其二進位制值
如下所示:
00000010

並且其10進位制值為:

0*2^7 + 0*2^6 + 0*2^5 + 0*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2^0 = 2(nt: 1 * 2^6 表示1乘以2的6次方， 也許這樣更
清楚些， 即把原來表達中的指數7 6 … 0挪到了下面來表達)

接近目標了， 因為我們已經知道， 如果資料包頭部中的SYN被置位， 那麼頭部中的第13個位元組的值為2(nt: 按照網路序， 即大頭方式， 最重要的位元組
在前面(在前面，即該位元組實際記憶體地址比較小， 最重要的位元組，指數學表示中數的高位， 如356中的3) ).

表達為tcpdump能理解的關係式就是:
tcp[13] 2

從而我們可以把此關係式當作tcpdump的過濾條件， 目標就是監控只含有SYN標誌的資料包:
tcpdump -i xl0 tcp[13] 2 (nt: xl0 指網路介面， 如eth0)

這個表示式是說”讓TCP資料包的第13個位元組擁有值2吧”， 這也是我們想要的結果.

現在， 假設我們需要抓取帶SYN標誌的資料包， 而忽略它是否包含其他標誌.(nt:只要帶SYN就是我們想要的). 讓我們來看看當一個含有
SYN-ACK的資料包(nt: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|

13號位元組的1號和4號位被置位， 其二進位制的值為:
00010010

轉換成十進位制就是:

0*2^7 + 0*2^6 + 0*2^5 + 1*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2 = 18(nt: 1 * 2^6 表示1乘以2的6次方， 也許這樣更
清楚些， 即把原來表達中的指數7 6 … 0挪到了下面來表達)

現在， 卻不能只用’tcp[13] 18’作為tcpdump的過濾表示式， 因為這將導致只選擇含有SYN-ACK標誌的資料包， 其他的都被丟棄.
提醒一下自己， 我們的目標是: 只要包的SYN標誌被設定就行， 其他的標誌我們不理會.

為了達到我們的目標， 我們需要把13號位元組的二進位制值與其他的一個數做AND操作(nt:邏輯與)來得到SYN位元位的值. 目標是:只要SYN 被設定
就行， 於是我們就把她與上13號位元組的SYN值(nt: 00000010).

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

我們可以發現， 不管包的ACK或其他標誌是否被設定， 以上的AND操作都會給我們相同的值， 其10進製表達就是2(2進製表達就是00000010).
從而我們知道， 對於帶有SYN標誌的資料包， 以下的表示式的結果總是真(true):

( ( value of octet 13 ) AND ( 2 ) ) ( 2 ) (nt: value of octet 13， 即13號位元組的值)

靈感隨之而來， 我們於是得到了如下的tcpdump 的過濾表示式
tcpdump -i xl0 ‘tcp[13] & 2 2’

注意， 單引號或反斜杆(nt: 這裡用的是單引號)不能省略， 這可以防止shell對&的解釋或替換.

UDP 資料包

UDP 資料包的顯示格式，可通過rwho這個具體應用所產生的資料包來說明:
actinide.who > broadcast.who: udp 84

其含義為:actinide主機上的埠who向broadcast主機上的埠who傳送了一個udp資料包(nt: actinide和broadcast都是指Internet地址).
這個資料包承載的使用者資料為84個位元組.

一些UDP服務可從資料包的源或目的埠來識別，也可從所顯示的更高層協議資訊來識別. 比如， Domain Name service requests(DNS 請求，
在RFC-1034/1035中)， 和Sun RPC calls to NFS(對NFS伺服器所發起的遠端呼叫(nt: 即Sun RPC)，在RFC-1050中有對遠端呼叫的描述).

UDP 名稱服務請求

(注意:以下的描述假設你對Domain Service protoco(nt:在RFC-103中有所描述)， 否則你會發現以下描述就是天書(nt:希臘文天書，
不必理會， 嚇嚇你的， 接著看就行))

名稱服務請求有如下的格式:
src > dst: id op? flags qtype qclass name (len)
(nt: 從下文來看， 格式應該是src > dst: id op flags qtype qclass? name (len))
比如有一個實際顯示為:
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

主機h2opolo 向helios 上執行的名稱伺服器查詢ucbvax.berkeley.edu 的地址記錄(nt: qtype等於A). 此查詢本身的id號為’3′. 符號
‘+’意味著遞迴查詢標誌被設定(nt: dns伺服器可向更高層dns伺服器查詢本伺服器不包含的地址記錄). 這個最終通過IP包傳送的查詢請求
資料長度為37位元組， 其中不包括UDP和IP協議的頭資料. 因為此查詢操作為預設值(nt | rt: normal one的理解)， op欄位被省略.
如果op欄位沒被省略， 會被顯示在’3′ 和’+’之間. 同樣， qclass也是預設值， C_IN， 從而也沒被顯示， 如果沒被忽略， 她會被顯示在’A’之後.

異常檢查會在方括中顯示出附加的域:　如果一個查詢同時包含一個回應(nt: 可理解為， 對之前其他一個請求的回應)， 並且此回應包含權威或附加記錄段，
ancount， nscout， arcount(nt: 具體欄位含義需補充) 將被顯示為'[na]’， ‘[nn]’， ‘[nau]’， 其中n代表合適的計數. 如果包中以下
回應位(比如AA位， RA位， rcode位)， 或者位元組2或3中任何一個’必須為0’的位被置位(nt: 設定為1)， ‘[b2&3]=x’ 將被顯示， 其中x表示
頭部位元組2與位元組3進行與操作後的值.

UDP 名稱服務應答

對名稱服務應答的資料包，tcpdump會有如下的顯示格式
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 所傳送的3號查詢請求回應了3條回答記錄(nt | rt: answer records)， 3條名稱伺服器記錄，
以及7條附加的記錄. 第一個回答記錄(nt: 3個回答記錄中的第一個)型別為A(nt: 表示地址)， 其資料為internet地址128.32.137.3.
此回應UDP資料包， 包含273位元組的資料(不包含UPD和IP的頭部資料). op欄位和rcode欄位被忽略(nt: op的實際值為Query， rcode， 即
response code的實際值為NoError)， 同樣被忽略的欄位還有class 欄位(nt | rt: 其值為C_IN， 這也是A型別記錄預設取值)

第二行表示: helios 對h2opolo 所傳送的2號查詢請求做了回應. 回應中， rcode編碼為NXDomain(nt: 表示不存在的域))， 沒有回答記錄，
但包含一個名稱伺服器記錄， 不包含權威伺服器記錄(nt | ck: 從上文來看， 此處的authority records 就是上文中對應的additional
records). ‘*’表示權威伺服器回答標誌被設定(nt: 從而additional records就表示的是authority records).
由於沒有回答記錄， type， class， data欄位都被忽略.

flag欄位還有可能出現其他一些字元， 比如’-‘(nt: 表示可遞迴地查詢， 即RA 標誌沒有被設定)， ‘|'(nt: 表示被截斷的訊息， 即TC 標誌
被置位). 如果應答(nt | ct: 可理解為， 包含名稱服務應答的UDP資料包， tcpdump知道這類資料包該怎樣解析其資料)的’question’段一個條
目(entry)都不包含(nt: 每個條目的含義， 需補充)，'[nq]’ 會被列印出來.

要注意的是:名稱伺服器的請求和應答資料量比較大， 而預設的68位元組的抓取長度(nt: snaplen， 可理解為tcpdump的一個設定選項)可能不足以抓取
資料包的全部內容. 如果你真的需要仔細檢視名稱伺服器的負載， 可以通過tcpdump 的-s 選項來擴大snaplen值.

SMB/CIFS 解碼

tcpdump 已可以對SMB/CIFS/NBT相關應用的資料包內容進行解碼(nt: 分別為’Server Message Block Common’， ‘Internet File System’
‘在TCP/IP上實現的網路協議NETBIOS的簡稱’. 這幾個服務通常使用UDP的137/138以及TCP的139埠). 原來的對IPX和NetBEUI SMB資料包的
解碼能力依然可以被使用(nt: NetBEUI為NETBIOS的增強版本).

tcpdump預設只按照最簡約模式對相應資料包進行解碼， 如果我們想要詳盡的解碼資訊可以使用其-v 啟動選現. 要注意的是， -v 會產生非常詳細的資訊，
比如對單一的一個SMB資料包， 將產生一螢幕或更多的資訊， 所以此選項， 確有需要才使用.

關於SMB資料包格式的資訊， 以及每個域的含義可以參看www.cifs.org 或者samba.org 映象站點的pub/samba/specs/ 目錄. linux 上的SMB 補丁
(nt | rt: patch)由 Andrew Tridgell (tridge@samba.org)提供.

NFS 請求和回應

tcpdump對Sun NFS(網路檔案系統)請求和回應的UDP資料包有如下格式的列印輸出:
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向主機wrl傳送了一個’交換請求'(nt: transaction)， 此請求的id為6709(注意， 主機名字後是交換
請求id號， 而不是源埠號). 此請求資料為112位元組， 其中不包括UDP和IP頭部的長度. 操作型別為readlink(nt: 即此操作為讀符號連結操作)，
操作引數為fh 21，24/10.73165(nt: 可按實際執行環境， 解析如下， fd 表示描述的為檔案控制程式碼， 21，24 表示此控制程式碼所對應設
備的主/從裝置號對， 10表示此控制程式碼所對應的i節點編號(nt:每個檔案都會在作業系統中對應一個i節點， 限於unix類系統中)，
73165是一個編號(nt: 可理解為標識此請求的一個隨機數， 具體含義需補充)).

第二行中， wrl 做了’ok’的回應， 並且在results 欄位中返回了sushi想要讀的符號連線的真實目錄(nt: 即sushi要求讀的符號連線其實是一個目錄).

第三行表明: sushi 再次請求 wrl 在’fh 9，74/4096.6878’所描述的目錄中查詢’xcolors’檔案. 需要注意的是， 每行所顯示的資料含義依賴於其中op欄位的
型別(nt: 不同op 所對應args 含義不相同)， 其格式遵循NFS 協議， 追求簡潔明瞭.

如果tcpdump 的-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 選項一般還會列印出IP頭部的TTL， ID， length， 以及fragmentation 域， 但在此例中， 都略過了(nt: 可理解為，簡潔起見， 做了刪減))
在第一行， sushi 請求wrl 從檔案 21，11/12.195(nt: 格式在上面有描述)中， 自偏移24576位元組處開始， 讀取8192位元組資料.
Wrl 回應讀取成功; 由於第二行只是回應請求的開頭片段， 所以只包含1472位元組(其他的資料將在接著的reply片段中到來， 但這些資料包不會再有NFS
頭， 甚至UDP頭資訊也為空(nt: 源和目的應該要有)， 這將導致這些片段不能滿足過濾條件， 從而沒有被列印). -v 選項除了顯示檔案資料資訊， 還會顯示
附加顯示檔案屬性資訊: file type(檔案型別， ”REG” 表示普通檔案)， file mode(檔案存取模式， 8進製表示的)， uid 和gid(nt: 檔案屬主和
組屬主)， file size (檔案大小).

如果-v 標誌被多次重複給出(nt: 如-vv)， tcpdump會顯示更加詳細的資訊.

必須要注意的是， NFS 請求包中資料比較多， 如果tcpdump 的snaplen(nt: 抓取長度) 取太短將不能顯示其詳細資訊. 可使用
‘-s 192’來增加snaplen， 這可用以監測NFS應用的網路負載(nt: traffic).

NFS 的回應包並不嚴格的緊隨之前相應的請求包(nt: RPC operation). 從而， tcpdump 會跟蹤最近收到的一系列請求包， 再通過其
交換序號(nt: transaction ID)與相應請求包相匹配. 這可能產生一個問題， 如果回應包來得太遲， 超出tcpdump 對相應請求包的跟蹤範圍，
該回應包將不能被分析.

AFS 請求和回應

AFS(nt: Andrew 檔案系統， Transarc ， 未知， 需補充)請求和回應有如下的答應

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 向pike 傳送了一個RX資料包.
這是一個對於檔案服務的請求資料包(nt: RX data packet， 傳送資料包 ， 可理解為傳送包過去， 從而請求對方的服務)， 這也是一個RPC
呼叫的開始(nt: RPC， remote procedure call). 此RPC 請求pike 執行rename(nt: 重新命名) 操作， 並指定了相關的引數:
原目錄描述符為536876964/1/1， 原檔名為 ‘.newsrc.new’， 新目錄描述符為536876964/1/1， 新檔名為 ‘.newsrc’.
主機pike 對此rename操作的RPC請求作了回應(回應表示rename操作成功， 因為回應的是包含資料內容的包而不是異常包).

一般來說， 所有的’AFS RPC’請求被顯示時， 會被冠以一個名字(nt: 即decode， 解碼)， 這個名字往往就是RPC請求的操作名.
並且， 這些RPC請求的部分引數在顯示時， 也會被冠以一個名字(nt | rt: 即decode， 解碼， 一般來說也是取名也很直接， 比如，
一個interesting 引數， 顯示的時候就會直接是’interesting’， 含義拗口， 需再翻).

這種顯示格式的設計初衷為’一看就懂’， 但對於不熟悉AFS 和 RX 工作原理的人可能不是很
有用(nt: 還是不用管， 書面嚇嚇你的， 往下看就行).

如果 -v(詳細)標誌被重複給出(nt: 如-vv)， tcpdump 會列印出確認包(nt: 可理解為， 與應答包有區別的包)以及附加頭部資訊
(nt: 可理解為， 所有包， 而不僅僅是確認包的附加頭部資訊)， 比如， RX call ID(請求包中’請求呼叫’的ID)，
call number(‘請求呼叫’的編號)， sequence number(nt: 包順序號)，
serial number(nt | rt: 可理解為與包中資料相關的另一個順訊號， 具體含義需補充)， 請求包的標識. (nt: 接下來一段為重複描述，
所以略去了)， 此外確認包中的MTU協商資訊也會被列印出來(nt: 確認包為相對於請求包的確認包， Maximum Transmission Unit， 最大傳輸單元).

如果 -v 選項被重複了三次(nt: 如-vvv)， 那麼AFS應用型別資料包的’安全索引'(‘security index’)以及’服務索引'(‘service id’)將會
被列印.

對於表示異常的資料包(nt: abort packet， 可理解為， 此包就是用來通知接受者某種異常已發生)， tcpdump 會列印出錯誤號(error codes).
但對於Ubik beacon packets(nt: Ubik 燈塔指示包， Ubik可理解為特殊的通訊協議， beacon packets， 燈塔資料包， 可理解為指明通訊中
關鍵資訊的一些資料包)， 錯誤號不會被列印， 因為對於Ubik 協議， 異常資料包不是表示錯誤， 相反卻是表示一種肯定應答(nt: 即， yes vote).

AFS 請求資料量大， 引數也多， 所以要求tcpdump的 snaplen 比較大， 一般可通過啟動tcpdump時設定選項’-s 256′ 來增大snaplen， 以
監測AFS 應用通訊負載.

AFS 回應包並不顯示標識RPC 屬於何種遠端呼叫. 從而， tcpdump 會跟蹤最近一段時間內的請求包， 並通過call number(呼叫編號)， service ID
(服務索引) 來匹配收到的回應包. 如果回應包不是針對最近一段時間內的請求包， tcpdump將無法解析該包.

KIP AppleTalk協議

(nt | rt: DDP in UDP可理解為， DDP， The AppleTalk Data Delivery Protocol，
相當於支援KIP AppleTalk協議棧的網路層協議， 而DDP 本身又是通過UDP來傳輸的，
即在UDP 上實現的用於其他網路的網路層，KIP AppleTalk是蘋果公司開發的整套網路協議棧).

AppleTalk DDP 資料包被封裝在UDP資料包中， 其解封裝(nt: 相當於解碼)和相應資訊的轉儲也遵循DDP 包規則.
(nt:encapsulate， 封裝， 相當於編碼， de-encapsulate， 解封裝， 相當於解碼， dump， 轉儲， 通常就是指對其資訊進行列印).

/etc/atalk.names 檔案中包含了AppleTalk 網路和節點的數字標識到名稱的對應關係. 其檔案格式通常如下所示:
number name

1.254 ether
16.1 icsd-net
1.254.110 ace

頭兩行表示有兩個AppleTalk 網路. 第三行給出了特定網路上的主機(一個主機會用3個位元組來標識，
而一個網路的標識通常只有兩個位元組， 這也是兩者標識的主要區別)(nt: 1.254.110 可理解為ether網路上的ace主機).
標識與其對應的名字之間必須要用空白分開. 除了以上內容， /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 主機/網路的條目， 資料包的網路地址將以數字形式顯示).

在第一行中， 網路144.1上的節點209通過2埠，向網路icsd-net上監聽在220埠的112節點傳送了一個NBP應用資料包
(nt | rt: NBP， name binding protocol， 名稱繫結協議， 從資料來看， NBP伺服器會在埠2提供此服務.
‘DDP port 2’ 可理解為’DDP 對應傳輸層的埠2’， DDP本身沒有埠的概念， 這點未確定， 需補充).

第二行與第一行類似， 只是源的全部地址可用’office’進行標識.
第三行表示: jssmag網路上的149節點通過235向icsd-net網路上的所有節點的2埠(NBP埠)傳送了資料包.(需要注意的是，
在AppleTalk 網路中如果地址中沒有節點， 則表示廣播地址， 從而節點標識和網路標識最好在/etc/atalk.names有所區別.
nt: 否則一個標識x.port 無法確定x是指一個網路上所有主機的port口還是指定主機x的port口).

tcpdump 可解析NBP (名稱繫結協議) and 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-net 中的節點112 通過220埠向網路jssmag 中所有節點的埠2傳送了對’LaserWriter’的名稱查詢請求(nt:
此處名稱可理解為一個資源的名稱， 比如印表機). 此查詢請求的序列號為190.

第二行表示: 網路jssmag 中的節點209 通過2埠向icsd-net.112節點的埠220進行了回應: 我有’LaserWriter’資源， 其資源名稱
為’RM1140’， 並且在埠250上提供改資源的服務. 此回應的序列號為190， 對應之前查詢的序列號.

第三行也是對第一行請求的回應: 節點techpit 通過2埠向icsd-net.112節點的埠220進行了回應:我有’LaserWriter’資源， 其資源名稱
為’techpit’， 並且在埠186上提供改資源的服務. 此回應的序列號為190， 對應之前查詢的序列號.

ATP 資料包的顯示格式如下:
jssmag.209.165 > helios.132: atp-req 12266 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: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 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 0xae030001
jssmag.209.133 > helios.132: atp-req* 12267 0xae030002

第一行表示節點 Jssmag.209 向節點helios 傳送了一個會話編號為12266的請求包， 請求helios
回應8個資料包(這8個資料包的順序號為0-7(nt: 順序號與會話編號不同， 後者為一次完整傳輸的編號，
前者為該傳輸中每個資料包的編號. transaction， 會話， 通常也被叫做傳輸)). 行尾的16進位制數字表示
該請求包中’userdata’域的值(nt: 從下文來看， 這並沒有把所有使用者資料都列印出來 ).

Helios 回應了8個512位元組的資料包. 跟在會話編號(nt: 12266)後的數字表示該資料包在該會話中的順序號.
括號中的數字表示該資料包中資料的大小， 這不包括atp 的頭部. 在順序號為7資料包(第8行)外帶了一個’*’號，
表示該資料包的EOM 標誌被設定了.(nt: EOM， End Of Media， 可理解為， 表示一次會話的資料回應完畢).

接下來的第9行表示， Jssmag.209 又向helios 提出了請求: 順序號為3以及5的資料包請重新傳送. Helios 收到這個
請求後重新傳送了這個兩個資料包， jssmag.209 再次收到這兩個資料包之後， 主動結束(release)了此會話.

在最後一行， jssmag.209 向helios 傳送了開始下一次會話的請求包. 請求包中的’*’表示該包的XO 標誌沒有被設定.
(nt: XO， exactly once， 可理解為在該會話中， 資料包在接受方只被精確地處理一次， 就算對方重複傳送了該資料包，
接收方也只會處理一次， 這需要用到特別設計的資料包接收和處理機制).

IP 資料包破碎

(nt: 指把一個IP資料包分成多個IP資料包)

碎片IP資料包(nt: 即一個大的IP資料包破碎後生成的小IP資料包)有如下兩種顯示格式.
(frag id:size@offset+)
(frag id:size@offset)
(第一種格式表示， 此碎片之後還有後續碎片. 第二種格式表示， 此碎片為最後一個碎片.)

id 表示破碎編號(nt: 從下文來看， 會為每個要破碎的大IP包分配一個破碎編號， 以便區分每個小碎片是否由同一資料包破碎而來).
size 表示此碎片的大小 ， 不包含碎片頭部資料. offset表示此碎片所含資料在原始整個IP包中的偏移((nt: 從下文來看，
一個IP資料包是作為一個整體被破碎的， 包括頭和資料， 而不只是資料被分割).

每個碎片都會使tcpdump產生相應的輸出列印. 第一個碎片包含了高層協議的頭資料(nt:從下文來看， 被破碎IP資料包中相應tcp頭以及
IP頭都放在了第一個碎片中 )， 從而tcpdump會針對第一個碎片顯示這些資訊， 並接著顯示此碎片本身的資訊. 其後的一些碎片並不包含
高層協議頭資訊， 從而只會在顯示源和目的之後顯示碎片本身的資訊. 以下有一個例子: 這是一個從arizona.edu 到lbl-rtsg.arpa
途經CSNET網路(nt: CSNET connection 可理解為建立在CSNET 網路上的連線)的ftp應用通訊片段:
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包的順序號.

第二， 從第一行的資訊中， 可以發現arizona需要向rtsg傳送308位元組的使用者資料， 而事實是， 相應IP包經破碎後會總共產生512位元組
資料(第一個碎片包含308位元組的資料， 第二個碎片包含204個位元組的資料， 這超過了308位元組). 如果你在查詢資料包的順序號空間中的
一些空洞(nt: hole，空洞， 指資料包之間的順序號沒有上下銜接上)， 512這個資料就足夠使你迷茫一陣(nt: 其實只要關注308就行，
不必關注破碎後的資料總量).

一個資料包(nt | rt: 指IP資料包)如果帶有非IP破碎標誌， 則顯示時會在最後顯示'(DF)’.(nt: 意味著此IP包沒有被破碎過).

時間戳

tcpdump的所有輸出列印行中都會預設包含時間戳資訊.
時間戳資訊的顯示格式如下
hh:mm:ss.frac　(nt: 小時:分鐘:秒.(nt: frac未知， 需補充))
此時間戳的精度與核心時間精度一致，　反映的是核心第一次看到對應資料包的時間(nt: saw， 即可對該資料包進行操作).
而資料包從物理線路傳遞到核心的時間， 以及核心花費在此包上的中斷處理時間都沒有算進來.

命令使用

tcpdump採用命令列方式，它的命令格式為：

tcpdump的簡單選項介紹

tcpdump條件表示式

該表示式用於決定哪些資料包將被列印. 如果不給定條件表示式， 網路上所有被捕獲的包都會被列印，否則， 只有滿足條件表示式的資料包被列印.(nt: all packets， 可理解為， 所有被指定介面捕獲的資料包).

表示式由一個或多個’表達元’組成(nt: primitive， 表達元， 可理解為組成表示式的基本元素). 一個表達元通常由一個或多個修飾符(qualifiers)後跟一個名字或數字表示的id組成(nt: 即， ‘qualifiers id’).有三種不同型別的修飾符:type， dir以及 proto.

除以上所描述的表達元(‘primitive’)， 還有其他形式的表達元， 並且與上述表達元格式不同. 比如: gateway， broadcast， less， greater以及算術表示式(nt: 其中每一個都算一種新的表達元). 下面將會對這些表達元進行說明.

表達元之間還可以通過關鍵字and， or 以及 not 進行連線， 從而可組成比較複雜的條件表示式. 比如，host foo and not port ftp and not port ftp-data'(nt: 其過濾條件可理解為， 資料包的主機為foo，並且埠不是ftp(埠21) 和ftp-data(埠20， 常用埠和名字的對應可在linux 系統中的/etc/service 檔案中找到)).

為了表示方便， 同樣的修飾符可以被省略， 如'tcp dst port ftp or ftp-data or domain' 與以下的表示式含義相同'tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.(nt: 其過濾條件可理解為，包的協議為tcp， 目的埠為ftp 或 ftp-data 或 domain(埠53) ).

藉助括號以及相應操作符，可把表達元組合在一起使用(由於括號是shell的特殊字元， 所以在shell指令碼或終端中使用時必須對括號進行轉義， 即'(' 與')'需要分別表達成'(' 與 ')').

有效的操作符有:

否定操作符的優先順序別最高. 與操作和或操作優先順序別相同， 並且二者的結合順序是從左到右. 要注意的是， 表達'與操作'時，

需要顯式寫出'and'操作符， 而不只是把前後表達元並列放置(nt: 二者中間的'and' 操作符不可省略).

如果一個識別符號前沒有關鍵字， 則表示式的解析過程中最近用過的關鍵字(往往也是從左往右距離識別符號最近的關鍵字)將被使用.比如，
not host vs and ace
是以下表達的精簡:
not host vs and host ace
而不是not (host vs or ace).(nt: 前兩者表示， 所需資料包不是來自或發往host vs， 而是來自或發往ace.而後者表示資料包只要不是來自或發往vs或ac都符合要求)

整個條件表示式可以被當作一個單獨的字串引數也可以被當作空格分割的多個引數傳入tcpdump， 後者更方便些. 通常， 如果表示式中包含元字元(nt: 如正規表示式中的'*'， '.'以及shell中的'('等字元)， 最好還是使用單獨字串的方式傳入. 這時，整個表示式需要被單引號括起來. 多引數的傳入方式中， 所有引數最終還是被空格串聯在一起， 作為一個字串被解析.

附錄:tcpdump的表達元

(nt: True 在以下的描述中含義為: 相應條件表示式中只含有以下所列的一個特定表達元， 此時表示式為真， 即條件得到滿足)

dst host host
如果IPv4/v6 資料包的目的域是host， 則與此對應的條件表示式為真.host 可以是一個ip地址， 也可以是一個主機名.
src host host
如果IPv4/v6 資料包的源域是host， 則與此對應的條件表示式為真.
host 可以是一個ip地址， 也可以是一個主機名.
host host

如果IPv4/v6資料包的源或目的地址是 host， 則與此對應的條件表示式為真.以上的幾個host 表示式之前可以新增以下關鍵字:ip， arp， rarp， 以及 ip6.比如:
ip host host
也可以表達為:
ether proto ip and host host(nt: 這種表達方式在下面有說明， 其中ip之前需要有來轉義，因為ip 對tcpdump 來說已經是一個關鍵字了.)

如果host 是一個擁有多個IP 的主機， 那麼任何一個地址都會用於包的匹配(nt: 即發向host 的資料包的目的地址可以是這幾個IP中的任何一個， 從host 接收的資料包的源地址也可以是這幾個IP中的任何一個).

ether dst ehost
如果資料包(nt: 指tcpdump 可抓取的資料包， 包括ip 資料包， tcp資料包)的乙太網目標地址是ehost，則與此對應的條件表示式為真. Ehost 可以是/etc/ethers 檔案中的名字或一個數字地址(nt: 可通過 man ethers 看到對/etc/ethers 檔案的描述， 樣例中用的是數字地址)

ether src ehost
如果資料包的乙太網源地址是ehost， 則與此對應的條件表示式為真.

ether host ehost
如果資料包的乙太網源地址或目標地址是ehost， 則與此對應的條件表示式為真.

gateway host
如果資料包的閘道器地址是host， 則與此對應的條件表示式為真. 需要注意的是， 這裡的閘道器地址是指乙太網地址， 而不是IP 地址(nt | rt: I.e.， 例如， 可理解為'注意'.the Ethernet source or destination address， 乙太網源和目標地址， 可理解為， 指代上句中的'閘道器地址' ).host 必須是名字而不是數字， 並且必須在機器的'主機名-ip地址'以及'主機名-以太地址'兩大對映關係中 有其條目(前一對映關係可通過/etc/hosts檔案， DNS 或 NIS得到， 而後一對映關係可通過/etc/ethers 檔案得到. nt: /etc/ethers並不一定存在 ， 可通過man ethers 看到其資料格式， 如何建立該檔案， 未知，需補充).也就是說host 的含義是 ether host ehost 而不是 host host， 並且ehost必須是名字而不是數字.
目前， 該選項在支援IPv6地址格式的配置環境中不起作用(nt: configuration， 配置環境， 可理解為，通訊雙方的網路配置).

dst net net
如果資料包的目標地址(IPv4或IPv6格式)的網路號欄位為 net， 則與此對應的條件表示式為真.
net 可以是從網路資料庫檔案/etc/networks 中的名字， 也可以是一個數字形式的網路編號.

一個數字IPv4 網路編號將以點分四元組(比如， 192.168.1.0)， 或點分三元組(比如， 192.168.1 )， 或點分二元組(比如， 172.16)， 或單一單元組(比如， 10)來表達;

對應於這四種情況的網路掩碼分別是:四元組:255.255.255.255(這也意味著對net 的匹配如同對主機地址(host)的匹配:地址的四個部分都用到了)，三元組:255.255.255.0， 二元組: 255.255.0.0， 一元組:255.0.0.0.

對於IPv6 的地址格式， 網路編號必須全部寫出來(8個部分必須全部寫出來); 相應網路掩碼為:
ff:ff:ff:ff:ff:ff:ff:ff， 所以IPv6 的網路匹配是真正的'host'方式的匹配(nt | rt | rc:地址的8個部分都會用到，是否不屬於網路的位元組填寫0， 需接下來補充)， 但同時需要一個網路掩碼長度引數來具體指定前面多少位元組為網路掩碼(nt: 可通過下面的net net/len 來指定)

src net net
如果資料包的源地址(IPv4或IPv6格式)的網路號欄位為 net， 則與此對應的條件表示式為真.

net net
如果資料包的源或目的地址(IPv4或IPv6格式)的網路號欄位為 net， 則與此對應的條件表示式為真.

net net mask netmask
如果資料包的源或目的地址(IPv4或IPv6格式)的網路掩碼與netmask 匹配， 則與此對應的條件表示式為真.此選項之前還可以配合src和dst來匹配源網路地址或目標網路地址(nt: 比如 src net net mask 255.255.255.0).該選項對於ipv6 網路地址無效.

net net/len
如果資料包的源或目的地址(IPv4或IPv6格式)的網路編號欄位的位元數與len相同， 則與此對應的條件表示式為真.此選項之前還可以配合src和dst來匹配源網路地址或目標網路地址(nt | rt | tt: src net net/24， 表示需要匹配源地址的網路編號有24位的資料包).

dst port port
如果資料包(包括ip/tcp， ip/udp， ip6/tcp or ip6/udp協議)的目的埠為port， 則與此對應的條件表示式為真.port 可以是一個數字也可以是一個名字(相應名字可以在/etc/services 中找到該名字， 也可以通過man tcp 和man udp來得到相關描述資訊 ). 如果使用名字， 則該名字對應的埠號和相應使用的協議都會被檢查. 如果只是使用一個數字埠號，則只有相應埠號被檢查(比如， dst port 513 將會使tcpdump抓取tcp協議的login 服務和udp協議的who 服務資料包， 而port domain 將會使tcpdump 抓取tcp協議的domain 服務資料包， 以及udp 協議的domain 資料包)(nt | rt: ambiguous name is used 不可理解， 需補充).

src port port
如果資料包的源埠為port， 則與此對應的條件表示式為真.

port port
如果資料包的源或目的埠為port， 則與此對應的條件表示式為真.

dst portrange port1-port2
如果資料包(包括ip/tcp， ip/udp， ip6/tcp or ip6/udp協議)的目的埠屬於port1到port2這個埠範圍(包括port1， port2)， 則與此對應的條件表示式為真. tcpdump 對port1 和port2 解析與對port 的解析一致(nt:在dst port port 選項的描述中有說明).

src portrange port1-port2
如果資料包的源埠屬於port1到port2這個埠範圍(包括 port1， port2)， 則與此對應的條件表示式為真.

portrange port1-port2
如果資料包的源埠或目的埠屬於port1到port2這個埠範圍(包括 port1， port2)， 則與此對應的條件表示式為真.

以上關於port 的選項都可以在其前面新增關鍵字:tcp 或者udp， 比如:
tcp src port port
這將使tcpdump 只抓取源埠是port 的tcp資料包.

less length
如果資料包的長度比length 小或等於length， 則與此對應的條件表示式為真. 這與'len ' 的含義一致.

greater length
如果資料包的長度比length 大或等於length， 則與此對應的條件表示式為真. 這與'len >= length' 的含義一致.

ip proto protocol
如果資料包為ipv4資料包並且其協議型別為protocol， 則與此對應的條件表示式為真.
Protocol 可以是一個數字也可以是名字， 比如:icmp6， igmp， igrp(nt: Interior Gateway Routing Protocol，內部閘道器路由協議)， pim(Protocol Independent Multicast， 獨立組播協議， 應用於組播路由器)，ah， esp(nt: ah， 認證頭， esp 安全負載封裝， 這兩者會用在IP包的安全傳輸機制中 )， vrrp(Virtual Router Redundancy Protocol， 虛擬路由器冗餘協議)， udp， or tcp. 由於tcp ， udp 以及icmp是tcpdump 的關鍵字，所以在這些協議名字之前必須要用來進行轉義(如果在C-shell 中需要用\來進行轉義). 注意此表達元不會把資料包中協議頭鏈中所有協議頭內容全部列印出來(nt: 實際上只會列印指定協議的一些頭部資訊， 比如可以用tcpdump -i eth0 'ip proto tcp and host 192.168.3.144'， 則只列印主機192.168.3.144 發出或接收的資料包中tcp 協議頭所包含的資訊)

ip6 proto protocol
如果資料包為ipv6資料包並且其協議型別為protocol， 則與此對應的條件表示式為真.
注意此表達元不會把資料包中協議頭鏈中所有協議頭內容全部列印出來

ip6 protochain protocol
如果資料包為ipv6資料包並且其協議鏈中包含型別為protocol協議頭， 則與此對應的條件表示式為真. 比如，
ip6 protochain 6

將匹配其協議頭鏈中擁有TCP 協議頭的IPv6資料包.此資料包的IPv6頭和TCP頭之間可能還會包含驗證頭， 路由頭， 或者逐跳尋徑選項頭.
由此所觸發的相應BPF(Berkeley Packets Filter， 可理解為， 在資料鏈路層提供資料包過濾的一種機制)程式碼比較繁瑣，並且BPF優化程式碼也未能照顧到此部分， 從而此選項所觸發的包匹配可能會比較慢.

ip protochain protocol
與ip6 protochain protocol 含義相同， 但這用在IPv4資料包.

ether broadcast
如果資料包是乙太網廣播資料包， 則與此對應的條件表示式為真. ether 關鍵字是可選的.

ip broadcast
如果資料包是IPv4廣播資料包， 則與此對應的條件表示式為真. 這將使tcpdump 檢查廣播地址是否符合全0和全1的一些約定，並查詢網路介面的網路掩碼(網路介面為當時在其上抓包的網路介面).

如果抓包所在網路介面的網路掩碼不合法， 或者此介面根本就沒有設定相應網路地址和網路， 亦或是在linux下的'any'網路介面上抓包(此'any'介面可以收到系統中不止一個介面的資料包(nt: 實際上， 可理解為系統中所有可用的介面))，網路掩碼的檢查不能正常進行.

ether multicast
如果資料包是一個乙太網多點廣播資料包(nt: 多點廣播， 可理解為把訊息同時傳遞給一組目的地址， 而不是網路中所有地址，後者為可稱為廣播(broadcast))， 則與此對應的條件表示式為真. 關鍵字ether 可以省略. 此選項的含義與以下條件表示式含義一致:ether[0] & 1 != 0′(nt: 可理解為， 乙太網資料包中第0個位元組的最低位是1， 這意味這是一個多點廣播資料包).

ip multicast
如果資料包是ipv4多點廣播資料包， 則與此對應的條件表示式為真.

ip6 multicast
如果資料包是ipv6多點廣播資料包， 則與此對應的條件表示式為真.

ether proto protocol
如果資料包屬於以下以太協議型別， 則與此對應的條件表示式為真.
協議(protocol)欄位， 可以是數字或以下所列出了名字: ip， ip6， arp， rarp， atalk(AppleTalk網路協議)，aarp(nt: AppleTalk Address Resolution Protocol， AppleTalk網路的地址解析協議)，decnet(nt: 一個由DEC公司所提供的網路協議棧)， sca(nt: 未知， 需補充)，lat(Local Area Transport， 區域傳輸協議， 由DEC公司開發的乙太網主機互聯協議)，mopdl， moprc， iso(nt: 未知， 需補充)， stp(Spanning tree protocol， 生成樹協議， 可用於防止網路中產生連結迴圈)，
ipx（nt: Internetwork Packet Exchange， Novell 網路中使用的網路層協議）， 或者
netbeui(nt: NetBIOS Extended User Interface，可理解為， 網路基本輸入輸出系統介面擴充套件).

protocol欄位可以是一個數字或以下協議名之一:ip， ip6， arp， rarp， atalk， aarp， decnet， sca， lat，mopdl， moprc， iso， stp， ipx， 或者netbeui. 必須要注意的是識別符號也是關鍵字， 從而必須通過”來進行轉義.

(SNAP：子網接入協議 （SubNetwork Access Protocol）)

在光纖分散式資料網路介面(其表達元形式可以是’fddi protocol arp’)， 令牌環網(其表達元形式可以是’tr protocol arp’)，以及IEEE 802.11 無線區域網(其表達元形式可以是’wlan protocol arp’)中， protocol 識別符號來自802.2 邏輯鏈路控制層頭，在FDDI， Token Ring 或 802.1頭中會包含此邏輯鏈路控制層頭.

當以這些網路上的相應的協議標識為過濾條件時， tcpdump只是檢查LLC頭部中以0x000000為組成單元識別符號(OUI， 0x000000
標識一個內部乙太網)的一段’SNAP格式結構’中的protocol ID 域， 而不會管包中是否有一段OUI為0x000000的’SNAP格式
結構'(nt: SNAP， SubNetwork Access Protocol，子網接入協議 ). 以下例外:

iso tcpdump 會檢查LLC頭部中的DSAP域(Destination service Access Point， 目標服務接入點)和SSAP域(源服務接入點).(nt: iso 協議未知， 需補充)

stp 以及 netbeui
tcpdump 將會檢查LLC 頭部中的目標服務接入點(Destination service Access Point);

atalk
tcpdump 將會檢查LLC 頭部中以0x080007 為OUI標識的’SNAP格式結構’， 並會檢查AppleTalk etype域.
(nt: AppleTalk etype 是否位於SNAP格式結構中， 未知， 需補充).

此外， 在乙太網中， 對於ether proto protocol 選項， tcpdump 會為 protocol 所指定的協議檢查乙太網型別域(the Ethernet type field)， 但以下這些協議除外:

iso， stp， and netbeui
tcpdump 將會檢查802.3 物理幀以及LLC 頭(這兩種檢查與FDDI， TR， 802.11網路中的相應檢查一致);
(nt: 802.3， 理解為IEEE 802.3， 其為一系列IEEE 標準的集合. 此集合定義了有線乙太網路中的物理層以及資料
鏈路層的媒體接入控制子層. stp 在上文已有描述)

atalk
tcpdump 將會檢查乙太網物理幀中的AppleTalk etype 域 ，　同時也會檢查資料包中LLC頭部中的’SNAP格式結構’
(這兩種檢查與FDDI， TR， 802.11網路中的相應檢查一致)

aarp tcpdump 將會檢查AppleTalk ARP etype 域， 此域或存在於乙太網物理幀中， 或存在於LLC(由802.2 所定義)的’SNAP格式結構’中， 當為後者時， 該’SNAP格式結構’的OUI標識為0x000000;
(nt: 802.2， 可理解為， IEEE802.2， 其中定義了邏輯鏈路控制層(LLC)， 該層對應於OSI 網路模型中資料鏈路層的上層部分.
LLC 層為使用資料鏈路層的使用者提供了一個統一的介面(通常使用者是網路層). LLC層以下是媒體接入控制層(nt: MAC層，對應於資料鏈路層的下層部分).該層的實現以及工作方式會根據不同物理傳輸媒介的不同而有所區別(比如， 乙太網， 令牌環網，光纖分佈資料介面(nt: 實際可理解為一種光纖網路)， 無線區域網(802.11)， 等等.)

ipx tcpdump 將會檢查物理以太幀中的IPX etype域， LLC頭中的IPX DSAP域，無LLC頭並對IPX進行了封裝的802.3幀，以及LLC 頭部’SNAP格式結構’中的IPX etype 域 (nt | rt: SNAP frame， 可理解為， LLC 頭中的’SNAP格式結構’.該含義屬初步理解階段， 需補充).

decnet src host
如果資料包中DECNET源地址為host， 則與此對應的條件表示式為真.
(nt:decnet， 由Digital Equipment Corporation 開發， 最早用於PDP-11 機器互聯的網路協議)

decnet dst host
如果資料包中DECNET目的地址為host， 則與此對應的條件表示式為真.
(nt: decnet 在上文已有說明)

decnet host host
如果資料包中DECNET目的地址或DECNET源地址為host， 則與此對應的條件表示式為真.
(nt: decnet 在上文已有說明)

ifname interface
如果資料包已被標記為從指定的網路介面中接收的， 則與此對應的條件表示式為真.
(此選項只適用於被OpenBSD中pf程式做過標記的包(nt: pf， packet filter， 可理解為OpenBSD中的防火牆程式))

on interface
與 ifname interface 含義一致.

rnr num
如果資料包已被標記為匹配PF的規則， 則與此對應的條件表示式為真.
(此選項只適用於被OpenBSD中pf程式做過標記的包(nt: pf， packet filter， 可理解為OpenBSD中的防火牆程式))

rulenum num
與 rulenum num 含義一致.

reason code
如果資料包已被標記為包含PF的匹配結果程式碼， 則與此對應的條件表示式為真.有效的結果程式碼有: match， bad-offset，fragment， short， normalize， 以及memory.
(此選項只適用於被OpenBSD中pf程式做過標記的包(nt: pf， packet filter， 可理解為OpenBSD中的防火牆程式))

rset name
如果資料包已被標記為匹配指定的規則集， 則與此對應的條件表示式為真.
(此選項只適用於被OpenBSD中pf程式做過標記的包(nt: pf， packet filter， 可理解為OpenBSD中的防火牆程式))

ruleset name
與 rset name 含義一致.

srnr num
如果資料包已被標記為匹配指定的規則集中的特定規則(nt: specified PF rule number， 特定規則編號， 即特定規則)，則與此對應的條件表示式為真.(此選項只適用於被OpenBSD中pf程式做過標記的包(nt: pf， packet filter， 可理解為OpenBSD中的防火牆程式))

subrulenum num
與 srnr 含義一致.

action act
如果包被記錄時PF會執行act指定的動作， 則與此對應的條件表示式為真. 有效的動作有: pass， block.
(此選項只適用於被OpenBSD中pf程式做過標記的包(nt: pf， packet filter， 可理解為OpenBSD中的防火牆程式))

ip， ip6， arp， rarp， atalk， aarp， decnet， iso， stp， ipx， netbeui
與以下表達元含義一致:
ether proto p
p是以上協議中的一個.

lat， moprc， mopdl
與以下表達元含義一致:
ether proto p
p是以上協議中的一個. 必須要注意的是tcpdump目前還不能分析這些協議.

vlan [vlan_id]
如果資料包為IEEE802.1Q VLAN 資料包， 則與此對應的條件表示式為真.
(nt: IEEE802.1Q VLAN， 即IEEE802.1Q 虛擬網路協議， 此協議用於不同網路的之間的互聯).
如果[vlan_id] 被指定， 則只有資料包含有指定的虛擬網路id(vlan_id)， 則與此對應的條件表示式為真.
要注意的是， 對於VLAN資料包， 在表示式中遇到的第一個vlan關鍵字會改變表示式中接下來關鍵字所對應資料包中資料的開始位置(即解碼偏移). 在VLAN網路體系中過濾資料包時， vlan [vlan_id]表示式可以被多次使用. 關鍵字vlan每出現一次都會增加4位元組過濾偏移(nt: 過濾偏移， 可理解為上面的解碼偏移).

例如:
vlan 100 && vlan 200
表示: 過濾封裝在VLAN100中的VLAN200網路上的資料包
再例如:
vlan && vlan 300 && ip
表示: 過濾封裝在VLAN300 網路中的IPv4資料包， 而VLAN300網路又被更外層的VLAN封裝

mpls [label_num]
如果資料包為MPLS資料包， 則與此對應的條件表示式為真.
(nt: MPLS， Multi-Protocol Label Switch， 多協議標籤交換， 一種在開放的通訊網上利用標籤引導資料傳輸的技術).

如果[label_num] 被指定， 則只有資料包含有指定的標籤id(label_num)， 則與此對應的條件表示式為真.
要注意的是， 對於內含MPLS資訊的IP資料包(即MPLS資料包)， 在表示式中遇到的第一個MPLS關鍵字會改變表示式中接下來關鍵字所對應資料包中資料的開始位置(即解碼偏移). 在MPLS網路體系中過濾資料包時， mpls [label_num]表示式可以被多次使用. 關鍵字mpls每出現一次都會增加4位元組過濾偏移(nt: 過濾偏移， 可理解為上面的解碼偏移).

例如:
mpls 100000 && mpls 1024
表示: 過濾外層標籤為100000 而層標籤為1024的資料包

再如:
mpls && mpls 1024 && host 192.9.200.1
表示: 過濾發往或來自192.9.200.1的資料包， 該資料包的內層標籤為1024， 且擁有一個外層標籤.

pppoed
如果資料包為PPP-over-Ethernet的伺服器探尋資料包(nt: Discovery packet，其ethernet type 為0x8863)，則與此對應的條件表示式為真.
(nt: PPP-over-Ethernet， 點對點乙太網承載協議， 其點對點的連線建立分為Discovery階段(地址發現) 和PPPoE 會話建立階段 ， discovery 資料包就是第一階段發出來的包. ethernet type是以太幀裡的一個欄位，用來指明應用於幀資料欄位的協議)

pppoes
如果資料包為PPP-over-Ethernet會話資料包(nt: ethernet type 為0x8864， PPP-over-Ethernet在上文已有說明， 可搜尋關鍵字’PPP-over-Ethernet’找到其描述)， 則與此對應的條件表示式為真.

要注意的是， 對於PPP-over-Ethernet會話資料包， 在表示式中遇到的第一個pppoes關鍵字會改變表示式中接下來關鍵字所對應資料包中資料的開始位置(即解碼偏移).

例如:
pppoes && ip
表示: 過濾嵌入在PPPoE資料包中的ipv4資料包

tcp， udp， icmp
與以下表達元含義一致:
ip proto p or ip6 proto p
其中p 是以上協議之一(含義分別為: 如果資料包為ipv4或ipv6資料包並且其協議型別為 tcp，udp， 或icmp則與此對應的條件表示式為真)

iso proto protocol
如果資料包的協議型別為iso-osi協議棧中protocol協議， 則與此對應的條件表示式為真.(nt: [初解]iso-osi 網路模型中每層的具體協議與tcp/ip相應層採用的協議不同. iso-osi各層中的具體協議另需補充 )

protocol 可以是一個數字編號， 或以下名字中之一:
clnp， esis， or isis.
(nt: clnp， Connectionless Network Protocol， 這是OSI網路模型中網路層協議 ， esis， isis 未知， 需補充)

clnp， esis， isis
是以下表達的縮寫
iso proto p
其中p 是以上協議之一

l1， l2， iih， lsp， snp， csnp， psnp
為IS-IS PDU 型別 的縮寫.
(nt: IS-IS PDU， Intermediate system to intermediate system Protocol Data Unit， 中間系統到中間系統的協議資料單元. OSI(Open Systems Interconnection)網路由終端系統， 中間系統構成.
終端系統指路由器， 而終端系統指使用者裝置. 路由器形成的本地組稱之為’區域’（Area）和多個區域組成一個’域’（Domain）.
IS-IS 提供域內或區域內的路由. l1， l2， iih， lsp， snp， csnp， psnp 表示PDU的型別， 具體含義另需補充)

vpi n
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ，
如果資料包為ATM資料包， 並且其虛擬路徑標識為n， 則與此對應的條件表示式為真.
(nt: ATM， Asychronous Transfer Mode， 實際上可理解為由ITU-T(國際電信聯盟電信標準化部門)提出的一個與
TCP/IP中IP層功能等同的一系列協議， 具體協議層次另需補充)

vci n
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ，如果資料包為ATM資料包， 並且其虛擬通道標識為n， 則與此對應的條件表示式為真。
(nt: ATM， 在上文已有描述)

lane
如果資料包為ATM LANE 資料包， 則與此對應的條件表示式為真. 要注意的是， 如果是模擬乙太網的LANE資料包或者LANE邏輯單元控制包， 表示式中第一個lane關鍵字會改變表示式中隨後條件的測試. 如果沒有指定lane關鍵字， 條件測試將按照資料包中內含LLC(邏輯鏈路層)的ATM包來進行.

llc
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置。如果資料包為ATM資料包，　並且內含LLC則與此對應的條件表示式為真

oamf4s
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ， 如果資料包為ATM資料包並且是Segment OAM F4 信元(VPI=0 並且 VCI=3)， 則與此對應的條件表示式為真.

(nt: OAM， Operation Administration and Maintenance， 操作管理和維護，可理解為:ATM網路中用於網路管理所產生的ATM信元的分類方式.

ATM網路中傳輸單位為信元， 要傳輸的資料終究會被分割成固定長度(53位元組)的信元，(初理解: 一條物理線路可被複用， 形成虛擬路徑(virtual path). 而一條虛擬路徑再次被複用， 形成虛擬通道(virtual channel)).通訊雙方的編址方式為:虛擬路徑編號(VPI)/虛擬通道編號(VCI)).

OAM F4 flow 信元又可分為segment 類和end-to-end 類， 其區別未知， 需補充.)

oamf4e
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ， 如果資料包為ATM資料包並且是 end-to-end OAM F4 信元(VPI=0 並且 VCI=4)， 則與此對應的條件表示式為真.
(nt: OAM 與 end-to-end OAM F4 在上文已有描述， 可搜尋’oamf4s’來定位)

oamf4
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ， 如果資料包為ATM資料包並且是 end-to-end 或 segment OAM F4 信元(VPI=0 並且 VCI=3 或者 VCI=4)， 則與此對應的條件表示式為真.
(nt: OAM 與 end-to-end OAM F4 在上文已有描述， 可搜尋’oamf4s’來定位)

oam
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ， 如果資料包為ATM資料包並且是 end-to-end 或 segment OAM F4 信元(VPI=0 並且 VCI=3 或者 VCI=4)， 則與此對應的條件表示式為真.
(nt: 此選項與oamf4重複， 需確認)

metac
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ， 如果資料包為ATM資料包並且是來自’元信令線路'(nt: VPI=0 並且 VCI=1， ‘元信令線路’， meta signaling circuit， 具體含義未知， 需補充)，則與此對應的條件表示式為真.

bcc
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ， 如果資料包為ATM資料包並且是來自’廣播信令線路'(nt: VPI=0 並且 VCI=2， ‘廣播信令線路’， broadcast signaling circuit， 具體含義未知， 需補充)，則與此對應的條件表示式為真.

sc
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ， 如果資料包為ATM資料包並且是來自’信令線路'(nt: VPI=0 並且 VCI=5， ‘信令線路’， signaling circuit， 具體含義未知， 需補充)，則與此對應的條件表示式為真.

ilmic
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ， 如果資料包為ATM資料包並且是來自’ILMI線路'(nt: VPI=0 並且 VCI=16， ‘ILMI’， Interim Local Management Interface ， 可理解為基於SNMP(簡易網路管理協議)的用於網路管理的介面)則與此對應的條件表示式為真.

connectmsg

如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ， 如果資料包為ATM資料包，並且是來自’信令線路’並且是Q.2931協議中規定的以下幾種訊息: Setup， Calling Proceeding， Connect，Connect Ack， Release， 或者Release Done. 則與此對應的條件表示式為真。(nt: Q.2931 為ITU(國際電信聯盟)制定的信令協議. 其中規定了在寬頻綜合業務數字網路的使用者介面層建立， 維護， 取消，網路連線的相關步驟。)

metaconnect
如果資料包為ATM資料包， 則與此對應的條件表示式為真. 對於Solaris 作業系統上的SunATM裝置 ， 如果資料包為ATM資料包，並且是來自’元信令線路’並且是Q.2931協議中規定的以下幾種訊息: Setup， Calling Proceeding， Connect，Connect Ack， Release， 或者Release Done. 則與此對應的條件表示式為真.

expr relop expr
如果relop 兩側的運算元(expr)滿足relop 指定的關係， 則與此對應的條件表示式為真。relop 可以是以下關係操作符之一: >， expr 是一個算術表示式. 此表示式中可使用整型常量(表示方式與標準C中一致)， 二進位制操作符(+， -， *， /， &， |，>)， 長度操作符， 以及對特定資料包中資料的引用操作符. 要注意的是， 所有的比較操作都預設運算元是無符號的，例如， 0x80000000 和 0xffffffff 都是大於0的(nt: 對於有符號的比較， 按照補碼規則， 0xffffffff 會小於0). 如果要引用資料包中的資料， 可採用以下表達方式:proto [expr : size]

proto 的取值可以是以下取值之一:ether， fddi， tr， wlan， ppp， slip， link， ip， arp， rarp，tcp， udp， icmp， ip6 或者 radio. 這指明瞭該引用操作所對應的協議層.(ether， fddi， wlan，tr， ppp， slip and link 對應於資料鏈路層， radio 對應於802.11(wlan，無線區域網)某些資料包中的附帶的”radio”頭(nt: 其中描述了波特率， 資料加密等資訊)).

要注意的是， tcp， udp 等上層協議目前只能應用於網路層採用為IPv4或IPv6協議的網路(此限制會在tcpdump未來版本中進行修改). 對於指定協議的所需資料， 其在包資料中的偏移位元組由expr 來指定.

以上表達中size 是可選的， 用來指明我們關注那部分資料段的長度(nt:通常這段資料是資料包的一個域)， 其長度可以是1， 2， 或4個位元組. 如果不給定size， 預設是1個位元組. 長度操作符的關鍵字為len，這程式碼整個資料包的長度.

例如， ‘ether[0] & 1 != 0’ 將會使tcpdump 抓取所有多點廣播資料包.(nt: ether[0]位元組的最低位為1表示
資料包目的地址是多點廣播地址). ‘ip[0] & 0xf != 5’ 對應抓取所有帶有選項的
IPv4資料包. ‘ip[6:2] & 0x1fff = 0’對應抓取沒被破碎的IPv4資料包或者
其片段編號為0的已破碎的IPv4資料包. 這種資料檢查方式也適用於tcp和udp資料的引用，
即， tcp[0]對應於TCP 頭中第一個位元組， 而不是對應任何一箇中間的位元組.

一些偏移以及域的取值除了可以用數字也可用名字來表達. 以下為可用的一些域(協議頭中的域)的名字: icmptype (指ICMP 協議頭
中type域)， icmpcode (指ICMP 協議頭code 域)， 以及tcpflags(指TCP協議頭的flags 域)

以下為ICMP 協議頭中type 域的可用取值:
icmp-echoreply， icmp-unreach， icmp-sourcequench， icmp-redirect， icmp-echo， icmp-routeradvert，icmp-routersolicit， icmp-timx-ceed， icmp-paramprob， icmp-tstamp， icmp-tstampreply，icmp-ireq， icmp-ireqreply， icmp-maskreq， icmp-maskreply

以下為TCP 協議頭中flags 域的可用取值:tcp-fin， tcp-syn， tcp-rst， tcp-push，tcp-ack， tcp-urg.