tcpdump命令的使用方法

　　AFS 請求和回應

　　AFS(nt: Andrew 文件系統(tǒng), 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 發(fā)送了一個RX數(shù)據(jù)包.

　　這是一個對于文件服務的請求數(shù)據(jù)包(nt: RX data packet, 發(fā)送數(shù)據(jù)包 , 可理解為發(fā)送包過去, 從而請求對方的服務), 這也是一個RPC

　　調(diào)用的開始(nt: RPC, remote procedure call). 此RPC 請求pike 執(zhí)行rename(nt: 重命名) 操作, 并指定了相關(guān)的參數(shù):

　　原目錄描述符為536876964/1/1, 原文件名為 '.newsrc.new', 新目錄描述符為536876964/1/1, 新文件名為 '.newsrc'.

　　主機pike 對此rename操作的RPC請求作了回應(回應表示rename操作成功, 因為回應的是包含數(shù)據(jù)內(nèi)容的包而不是異常包).

　　一般來說, 所有的'AFS RPC'請求被顯示時, 會被冠以一個名字(nt: 即decode, 解碼), 這個名字往往就是RPC請求的操作名.

　　并且, 這些RPC請求的部分參數(shù)在顯示時, 也會被冠以一個名字(nt | rt: 即decode, 解碼, 一般來說也是取名也很直接, 比如,

　　一個interesting 參數(shù), 顯示的時候就會直接是'interesting', 含義拗口, 需再翻).

　　這種顯示格式的設計初衷為'一看就懂', 但對于不熟悉AFS 和 RX 工作原理的人可能不是很

　　有用(nt: 還是不用管, 書面嚇嚇你的, 往下看就行).

　　如果 -v(詳細)標志被重復給出(nt: 如-vv), tcpdump 會打印出確認包(nt: 可理解為, 與應答包有區(qū)別的包)以及附加頭部信息

　　(nt: 可理解為, 所有包, 而不僅僅是確認包的附加頭部信息), 比如, RX call ID(請求包中'請求調(diào)用'的ID),

　　call number('請求調(diào)用'的編號), sequence number(nt: 包順序號),

　　serial number(nt | rt: 可理解為與包中數(shù)據(jù)相關(guān)的另一個順信號, 具體含義需補充), 請求包的標識. (nt: 接下來一段為重復描述,

　　所以略去了), 此外確認包中的MTU協(xié)商信息也會被打印出來(nt: 確認包為相對于請求包的確認包, Maximum Transmission Unit, 最大傳輸單元).

　　如果 -v 選項被重復了三次(nt: 如-vvv), 那么AFS應用類型數(shù)據(jù)包的'安全索引'('security index')以及'服務索引'('service id')將會

　　被打印.

　　對于表示異常的數(shù)據(jù)包(nt: abort packet, 可理解為, 此包就是用來通知接受者某種異常已發(fā)生), tcpdump 會打印出錯誤號(error codes).

　　但對于Ubik beacon packets(nt: Ubik 燈塔指示包, Ubik可理解為特殊的通信協(xié)議, beacon packets, 燈塔數(shù)據(jù)包, 可理解為指明通信中

　　關(guān)鍵信息的一些數(shù)據(jù)包), 錯誤號不會被打印, 因為對于Ubik 協(xié)議, 異常數(shù)據(jù)包不是表示錯誤, 相反卻是表示一種肯定應答(nt: 即, yes vote).

　　AFS 請求數(shù)據(jù)量大, 參數(shù)也多, 所以要求tcpdump的 snaplen 比較大, 一般可通過啟動tcpdump時設置選項'-s 256' 來增大snaplen, 以

　　監(jiān)測AFS 應用通信負載.

　　AFS 回應包并不顯示標識RPC 屬于何種遠程調(diào)用. 從而, tcpdump 會跟蹤最近一段時間內(nèi)的請求包, 并通過call number(調(diào)用編號), service ID

　　(服務索引) 來匹配收到的回應包. 如果回應包不是針對最近一段時間內(nèi)的請求包, tcpdump將無法解析該包.

　　KIP AppleTalk協(xié)議

　　(nt | rt: DDP in UDP可理解為, DDP, The AppleTalk Data Delivery Protocol,

　　相當于支持KIP AppleTalk協(xié)議棧的網(wǎng)絡層協(xié)議, 而DDP 本身又是通過UDP來傳輸?shù)?

　　即在UDP 上實現(xiàn)的用于其他網(wǎng)絡的網(wǎng)絡層，KIP AppleTalk是蘋果公司開發(fā)的整套網(wǎng)絡協(xié)議棧).

　　AppleTalk DDP 數(shù)據(jù)包被封裝在UDP數(shù)據(jù)包中, 其解封裝(nt: 相當于解碼)和相應信息的轉(zhuǎn)儲也遵循DDP 包規(guī)則.

