Linux tcpdump 命令詳解

簡介

用簡單的話來定義tcpdump，就是：dump the traffic on a network，根據使用者的定義對網絡上的數據包進行截獲的包分析工具。 tcpdump能夠將網絡中傳送的數據包的「頭」徹底截獲下來提供分析。它支持針對網絡層、協議、主機、網絡或端口的過濾，並提供and、or、not等邏輯語句來幫助你去掉無用的信息。

實用命令實例

默認啓動

1

tcpdump

普通狀況下，直接啓動tcpdump將監視第一個網絡接口上全部流過的數據包。

監視指定網絡接口的數據包

1	tcpdump -i eth1

若是不指定網卡，默認tcpdump只會監視第一個網絡接口，通常是eth0，下面的例子都沒有指定網絡接口。

監視指定主機的數據包

打印全部進入或離開sundown的數據包.

1	tcpdump host sundown

也能夠指定ip，例如截獲全部210.27.48.1 的主機收到的和發出的全部的數據包

1	tcpdump host 210.27.48.1

打印helios 與 hot 或者與 ace 之間通訊的數據包

1	tcpdump host helios and ( hot or ace )

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

1	tcpdump host 210.27.48.1 and  (210.27.48.2 or 210.27.48.3 )

打印ace與任何其餘主機之間通訊的IP 數據包， 但不包括與helios之間的數據包.

1	tcpdump ip host ace and not helios

若是想要獲取主機210.27.48.1除了和主機210.27.48.2以外全部主機通訊的ip包，使用命令：

1	tcpdump ip host 210.27.48.1 and ! 210.27.48.2

截獲主機hostname發送的全部數據

1	tcpdump -i eth0 src host hostname

監視全部送到主機hostname的數據包

1	tcpdump -i eth0 dst host hostname

監視指定主機和端口的數據包

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

1	tcpdump tcp port 23 and host 210.27.48.1

對本機的udp 123 端口進行監視 123 爲ntp的服務端口

1	tcpdump udp port 123

監視指定網絡的數據包

打印本地主機與Berkeley網絡上的主機之間的全部通訊數據包(nt: ucb-ether， 此處可理解爲’Berkeley網絡’的網絡地址，此表達式最原始的含義可表達爲: 打印網絡地址爲ucb-ether的全部數據包)

1	tcpdump net ucb-ether

打印全部經過網關snup的ftp數據包(注意， 表達式被單引號括起來了， 這能夠防止shell對其中的括號進行錯誤解析)

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

打印全部源地址或目標地址是本地主機的IP數據包

(若是本地網絡經過網關連到了另外一網絡， 則另外一網絡並不能算做本地網絡.(nt: 此句翻譯曲折，需補充).localnet 實際使用時要真正替換成本地網絡的名字)

1	tcpdump ip and not net localnet

監視指定協議的數據包

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

1	tcpdump 'tcp[tcpflags]

打印全部源或目的端口是80， 網絡層協議爲IPv4， 而且含有數據，而不是SYN，FIN以及ACK-only等不含數據的數據包.(ipv6的版本的表達式可作練習)

1	tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]

