Linux tcpdump 命令詳解
簡介
用簡單的話來定義tcpdump，就是：dump the traffic on a network，根據使用者的定義對網路上的資料包進行截獲的包分析工具。 tcpdump可以將網路中傳送的資料包的“頭”完全截獲下來提供分析。它支援針對網路層、協議、主機、網路或埠的過濾，並提供and、or、not等邏輯語句來幫助你去掉無用的資訊。
實用命令例項
預設啟動
| 1 | tcpdump |
普通情況下，直接啟動tcpdump將監視第一個網路介面上所有流過的資料包。
監視指定網路介面的資料包
| 1 | tcpdump-ieth1 |
如果不指定網絡卡，預設tcpdump只會監視第一個網路介面，一般是eth0，下面的例子都沒有指定網路介面。
監視指定主機的資料包
列印所有進入或離開sundown的資料包.
| 1 | tcpdump host sundown |
也可以指定ip，例如截獲所有210.27.48.1 的主機收到的和發出的所有的資料包
| 1 | tcpdump host210.27.48.1 |
列印helios 與 hot 或者與 ace 之間通訊的資料包
| 1 | tcpdump host helios and(hot orace) |
截獲主機210.27.48.1 和主機210.27.48.2 或210.27.48.3的通訊
| 1 | tcpdump host210.27.48.1and(210.27.48.2or210.27.48.3) |
列印ace與任何其他主機之間通訊的IP 資料包， 但不包括與helios之間的資料包.
| 1 | tcpdump ip host ace andnothelios |
如果想要獲取主機210.27.48.1除了和主機210.27.48.2之外所有主機通訊的ip包，使用命令：
| 1 | tcpdump ip host210.27.48.1and!210.27.48.2 |
截獲主機hostname傳送的所有資料
| 1 | tcpdump-ieth0 src host hostname |
監視所有送到主機hostname的資料包
| 1 | tcpdump-ieth0 dst host hostname |
監視指定主機和埠的資料包
如果想要獲取主機210.27.48.1接收或發出的telnet包，使用如下命令
| 1 | tcpdump tcp port23andhost210.27.48.1 |
對本機的udp 123 埠進行監視 123 為ntp的服務埠
| 1 | tcpdump udp port123 |
監視指定網路的資料包
列印本地主機與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 andnotnet localnet |
監視指定協議的資料包
列印TCP會話中的的開始和結束資料包， 並且資料包的源或目的不是本地網路上的主機.(nt: localnet， 實際使用時要真正替換成本地網路的名字))
| 1 | tcpdump'tcp[tcpflags] |
列印所有源或目的埠是80， 網路層協議為IPv4， 並且含有資料，而不是SYN，FIN以及ACK-only等不含資料的資料包.(ipv6的版本的表示式可做練習)
| 1 | tcpdump'tcp port80and(((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-ieth1-t-s0-c100anddst port!22andsrc net192.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-XvvennSs0-ieth0 tcp[20:2]=0x4745ortcp[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’
(遠端登入)過程開始階段的資料包樣例:
| 12 | arp who-has csam tell rtsgarp 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 ([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位元組資料.
Wr