主機 h2opolo 訪問 helios 上的 域名服務, 詢問和 UCbvax.berkeley.edu. 關聯的 地址記錄(qtype=A). 查詢號是 `3'. `+' 表明 設置了 遞歸請求 標志. 查詢長度是 37 字節, 不包括 UDP 和 IP 頭. 查詢操作 是 普通的 Query 操作, 因此 op 域 可以 忽略. 如果 op 設置成 其他什麼東西, 它應該 顯示在 `3' 和 `+' 之間. 類似的, qclass 是 普通的 C_IN 類型, 也被 忽略了. 其他類型的 qclass 應該 在 `A' 後面 顯示. Tcpdump 會檢查 一些 不規則 情況, 相應的 結果 作為 補充域 放在 方括號內: 如果 某個 查詢 包含 回答, 名字服務 或 管理機構部分, 就把 ancount, nscount, 或 arcount 顯示成 `[na]', `[nn]' 或 `[nau]', 這裡的 n 代表 相應的 數量. 如果 在 第二和第三字節 中, 任何一個 回答位(AA, RA 或 rcode) 或 任何一個 `必須為零' 的位 被 置位, 就顯示 `[b2&3=x]', 這裡的 x 是 報頭 第二和第三字節 的 16進制數. UDP 名字服務回答 名字服務回答的 格式 是 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 個 回答記錄, 3 個 名字服務記錄 和 7 個管理結構記錄. 第一個 回答紀錄 的 類型是 A (地址), 數據是 internet 地址 128.32.137.3. 回答的 全長 為 273 字節, 不包括 UDP 和 IP 報頭. 作為 A 記錄的 class(C_IN) 可以 忽略 op (詢問) 和 rcode (NoError). 在第二個例子裡, helios 對 標識為2 的 詢問 作出 域名不存在 (NXDomain) 的 回答, 沒有 回答記錄, 一個 名字服務記錄, 而且 沒有 管理結構. `*' 表明 設置了 權威回答(authoritative answer). 由於 沒有 回答記錄, 這裡就 不顯示 type, class 和 data. 其他 標志 字符 可以 顯示為 `-' (沒有設置遞歸有效(RA)) 和 `' (設置 消息截短(TC)). 如果 `問題' 部分 沒有 有效的 內容, 就 顯示 `[nq]'. 注意 名字服務的 詢問和回答 一般說來 比較大, 68 字節的 snaplen 可能無法 捕捉到 足夠的 報文內容. 如果 你 的確 在 研究 名字服務 的 情況, 可以使用 -s 選項 增大 捕捉緩沖區. `-s 128' 應該 效果 不錯了. NFS 請求和響應 Sun NFS (網絡文件系統) 的 請求和響應 顯示格式 是: 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 發送 號碼為 6709 的 交易會話 (注意 源主機 後面的 數字 是 交易號, 不是 端口). 這項請求 長 112 字節, 不包括 UDP 和 IP 報頭. 在 文件句柄 (fh) 21,24/10.731657119 上執行 readlink (讀取 符號連接) 操作. (如果 運氣 不錯, 就象 這種情況, 文件句柄 可以 依次翻譯成 主次設備號, i 節點號, 和 事件號(generation number). ) Wrl 回答 `ok' 和 連接的 內容. 在第三行, sushi 請求 wrl 在 目錄文件 9,74/4096.6878 中 查找 `xcolors'. 注意 數據的 打印格式 取決於 操作類型. 格式 應該是 可以自我說明的. 給出 -v (verbose) 選項 可以 顯示 附加信息. 例如: 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, 和 分片域, 在 這個例子裡 把它們省略了.) 在第一行, sushi 請求 wrl 從 文件 21,11/12.195 的 偏移位置 24576 開始, 讀取 8192 字節. Wrl 回答 `ok'; 第二行 顯示的 報文 是 應答的 第一個 分片, 因此 只有 1472 字節 (其余數據 在 後續的 分片中傳過來, 但由於 這些分片裡 沒有 NFS 甚至 UDP 報頭, 因此 根據 所使用的 過濾器表達式, 有可能 不顯示). -v 選項 還會 顯示 一些 文件屬性 (它們 作為 文件數據 的 附帶部分 傳回來): 文件類型 (普通文件 ``REG''), 存取模式 (八進制數), uid 和 gid, 以及 文件大小. 如果再給一個 -v 選項 (-vv), 還能 顯示 更多的細節. 注意 NFS 請求 的 數據量 非常大, 除非 增加 snaplen, 否則 很多細節 無法顯示. 試一試 `-s 192' 選項. NFS 應答報文 沒有明確 標明 RPC 操作. 因此 tcpdump 保留有 ``近來的'' 請求 記錄, 根據 交易號 匹配 應答報文. 如果 應答報文 沒有 相應的 請求報文, 它 就 無法分析. KIP Appletalk (UDP 上的 DDP) Appletalk DDP 報文 封裝在 UDP 數據報 中, 解包後 按 DDP 報文 轉儲 (也就是說, 忽略 所有的 UDP 報頭 信息). 文件 /etc/atalk.names 用來 把 appletalk 網絡和節點號 翻譯成 名字. 這個文件 的 行格式 是 number name 1.254 ether 16.1 icsd-net 1.254.110 ace 前兩行 給出了 appletalk 的 網絡名稱. 第三行 給出 某個主機 的 名字 (主機和網絡 依據 第三組 數字 區分 - 網絡號 一定 是 兩組數字, 主機號 一定 是 三組 數字.) 號碼 和 名字 用 空白符(空格或tab) 隔開. /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 , 或者 裡面 缺少 有效項目, 就以 數字形式 顯示 地址.) 第一個例子裡, 網絡 144.1 的 209 節點的 NBP (DDP 端口 2) 向 網絡 icsd 的 112 節點 的 220 端口 發送數據. 第二行 和 上面 一樣, 只是 知道了 源節點 的 全稱 (`office'). 第三行 是從 網絡 jssmag 的 149 節點 的 235 端口 向 icsd-net 的 NBP 端口廣播 (注意 廣播地址 (255) 隱含在 無主機號的 網絡名字 中 - 所以 在 /etc/atalk.names 中 區分 節點名 和 網絡名 是個 好主意). Tcpdump 可以 翻譯 NBP (名字聯結協議) 和 ATP (Appletalk 交互協議) 的 報文內容. 其他協議 只轉儲 協議名稱 (或號碼, 如果 還 沒給 這個協議 注冊 名稱) 和 報文大小. NBP 報文 的 輸出格式 就象 下面的 例子: 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 第一行 是 網絡 icsd 的 112 主機 在 網絡 jssmag 上的 廣播, 對 名字 laserwriter 做 名字查詢請求. 名字查詢請求 的 nbp 標識號 是 190. 第二行 顯示的是 對 這個請求 的 回答 (注意 它們 有 同樣的 標識號), 主機 jssmag.209 表示 在它的 250 端口 注冊了 一個 laserwriter 的 資源, 名字是 "RM1140". 第三行 是 這個請求 的 其他回答, 主機 techpit 的 186 端口 有 laserwriter 注冊的 "techpit". ATP 報文 格式 如 下例 所示: jssmag.209.165 > helios.132: atp-req 12266 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:4 (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 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 0xae030001 jssmag.209.133 > helios.132: atp-req* 12267 0xae030002 Jssmag.209 向 主機 helios 發起 12266 號 交易, 請求 8 個 報文(`'). 行尾的 十六進制數 是 請求中 `userdata' 域 的 值.