　　(nt:encapsulate, 封裝, 相當于編碼, de-encapsulate, 解封裝, 相當于解碼, dump, 轉(zhuǎn)儲, 通常就是指對其信息進行打印).

　　/etc/atalk.names 文件中包含了AppleTalk 網(wǎng)絡和節(jié)點的數(shù)字標識到名稱的對應關(guān)系. 其文件格式通常如下所示:

　　number name

　　1.254 ether

　　16.1 icsd-net

　　1.254.110 ace

　　頭兩行表示有兩個AppleTalk 網(wǎng)絡. 第三行給出了特定網(wǎng)絡上的主機(一個主機會用3個字節(jié)來標識,

　　而一個網(wǎng)絡的標識通常只有兩個字節(jié), 這也是兩者標識的主要區(qū)別)(nt: 1.254.110 可理解為ether網(wǎng)絡上的ace主機).

　　標識與其對應的名字之間必須要用空白分開. 除了以上內(nèi)容, /etc/atalk.names中還包含空行以及注釋行(以'#'開始的行).

　　AppleTalk 完整網(wǎng)絡地址將以如下格式顯示:

　　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 主機/網(wǎng)絡的條目, 數(shù)據(jù)包的網(wǎng)絡地址將以數(shù)字形式顯示).

　　在第一行中, 網(wǎng)絡144.1上的節(jié)點209通過2端口,向網(wǎng)絡icsd-net上監(jiān)聽在220端口的112節(jié)點發(fā)送了一個NBP應用數(shù)據(jù)包

　　(nt | rt: NBP, name binding protocol, 名稱綁定協(xié)議, 從數(shù)據(jù)來看, NBP服務器會在端口2提供此服務.

　　'DDP port 2' 可理解為'DDP 對應傳輸層的端口2', DDP本身沒有端口的概念, 這點未確定, 需補充).

　　第二行與第一行類似, 只是源的全部地址可用'office'進行標識.

　　第三行表示: jssmag網(wǎng)絡上的149節(jié)點通過235向icsd-net網(wǎng)絡上的所有節(jié)點的2端口(NBP端口)發(fā)送了數(shù)據(jù)包.(需要注意的是,

　　在AppleTalk 網(wǎng)絡中如果地址中沒有節(jié)點, 則表示廣播地址, 從而節(jié)點標識和網(wǎng)絡標識最好在/etc/atalk.names有所區(qū)別.

　　nt: 否則一個標識x.port 無法確定x是指一個網(wǎng)絡上所有主機的port口還是指定主機x的port口).

　　tcpdump 可解析NBP (名稱綁定協(xié)議) and ATP (AppleTalk傳輸協(xié)議)數(shù)據(jù)包, 對于其他應用層的協(xié)議, 只會打印出相應協(xié)議名字(

　　如果此協(xié)議沒有注冊一個通用名字, 只會打印其協(xié)議號)以及數(shù)據(jù)包的大小.

　　NBP 數(shù)據(jù)包會按照如下格式顯示:

　　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

　　第一行表示: 網(wǎng)絡icsd-net 中的節(jié)點112 通過220端口向網(wǎng)絡jssmag 中所有節(jié)點的端口2發(fā)送了對'LaserWriter'的名稱查詢請求(nt:

　　此處名稱可理解為一個資源的名稱, 比如打印機). 此查詢請求的序列號為190.

　　第二行表示: 網(wǎng)絡jssmag 中的節(jié)點209 通過2端口向icsd-net.112節(jié)點的端口220進行了回應: 我有'LaserWriter'資源, 其資源名稱

　　為'RM1140', 并且在端口250上提供改資源的服務. 此回應的序列號為190, 對應之前查詢的序列號.

　　第三行也是對第一行請求的回應: 節(jié)點techpit 通過2端口向icsd-net.112節(jié)點的端口220進行了回應:我有'LaserWriter'資源, 其資源名稱

　　為'techpit', 并且在端口186上提供改資源的服務. 此回應的序列號為190, 對應之前查詢的序列號.

　　ATP 數(shù)據(jù)包的顯示格式如下:

　　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_2266: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

　　第一行表示節(jié)點 Jssmag.209 向節(jié)點helios 發(fā)送了一個會話編號為12266的請求包, 請求helios

　　回應8個數(shù)據(jù)包(這8個數(shù)據(jù)包的順序號為0-7(nt: 順序號與會話編號不同, 后者為一次完整傳輸?shù)木幪?

　　前者為該傳輸中每個數(shù)據(jù)包的編號. transaction, 會話, 通常也被叫做傳輸)). 行尾的16進制數(shù)字表示

　　該請求包中'userdata'域的值(nt: 從下文來看, 這并沒有把所有用戶數(shù)據(jù)都打印出來 ).