tcpdump使用
簡介
用簡單的話來定義tcpdump，就是：dump the traffic on a network，根據使用者的定義對網路上的資料包進行截獲的包分析工具。 tcpdump可以將網路中傳送的資料包的“頭”完全截獲下來提供分析。它支援針對網路層、協議、主機、網路或埠的過濾，並提供and、or、not等邏輯語句來幫助你去掉無用的資訊。
實用命令例項
預設啟動
tcpdump
普通情況下，直接啟動tcpdump將監視第一個網路介面上所有流過的資料包。
監視指定網路介面的資料包
tcpdump -i eth1
如果不指定網路卡，預設tcpdump只會監視第一個網路介面，一般是eth0，下面的例子都沒有指定網路介面。
監視指定主機的資料包
列印所有進入或離開sundown的資料包.
tcpdump host sundown
也可以指定ip,例如截獲所有10.10.15.110 的主機收到的和發出的所有的資料包
tcpdump host 10.10.15.110
列印helios 與 hot 或者與 ace 之間通訊的資料包
tcpdump host helios and \( hot or ace \)
截獲主機10.10.15.110 和主機10.10.15.96 或10.10.15.212的通訊
tcpdump host 10.10.15.110 and \ (10.10.15.96 or 10.10.15.212 \)
列印ace與任何其他主機之間通訊的IP 資料包, 但不包括與helios之間的資料包.
tcpdump ip host ace and not helios
如果想要獲取主機10.10.15.110除了和主機10.10.15.96之外所有主機通訊的ip包，使用命令：
tcpdump ip host 10.10.15.110 and ! 10.10.15.96
截獲主機hostname傳送的所有資料
tcpdump -i eth0 src host hostname
監視所有送到主機hostname的資料包
tcpdump -i eth0 dst host hostname
監視指定主機和埠的資料包
如果想要獲取主機10.10.15.110接收或發出的telnet包，使用如下命令
tcpdump tcp port 23 and host 10.10.15.110
對本機的udp 123 埠進行監視 123 為ntp的服務埠
tcpdump udp port 123
監視指定網路的資料包
列印本地主機與Berkeley網路上的主機之間的所有通訊資料包(nt: ucb-ether, 此處可理解為'Berkeley網路'的網路地址,此表示式最原始的含義可表達為: 列印網路地址為ucb-ether的所有資料包)
tcpdump net ucb-ether
列印所有透過閘道器snup的ftp資料包(注意, 表示式被單引號括起來了, 這可以防止shell對其中的括號進行錯誤解析)
tcpdump 'gateway snup and (port ftp or ftp-data)'
列印所有源地址或目標地址是本地主機的IP資料包
(如果本地網路透過閘道器連到了另一網路, 則另一網路並不能算作本地網路.(nt: 此句翻譯曲折,需補充).localnet 實際使用時要真正替換成本地網路的名字)
tcpdump ip and not net localnet
監視指定協議的資料包
列印TCP會話中的的開始和結束資料包, 並且資料包的源或目的不是本地網路上的主機.(nt: localnet, 實際使用時要真正替換成本地網路的名字))
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'
列印所有源或目的埠是80, 網路層協議為IPv4, 並且含有資料,而不是SYN,FIN以及ACK-only等不含資料的資料包.(ipv6的版本的表示式可做練習)
tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
(nt: 可理解為, ip[2:2]表示整個ip資料包的長度, (ip[0]&0xf)<<2)表示ip資料包包頭的長度(ip[0]&0xf代表包中的IHL域, 而此域的單位為32bit, 要換算
成位元組數需要乘以4, 即左移2. (tcp[12]&0xf0)>>4 表示tcp頭的長度, 此域的單位也是32bit, 換算成位元數為 ((tcp[12]&0xf0) >> 4) << ２,
即 ((tcp[12]&0xf0)>>2). ((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0 表示: 整個ip資料包的長度減去ip頭的長度,再減去
tcp頭的長度不為0, 這就意味著, ip資料包中確實是有資料.對於ipv6版本只需考慮ipv6頭中的'Payload Length' 與 'tcp頭的長度'的差值, 並且其中表達方式'ip[]'需換成'ip6[]'.)
列印長度超過576位元組, 並且閘道器地址是snup的IP資料包
tcpdump 'gateway snup and ip[2:2] > 576'
列印所有IP層廣播或多播的資料包， 但不是物理乙太網層的廣播或多播資料包
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
列印除'echo request'或者'echo reply'型別以外的ICMP資料包( 比如,需要列印所有非ping 程式產生的資料包時可用到此表示式 .
(nt: 'echo reuqest' 與 'echo reply' 這兩種型別的ICMP資料包通常由ping程式產生))
tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
tcpdump 與wireshark
Wireshark(以前是ethereal)是Windows下非常簡單易用的抓包工具。但在Linux下很難找到一個好用的圖形化抓包工具。
還好有Tcpdump。我們可以用Tcpdump + Wireshark 的完美組合實現：在 Linux 裡抓包，然後在Windows 裡分析包。
tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap
(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包
tcpdump -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854
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'
(遠端登入)過程開始階段的資料包樣例:
arp who-has csam tell rtsg
arp reply csam is-at CSAM
第一行表示: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的一些選項, 這些選項都用尖括號來表示(如 <mss 1024>).
src, dst 和 flags 這三個域總是會被顯示. 其他域的顯示與否依賴於tcp協議頭裡的資訊.
這是一個從trsg到csam的一個rlogin應用登入的開始階段.
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
第一行表示有一個資料包從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資料包格式的資訊, 以及每個域的含義可以參看 或者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<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: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 傳送了一個會話編號為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 [ -AdDeflLnNOpqRStuUvxX ] [ -c count ]
[ -C file_size ] [ -F file ]
[ -i interface ] [ -m module ] [ -M secret ]
[ -r file ] [ -s snaplen ] [ -T type ] [ -w file ]
[ -W filecount ]
[ -E spi@ipaddr algo:secret,... ]
[ -y datalinktype ] [ -Z user ]
[ expression ]
複製程式碼
tcpdump的簡單選項介紹
複製程式碼
-A 以ASCII碼方式顯示每一個資料包(不會顯示資料包中鏈路層頭部資訊). 在抓取包含網頁資料的資料包時, 可方便檢視資料(nt: 即Handy for capturing web pages).
-c count
tcpdump將在接受到count個資料包後退出.
-C file-size (nt: 此選項用於配合-w file 選項使用)
該選項使得tcpdump 在把原始資料包直接儲存到檔案中之前, 檢查此檔案大小是否超過file-size. 如果超過了, 將關閉此檔案,另創一個檔案繼續用於原始資料包的記錄. 新建立的檔名與-w 選項指定的檔名一致, 但檔名後多了一個數字.該數字會從1開始隨著新建立檔案的增多而增加. file-size的單位是百萬位元組(nt: 這裡指1,000,000個位元組,並非1,048,576個位元組, 後者是以1024位元組為1k, 1024k位元組為1M計算所得, 即1M=1024 ＊ 1024 ＝ 1,048,576)
-d 以容易閱讀的形式,在標準輸出上列印出編排過的包匹配碼, 隨後tcpdump停止.(nt | rt: human readable, 容易閱讀的,通常是指以ascii碼來列印一些資訊. compiled, 編排過的. packet-matching code, 包匹配碼,含義未知, 需補充)
-dd 以C語言的形式列印出包匹配碼.
-ddd 以十進位制數的形式列印出包匹配碼(會在包匹配碼之前有一個附加的'count'字首).
-D 列印系統中所有tcpdump可以在其上進行抓包的網路介面. 每一個介面會列印出數字編號, 相應的介面名字, 以及可能的一個網路介面描述. 其中網路介面名字和數字編號可以用在tcpdump 的-i flag 選項(nt: 把名字或數字代替flag), 來指定要在其上抓包的網路介面.
此選項在不支援介面列表命令的系統上很有用(nt: 比如, Windows 系統, 或缺乏 ifconfig -a 的UNIX系統); 介面的數字編號在windows 2000 或其後的系統中很有用, 因為這些系統上的介面名字比較複雜, 而不易使用.
如果tcpdump編譯時所依賴的libpcap庫太老,-D 選項不會被支援, 因為其中缺乏 pcap_findalldevs()函式.
-e 每行的列印輸出中將包括資料包的資料鏈路層頭部資訊
-E spi@ipaddr algo:secret,...
可透過spi@ipaddr algo:secret 來解密IPsec ESP包(nt | rt:IPsec Encapsulating Security Payload,IPsec 封裝安全負載, IPsec可理解為, 一整套對ip資料包的加密協議, ESP 為整個IP 資料包或其中上層協議部分被加密後的資料,前者的工作模式稱為隧道模式; 後者的工作模式稱為傳輸模式 . 工作原理, 另需補充).
需要注意的是, 在終端啟動tcpdump 時, 可以為IPv4 ESP packets 設定金鑰(secret）.
可用於加密的演算法包括des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, 或者沒有(none).預設的是des-cbc(nt: des, Data Encryption Standard, 資料加密標準, 加密演算法未知, 另需補充).secret 為用於ESP 的金鑰, 使用ASCII 字串方式表達. 如果以 0x 開頭, 該金鑰將以16進位制方式讀入.
該選項中ESP 的定義遵循RFC2406, 而不是 RFC1827. 並且, 此選項只是用來除錯的, 不推薦以真實金鑰(secret)來使用該選項, 因為這樣不安全: 在命令列中輸入的secret 可以被其他人透過ps 等命令檢視到.
除了以上的語法格式(nt: 指spi@ipaddr algo:secret), 還可以在後面新增一個語法輸入檔名字供tcpdump 使用(nt：即把spi@ipaddr algo:secret,... 中...換成一個語法檔名). 此檔案在接受到第一個ESP 包時會開啟此檔案, 所以最好此時把賦予tcpdump 的一些特權取消(nt: 可理解為, 這樣防範之後, 當該檔案為惡意編寫時,不至於造成過大損害).
-f 顯示外部的IPv4 地址時(nt: foreign IPv4 addresses, 可理解為, 非本機ip地址), 採用數字方式而不是名字.(此選項是用來對付Sun公司的NIS伺服器的缺陷(nt: NIS, 網路資訊服務, tcpdump 顯示外部地址的名字時會用到她提供的名稱服務): 此NIS伺服器在查詢非本地地址名字時,常常會陷入無盡的查詢迴圈).
由於對外部(foreign)IPv4地址的測試需要用到本地網路介面(nt: tcpdump 抓包時用到的介面)及其IPv4 地址和網路掩碼. 如果此地址或網路掩碼不可用, 或者此介面根本就沒有設定相應網路地址和網路掩碼(nt: linux 下的 'any' 網路介面就不需要設定地址和掩碼, 不過此'any'介面可以收到系統中所有介面的資料包), 該選項不能正常工作.
-F file
使用file 檔案作為過濾條件表示式的輸入, 此時命令列上的輸入將被忽略.
-i interface
指定tcpdump 需要監聽的介面. 如果沒有指定, tcpdump 會從系統介面列表中搜尋編號最小的已配置好的介面(不包括 loopback 介面).一但找到第一個符合條件的介面, 搜尋馬上結束.
在採用2.2版本或之後版本核心的Linux 作業系統上, 'any' 這個虛擬網路介面可被用來接收所有網路介面上的資料包(nt: 這會包括目的是該網路介面的, 也包括目的不是該網路介面的). 需要注意的是如果真實網路介面不能工作在'混雜'模式(promiscuous)下,則無法在'any'這個虛擬的網路介面上抓取其資料包.
如果 -D 標誌被指定, tcpdump會列印系統中的介面編號，而該編號就可用於此處的interface 引數.
-l 對標準輸出進行行緩衝(nt: 使標準輸出裝置遇到一個換行符就馬上把這行的內容列印出來).在需要同時觀察抓包列印以及儲存抓包記錄的時候很有用. 比如, 可透過以下命令組合來達到此目的:
``tcpdump -l | tee dat'' 或者 ``tcpdump -l > dat & tail -f dat''.(nt: 前者使用tee來把tcpdump 的輸出同時放到檔案dat和標準輸出中, 而後者透過重定向操作'>', 把tcpdump的輸出放到dat 檔案中, 同時透過tail把dat檔案中的內容放到標準輸出中)
-L 列出指定網路介面所支援的資料鏈路層的型別後退出.(nt: 指定介面透過-i 來指定)
-m module
透過module 指定的file 裝載SMI MIB 模組(nt: SMI，Structure of Management Information, 管理資訊結構MIB, Management Information Base, 管理資訊庫. 可理解為, 這兩者用於SNMP(Simple Network Management Protoco)協議資料包的抓取. 具體SNMP 的工作原理未知, 另需補充).
此選項可多次使用, 從而為tcpdump 裝載不同的MIB 模組.
-M secret 如果TCP 資料包(TCP segments)有TCP-MD5選項(在RFC 2385有相關描述), 則為其摘要的驗證指定一個公共的金鑰secret.
-n 不對地址(比如, 主機地址, 埠號)進行數字表示到名字表示的轉換.
-N 不列印出host 的域名部分. 比如, 如果設定了此選現, tcpdump 將會列印'nic' 而不是 'nic.ddn.mil'.
-O 不啟用進行包匹配時所用的最佳化程式碼. 當懷疑某些bug是由最佳化程式碼引起的, 此選項將很有用.
-p 一般情況下, 把網路介面設定為非'混雜'模式. 但必須注意 , 在特殊情況下此網路介面還是會以'混雜'模式來工作； 從而, '-p' 的設與不設, 不能當做以下選現的代名詞:'ether host {local-hw-add}' 或 'ether broadcast'(nt: 前者表示只匹配乙太網地址為host 的包, 後者表示匹配乙太網地址為廣播地址的資料包).
-q 快速(也許用'安靜'更好?)列印輸出. 即列印很少的協議相關資訊, 從而輸出行都比較簡短.
-R 設定tcpdump 對 ESP/AH 資料包的解析按照 RFC1825而不是RFC1829(nt: AH, 認證頭, ESP， 安全負載封裝, 這兩者會用在IP包的安全傳輸機制中). 如果此選項被設定, tcpdump 將不會列印出'禁止中繼'域(nt: relay prevention field). 另外,由於ESP/AH規範中沒有規定ESP/AH資料包必須擁有協議版本號域,所以tcpdump不能從收到的ESP/AH資料包中推匯出協議版本號.
-r file
從檔案file 中讀取包資料. 如果file 欄位為 '-' 符號, 則tcpdump 會從標準輸入中讀取包資料.
-S 列印TCP 資料包的順序號時, 使用絕對的順序號, 而不是相對的順序號.(nt: 相對順序號可理解為, 相對第一個TCP 包順序號的差距,比如, 接受方收到第一個資料包的絕對順序號為232323, 對於後來接收到的第2個,第3個資料包, tcpdump會列印其序列號為1, 2分別表示與第一個資料包的差距為1 和 2. 而如果此時-S 選項被設定, 對於後來接收到的第2個, 第3個資料包會列印出其絕對順序號:232324, 232325).
-s snaplen
設定tcpdump的資料包抓取長度為snaplen, 如果不設定預設將會是68位元組(而支援網路介面分接頭(nt: NIT, 上文已有描述,可搜尋'網路介面分接頭'關鍵字找到那裡)的SunOS系列作業系統中預設的也是最小值是96).68位元組對於IP, ICMP(nt: Internet Control Message Protocol,因特網控制報文協議), TCP 以及 UDP 協議的報文已足夠, 但對於名稱服務(nt: 可理解為dns, nis等服務), NFS服務相關的資料包會產生包截短. 如果產生包截短這種情況, tcpdump的相應列印輸出行中會出現''[|proto]''的標誌（proto 實際會顯示為被截短的資料包的相關協議層次). 需要注意的是, 採用長的抓取長度(nt: snaplen比較大), 會增加包的處理時間, 並且會減少tcpdump 可快取的資料包的數量， 從而會導致資料包的丟失. 所以, 在能抓取我們想要的包的前提下, 抓取長度越小越好.把snaplen 設定為0 意味著讓tcpdump自動選擇合適的長度來抓取資料包.
-T type
強制tcpdump按type指定的協議所描述的包結構來分析收到的資料包. 目前已知的type 可取的協議為:
aodv (Ad-hoc On-demand Distance Vector protocol, 按需距離向量路由協議, 在Ad hoc(點對點模式)網路中使用),
cnfp (Cisco NetFlow protocol), rpc(Remote Procedure Call), rtp (Real-Time Applications protocol),
rtcp (Real-Time Applications con-trol protocol), snmp (Simple Network Management Protocol),
tftp (Trivial File Transfer Protocol, 碎檔案協議), vat (Visual Audio Tool, 可用於在internet 上進行電
視電話會議的應用層協議), 以及wb (distributed White Board, 可用於網路會議的應用層協議).
-t 在每行輸出中不列印時間戳
-tt 不對每行輸出的時間進行格式處理(nt: 這種格式一眼可能看不出其含義, 如時間戳列印成1261798315)
-ttt tcpdump 輸出時, 每兩行列印之間會延遲一個段時間(以毫秒為單位)
-tttt 在每行列印的時間戳之前新增日期的列印
-u 列印出未加密的NFS 控制程式碼(nt: handle可理解為NFS 中使用的檔案控制程式碼, 這將包括資料夾和資料夾中的檔案)
-U 使得當tcpdump在使用-w 選項時, 其檔案寫入與包的儲存同步.(nt: 即, 當每個資料包被儲存時, 它將及時被寫入檔案中,而不是等檔案的輸出緩衝已滿時才真正寫入此檔案)
-U 標誌在老版本的libcap庫(nt: tcpdump 所依賴的報文捕獲庫)上不起作用, 因為其中缺乏pcap_cump_flush()函式.
-v 當分析和列印的時候, 產生詳細的輸出. 比如, 包的生存時間, 標識, 總長度以及IP包的一些選項. 這也會開啟一些附加的包完整性檢測, 比如對IP或ICMP包頭部的校驗和.
-vv 產生比-v更詳細的輸出. 比如, NFS回應包中的附加域將會被列印, SMB資料包也會被完全解碼.
-vvv 產生比-vv更詳細的輸出. 比如, telent 時所使用的SB, SE 選項將會被列印, 如果telnet同時使用的是圖形介面,
其相應的圖形選項將會以16進位制的方式列印出來(nt: telnet 的SB,SE選項含義未知, 另需補充).
-w 把包資料直接寫入檔案而不進行分析和列印輸出. 這些包資料可在隨後透過-r 選項來重新讀入並進行分析和列印.
-W filecount
此選項與-C 選項配合使用, 這將限制可開啟的檔案數目, 並且當檔案資料超過這裡設定的限制時, 依次迴圈替代之前的檔案, 這相當於一個擁有filecount 個檔案的檔案緩衝池. 同時, 該選項會使得每個檔名的開頭會出現足夠多並用來佔位的0, 這可以方便這些檔案被正確的排序.
-x 當分析和列印時, tcpdump 會列印每個包的頭部資料, 同時會以16進位制列印出每個包的資料(但不包括連線層的頭部).總共列印的資料大小不會超過整個資料包的大小與snaplen 中的最小值. 必須要注意的是, 如果高層協議資料沒有snaplen 這麼長,並且資料鏈路層(比如, Ethernet層)有填充資料, 則這些填充資料也會被列印.(nt: so for link layers that pad, 未能銜接理解和翻譯, 需補充 )
-xx tcpdump 會列印每個包的頭部資料, 同時會以16進位制列印出每個包的資料, 其中包括資料鏈路層的頭部.
-X 當分析和列印時, tcpdump 會列印每個包的頭部資料, 同時會以16進位制和ASCII碼形式列印出每個包的資料(但不包括連線層的頭部).這對於分析一些新協議的資料包很方便.
-XX 當分析和列印時, tcpdump 會列印每個包的頭部資料, 同時會以16進位制和ASCII碼形式列印出每個包的資料, 其中包括資料鏈路層的頭部.這對於分析一些新協議的資料包很方便.
-y datalinktype
設定tcpdump 只捕獲資料鏈路層協議型別是datalinktype的資料包
-Z user
使tcpdump 放棄自己的超級許可權(如果以root使用者啟動tcpdump, tcpdump將會有超級使用者許可權), 並把當前tcpdump的使用者ID設定為user, 組ID設定為user首要所屬組的ID(nt: tcpdump 此處可理解為tcpdump 執行之後對應的程式)
此選項也可在編譯的時候被設定為預設開啟.(nt: 此時user 的取值未知, 需補充)
複製程式碼
tcpdump條件表示式
該表示式用於決定哪些資料包將被列印. 如果不給定條件表示式, 網路上所有被捕獲的包都會被列印,否則, 只有滿足條件表示式的資料包被列印.(nt: all packets, 可理解為, 所有被指定介面捕獲的資料包).
表示式由一個或多個'表達元'組成(nt: primitive, 表達元, 可理解為組成表示式的基本元素). 一個表達元通常由一個或多個修飾符(qualifiers)後跟一個名字或數字表示的id組成(nt: 即, 'qualifiers id').有三種不同型別的修飾符:type, dir以及 proto.
複製程式碼
type 修飾符指定id 所代表的物件型別, id可以是名字也可以是數字. 可選的物件型別有: host, net, port 以及portrange(nt: host 表明id表示主機, net 表明id是網路, port 表明id是端而portrange 表明id 是一個埠範圍). 如, 'host foo', 'net 128.3', 'port 20', 'portrange 6000-6008'(nt: 分別表示主機 foo,網路 128.3, 埠 20, 埠範圍 6000-6008). 如果不指定type 修飾符, id預設的修飾符為host.
dir 修飾符描述id 所對應的傳輸方向, 即發往id 還是從id 接收（nt: 而id 到底指什麼需要看其前面的type 修飾符）.可取的方向為: src, dst, src 或 dst, src並且dst.(nt:分別表示, id是傳輸源, id是傳輸目的, id是傳輸源或者傳輸目的, id是傳輸源並且是傳輸目的). 例如, 'src foo','dst net 128.3', 'src or dst port ftp-data'.(nt: 分別表示符合條件的資料包中, 源主機是foo, 目的網路是128.3, 源或目的埠為 ftp-data).如果不指定dir修飾符, id 預設的修飾符為src 或 dst.對於鏈路層的協議,比如SLIP(nt: Serial Line InternetProtocol, 串聯線路網際網路協議), 以及linux下指定'any' 裝置, 並指定'cooked'(nt | rt: cooked 含義未知, 需補充) 抓取型別, 或其他裝置型別,可以用'inbound' 和 'outbount' 修飾符來指定想要的傳輸方向.
proto 修飾符描述id 所屬的協議. 可選的協議有: ether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, tcp以及 upd.(nt | rt: ether, fddi, tr, 具體含義未知, 需補充. 可理解為物理乙太網傳輸協議, 光纖分佈資料網傳輸協議,以及用於路由跟蹤的協議. wlan, 無線區域網協議; ip,ip6 即通常的TCP/IP協議棧中所使用的ipv4以及ipv6網路層協議;arp, rarp 即地址解析協議,反向地址解析協議; decnet, Digital Equipment Corporation開發的, 最早用於PDP-11 機器互聯的網路協議; tcp and udp, 即通常TCP/IP協議棧中的兩個傳輸層協議).
例如, `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange 7000-7009'分別表示 '從乙太網地址foo 來的資料包','發往或來自128.3網路的arp協議資料包', '傳送或接收埠為21的tcp協議資料包', '傳送或接收埠範圍為7000-7009的udp協議資料包'.
如果不指定proto 修飾符, 則預設為與相應type匹配的修飾符. 例如, 'src foo' 含義是 '(ip or arp or rarp) src foo' (nt: 即, 來自主機foo的ip/arp/rarp協議資料包, 預設type為host),`net bar' 含義是`(ip or arp or rarp) net bar'(nt: 即, 來自或發往bar網路的ip/arp/rarp協議資料包),`port 53' 含義是 `(tcp or udp) port 53'(nt: 即, 傳送或接收埠為53的tcp/udp協議資料包).(nt: 由於tcpdump 直接透過資料鏈路層的 BSD 資料包過濾器或 DLPI(datalink provider interface, 資料鏈層提供者介面)來直接獲得網路資料包, 其可抓取的資料包可涵蓋上層的各種協議, 包括arp, rarp, icmp(因特網控制報文協議),ip, ip6, tcp, udp, sctp(流控制傳輸協議).
對於修飾符後跟id 的格式,可理解為, type id 是對包最基本的過濾條件: 即對包相關的主機, 網路, 埠的限制;dir 表示對包的傳送方向的限制; proto表示對包相關的協議限制)
'fddi'(nt: Fiber Distributed Data Interface) 實際上與'ether' 含義一樣: tcpdump 會把他們當作一種''指定網路介面上的資料鏈路層協議''. 如同ehter網(乙太網), FDDI 的頭部通常也會有源, 目的, 以及包型別, 從而可以像ether網資料包一樣對這些域進行過濾. 此外, FDDI 頭部還有其他的域, 但不能被放到表示式中用來過濾
同樣, 'tr' 和 'wlan' 也和 'ether' 含義一致, 上一段對fddi 的描述同樣適用於tr(Token Ring) 和wlan(802.11 wireless LAN)的頭部. 對於802.11 協議資料包的頭部, 目的域稱為DA, 源域稱為 SA;而其中的 BSSID, RA, TA 域(nt | rt: 具體含義需補充)不會被檢測(nt: 不能被用於包過慮表示式中).
複製程式碼
除以上所描述的表達元('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指令碼或終端中使用時必須對括號進行轉義, 即'(' 與')'需要分別表達成'\(' 與 '\)').
有效的運算子有:
否定操作 (`!' 或 `not')
與操作(`&&' 或 `and')
或操作(`||' 或 `or')
否定運算子的優先順序別最高. 與操作和或操作優先順序別相同, 並且二者的結合順序是從左到右. 要注意的是, 表達'與操作'時,
需要顯式寫出'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 <= length' 的含義一致.
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.
用簡單的話來定義tcpdump，就是：dump the traffic on a network，根據使用者的定義對網路上的資料包進行截獲的包分析工具。 tcpdump可以將網路中傳送的資料包的“頭”完全截獲下來提供分析。它支援針對網路層、協議、主機、網路或埠的過濾，並提供and、or、not等邏輯語句來幫助你去掉無用的資訊。
實用命令例項
預設啟動
tcpdump
普通情況下，直接啟動tcpdump將監視第一個網路介面上所有流過的資料包。
監視指定網路介面的資料包
tcpdump -i eth1
如果不指定網路卡，預設tcpdump只會監視第一個網路介面，一般是eth0，下面的例子都沒有指定網路介面。
監視指定主機的資料包
列印所有進入或離開sundown的資料包.
tcpdump host sundown
也可以指定ip,例如截獲所有10.10.15.110 的主機收到的和發出的所有的資料包
tcpdump host 10.10.15.110
列印helios 與 hot 或者與 ace 之間通訊的資料包
tcpdump host helios and \( hot or ace \)
截獲主機10.10.15.110 和主機10.10.15.96 或10.10.15.212的通訊
tcpdump host 10.10.15.110 and \ (10.10.15.96 or 10.10.15.212 \)
列印ace與任何其他主機之間通訊的IP 資料包, 但不包括與helios之間的資料包.
tcpdump ip host ace and not helios
如果想要獲取主機10.10.15.110除了和主機10.10.15.96之外所有主機通訊的ip包，使用命令：
tcpdump ip host 10.10.15.110 and ! 10.10.15.96
截獲主機hostname傳送的所有資料
tcpdump -i eth0 src host hostname
監視所有送到主機hostname的資料包
tcpdump -i eth0 dst host hostname
監視指定主機和埠的資料包
如果想要獲取主機10.10.15.110接收或發出的telnet包，使用如下命令
tcpdump tcp port 23 and host 10.10.15.110
對本機的udp 123 埠進行監視 123 為ntp的服務埠
tcpdump udp port 123
監視指定網路的資料包
列印本地主機與Berkeley網路上的主機之間的所有通訊資料包(nt: ucb-ether, 此處可理解為'Berkeley網路'的網路地址,此表示式最原始的含義可表達為: 列印網路地址為ucb-ether的所有資料包)
tcpdump net ucb-ether
列印所有透過閘道器snup的ftp資料包(注意, 表示式被單引號括起來了, 這可以防止shell對其中的括號進行錯誤解析)
tcpdump 'gateway snup and (port ftp or ftp-data)'
列印所有源地址或目標地址是本地主機的IP資料包
(如果本地網路透過閘道器連到了另一網路, 則另一網路並不能算作本地網路.(nt: 此句翻譯曲折,需補充).localnet 實際使用時要真正替換成本地網路的名字)
tcpdump ip and not net localnet
監視指定協議的資料包
列印TCP會話中的的開始和結束資料包, 並且資料包的源或目的不是本地網路上的主機.(nt: localnet, 實際使用時要真正替換成本地網路的名字))
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'
列印所有源或目的埠是80, 網路層協議為IPv4, 並且含有資料,而不是SYN,FIN以及ACK-only等不含資料的資料包.(ipv6的版本的表示式可做練習)
tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
(nt: 可理解為, ip[2:2]表示整個ip資料包的長度, (ip[0]&0xf)<<2)表示ip資料包包頭的長度(ip[0]&0xf代表包中的IHL域, 而此域的單位為32bit, 要換算
成位元組數需要乘以4, 即左移2. (tcp[12]&0xf0)>>4 表示tcp頭的長度, 此域的單位也是32bit, 換算成位元數為 ((tcp[12]&0xf0) >> 4) << ２,
即 ((tcp[12]&0xf0)>>2). ((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0 表示: 整個ip資料包的長度減去ip頭的長度,再減去
tcp頭的長度不為0, 這就意味著, ip資料包中確實是有資料.對於ipv6版本只需考慮ipv6頭中的'Payload Length' 與 'tcp頭的長度'的差值, 並且其中表達方式'ip[]'需換成'ip6[]'.)
列印長度超過576位元組, 並且閘道器地址是snup的IP資料包
tcpdump 'gateway snup and ip[2:2] > 576'
列印所有IP層廣播或多播的資料包， 但不是物理乙太網層的廣播或多播資料包
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
列印除'echo request'或者'echo reply'型別以外的ICMP資料包( 比如,需要列印所有非ping 程式產生的資料包時可用到此表示式 .
(nt: 'echo reuqest' 與 'echo reply' 這兩種型別的ICMP資料包通常由ping程式產生))
tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
tcpdump 與wireshark
Wireshark(以前是ethereal)是Windows下非常簡單易用的抓包工具。但在Linux下很難找到一個好用的圖形化抓包工具。
還好有Tcpdump。我們可以用Tcpdump + Wireshark 的完美組合實現：在 Linux 裡抓包，然後在Windows 裡分析包。
tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap
(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包
tcpdump -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854
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'
(遠端登入)過程開始階段的資料包樣例:
arp who-has csam tell rtsg
arp reply csam is-at CSAM
第一行表示: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的一些選項, 這些選項都用尖括號來表示(如 <mss 1024>).
src, dst 和 flags 這三個域總是會被顯示. 其他域的顯示與否依賴於tcp協議頭裡的資訊.
這是一個從trsg到csam的一個rlogin應用登入的開始階段.
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
第一行表示有一個資料包從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資料包格式的資訊, 以及每個域的含義可以參看 或者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<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: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 傳送了一個會話編號為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 [ -AdDeflLnNOpqRStuUvxX ] [ -c count ]
[ -C file_size ] [ -F file ]
[ -i interface ] [ -m module ] [ -M secret ]
[ -r file ] [ -s snaplen ] [ -T type ] [ -w file ]
[ -W filecount ]
[ -E spi@ipaddr algo:secret,... ]
[ -y datalinktype ] [ -Z user ]
[ expression ]
複製程式碼
tcpdump的簡單選項介紹
複製程式碼
-A 以ASCII碼方式顯示每一個資料包(不會顯示資料包中鏈路層頭部資訊). 在抓取包含網頁資料的資料包時, 可方便檢視資料(nt: 即Handy for capturing web pages).
-c count
tcpdump將在接受到count個資料包後退出.
-C file-size (nt: 此選項用於配合-w file 選項使用)
該選項使得tcpdump 在把原始資料包直接儲存到檔案中之前, 檢查此檔案大小是否超過file-size. 如果超過了, 將關閉此檔案,另創一個檔案繼續用於原始資料包的記錄. 新建立的檔名與-w 選項指定的檔名一致, 但檔名後多了一個數字.該數字會從1開始隨著新建立檔案的增多而增加. file-size的單位是百萬位元組(nt: 這裡指1,000,000個位元組,並非1,048,576個位元組, 後者是以1024位元組為1k, 1024k位元組為1M計算所得, 即1M=1024 ＊ 1024 ＝ 1,048,576)
-d 以容易閱讀的形式,在標準輸出上列印出編排過的包匹配碼, 隨後tcpdump停止.(nt | rt: human readable, 容易閱讀的,通常是指以ascii碼來列印一些資訊. compiled, 編排過的. packet-matching code, 包匹配碼,含義未知, 需補充)
-dd 以C語言的形式列印出包匹配碼.
-ddd 以十進位制數的形式列印出包匹配碼(會在包匹配碼之前有一個附加的'count'字首).
-D 列印系統中所有tcpdump可以在其上進行抓包的網路介面. 每一個介面會列印出數字編號, 相應的介面名字, 以及可能的一個網路介面描述. 其中網路介面名字和數字編號可以用在tcpdump 的-i flag 選項(nt: 把名字或數字代替flag), 來指定要在其上抓包的網路介面.
此選項在不支援介面列表命令的系統上很有用(nt: 比如, Windows 系統, 或缺乏 ifconfig -a 的UNIX系統); 介面的數字編號在windows 2000 或其後的系統中很有用, 因為這些系統上的介面名字比較複雜, 而不易使用.
如果tcpdump編譯時所依賴的libpcap庫太老,-D 選項不會被支援, 因為其中缺乏 pcap_findalldevs()函式.
-e 每行的列印輸出中將包括資料包的資料鏈路層頭部資訊
-E spi@ipaddr algo:secret,...
可透過spi@ipaddr algo:secret 來解密IPsec ESP包(nt | rt:IPsec Encapsulating Security Payload,IPsec 封裝安全負載, IPsec可理解為, 一整套對ip資料包的加密協議, ESP 為整個IP 資料包或其中上層協議部分被加密後的資料,前者的工作模式稱為隧道模式; 後者的工作模式稱為傳輸模式 . 工作原理, 另需補充).
需要注意的是, 在終端啟動tcpdump 時, 可以為IPv4 ESP packets 設定金鑰(secret）.
可用於加密的演算法包括des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, 或者沒有(none).預設的是des-cbc(nt: des, Data Encryption Standard, 資料加密標準, 加密演算法未知, 另需補充).secret 為用於ESP 的金鑰, 使用ASCII 字串方式表達. 如果以 0x 開頭, 該金鑰將以16進位制方式讀入.
該選項中ESP 的定義遵循RFC2406, 而不是 RFC1827. 並且, 此選項只是用來除錯的, 不推薦以真實金鑰(secret)來使用該選項, 因為這樣不安全: 在命令列中輸入的secret 可以被其他人透過ps 等命令檢視到.
除了以上的語法格式(nt: 指spi@ipaddr algo:secret), 還可以在後面新增一個語法輸入檔名字供tcpdump 使用(nt：即把spi@ipaddr algo:secret,... 中...換成一個語法檔名). 此檔案在接受到第一個ESP 包時會開啟此檔案, 所以最好此時把賦予tcpdump 的一些特權取消(nt: 可理解為, 這樣防範之後, 當該檔案為惡意編寫時,不至於造成過大損害).
-f 顯示外部的IPv4 地址時(nt: foreign IPv4 addresses, 可理解為, 非本機ip地址), 採用數字方式而不是名字.(此選項是用來對付Sun公司的NIS伺服器的缺陷(nt: NIS, 網路資訊服務, tcpdump 顯示外部地址的名字時會用到她提供的名稱服務): 此NIS伺服器在查詢非本地地址名字時,常常會陷入無盡的查詢迴圈).
由於對外部(foreign)IPv4地址的測試需要用到本地網路介面(nt: tcpdump 抓包時用到的介面)及其IPv4 地址和網路掩碼. 如果此地址或網路掩碼不可用, 或者此介面根本就沒有設定相應網路地址和網路掩碼(nt: linux 下的 'any' 網路介面就不需要設定地址和掩碼, 不過此'any'介面可以收到系統中所有介面的資料包), 該選項不能正常工作.
-F file
使用file 檔案作為過濾條件表示式的輸入, 此時命令列上的輸入將被忽略.
-i interface
指定tcpdump 需要監聽的介面. 如果沒有指定, tcpdump 會從系統介面列表中搜尋編號最小的已配置好的介面(不包括 loopback 介面).一但找到第一個符合條件的介面, 搜尋馬上結束.
在採用2.2版本或之後版本核心的Linux 作業系統上, 'any' 這個虛擬網路介面可被用來接收所有網路介面上的資料包(nt: 這會包括目的是該網路介面的, 也包括目的不是該網路介面的). 需要注意的是如果真實網路介面不能工作在'混雜'模式(promiscuous)下,則無法在'any'這個虛擬的網路介面上抓取其資料包.
如果 -D 標誌被指定, tcpdump會列印系統中的介面編號，而該編號就可用於此處的interface 引數.
-l 對標準輸出進行行緩衝(nt: 使標準輸出裝置遇到一個換行符就馬上把這行的內容列印出來).在需要同時觀察抓包列印以及儲存抓包記錄的時候很有用. 比如, 可透過以下命令組合來達到此目的:
``tcpdump -l | tee dat'' 或者 ``tcpdump -l > dat & tail -f dat''.(nt: 前者使用tee來把tcpdump 的輸出同時放到檔案dat和標準輸出中, 而後者透過重定向操作'>', 把tcpdump的輸出放到dat 檔案中, 同時透過tail把dat檔案中的內容放到標準輸出中)
-L 列出指定網路介面所支援的資料鏈路層的型別後退出.(nt: 指定介面透過-i 來指定)
-m module
透過module 指定的file 裝載SMI MIB 模組(nt: SMI，Structure of Management Information, 管理資訊結構MIB, Management Information Base, 管理資訊庫. 可理解為, 這兩者用於SNMP(Simple Network Management Protoco)協議資料包的抓取. 具體SNMP 的工作原理未知, 另需補充).
此選項可多次使用, 從而為tcpdump 裝載不同的MIB 模組.
-M secret 如果TCP 資料包(TCP segments)有TCP-MD5選項(在RFC 2385有相關描述), 則為其摘要的驗證指定一個公共的金鑰secret.
-n 不對地址(比如, 主機地址, 埠號)進行數字表示到名字表示的轉換.
-N 不列印出host 的域名部分. 比如, 如果設定了此選現, tcpdump 將會列印'nic' 而不是 'nic.ddn.mil'.
-O 不啟用進行包匹配時所用的最佳化程式碼. 當懷疑某些bug是由最佳化程式碼引起的, 此選項將很有用.
-p 一般情況下, 把網路介面設定為非'混雜'模式. 但必須注意 , 在特殊情況下此網路介面還是會以'混雜'模式來工作； 從而, '-p' 的設與不設, 不能當做以下選現的代名詞:'ether host {local-hw-add}' 或 'ether broadcast'(nt: 前者表示只匹配乙太網地址為host 的包, 後者表示匹配乙太網地址為廣播地址的資料包).
-q 快速(也許用'安靜'更好?)列印輸出. 即列印很少的協議相關資訊, 從而輸出行都比較簡短.
-R 設定tcpdump 對 ESP/AH 資料包的解析按照 RFC1825而不是RFC1829(nt: AH, 認證頭, ESP， 安全負載封裝, 這兩者會用在IP包的安全傳輸機制中). 如果此選項被設定, tcpdump 將不會列印出'禁止中繼'域(nt: relay prevention field). 另外,由於ESP/AH規範中沒有規定ESP/AH資料包必須擁有協議版本號域,所以tcpdump不能從收到的ESP/AH資料包中推匯出協議版本號.
-r file
從檔案file 中讀取包資料. 如果file 欄位為 '-' 符號, 則tcpdump 會從標準輸入中讀取包資料.
-S 列印TCP 資料包的順序號時, 使用絕對的順序號, 而不是相對的順序號.(nt: 相對順序號可理解為, 相對第一個TCP 包順序號的差距,比如, 接受方收到第一個資料包的絕對順序號為232323, 對於後來接收到的第2個,第3個資料包, tcpdump會列印其序列號為1, 2分別表示與第一個資料包的差距為1 和 2. 而如果此時-S 選項被設定, 對於後來接收到的第2個, 第3個資料包會列印出其絕對順序號:232324, 232325).
-s snaplen
設定tcpdump的資料包抓取長度為snaplen, 如果不設定預設將會是68位元組(而支援網路介面分接頭(nt: NIT, 上文已有描述,可搜尋'網路介面分接頭'關鍵字找到那裡)的SunOS系列作業系統中預設的也是最小值是96).68位元組對於IP, ICMP(nt: Internet Control Message Protocol,因特網控制報文協議), TCP 以及 UDP 協議的報文已足夠, 但對於名稱服務(nt: 可理解為dns, nis等服務), NFS服務相關的資料包會產生包截短. 如果產生包截短這種情況, tcpdump的相應列印輸出行中會出現''[|proto]''的標誌（proto 實際會顯示為被截短的資料包的相關協議層次). 需要注意的是, 採用長的抓取長度(nt: snaplen比較大), 會增加包的處理時間, 並且會減少tcpdump 可快取的資料包的數量， 從而會導致資料包的丟失. 所以, 在能抓取我們想要的包的前提下, 抓取長度越小越好.把snaplen 設定為0 意味著讓tcpdump自動選擇合適的長度來抓取資料包.
-T type
強制tcpdump按type指定的協議所描述的包結構來分析收到的資料包. 目前已知的type 可取的協議為:
aodv (Ad-hoc On-demand Distance Vector protocol, 按需距離向量路由協議, 在Ad hoc(點對點模式)網路中使用),
cnfp (Cisco NetFlow protocol), rpc(Remote Procedure Call), rtp (Real-Time Applications protocol),
rtcp (Real-Time Applications con-trol protocol), snmp (Simple Network Management Protocol),
tftp (Trivial File Transfer Protocol, 碎檔案協議), vat (Visual Audio Tool, 可用於在internet 上進行電
視電話會議的應用層協議), 以及wb (distributed White Board, 可用於網路會議的應用層協議).
-t 在每行輸出中不列印時間戳
-tt 不對每行輸出的時間進行格式處理(nt: 這種格式一眼可能看不出其含義, 如時間戳列印成1261798315)
-ttt tcpdump 輸出時, 每兩行列印之間會延遲一個段時間(以毫秒為單位)
-tttt 在每行列印的時間戳之前新增日期的列印
-u 列印出未加密的NFS 控制程式碼(nt: handle可理解為NFS 中使用的檔案控制程式碼, 這將包括資料夾和資料夾中的檔案)
-U 使得當tcpdump在使用-w 選項時, 其檔案寫入與包的儲存同步.(nt: 即, 當每個資料包被儲存時, 它將及時被寫入檔案中,而不是等檔案的輸出緩衝已滿時才真正寫入此檔案)
-U 標誌在老版本的libcap庫(nt: tcpdump 所依賴的報文捕獲庫)上不起作用, 因為其中缺乏pcap_cump_flush()函式.
-v 當分析和列印的時候, 產生詳細的輸出. 比如, 包的生存時間, 標識, 總長度以及IP包的一些選項. 這也會開啟一些附加的包完整性檢測, 比如對IP或ICMP包頭部的校驗和.
-vv 產生比-v更詳細的輸出. 比如, NFS回應包中的附加域將會被列印, SMB資料包也會被完全解碼.
-vvv 產生比-vv更詳細的輸出. 比如, telent 時所使用的SB, SE 選項將會被列印, 如果telnet同時使用的是圖形介面,
其相應的圖形選項將會以16進位制的方式列印出來(nt: telnet 的SB,SE選項含義未知, 另需補充).
-w 把包資料直接寫入檔案而不進行分析和列印輸出. 這些包資料可在隨後透過-r 選項來重新讀入並進行分析和列印.
-W filecount
此選項與-C 選項配合使用, 這將限制可開啟的檔案數目, 並且當檔案資料超過這裡設定的限制時, 依次迴圈替代之前的檔案, 這相當於一個擁有filecount 個檔案的檔案緩衝池. 同時, 該選項會使得每個檔名的開頭會出現足夠多並用來佔位的0, 這可以方便這些檔案被正確的排序.
-x 當分析和列印時, tcpdump 會列印每個包的頭部資料, 同時會以16進位制列印出每個包的資料(但不包括連線層的頭部).總共列印的資料大小不會超過整個資料包的大小與snaplen 中的最小值. 必須要注意的是, 如果高層協議資料沒有snaplen 這麼長,並且資料鏈路層(比如, Ethernet層)有填充資料, 則這些填充資料也會被列印.(nt: so for link layers that pad, 未能銜接理解和翻譯, 需補充 )
-xx tcpdump 會列印每個包的頭部資料, 同時會以16進位制列印出每個包的資料, 其中包括資料鏈路層的頭部.
-X 當分析和列印時, tcpdump 會列印每個包的頭部資料, 同時會以16進位制和ASCII碼形式列印出每個包的資料(但不包括連線層的頭部).這對於分析一些新協議的資料包很方便.
-XX 當分析和列印時, tcpdump 會列印每個包的頭部資料, 同時會以16進位制和ASCII碼形式列印出每個包的資料, 其中包括資料鏈路層的頭部.這對於分析一些新協議的資料包很方便.
-y datalinktype
設定tcpdump 只捕獲資料鏈路層協議型別是datalinktype的資料包
-Z user
使tcpdump 放棄自己的超級許可權(如果以root使用者啟動tcpdump, tcpdump將會有超級使用者許可權), 並把當前tcpdump的使用者ID設定為user, 組ID設定為user首要所屬組的ID(nt: tcpdump 此處可理解為tcpdump 執行之後對應的程式)
此選項也可在編譯的時候被設定為預設開啟.(nt: 此時user 的取值未知, 需補充)
複製程式碼
tcpdump條件表示式
該表示式用於決定哪些資料包將被列印. 如果不給定條件表示式, 網路上所有被捕獲的包都會被列印,否則, 只有滿足條件表示式的資料包被列印.(nt: all packets, 可理解為, 所有被指定介面捕獲的資料包).
表示式由一個或多個'表達元'組成(nt: primitive, 表達元, 可理解為組成表示式的基本元素). 一個表達元通常由一個或多個修飾符(qualifiers)後跟一個名字或數字表示的id組成(nt: 即, 'qualifiers id').有三種不同型別的修飾符:type, dir以及 proto.
複製程式碼
type 修飾符指定id 所代表的物件型別, id可以是名字也可以是數字. 可選的物件型別有: host, net, port 以及portrange(nt: host 表明id表示主機, net 表明id是網路, port 表明id是端而portrange 表明id 是一個埠範圍). 如, 'host foo', 'net 128.3', 'port 20', 'portrange 6000-6008'(nt: 分別表示主機 foo,網路 128.3, 埠 20, 埠範圍 6000-6008). 如果不指定type 修飾符, id預設的修飾符為host.
dir 修飾符描述id 所對應的傳輸方向, 即發往id 還是從id 接收（nt: 而id 到底指什麼需要看其前面的type 修飾符）.可取的方向為: src, dst, src 或 dst, src並且dst.(nt:分別表示, id是傳輸源, id是傳輸目的, id是傳輸源或者傳輸目的, id是傳輸源並且是傳輸目的). 例如, 'src foo','dst net 128.3', 'src or dst port ftp-data'.(nt: 分別表示符合條件的資料包中, 源主機是foo, 目的網路是128.3, 源或目的埠為 ftp-data).如果不指定dir修飾符, id 預設的修飾符為src 或 dst.對於鏈路層的協議,比如SLIP(nt: Serial Line InternetProtocol, 串聯線路網際網路協議), 以及linux下指定'any' 裝置, 並指定'cooked'(nt | rt: cooked 含義未知, 需補充) 抓取型別, 或其他裝置型別,可以用'inbound' 和 'outbount' 修飾符來指定想要的傳輸方向.
proto 修飾符描述id 所屬的協議. 可選的協議有: ether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, tcp以及 upd.(nt | rt: ether, fddi, tr, 具體含義未知, 需補充. 可理解為物理乙太網傳輸協議, 光纖分佈資料網傳輸協議,以及用於路由跟蹤的協議. wlan, 無線區域網協議; ip,ip6 即通常的TCP/IP協議棧中所使用的ipv4以及ipv6網路層協議;arp, rarp 即地址解析協議,反向地址解析協議; decnet, Digital Equipment Corporation開發的, 最早用於PDP-11 機器互聯的網路協議; tcp and udp, 即通常TCP/IP協議棧中的兩個傳輸層協議).
例如, `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange 7000-7009'分別表示 '從乙太網地址foo 來的資料包','發往或來自128.3網路的arp協議資料包', '傳送或接收埠為21的tcp協議資料包', '傳送或接收埠範圍為7000-7009的udp協議資料包'.
如果不指定proto 修飾符, 則預設為與相應type匹配的修飾符. 例如, 'src foo' 含義是 '(ip or arp or rarp) src foo' (nt: 即, 來自主機foo的ip/arp/rarp協議資料包, 預設type為host),`net bar' 含義是`(ip or arp or rarp) net bar'(nt: 即, 來自或發往bar網路的ip/arp/rarp協議資料包),`port 53' 含義是 `(tcp or udp) port 53'(nt: 即, 傳送或接收埠為53的tcp/udp協議資料包).(nt: 由於tcpdump 直接透過資料鏈路層的 BSD 資料包過濾器或 DLPI(datalink provider interface, 資料鏈層提供者介面)來直接獲得網路資料包, 其可抓取的資料包可涵蓋上層的各種協議, 包括arp, rarp, icmp(因特網控制報文協議),ip, ip6, tcp, udp, sctp(流控制傳輸協議).
對於修飾符後跟id 的格式,可理解為, type id 是對包最基本的過濾條件: 即對包相關的主機, 網路, 埠的限制;dir 表示對包的傳送方向的限制; proto表示對包相關的協議限制)
'fddi'(nt: Fiber Distributed Data Interface) 實際上與'ether' 含義一樣: tcpdump 會把他們當作一種''指定網路介面上的資料鏈路層協議''. 如同ehter網(乙太網), FDDI 的頭部通常也會有源, 目的, 以及包型別, 從而可以像ether網資料包一樣對這些域進行過濾. 此外, FDDI 頭部還有其他的域, 但不能被放到表示式中用來過濾
同樣, 'tr' 和 'wlan' 也和 'ether' 含義一致, 上一段對fddi 的描述同樣適用於tr(Token Ring) 和wlan(802.11 wireless LAN)的頭部. 對於802.11 協議資料包的頭部, 目的域稱為DA, 源域稱為 SA;而其中的 BSSID, RA, TA 域(nt | rt: 具體含義需補充)不會被檢測(nt: 不能被用於包過慮表示式中).
複製程式碼
除以上所描述的表達元('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指令碼或終端中使用時必須對括號進行轉義, 即'(' 與')'需要分別表達成'\(' 與 '\)').
有效的運算子有:
否定操作 (`!' 或 `not')
與操作(`&&' 或 `and')
或操作(`||' 或 `or')
否定運算子的優先順序別最高. 與操作和或操作優先順序別相同, 並且二者的結合順序是從左到右. 要注意的是, 表達'與操作'時,
需要顯式寫出'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 <= length' 的含義一致.
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.
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28869493/viewspace-2144318/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Tcpdump使用示例TCP
- TcpDump使用手冊TCP
- tcpdumpTCP
- [20200227]使用tcpdump or and ()語法問題.txtTCP
- 使用tcpdump檢視原始資料包TCP
- tcpdump命令TCP
- 故障排查工具-strace,tcpdump的簡單使用TCP
- 在 Linux 命令列中使用 tcpdump 抓包Linux命令列TCP
- tcpdump歷史TCP
- tcpdump抓包TCP
- Linux - Tcpdump命令LinuxTCP
- wireshark安裝使用與tcpdump的抓包分析TCP
- tcpdump命令詳解TCP
- 使用tcpdump+wireshark抓包分析網路資料包TCP
- tcpdump抓包分析NAT ping不通TCP
- 說說Linux抓包命令tcpdumpLinuxTCP
- tcpdump 命令的常用選項：一TCP
- tcpdump 命令的常用選項：二TCP
- tcpdump 命令的常用選項：三TCP
- 抓包工具tcpdump用法說明TCP
- tcpdump 命令的個常用選項：三TCP
- tcpdump 命令的個常用選項：一TCP
- tcpdump 命令的個常用選項：二TCP
- 在Linux中，如何使用 tcpdump 監聽主機為 192.168.1.1，tcp 端⼝為 80 的資料，並將將輸出結果儲存輸出到tcpdump.log？LinuxTCP
- 重定向Kubernetes pod中的tcpdump輸出TCP
- tcpdump抓包及tshark解包方法介紹TCP
- Linux 基礎教程 30-tcpdump命令-2LinuxTCP
- 最簡明的 Tcpdump 抓包入門指南TCP
- 網路資料包分析工具tcpdump之一TCP
- docker中安裝tcpdump出錯解決方法DockerTCP
- Linux伺服器抓包工具tcpdump示例詳解Linux伺服器TCP
- Java高效開發-SSH+Wireshark+tcpdump組合拳JavaTCP
- tcpdump統計http請求並匯出URL文字TCPHTTP
- Linux 網路分析必備技能：tcpdump 實戰詳解LinuxTCP
- 019 Linux tcpdump 抓包案例入門可真簡單啊？LinuxTCP
- 使用tcpdump，netstat簡單看下tcp連線握手與揮手的過程和核心緩衝區的變化TCP
- tcpdump抓包mysql建聯驗證TCP的三次握手TCPMySql
- 實戰：tcpdump抓包分析三次握手四次揮手TCP
- tcpdump 和 wireshark 抓包工具 ，介紹、安裝、命令使用。 詳解三次握手、四次揮手。兩個結合使用，會更好分析報文TCP