tcpdump命令的使用方法(6)
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ù)包.
這是一個對于文件服務(wù)的請求數(shù)據(jù)包(nt: RX data packet, 發(fā)送數(shù)據(jù)包 , 可理解為發(fā)送包過去, 從而請求對方的服務(wù)), 這也是一個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', 含義拗口, 需再翻).
這種顯示格式的設(shè)計初衷為'一看就懂', 但對于不熟悉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')以及'服務(wù)索引'('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時設(shè)置選項'-s 256' 來增大snaplen, 以
監(jiān)測AFS 應用通信負載.
AFS 回應包并不顯示標識RPC 屬于何種遠程調(diào)用. 從而, tcpdump 會跟蹤最近一段時間內(nèi)的請求包, 并通過call number(調(diào)用編號), service ID
(服務(wù)索引) 來匹配收到的回應包. 如果回應包不是針對最近一段時間內(nèi)的請求包, tcpdump將無法解析該包.
KIP AppleTalk協(xié)議
(nt | rt: DDP in UDP可理解為, DDP, The AppleTalk Data Delivery Protocol,
相當于支持KIP AppleTalk協(xié)議棧的網(wǎng)絡(luò)層協(xié)議, 而DDP 本身又是通過UDP來傳輸?shù)?
即在UDP 上實現(xiàn)的用于其他網(wǎng)絡(luò)的網(wǎng)絡(luò)層,KIP AppleTalk是蘋果公司開發(fā)的整套網(wǎng)絡(luò)協(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)絡(luò)和節(jié)點的數(shù)字標識到名稱的對應關(guān)系. 其文件格式通常如下所示:
number name
1.254 ether
16.1 icsd-net
1.254.110 ace
頭兩行表示有兩個AppleTalk 網(wǎng)絡(luò). 第三行給出了特定網(wǎng)絡(luò)上的主機(一個主機會用3個字節(jié)來標識,
而一個網(wǎng)絡(luò)的標識通常只有兩個字節(jié), 這也是兩者標識的主要區(qū)別)(nt: 1.254.110 可理解為ether網(wǎng)絡(luò)上的ace主機).
標識與其對應的名字之間必須要用空白分開. 除了以上內(nèi)容, /etc/atalk.names中還包含空行以及注釋行(以'#'開始的行).
AppleTalk 完整網(wǎng)絡(luò)地址將以如下格式顯示:
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)絡(luò)的條目, 數(shù)據(jù)包的網(wǎng)絡(luò)地址將以數(shù)字形式顯示).
在第一行中, 網(wǎng)絡(luò)144.1上的節(jié)點209通過2端口,向網(wǎng)絡(luò)icsd-net上監(jiān)聽在220端口的112節(jié)點發(fā)送了一個NBP應用數(shù)據(jù)包
(nt | rt: NBP, name binding protocol, 名稱綁定協(xié)議, 從數(shù)據(jù)來看, NBP服務(wù)器會在端口2提供此服務(wù).
'DDP port 2' 可理解為'DDP 對應傳輸層的端口2', DDP本身沒有端口的概念, 這點未確定, 需補充).
第二行與第一行類似, 只是源的全部地址可用'office'進行標識.
第三行表示: jssmag網(wǎng)絡(luò)上的149節(jié)點通過235向icsd-net網(wǎng)絡(luò)上的所有節(jié)點的2端口(NBP端口)發(fā)送了數(shù)據(jù)包.(需要注意的是,
在AppleTalk 網(wǎng)絡(luò)中如果地址中沒有節(jié)點, 則表示廣播地址, 從而節(jié)點標識和網(wǎng)絡(luò)標識最好在/etc/atalk.names有所區(qū)別.
nt: 否則一個標識x.port 無法確定x是指一個網(wǎng)絡(luò)上所有主機的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)絡(luò)icsd-net 中的節(jié)點112 通過220端口向網(wǎng)絡(luò)jssmag 中所有節(jié)點的端口2發(fā)送了對'LaserWriter'的名稱查詢請求(nt:
此處名稱可理解為一個資源的名稱, 比如打印機). 此查詢請求的序列號為190.
第二行表示: 網(wǎng)絡(luò)jssmag 中的節(jié)點209 通過2端口向icsd-net.112節(jié)點的端口220進行了回應: 我有'LaserWriter'資源, 其資源名稱
為'RM1140', 并且在端口250上提供改資源的服務(wù). 此回應的序列號為190, 對應之前查詢的序列號.
第三行也是對第一行請求的回應: 節(jié)點techpit 通過2端口向icsd-net.112節(jié)點的端口220進行了回應:我有'LaserWriter'資源, 其資源名稱
為'techpit', 并且在端口186上提供改資源的服務(wù). 此回應的序列號為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ù)都打印出來 ).