簡單介紹

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

有用命令例項

預設啟動

tcpdump

一般情況下，直接啟動tcpdump將監視第一個網路介面上全部流過的資料包。

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

tcpdump -i eth1

假設不指定網絡卡，預設tcpdump僅僅會監視第一個網路介面，一般是eth0，下面的樣例都沒有指定網路介面。　

監視指定主機的資料包

列印全部進入或離開sundown的資料包.

tcpdump host sundown

也能夠指定ip,比如截獲全部210.27.48.1 的主機收到的和發出的全部的資料包

tcpdump host 210.27.48.1 

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

tcpdump host helios and \( hot or ace \)

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

tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \) 

列印ace與不論什麼其他主機之間通訊的IP 資料包, 但不包含與helios之間的資料包.

tcpdump ip host ace and not helios

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

tcpdump ip host 210.27.48.1 and ! 210.27.48.2

截獲主機hostname傳送的全部資料

tcpdump -i eth0 src host hostname

監視全部送到主機hostname的資料包

tcpdump -i eth0 dst host hostname

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

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

tcpdump tcp port 23 host 210.27.48.1

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

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'

列印全部源或目的port是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下很easy易用的抓包工具。但在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 : 不抓取目標port是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總的的輸出格式為：系統時間 來源主機.port > 目標主機.port 資料包引數

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地址以及對應的port. 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主機的tcpport1023傳送到了csam主機的tcpportlogin上(nt:udp協議的port和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主機上的portwho向broadcast主機上的portwho傳送了一個udp資料包(nt: actinide和broadcast都是指Internet地址).
這個資料包承載的使用者資料為84個位元組.

一些UDP服務可從資料包的源或目的port來識別，也可從所顯示的更高層協議資訊來識別. 比方, Domain Name service requests(DNS 請求,
在RFC-1034/1035中), 和Sun RPC calls to NFS(對NFSserver所發起的遠端呼叫(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 上執行的名稱server查詢ucbvax.berkeley.edu 的地址記錄(nt: qtype等於A). 此查詢本身的id號為'3'. 符號
'+'意味著遞迴查詢標誌被設定(nt: dnsserver可向更高層dnsserver查詢本server不包含的地址記錄). 這個終於通過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條名稱server記錄,
以及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: 表示不存在的域)), 沒有回答記錄,
但包含一個名稱server記錄, 不包含權威server記錄(nt | ck: 從上文來看, 此處的authority records 就是上文中對應的additional
records). '*'表示權威server回答標誌被設定(nt: 從而additional records就表示的是authority records).
因為沒有回答記錄, type, class, data欄位都被忽略.

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

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

SMB/CIFS 解碼

tcpdump 已能夠對SMB/CIFS/NBT相關應用的資料包內容進行解碼(nt: 分別為'Server Message Block Common', 'Internet File System'
'在TCP/IP上實現的網路協議NETBIOS的簡稱'. 這幾個服務通常使用UDP的137/138以及TCP的139port). 原來的對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 ([email protected])提供.

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號, 而不是源port號). 此請求資料為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通過2port,向網路icsd-net上監聽在220port的112節點發送了一個NBP應用資料包
(nt | rt: NBP, name binding protocol, 名稱繫結協議, 從資料來看, NBPserver會在port2提供此服務.
'DDP port 2' 可理解為'DDP 對應傳輸層的port2', DDP本身沒有port的概念, 這點未確定, 需補充).

第二行與第一行相似, 僅僅是源的全部地址可用'office'進行標識.
第三行表示: jssmag網路上的149節點通過235向icsd-net網路上的全部節點的2port(NBPport)傳送了資料包.(須要注意的是,
在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: "=:[email protected]*"
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:[email protected]*" 250
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:[email protected]*" 186

第一行表示: 網路icsd-net 中的節點112 通過220port向網路jssmag 中全部節點的port2傳送了對'LaserWriter'的名稱查詢請求(nt:
此處名稱可理解為一個資源的名稱, 比方印表機). 此查詢請求的序列號為190.

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

第三行也是對第一行請求的迴應: 節點techpit 通過2port向icsd-net.112節點的port220進行了迴應:我有'LaserWriter'資源, 其資源名稱
為'techpit', 並且在port186上提供改資源的服務. 此迴應的序列號為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:[email protected]+)
(frag id:[email protected])
(第一種格式表示, 此碎片之後還有興許碎片. 另外一種格式表示, 此碎片為最後一個碎片.)

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:[email protected]+)
arizona > rtsg: (frag 595a:[email protected])
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560

有幾點值得注意:
第一, 第二行的列印中, 地址後面沒有port號.
這是因為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 [email protected] 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  [email protected] algo:secret,...

    可通過[email protected] 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: 指[email protected] algo:secret), 還能夠在後面增加一個語法輸入檔名稱字供tcpdump 使用(nt：即把[email protected] algo:secret,... 中...換成一個語法檔名稱). 此檔案在接受到第一個ESP　包時會開啟此檔案, 所以最好此時把賦予tcpdump 的一些特權取消(nt: 可理解為, 這樣防範之後, 當該檔案為惡意編寫時,不至於造成過大損害).

-f  顯示外部的IPv4 地址時(nt: foreign IPv4 addresses, 可理解為, 非本機ip地址), 採用數字方式而不是名字.(此選項是用來對付Sun公司的NISserver的缺陷(nt: NIS, 網路資訊服務, tcpdump 顯示外部地址的名字時會用到她提供的名稱服務): 此NISserver在查詢非本地地址名字時,經常會陷入無盡的查詢迴圈).

    因為對外部(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  不正確地址(比方, 主機地址, port號)進行數字表示到名字表示的轉換.

-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, 上文已有描述,可搜尋'網路介面分接頭'keyword找到那裡)的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的