(nt: 可理解爲， ip[2:2]表示整個ip數據包的長度， (ip[0]&0xf)

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

打印長度超過576字節， 而且網關地址是snup的IP數據包

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

打印全部IP層廣播或多播的數據包， 但不是物理以太網層的廣播或多播數據報

1	tcpdump 'ether[0]

打印除’echo request’或者’echo reply’類型之外的ICMP數據包( 好比，須要打印全部非ping 程序產生的數據包時可用到此表達式 .
(nt: ‘echo reuqest’ 與 ‘echo reply’ 這兩種類型的ICMP數據包一般由ping程序產生))

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

tcpdump 與wireshark

Wireshark(之前是ethereal)是Windows下很是簡單易用的抓包工具。但在Linux下很難找到一個好用的圖形化抓包工具。
還好有Tcpdump。咱們能夠用Tcpdump + Wireshark 的完美組合實現：在 Linux 裏抓包，而後在Windows 裏分析包。

1	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包

1	tcpdump  -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854

0×4745 爲」GET」前兩個字母」GE」，0×4854 爲」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’
(遠程登陸)過程開始階段的數據包樣例:

1 2	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的一些選項， 這些選項都用尖括號來表示(如 ).

src， dst 和 flags 這三個域老是會被顯示. 其餘域的顯示與否依賴於tcp協議頭裏的信息.

這是一個從trsg到csam的一個rlogin應用登陸的開始階段.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
第一行表示有一個數據包從rtsg主機的tcp端口1023發送到了csam主機的tcp端口login上(nt:udp協議的端口和tcp協議的端
口是分別的兩個空間， 雖然取值範圍一致). S表示設置了SYN標誌. 包的順序號是768512， 而且沒有包含數據.(表示格式
爲:’first:last(nbytes)’， 其含義是’此包中數據的順序號從first開始直到last結束，不包括last. 而且總共包含nbytes的
用戶數據’.) 沒有捎帶應答(nt:從下文來看，第二行纔是有捎帶應答的數據包)， 可用的接受窗口的大小爲4096bytes， 而且請求端(rtsg)
的最大可接受的數據段大小是1024字節(nt:這個信息做爲請求發向應答端csam， 以便雙方進一步的協商).

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

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

第六行的含義爲:rtsg 向 csam發送了19字節的數據(字節的編號爲2到20，傳送方向爲rtsg到csam). 包中設置了PUSH標誌. 在第7行，
csam 喊到， 她已經從rtsg中收到了21如下的字節， 但不包括21編號的字節. 這些字節存放在csam的socket的接收緩衝中， 相應地，
csam的接收緩衝窗口大小會減小19字節(nt:能夠從第5行和第7行win屬性值的變化看出來). csam在第7行這個包中也向rtsg發送了一個
字節. 在第8行和第9行， csam 繼續向rtsg 分別發送了兩個只包含一個字節的數據包， 而且這個數據包帶PUSH標誌.

若是所抓到的tcp包(nt:即這裏的snapshot)過小了，以致tcpdump沒法完整獲得其頭部數據， 這時， tcpdump會盡可能解析這個不完整的頭，
並把剩下不能解析的部分顯示爲’[|tcp]‘. 若是頭部含有虛假的屬性信息(好比其長度屬性其實比頭部實際長度長或短)， tcpdump會爲該頭部
顯示’[bad opt]‘. 若是頭部的長度告訴咱們某些選項(nt | rt:從下文來看， 指tcp包的頭部中針對ip包的一些選項， 回頭再翻)會在此包中，
而真正的IP(數據包的長度又不夠容納這些選項， tcpdump會顯示’[bad hdr length]‘.

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

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

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

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

一個TCP頭部，在不包含選項數據的狀況下一般佔用20個字節(nt | rt:options 理解爲選項數據，需回譯). 第一行包含0到3編號的字節，
第二行包含編號4-7的字節.

若是編號從0開始算， TCP控制標誌位於13字節(nt:第四行左半部分).

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

讓咱們仔細看看編號13的字節:

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

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

提醒一下本身， 咱們只是要獲得包含SYN標誌的數據包. 讓咱們看看在一個包的包頭中， 若是SYN位被設置， 到底
在13號字節發生了什麼:

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

在控制段的數據中， 只有比特1(bit number 1)被置位.

假設編號爲13的字節是一個8位的無符號字符型，而且按照網絡字節號排序(nt:對於一個字節來講，網絡字節序等同於主機字節序)， 其二進制值
以下所示:
00000010

而且其10進制值爲:

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

接近目標了， 由於咱們已經知道， 若是數據包頭部中的SYN被置位， 那麼頭部中的第13個字節的值爲2(nt: 按照網絡序， 即大頭方式， 最重要的字節
在前面(在前面，即該字節實際內存地址比較小， 最重要的字節，指數學表示中數的高位， 如356中的3) ).

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

從而咱們能夠把此關係式看成tcpdump的過濾條件， 目標就是監控只含有SYN標誌的數據包:
tcpdump -i xl0 tcp[13] 2 (nt: xl0 指網絡接口， 如eth0)

這個表達式是說」讓TCP數據包的第13個字節擁有值2吧」， 這也是咱們想要的結果.

如今， 假設咱們須要抓取帶SYN標誌的數據包， 而忽略它是否包含其餘標誌.(nt:只要帶SYN就是咱們想要的). 讓咱們來看看當一個含有
SYN-ACK的數據包(nt:SYN 和 ACK 標誌都有)， 來到時發生了什麼:
|C|E|U|A|P|R|S|F|
|—————|
|0 0 0 1 0 0 1 0|
|—————|
|7 6 5 4 3 2 1 0|

13號字節的1號和4號位被置位， 其二進制的值爲:
00010010

轉換成十進制就是:

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

如今， 卻不能只用’tcp[13] 18′做爲tcpdump的過濾表達式， 由於這將致使只選擇含有SYN-ACK標誌的數據包， 其餘的都被丟棄.
提醒一下本身， 咱們的目標是: 只要包的SYN標誌被設置就行， 其餘的標誌咱們不理會.

爲了達到咱們的目標， 咱們須要把13號字節的二進制值與其餘的一個數作AND操做(nt:邏輯與)來獲得SYN比特位的值. 目標是:只要SYN 被設置
就行， 因而咱們就把她與上13號字節的SYN值(nt: 00000010).

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

咱們能夠發現， 無論包的ACK或其餘標誌是否被設置， 以上的AND操做都會給咱們相同的值， 其10進製表達就是2(2進製表達就是00000010).
從而咱們知道， 對於帶有SYN標誌的數據包， 如下的表達式的結果老是真(true):

( ( value of octet 13 ) AND ( 2 ) ) ( 2 ) (nt: value of octet 13， 即13號字節的值)

靈感隨之而來， 咱們因而獲得了以下的tcpdump 的過濾表達式
tcpdump -i xl0 ‘tcp[13] & 2 2′

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

UDP 數據包

UDP 數據包的顯示格式，可經過rwho這個具體應用所產生的數據包來講明:
actinide.who > broadcast.who: udp 84

其含義爲:actinide主機上的端口who向broadcast主機上的端口who發送了一個udp數據包(nt: actinide和broadcast都是指Internet地址).
這個數據包承載的用戶數據爲84個字節.

一些UDP服務可從數據包的源或目的端口來識別，也可從所顯示的更高層協議信息來識別. 好比， Domain Name service requests(DNS 請求，
在RFC-1034/1035中)， 和Sun RPC calls to NFS(對NFS服務器所發起的遠程調用(nt: 即Sun RPC)，在RFC-1050中有對遠程調用的描述).

UDP 名稱服務請求

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

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

主機h2opolo 向helios 上運行的名稱服務器查詢ucbvax.berkeley.edu 的地址記錄(nt: qtype等於A). 此查詢自己的id號爲’3′. 符號
‘+’意味着遞歸查詢標誌被設置(nt: dns服務器可向更高層dns服務器查詢本服務器不包含的地址記錄). 這個最終經過IP包發送的查詢請求
數據長度爲37字節， 其中不包括UDP和IP協議的頭數據. 由於此查詢操做爲默認值(nt | rt: normal one的理解)， op字段被省略.
若是op字段沒被省略， 會被顯示在’3′ 和’+'之間. 一樣， qclass也是默認值， C_IN， 從而也沒被顯示， 若是沒被忽略， 她會被顯示在’A'以後.

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

UDP 名稱服務應答

對名稱服務應答的數據包，tcpdump會有以下的顯示格式
src > dst: id op rcode flags a/n/au type class data (len)
好比具體顯示以下:
helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)

第一行表示: helios 對h2opolo 所發送的3號查詢請求迴應了3條回答記錄(nt | rt: answer records)， 3條名稱服務器記錄，
以及7條附加的記錄. 第一個回答記錄(nt: 3個回答記錄中的第一個)類型爲A(nt: 表示地址)， 其數據爲internet地址128.32.137.3.
此迴應UDP數據包， 包含273字節的數據(不包含UPD和IP的頭部數據). op字段和rcode字段被忽略(nt: op的實際值爲Query， rcode， 即
response code的實際值爲NoError)， 一樣被忽略的字段還有class 字段(nt | rt: 其值爲C_IN， 這也是A類型記錄默認取值)

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

flag字段還有可能出現其餘一些字符， 好比’-'(nt: 表示可遞歸地查詢， 即RA 標誌沒有被設置)， ‘|’(nt: 表示被截斷的消息， 即TC 標誌
被置位). 若是應答(nt | ct: 可理解爲， 包含名稱服務應答的UDP數據包， tcpdump知道這類數據包該怎樣解析其數據)的’question’段一個條
目(entry)都不包含(nt: 每一個條目的含義， 需補充)，’[nq]‘ 會被打印出來.

