2. adb push tcpdump into the Android system: $adb push tcpdump /data/local/    , before that ,you must adb remount your system.

3.chmod 777 /data/local/tcpdump

4. in the folder /data/local, run the cmd: ./tcpdump -i any -p -vv -s 0 -w capture.pcap

5. run the android app that you want to capture, you will find the capture file. pull it your local position, open it using the wiresharp.

附錄tcpdump 命令

簡介

用簡單的話來定義tcpdump，就是：dump the traffic on a network，根據使用者的定義對網路上的資料包進行截獲的包分析工具。 tcpdump可以將網路中傳送的資料包的“頭”完全截獲下來提供分析。它支援針對網路層、協議、主機、網路或埠的過濾，並提供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 

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

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

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

tcpdump tcp port 23 and host 210.27.48.1

對本機的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資料包格式的資訊, 以及每個域的含義可以參看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號, 而不是源埠號). 此請求資料為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

頭