要注意的是:名稱服務器的請求和應答數據量比較大， 而默認的68字節的抓取長度(nt: snaplen， 可理解爲tcpdump的一個設置選項)可能不足以抓取
數據包的所有內容. 若是你真的須要仔細查看名稱服務器的負載， 能夠經過tcpdump 的-s 選項來擴大snaplen值.

SMB/CIFS 解碼

tcpdump 已能夠對SMB/CIFS/NBT相關應用的數據包內容進行解碼(nt: 分別爲’Server Message Block Common’， ‘Internet File System’
‘在TCP/IP上實現的網絡協議NETBIOS的簡稱’. 這幾個服務一般使用UDP的137/138以及TCP的139端口). 原來的對IPX和NetBEUI SMB數據包的
解碼能力依然能夠被使用(nt: NetBEUI爲NETBIOS的加強版本).

tcpdump默認只按照最簡約模式對相應數據包進行解碼， 若是咱們想要詳盡的解碼信息可使用其-v 啓動選現. 要注意的是， -v 會產生很是詳細的信息，
好比對單一的一個SMB數據包， 將產生一屏幕或更多的信息， 因此此選項， 確有須要才使用.

關於SMB數據包格式的信息， 以及每一個域的含義能夠參看www.cifs.org 或者samba.org 鏡像站點的pub/samba/specs/ 目錄. linux 上的SMB 補丁
(nt | rt: patch)由 Andrew Tridgell (tridge@samba.org)提供.

NFS 請求和迴應

tcpdump對Sun NFS(網絡文件系統)請求和迴應的UDP數據包有以下格式的打印輸出:
src.xid > dst.nfs: len op args
src.nfs > dst.xid: reply stat len op results

如下是一組具體的輸出數據
sushi.6709 > wrl.nfs: 112 readlink fh 21，24/10.73165
wrl.nfs > sushi.6709: reply ok 40 readlink 「../var」
sushi.201b > wrl.nfs:
144 lookup fh 9，74/4096.6878 「xcolors」
wrl.nfs > sushi.201b:
reply ok 128 lookup fh 9，74/4134.3150

第一行輸出代表: 主機sushi向主機wrl發送了一個’交換請求’(nt: transaction)， 此請求的id爲6709(注意， 主機名字後是交換
請求id號， 而不是源端口號). 此請求數據爲112字節， 其中不包括UDP和IP頭部的長度. 操做類型爲readlink(nt: 即此操做爲讀符號連接操做)，
操做參數爲fh 21，24/10.73165(nt: 可按實際運行環境， 解析以下， fd 表示描述的爲文件句柄， 21，24 表示此句柄所對應設
備的主/從設備號對， 10表示此句柄所對應的i節點編號(nt:每一個文件都會在操做系統中對應一個i節點， 限於unix類系統中)，
73165是一個編號(nt: 可理解爲標識此請求的一個隨機數， 具體含義需補充)).

第二行中， wrl 作了’ok’的迴應， 而且在results 字段中返回了sushi想要讀的符號鏈接的真實目錄(nt: 即sushi要求讀的符號鏈接實際上是一個目錄).

第三行代表: sushi 再次請求 wrl 在’fh 9，74/4096.6878′所描述的目錄中查找’xcolors’文件. 須要注意的是， 每行所顯示的數據含義依賴於其中op字段的
類型(nt: 不一樣op 所對應args 含義不相同)， 其格式遵循NFS 協議， 追求簡潔明瞭.

若是tcpdump 的-v選項(詳細打印選項) 被設置， 附加的信息將被顯示. 好比:
sushi.1372a > wrl.nfs:
148 read fh 21，11/12.195 8192 bytes @ 24576
wrl.nfs > sushi.1372a:
reply ok 1472 read REG 100664 ids 417/0 sz 29388

(-v 選項通常還會打印出IP頭部的TTL， ID， length， 以及fragmentation 域， 但在此例中， 都略過了(nt: 可理解爲，簡潔起見， 作了刪減))
在第一行， sushi 請求wrl 從文件 21，11/12.195(nt: 格式在上面有描述)中， 自偏移24576字節處開始， 讀取8192字節數據.
Wrl 迴應讀取成功; 因爲第二行只是迴應請求的開頭片斷， 因此只包含1472字節(其餘的數據將在接着的reply片斷中到來， 但這些數據包不會再有NFS
頭， 甚至UDP頭信息也爲空(nt: 源和目的應該要有)， 這將致使這些片斷不能知足過濾條件， 從而沒有被打印). -v 選項除了顯示文件數據信息， 還會顯示
附加顯示文件屬性信息: file type(文件類型， 」REG」 表示普通文件)， file mode(文件存取模式， 8進製表示的)， uid 和gid(nt: 文件屬主和
組屬主)， file size (文件大小).

若是-v 標誌被屢次重複給出(nt: 如-vv)， tcpdump會顯示更加詳細的信息.

必需要注意的是， NFS 請求包中數據比較多， 若是tcpdump 的snaplen(nt: 抓取長度) 取過短將不能顯示其詳細信息. 可以使用
‘-s 192′來增長snaplen， 這可用以監測NFS應用的網絡負載(nt: traffic).

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

AFS 請求和迴應

AFS(nt: Andrew 文件系統， Transarc ， 未知， 需補充)請求和迴應有以下的答應

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

elvis.7001 > pike.afsfs:
rx data fs call rename old fid 536876964/1/1 「.newsrc.new」
new fid 536876964/1/1 「.newsrc」
pike.afsfs > elvis.7001: rx data fs reply rename

在第一行， 主機elvis 向pike 發送了一個RX數據包.
這是一個對於文件服務的請求數據包(nt: RX data packet， 發送數據包 ， 可理解爲發送包過去， 從而請求對方的服務)， 這也是一個RPC
調用的開始(nt: RPC， remote procedure call). 此RPC 請求pike 執行rename(nt: 重命名) 操做， 並指定了相關的參數:
原目錄描述符爲536876964/1/1， 原文件名爲 ‘.newsrc.new’， 新目錄描述符爲536876964/1/1， 新文件名爲 ‘.newsrc’.
主機pike 對此rename操做的RPC請求做了迴應(迴應表示rename操做成功， 由於迴應的是包含數據內容的包而不是異常包).

通常來講， 全部的’AFS RPC’請求被顯示時， 會被冠以一個名字(nt: 即decode， 解碼)， 這個名字每每就是RPC請求的操做名.
而且， 這些RPC請求的部分參數在顯示時， 也會被冠以一個名字(nt | rt: 即decode， 解碼， 通常來講也是取名也很直接， 好比，
一個interesting 參數， 顯示的時候就會直接是’interesting’， 含義拗口， 需再翻).

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

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

若是 -v 選項被重複了三次(nt: 如-vvv)， 那麼AFS應用類型數據包的’安全索引’(‘security index’)以及’服務索引’(‘service id’)將會
被打印.

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

AFS 請求數據量大， 參數也多， 因此要求tcpdump的 snaplen 比較大， 通常可經過啓動tcpdump時設置選項’-s 256′ 來增大snaplen， 以
監測AFS 應用通訊負載.

AFS 迴應包並不顯示標識RPC 屬於何種遠程調用. 從而， tcpdump 會跟蹤最近一段時間內的請求包， 並經過call number(調用編號)， service ID
(服務索引) 來匹配收到的迴應包. 若是迴應包不是針對最近一段時間內的請求包， tcpdump將沒法解析該包.

KIP AppleTalk協議

(nt | rt: DDP in UDP可理解爲， DDP， The AppleTalk Data Delivery Protocol，
至關於支持KIP AppleTalk協議棧的網絡層協議， 而DDP 自己又是經過UDP來傳輸的，
即在UDP 上實現的用於其餘網絡的網絡層，KIP AppleTalk是蘋果公司開發的整套網絡協議棧).

AppleTalk DDP 數據包被封裝在UDP數據包中， 其解封裝(nt: 至關於解碼)和相應信息的轉儲也遵循DDP 包規則.
(nt:encapsulate， 封裝， 至關於編碼， de-encapsulate， 解封裝， 至關於解碼， dump， 轉儲， 一般就是指對其信息進行打印).

/etc/atalk.names 文件中包含了AppleTalk 網絡和節點的數字標識到名稱的對應關係. 其文件格式一般以下所示:
number name

1.254 ether
16.1 icsd-net
1.254.110 ace

頭兩行表示有兩個AppleTalk 網絡. 第三行給出了特定網絡上的主機(一個主機會用3個字節來標識，
而一個網絡的標識一般只有兩個字節， 這也是二者標識的主要區別)(nt: 1.254.110 可理解爲ether網絡上的ace主機).
標識與其對應的名字之間必需要用空白分開. 除了以上內容， /etc/atalk.names中還包含空行以及註釋行(以’#'開始的行).

AppleTalk 完整網絡地址將以以下格式顯示:
net.host.port

如下爲一段具體顯示:
144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2

(若是/etc/atalk.names 文件不存在， 或者沒有相應AppleTalk 主機/網絡的條目， 數據包的網絡地址將以數字形式顯示).

在第一行中， 網絡144.1上的節點209經過2端口，向網絡icsd-net上監聽在220端口的112節點發送了一個NBP應用數據包
(nt | rt: NBP， name binding protocol， 名稱綁定協議， 從數據來看， NBP服務器會在端口2提供此服務.
‘DDP port 2′ 可理解爲’DDP 對應傳輸層的端口2′， DDP自己沒有端口的概念， 這點未肯定， 需補充).

第二行與第一行相似， 只是源的所有地址可用’office’進行標識.
第三行表示: jssmag網絡上的149節點經過235向icsd-net網絡上的全部節點的2端口(NBP端口)發送了數據包.(須要注意的是，
在AppleTalk 網絡中若是地址中沒有節點， 則表示廣播地址， 從而節點標識和網絡標識最好在/etc/atalk.names有所區別.
nt: 不然一個標識x.port 沒法肯定x是指一個網絡上全部主機的port口仍是指定主機x的port口).

tcpdump 可解析NBP (名稱綁定協議) and ATP (AppleTalk傳輸協議)數據包， 對於其餘應用層的協議， 只會打印出相應協議名字(
若是此協議沒有註冊一個通用名字， 只會打印其協議號)以及數據包的大小.

NBP 數據包會按照以下格式顯示:
icsd-net.112.220 > jssmag.2: nbp-lkup 190: 「=:LaserWriter@*」
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: 「RM1140:LaserWriter@*」 250
techpit.2 > icsd-net.112.220: nbp-reply 190: 「techpit:LaserWriter@*」 186

第一行表示: 網絡icsd-net 中的節點112 經過220端口向網絡jssmag 中全部節點的端口2發送了對’LaserWriter’的名稱查詢請求(nt:
此處名稱可理解爲一個資源的名稱， 好比打印機). 此查詢請求的序列號爲190.

第二行表示: 網絡jssmag 中的節點209 經過2端口向icsd-net.112節點的端口220進行了迴應: 我有’LaserWriter’資源， 其資源名稱
爲’RM1140′， 而且在端口250上提供改資源的服務. 此迴應的序列號爲190， 對應以前查詢的序列號.

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

ATP 數據包的顯示格式以下:
jssmag.209.165 > helios.132: atp-req 12266 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
jssmag.209.165 > helios.132: atp-req 12266 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
jssmag.209.165 > helios.132: atp-rel 12266 0xae030001
jssmag.209.133 > helios.132: atp-req* 12267 0xae030002

第一行表示節點 Jssmag.209 向節點helios 發送了一個會話編號爲12266的請求包， 請求helios
迴應8個數據包(這8個數據包的順序號爲0-7(nt: 順序號與會話編號不一樣， 後者爲一次完整傳輸的編號，
前者爲該傳輸中每一個數據包的編號. transaction， 會話， 一般也被叫作傳輸)). 行尾的16進制數字表示
該請求包中’userdata’域的值(nt: 從下文來看， 這並無把全部用戶數據都打印出來 ).

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

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

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

IP 數據包破碎

(nt: 指把一個IP數據包分紅多個IP數據包)

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

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

每一個碎片都會使tcpdump產生相應的輸出打印. 第一個碎片包含了高層協議的頭數據(nt:從下文來看， 被破碎IP數據包中相應tcp頭以及
IP頭都放在了第一個碎片中 )， 從而tcpdump會針對第一個碎片顯示這些信息， 並接着顯示此碎片自己的信息. 其後的一些碎片並不包含
高層協議頭信息， 從而只會在顯示源和目的以後顯示碎片自己的信息. 如下有一個例子: 這是一個從arizona.edu 到lbl-rtsg.arpa
途經CSNET網絡(nt: CSNET connection 可理解爲創建在CSNET 網絡上的鏈接)的ftp應用通訊片斷:
arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560

有幾點值得注意:
第一， 第二行的打印中， 地址後面沒有端口號.
這是由於TCP協議信息都放到了第一個碎片中， 當顯示第二個碎片時， 咱們沒法知道此碎片所對應TCP包的順序號.

第二， 從第一行的信息中， 能夠發現arizona須要向rtsg發送308字節的用戶數據， 而事實是， 相應IP包經破碎後會總共產生512字節
數據(第一個碎片包含308字節的數據， 第二個碎片包含204個字節的數據， 這超過了308字節). 若是你在查找數據包的順序號空間中的
一些空洞(nt: hole，空洞， 指數據包之間的順序號沒有上下銜接上)， 512這個數據就足夠使你迷茫一陣(nt: 其實只要關注308就行，
沒必要關注破碎後的數據總量).

一個數據包(nt | rt: 指IP數據包)若是帶有非IP破碎標誌， 則顯示時會在最後顯示’(DF)’.(nt: 意味着此IP包沒有被破碎過).

時間戳

tcpdump的全部輸出打印行中都會默認包含時間戳信息.
時間戳信息的顯示格式以下
hh:mm:ss.frac　(nt: 小時:分鐘:秒.(nt: frac未知， 需補充))
此時間戳的精度與內核時間精度一致，　反映的是內核第一次看到對應數據包的時間(nt: saw， 便可對該數據包進行操做).
而數據包從物理線路傳遞到內核的時間， 以及內核花費在此包上的中斷處理時間都沒有算進來.

命令使用

tcpdump採用命令行方式，它的命令格式爲：

1

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的簡單選項介紹

1

-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

tcpdump條件表達式

該表達式用於決定哪些數據包將被打印. 若是不給定條件表達式， 網絡上全部被捕獲的包都會被打印，不然， 只有知足條件表達式的數據包被打印.(nt: all packets， 可理解爲， 全部被指定接口捕獲的數據包).

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

1

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腳本或終端中使用時必須對括號進行轉義， 即’(‘ 與’)'須要分別表達成’(‘ 與 ‘)’).

有效的操做符有:

1	否認操做 (`!' 或 `not') 與操做(`

否認操做符的優先級別最高. 與操做和或操做優先級別相同， 而且兩者的結合順序是從左到右. 要注意的是， 表達’與操做’時，

須要顯式寫出’and’操做符， 而不僅是把先後表達元並列放置(nt: 兩者中間的’and’ 操做符不可省略).

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

整個條件表達式能夠被看成一個單獨的字符串參數也能夠被看成空格分割的多個參數傳入tcpdump， 後者更方便些. 一般， 若是表達式中包含元字符(nt: 如正則表達式中的’*'， ‘.’以及shell中的’(‘等字符)， 最好仍是使用單獨字符串的方式傳入. 這時，整個表達式須要被單引號括起來. 多參數的傳入方式中， 全部參數最終仍是被空格串聯在一塊兒， 做爲一個字符串被解析.

附錄:tcpdump的表達元

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

dst host host
若是IPv4/v6 數據包的目的域是host， 則與此對應的條件表達式爲真.host 能夠是一個ip地址， 也能夠是一個主機名.
src host host
若是IPv4/v6 數據包的源域是host， 則與此對應的條件表達式爲真.
host 能夠是一個ip地址， 也能夠是一個主機名.
host host

若是IPv4/v6數據包的源或目的地址是 host， 則與此對應的條件表達式爲真.以上的幾個host 表達式以前能夠添加如下關鍵字:ip， arp， rarp， 以及 ip6.好比:
ip host host
也能夠表達爲:
ether proto ip and host host(nt: 這種表達方式在下面有說明， 其中ip以前須要有來轉義，由於ip 對tcpdump 來講已是一個關鍵字了.)

若是host 是一個擁有多個IP 的主機， 那麼任何一個地址都會用於包的匹配(nt: 即發向host 的數據包的目的地址能夠是這幾個IP中的任何一個， 從host 接收的數據包的源地址也能夠是這幾個IP中的任何一個).

ether dst ehost
若是數據包(nt: 指tcpdump 可抓取的數據包， 包括ip 數據包， tcp數據包)的以太網目標地址是ehost，則與此對應的條件表達式爲真. Ehost 能夠是/etc/ethers 文件中的名字或一個數字地址(nt: 可經過 man ethers 看到對/etc/ethers 文件的描述， 樣例中用的是數字地址)

ether src ehost
若是數據包的以太網源地址是ehost， 則與此對應的條件表達式爲真.

ether host ehost
若是數據包的以太網源地址或目標地址是ehost， 則與此對應的條件表達式爲真.

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

dst net net
若是數據包的目標地址(IPv4或IPv6格式)的網絡號字段爲 net， 則與此對應的條件表達式爲真.
net 能夠是從網絡數據庫文件/etc/networks 中的名字， 也能夠是一個數字形式的網絡編號.

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

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

對於IPv6 的地址格式， 網絡編號必須所有寫出來(8個部分必須所有寫出來); 相應網絡掩碼爲:
ff:ff:ff:ff:ff:ff:ff:ff， 因此IPv6 的網絡匹配是真正的’host’方式的匹配(nt | rt | rc:地址的8個部分都會用到，是否不屬於網絡的字節填寫0， 需接下來補充)， 但同時須要一個網絡掩碼長度參數來具體指定前面多少字節爲網絡掩碼(nt: 可經過下面的net net/len 來指定)

src net net
若是數據包的源地址(IPv4或IPv6格式)的網絡號字段爲 net， 則與此對應的條件表達式爲真.

net net
若是數據包的源或目的地址(IPv4或IPv6格式)的網絡號字段爲 net， 則與此對應的條件表達式爲真.

net net mask netmask
若是數據包的源或目的地址(IPv4或IPv6格式)的網絡掩碼與netmask 匹配， 則與此對應的條件表達式爲真.此選項以前還能夠配合src和dst來匹配源網絡地址或目標網絡地址(nt: 好比 src net net mask 255.255.255.0).該選項對於ipv6 網絡地址無效.

net net/len
若是數據包的源或目的地址(IPv4或IPv6格式)的網絡編號字段的比特數與len相同， 則與此對應的條件表達式爲真.此選項以前還能夠配合src和dst來匹配源網絡地址或目標網絡地址(nt | rt | tt: src net net/24， 表示須要匹配源地址的網絡編號有24位的數據包).

dst port port
若是數據包(包括ip/tcp， ip/udp， ip6/tcp or ip6/udp協議)的目的端口爲port， 則與此對應的條件表達式爲真.port 能夠是一個數字也能夠是一個名字(相應名字能夠在/etc/services 中找到該名字， 也能夠經過man tcp 和man udp來獲得相關描述信息 ). 若是使用名字， 則該名字對應的端口號和相應使用的協議都會被檢查. 若是隻是使用一個數字端口號，則只有相應端口號被檢查(好比， dst port 513 將會使tcpdump抓取tcp協議的login 服務和udp協議的who 服務數據包， 而port domain 將會使tcpdump 抓取tcp協議的domain 服務數據包， 以及udp 協議的domain 數據包)(nt | rt: ambiguous name is used 不可理解， 需補充).

src port port
若是數據包的源端口爲port， 則與此對應的條件表達式爲真.

port port
若是數據包的源或目的端口爲port， 則與此對應的條件表達式爲真.

dst portrange port1-port2
若是數據包(包括ip/tcp， ip/udp， ip6/tcp or ip6/udp協議)的目的端口屬於port1到port2這個端口範圍(包括port1， port2)， 則與此對應的條件表達式爲真. tcpdump 對port1 和port2 解析與對port 的解析一致(nt:在dst port port 選項的描述中有說明).

src portrange port1-port2
若是數據包的源端口屬於port1到port2這個端口範圍(包括 port1， port2)， 則與此對應的條件表達式爲真.

portrange port1-port2
若是數據包的源端口或目的端口屬於port1到port2這個端口範圍(包括 port1， port2)， 則與此對應的條件表達式爲真.

以上關於port 的選項均可以在其前面添加關鍵字:tcp 或者udp， 好比:
tcp src port port
這將使tcpdump 只抓取源端口是port 的tcp數據包.

less length
若是數據包的長度比length 小或等於length， 則與此對應的條件表達式爲真. 這與’len ‘ 的含義一致.

greater length
若是數據包的長度比length 大或等於length， 則與此對應的條件表達式爲真. 這與’len >= length’ 的含義一致.

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

ip6 proto protocol
若是數據包爲ipv6數據包而且其協議類型爲protocol， 則與此對應的條件表達式爲真.
注意此表達元不會把數據包中協議頭鏈中全部協議頭內容所有打印出來

ip6 protochain protocol
若是數據包爲ipv6數據包而且其協議鏈中包含類型爲protocol協議頭， 則與此對應的條件表達式爲真. 好比，
ip6 protochain 6

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

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

ether broadcast
若是數據包是以太網廣播數據包， 則與此對應的條件表達式爲真. ether 關鍵字是可選的.

ip broadcast
若是數據包是IPv4廣播數據包， 則與此對應的條件表達式爲真. 這將使tcpdump 檢查廣播地址是否符合全0和全1的一些約定，並查找網絡接口的網絡掩碼(網絡接口爲當時在其上抓包的網絡接口).

若是抓包所在網絡接口的網絡掩碼不合法， 或者此接口根本就沒有設置相應網絡地址和網絡， 亦或是在linux下的’any’網絡接口上抓包(此’any’接口能夠收到系統中不止一個接口的數據包(nt: 實際上， 可理解爲系統中全部可用的接口))，網絡掩碼的檢查不能正常進行.

ether multicast
若是數據包是一個以太網多點廣播數據包(nt: 多點廣播， 可理解爲把消息同時傳遞給一組目的地址， 而不是網絡中全部地址，後者爲可稱爲廣播(broadcast))， 則與此對應的條件表達式爲真. 關鍵字ether 能夠省略. 此選項的含義與如下條件表達式含義一致:`ether[0] & 1 != 0′(nt: 可理解爲， 以太網數據包中第0個字節的最低位是1， 這意味這是一個多點廣播數據包).

ip multicast
若是數據包是ipv4多點廣播數據包， 則與此對應的條件表達式爲真.

ip6 multicast
若是數據包是ipv6多點廣播數據包， 則與此對應的條件表達式爲真.

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

protocol字段能夠是一個數字或如下協議名之一:ip， ip6， arp， rarp， atalk， aarp， decnet， sca， lat，mopdl， moprc， iso， stp， ipx， 或者netbeui. 必需要注意的是標識符也是關鍵字， 從而必須經過」來進行轉義.

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

在光纖分佈式數據網絡接口(其表達元形式能夠是’fddi protocol arp’)， 令牌環網(其表達元形式能夠是’tr protocol arp’)，以及IEEE 802.11 無線局域網(其表達元形式能夠是’wlan protocol arp’)中， protocol 標識符來自802.2 邏輯鏈路控制層頭，在FDDI， Token Ring 或 802.1頭中會包含此邏輯鏈路控制層頭.

當以這些網絡上的相應的協議標識爲過濾條件時， tcpdump只是檢查LLC頭部中以0×000000爲組成單元標識符(OUI， 0×000000
標識一個內部以太網)的一段’SNAP格式結構’中的protocol ID 域， 而不會管包中是否有一段OUI爲0×000000的’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 頭部中以0×080007 爲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標識爲0×000000;
(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 爲0×8863)，則與此對應的條件表達式爲真.
(nt: PPP-over-Ethernet， 點對點以太網承載協議， 其點對點的鏈接創建分爲Discovery階段(地址發現) 和PPPoE 會話創建階段 ， discovery 數據包就是第一階段發出來的包. ethernet type是以太幀裏的一個字段，用來指明應用於幀數據字段的協議)

pppoes
若是數據包爲PPP-over-Ethernet會話數據包(nt: ethernet type 爲0×8864， 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中一致)， 二進制操做符(+， -， *， /， &， |，>)， 長度操做符， 以及對特定數據包中數據的引用操做符. 要注意的是， 全部的比較操做都默認操做數是無符號的，例如， 0×80000000 和 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.

問啊-一鍵呼叫程序員答題神器，牛人一對一服務，開發者編程必備官方網站：www.wenaaa.com

QQ羣290551701 彙集不少互聯網精英，技術總監，架構師，項目經理！開源技術研究，歡迎業內人士，大牛及新手有志於從事IT行業人員進入！