歡迎您光臨本站 註冊首頁

TCPDUMP中文手冊

←手機掃碼閱讀     火星人 @ 2014-03-12 , reply:0
  TCPDUMP
Section: Maintenance Commands (8)
Updated: 30 June 1997

-------------------------------------------------------

名稱 (NAME)
tcpdump - 轉儲網路上的數據流
總覽 (SYNOPSIS)
tcpdump [ -adeflnNOpqStvx ] [ -c count ] [ -F file ]

[ -i interface ] [ -r file ] [ -s snaplen ]

[ -T type ] [ -w file ] [ expression ]

描述 (DESCRIPTION)
Tcpdump 列印出 在某個 網路界面 上, 匹配 布爾表達式 expression 的 報頭.

對於 SunOS 的 nit 或 bpf 界面: 要 運行 tcpdump , 你 必須 有 /dev/nit 或 /dev/bpf* 的 讀訪問 許可權.

對於 Solaris 的 dlpi: 你 必須 有 網路模擬設備 (network pseudo device), 如 /dev/le 的 讀訪問 許可權.

對於 HP-UX 的 dlpi: 你 必須 是 root, 或者 把它 安裝成 root 的 設置uid 程序. 對於 IRIX 的 snoop: 你 必須 是 root, 或者 把它 安裝成 root 的 設置uid 程序. 對於 Linux: 你 必須 是 root, 或者 把它 安裝成 root 的 設置uid 程序.

對於 Ultrix 和 Digital UNIX: 一旦 超級用戶 使用 pfconfig(8) 開放了 promiscuous 操作模式 (promiscuous-mode), 任何用戶 都可以 運行 tcpdump.

對於 BSD: 你 必須 有 /dev/bpf* 的 讀訪問 許可權.


選項 (OPTIONS)
-a
試著 把 網路和廣播地址 轉換成 名稱.
-c
當 收到 count 報文 后 退出.
-d
把 編譯好的 報文匹配模板 (packet-matching code) 翻譯成 可讀形式, 傳往 標準輸出, 然後退出.
-dd
把 報文匹配模板 (packet-matching code) 以 C 程序片斷 的 形式 輸出.
-ddd
把 報文匹配模板 (packet-matching code) 以 十進位數 形式 輸出 (前面 加上 總數).
-e
每行 都 顯示 鏈路層報頭.
-f
用 數字形式 顯示 '外部的' 互聯網地址, 而不是 字元形式 (這個 選項 用來繞開 腦殼壞光的 SUN 黃頁伺服器 的 問題 --- 一般說來 它 翻譯 外部網路數字地址 的時候 會 長期掛起).
-F
把 file 的內容 用作 過濾表達式. 忽略 命令行 上 的 表達式.
-i
監聽 interface. 如果 不指定 介面, tcpdump 在 系統 的 介面 清單 中, 尋找 號碼最小, 已經 配置好的 介面 (loopback 除外). 選中的時候 會 中斷 連接.
-l
行緩衝 標準輸出. 可用於 捕捉 數據 的 同時 查看 數據. 例如,
``tcpdump -l | tee dat'' or ``tcpdump -l > dat & tail -f dat''.
-n
別把 地址 轉換成 名字 (就是說, 主機地址, 埠號等)
-N
不顯示 主機名字 中的 域名 部分. 例如, 如果 使用 這個 選項, tcpdump 只顯示 ``nic'', 而不是 ``nic.ddn.mil''.
-O
禁止運行 報文匹配模板 的 優化器. 只有 當你 懷疑 優化器 有 bug 時 才有用.
-p
禁止 把 介面 置成 promiscuous 模式. 注意, 介面 有可能 因 其他原因而 處於 promiscuous 模式; 因此, '-p' 不能 作為 `ether host {local-hw-addr} 或 ether broadcast' 的 簡寫.
-q
快速輸出. 顯示 較少的 協議信息, 輸出行 會 短一點點.
-r
從 file 中 讀入 數據報 (文件 是用 -w 選項 創建的). 如果 file 是 ``-'', 就 讀 標準輸入.
-s
從每個 報文 中 截取 snaplen 位元組的數據, 而不是 預設的 68 (如果是 SunOS 的 NIT, 最小值是 96). 68 個位元組 適用於 IP, ICMP, TCP 和 UDP, 但是 有可能 截掉 名字伺服器 和 NFS 報文 的 協議 信息 (見下面). 輸出時 如果指定 ``[|proto]'', tcpdump 可以 指出 那些 捕捉量過小的 數據報, 這裡的 proto 是 截斷髮生處 的 協議層 名稱. 注意, 採用 更大的 捕捉範圍 既增加了 處理 報文 的 時間, 又 相應的 減少了報文的 緩衝 數量, 可能 導致 報文的丟失. 你 應該 把 snaplen 設的盡量小, 只要 能夠 容納 你 需要 的 協議信息 就可以了.

-T
把 通過 "expression" 挑選出來的 報文 解釋成 指定的 type. 目前 已知 的 類型 有: rpc (遠程過程調用 Remote Procedure Call), rtp (實時應用協議 Real-Time Applications protocol), rtcp (實時應用控制協議 Real-Time Applications control protocol), vat (可視音頻工具 Visual Audio Tool), 和 wb (分散式白板 distributed White Board).
-S
顯示 絕對的, 而不是 相對的 TCP 序列號.
-t
禁止 顯示 時戳標誌.
-tt
顯示 未格式化的 時戳標誌.
-v
(稍微多一點) 繁瑣的輸出. 例如, 顯示 IP 數據報 中的 生存周期 和 服務類型.
-vv
更繁瑣的輸出. 例如, 顯示 NFS 應答報文 的 附加域.
-w
把 原始報文 存進 file, 而不是 分析 和 顯示. 它們 可以 以後 用 -r 選項 顯示. 如果 file 是 ``-'', 就 寫往 標準輸出.
-x
以 16 進位數 形式 顯示 每一個 報文 (去掉鏈路層報頭后) . 可以 顯示 較小的 完整 報文, 否則 只 顯示 snaplen 個 位元組 .
expression
用來 選擇 要 轉儲 的 數據報. 如果 沒有 指定 expression , 就 轉儲 網路的 全部 報文. 否則, 只轉儲 相對 expression 為 `true' 的 數據報.
expression 一個或多個 原語 (primitive) 組成. 原語 通常 由 一個 標識 (id, 名稱或數字), 和 標識 前面的 一個或多個 修飾子(qualifier) 組成. 修飾子 有 三種 不同的類型:

type
類型修飾子 指出 標識名稱 或 標識數字 代表 什麼 類型的東西. 可以使用的 類型 有 host, net 和 port. 例如, `host foo', `net 128.3', `port 20'. 如果 不指定 類型修飾子, 就使用 預設的 host .

dir
方向修飾子 指出 相對於 標識 的 傳輸方向 (數據是 傳入還是傳出 標識). 可以使用的 方向 有 src, dst, src or dst 和 src and dst. 例如, `src foo', `dst net 128.3', `src or dst port ftp-data'. 如果 不指定 方向修飾子, 就使用 預設的 src or dst . 對於 `null' 鏈路層 (就是說 象 slip 之類的 點到點 協議), 用 inbound 和 outbound 修飾子 指定 所需的 傳輸方向.
proto
協議修飾子 要求 匹配 指定的協議. 可以使用的 協議 有: ether, fddi, ip, arp, rarp, decnet, lat, sca, moprc, mopdl, tcp 和 udp. 例如, `ether src foo', `arp net 128.3', `tcp port 21'. 如果 不指定協議修飾子, 就使用 所有 符合 類型 的 協議. 例如, `src foo' 指 `(ip 或 arp 或 rarp) src foo' (注意後者不符合語法), `net bar' 指 `(ip 或 arp 或 rarp) net bar', `port 53' 指 `(tcp 或 udp) port 53'.
[`fddi' 實際上 是 `ether' 的 別名; 分析器 把 它們 視為 ``用在 指定 網路介面 上的 數據鏈路層.'' FDDI 報頭 包含 類似於 以太協議的 源目地址, 而且 通常 包含 類似於 以太協議 的 報文類型, 因此 你 可以過濾 FDDI 域, 就象 分析 以太協議 一樣. FDDI 報頭 也 包含 其他 域, 但是你 不能 在 過濾器 表達式 里 顯式描述.]


作為 上述 的 補充, 有一些 特殊的 `原語' 關鍵字, 它們 不同於 上面的模式: gateway, broadcast, less, greater 和 數學表達式. 這些 在 後面 有 敘述.

更複雜的 過濾器表達式 可以 通過 and, or 和 not 連接 原語 來 組建. 例如, `host foo and not port ftp and not port ftp-data'. 為了少敲點鍵, 可以忽略 相同的 修飾子. 例如, `tcp dst port ftp or ftp-data or domain' 實際上 就是 `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.

允許的 原語 有:

dst host host
如果 報文中 IP 的 目的地址域 是 host, 則 邏輯 為 真. host 既可以 是 地址, 也可以 是 主機名.
src host host
如果 報文中 IP 的 源地址域 是 host, 則 邏輯 為 真.
host host
如果 報文中 IP 的 源地址域 或者 目的地址域 是 host, 則 邏輯 為 真. 上面 所有的 host 表達式 都可以 加上 ip, arp, 或 rarp 關鍵字 做 前綴, 就象:
ip host host

它等價於:
ether proto \ip and host host

如果 host 是 擁有 多個 IP 地址 的 主機名, 它的 每個地址 都會 被查驗.

ether dst ehost
如果 報文的 以太目的地址 是 ehost, 則 邏輯 為 真. Ehost 既可以是 名字 (/etc/ethers 里有), 也可以是 數字 (有關 數字格式 另見 ethers(3N) ).
ether src ehost
如果 報文的 以太源地址 是 ehost, 則 邏輯 為 真.
ether host ehost
如果 報文的 以太源地址 或 以太目的地址 是 ehost, 則 邏輯 為 真.
gateway host
如果 報文 把 host 當做 網關, 則 邏輯 為 真. 也就是說, 報文的以太源或目的地址 是 host, 但是 IP 的 源目地址 都不是 host. host 必須 是個 主機名, 而且 必須 存在 /etc/hosts 和 /etc/ethers 中. (一個等價的表達式是
ether host ehost and not host host

對於 host / ehost, 它既可以是 名字, 也可以是 數字.)
dst net net
如果 報文的 IP 目的地址 屬於 網路號 net, 則 邏輯 為 真. net 既可以 是 名字 (存在 /etc/networks 中), 也可以是 網路號. (詳見 networks(4)).
src net net
如果 報文的 IP 源地址 屬於 網路號 net, 則 邏輯 為 真.
net net
如果 報文的 IP 源地址 或 目的地址 屬於 網路號 net, 則 邏輯 為 真.
net net mask mask
如果 IP 地址 匹配 指定 網路掩碼(netmask) 的 net, 則 邏輯 為 真. 本原語 可以用 src 或 dst 修飾.
net net/len
如果 IP 地址 匹配 指定 網路掩碼 的 net, 則 邏輯 為 真, 掩碼 的 有效位寬 為 len. 本原語 可以用 src 或 dst 修飾.
dst port port
如果 報文 是 ip/tcp 或 ip/udp, 並且 目的埠 是 port, 則 邏輯 為 真. port 是一個 數字, 也可以是 /etc/services 中 說明過的 名字 (參看 tcp(4P) 和 udp(4P)). 如果 使用 名字, 則 檢查 埠號 和 協議. 如果 使用 數字, 或者 有二義的名字, 則 只檢查 埠號 (例如, dst port 513 將顯示 tcp/login 的數據 和 udp/who 的數據, 而 port domain 將顯示 tcp/domain 和 udp/domain 的數據).
src port port
如果 報文 的 源埠號 是 port, 則 邏輯 為 真.
port port
如果 報文 的 源埠 或 目的埠 是 port, 則 邏輯 為 真. 上述的 任意一個 埠表達式 都可以 用 關鍵字 tcp 或 udp 做 前綴, 就象:
tcp src port port

它 只匹配 源埠 是 port 的 TCP 報文.
less length
如果 報文 的 長度 小於等於 length, 則 邏輯 為 真. 它等同於:
len <= length.

greater length
如果 報文 的 長度 大於等於 length, 則 邏輯 為 真. 它等同於:
len >= length.

ip proto protocol
如果 報文 是 IP 數據報(參見 ip(4P)), 其 內容 的 協議類型 是 protocol, 則 邏輯 為 真. Protocol 可以是 數字, 也可以是 下列 名稱 中的 一個: icmp, igrp, udp, nd, 或 tcp. 注意 這些 標識符 tcp, udp, 和 icmp 也同樣是 關鍵字, 所以 必須 用 反斜杠(\) 轉義, 在 C-shell 中 應該是 \\ .
ether broadcast
如果 報文 是 以太廣播報文, 則 邏輯 為 真. 關鍵字 ether 是 可選的.
ip broadcast
如果 報文 是 IP廣播報文, 則 邏輯 為 真. Tcpdump 檢查 全0 和 全1 廣播約定, 並且 檢查 本地 的 子網掩碼.
ether multicast
如果 報文 是 以太多目傳送報文(multicast), 則 邏輯 為 真. 關鍵字 ether 是 可選的. 這實際上 是 `ether[0] & 1 != 0' 的簡寫.
ip multicast
如果 報文 是 IP多目傳送報文, 則 邏輯 為 真.
ether proto protocol
如果 報文協議 屬於 以太類型 的 protocol, 則 邏輯 為 真. Protocol 可以是 數字, 也可以是 名字, 如 ip, arp, 或 rarp. 注意 這些 標識符 也是 關鍵字, 所以 必須 用 反斜杠(\) 轉義. [如果是 FDDI (例如, `fddi protocol arp'), 協議 標識 來自 802.2 邏輯鏈路控制(LLC)報頭, 它 通常 位於 FDDI 報頭 的 頂層. 當 根據 協議標識過濾 報文 時, Tcpdump 假設 所有的 FDDI 報文 含有 LLC 報頭, 而且 LLC 報頭 用的是 SNAP 格式.]

decnet src host
如果 DECNET 的 源地址 是 host, 則 邏輯 為 真, 該 主機地址 的 形式 可能 是 ``10.123'', 或者是 DECNET 主機名. [只有 配置成 運行 DECNET 的 Ultrix 系統 支持 DECNET 主機名.]
decnet dst host
如果 DECNET 的 目的地址 是 host, 則 邏輯 為 真.
decnet host host
如果 DECNET 的 源地址 或 目的地址 是 host, 則 邏輯 為 真.
ip, arp, rarp, decnet
是:
ether proto p

的 簡寫 形式, 其中 p 為 上述 協議 的 一種.
lat, moprc, mopdl
是:
ether proto p

的 簡寫 形式, 其中 p 為 上述 協議 的 一種. 注意 tcpdump 目前 不知道 如何 分析 這些 協議.
tcp, udp, icmp
是:
ip proto p

的 簡寫 形式, 其中 p 為 上述 協議 的 一種.
expr relop expr
如果 這個 關係 成立, 則 邏輯 為 真, 其中 relop 是 >, <, >=, <=, =, != 之一, expr 是 數學表達式, 由 常整數(標準C語法形式), 普通的 二進位運算符 [+, -, *, /, &, |], 一個 長度運算符, 和 指定的 報文數據訪問算符 組成. 要 訪問 報文內 的 數據, 使用 下面的 語法:
proto [ expr : size ]

Proto 是 ether, fddi, ip, arp, rarp, tcp, udp, or icmp 之一, 同時 也指出了 下標 操作 的協議層. expr 給出 位元組單位 的 偏移量, 該 偏移量 相對於 指定的 協議層. Size 是 可選項, 指出 感興趣的 位元組數; 它可以 是 1, 2, 4, 預設為 1 位元組. 由 關鍵字 len 給出的 長度運算符 指明 報文 的 長度.
例如, `ether[0] & 1 != 0' 捕捉 所有的 多目傳送 報文. 表達式 `ip[0] & 0xf != 5' 捕捉 所有 帶 可選域 的 IP 報文. 表達式 `ip[6:2] & 0x1fff = 0' 只捕捉 未分片 和 片偏移為0 的 數據報. 這種 檢查 隱含在 tcp 和 udp 下標操作 中. 例如, tcp[0] 一定是 TCP 報頭 的 第一個 位元組, 而不是 其中 某個 IP片 的 第一個 位元組.

原語 可以 用 下述 方法 結合使用:

園括弧 括起來的 原語 和 操作符 (園括弧 在 Shell 中 有專用, 所以必須轉義).
取反操作 (`!' or `not').
連結操作 (`&&' or `and').
或操作 (`||' or `or').
取反操作 有 最高優先順序. 或操作 和 連結操作 有 相同的 優先順序, 運算時 從左到右 結合. 注意 連結操作 需要 顯式的 and 算符, 而不是 並列放置.

如果 給出 標識符, 但沒給 關鍵字, 那麼 暗指 最近使用 的 關鍵字. 例如,

not host vs and ace

作為
not host vs and host ace

的 簡寫形式, 不應該 和
not ( host vs or ace )

混淆.
表達式參數 可以 作為 單個 參數 傳給 tcpdump, 也可以 作為 複合參數, 後者 更方便 一些. 一般說來, 如果 表達式 包含 Shell 元字元(metacharacter), 傳遞 單個 括起來的 參數 要 容易 一些. 複合參數 在 被解析前 用 空格 聯接 一起.


示例 (EXAMPLES)
顯示 所有 進出 sundown 的 報文:

tcpdump host sundown

顯示 helios 和 主機 hot, ace 之間 的 報文 傳送:

tcpdump host helios and \( hot or ace \)

顯示 ace 和 除了 helios 以外的 所有 主機 的 IP報文:

tcpdump ip host ace and not helios

顯示 本地的主機 和 Berkeley的主機 之間 的 網路數據:

tcpdump net ucb-ether

顯示 所有 通過 網關 snup 的 ftp 報文 (注意 這個 表達式 被 單引號 括起, 防止 shell 解釋 園括弧):

tcpdump 'gateway snup and (port ftp or ftp-data)'

顯示 既不是 來自 本地主機, 也不是 傳往 本地主機 的 網路數據 (如果 你 把 網關 通往 某個 其他網路, 這個 做法 將不會 把 數據 發往 你的本地網路).

tcpdump ip and not net localnet

顯示 每個 TCP會話 的 起始 和 結束 報文 (SYN 和 FIN 報文), 而且 會話方 中有一個 遠程主機.

tcpdump 'tcp[13] & 3 != 0 and not src and dst net localnet'

顯示 經過 網關 snup 中 大於 576 位元組的 IP 數據報:

tcpdump 'gateway snup and ip[2:2] > 576'

顯示 IP 廣播 或 多目傳送 的 數據報, 這些 報文 不是 通過 乙太網 的 廣播 或 多目傳送 形式 傳送的:

tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

顯示 所有 不是 迴響請求/應答 的 ICMP 報文 (也就是說, 不是 ping 報文):

tcpdump 'icmp[0] != 8 and icmp[0] != 0"

輸出格式 (OUTPUT FORMAT)
tcpdump 的 輸出格式 取決於 協議. 下面的 描述 給出 大多數 格式 的簡要說明 和 範例.

鏈路層報頭 (Link Level Headers)

如果 給出 '-e' 選項 就 顯示 鏈路層報頭. 在 乙太網上, 顯示 報文的 源目地址, 協議 和 報文長度.

在 FDDI 網路上, '-e' 選項 導致 tcpdump 顯示出 `幀控制(frame control)' 域, 源目地址 和 報文長度. (`幀控制' 域 負責 解釋 其餘的 報文. 普通報文 (比如說 載有 IP數據報) 是 `非同步' 報文, 優先順序 介於 0 到 7; 例如, `async4'. 這些 被認為 載有 802.2 邏輯鏈路控制(LLC) 報文; 如果 它們 不是 ISO 數據報 或者 所謂的 SNAP 報文, 就顯示出 LLC 報頭.

(注意: 以下 描述中 假設 你 熟悉 RFC-1144 中說明的 SLIP 壓縮演算法.)

在 SLIP 鏈路上, tcpdump 顯示出 方向指示 (``I'' 指 inbound, ``O'' 指 outbound), 報文類型 和 壓縮信息. 首先顯示的 是 報文類型. 有三種 類型 ip, utcp 和 ctcp. 對於 ip 報文 不再 顯示 更多的 鏈路信息. 對於 TCP 報文, 在 類型 後面 顯示 連接標識. 如果 報文 是 壓縮過的, 就顯示出 編碼的報頭. 特殊 情形 以 *S+n 和 *SA+n 的 形式 顯示, 這裡的 n 是 順序號 (或順序號 及其 確認) 發生 的 改變 總和. 如果 不是 特殊 情形, 就顯示 0 或 多少個 改變. 改變 由 U (urgent pointer), W (window), A (ack), S (sequence number) 和 I (packet ID) 指明, 後跟 一個 變化量(+n or -n), 或 另一個 值(=n). 最後顯示 報文中 的 數據總和, 以及 壓縮報頭 的 長度.

例如, 下面一行 顯示了 一個 傳出的 壓縮的 TCP 報文, 有一個 隱含的 連接標識; 確認(ack)的 變化量是 6, 順序號 是 49, 報文ID 是 6; 有三個位元組的數據 和六個位元組 的 壓縮報頭:

O ctcp * A+6 S+49 I+6 3 (6)

ARP/RARP 報文

Arp/rarp 報文 的 輸出 顯示 請求類型 及其 參數. 輸出格式 傾向於 能夠 自我解釋. 這裡 是一個 簡單的例子, 來自 主機 rtsg 到 主機 csam 的 'rlogin' 開始 部分:

arp who-has csam tell rtsg
arp reply csam is-at CSAM


第一行 說明 rtsg 發出 一個 arp 報文 詢問 internet 主機 csam 的 乙太網地址. Csam 用 它的 以太地址 作應答 (這個例子中, 以太地址 是 大寫的, internet 地址為 小寫).
如果 用 tcpdump -n 看上去 要 清楚一些:

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


這裡 第一個 報文 指出 乙太網源地址是 RTSG, 目的地址 是 乙太網廣播地址, 類型域 為 16進位數 0806 (類型 ETHER_ARP), 報文全長 64 位元組.
TCP 報文

(注意: 以下的描述中 假設 你 熟悉 RFC-793 中 說明的 TCP 協議, 如果 你不了解 這個 協議, 無論是 本文 還是 tcpdump 都對你 用處 不大)

一般說來 tcp 協議的 輸出格式是:

src > dst: flags data-seqno ack window urgent options


Src 和 dst 是 源目IP地址和埠. Flags 是 S (SYN), F (FIN), P (PUSH) 或 R (RST) 或 單獨的 `.'(無標誌), 或者是 它們的 組合. Data-seqno 說明了 本報文中的數據 在 流序號 中的 位置 (見下例). Ack 是 在這條連接上 信源機 希望 下一個 接收的 位元組的 流序號 (sequence number). Window 是 在這條連接上 信源機 接收緩衝區 的 位元組大小. Urg 表明 報文內 是 `緊急(urgent)' 數據. Options 是 tcp 可選報頭, 用 尖括弧 括起 (例如, ).
Src, dst 和 flags 肯定 存在. 其他域 依據 報文的 tcp 報頭 內容, 只輸出 有必要 的 部分.

下面 是 從 主機 rtsg rlogin 到 主機 csam 的 開始部分.

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 的 login 埠 發送 報文. S 標誌 表明 設置了 SYN 標誌. 報文 的 流序號 是 768512, 沒有 數據. (這個寫成 `first:last(nbytes)', 意思是 `從 流序號 first 到 last, 不包括 last, 有 nbytes 位元組的 用戶數據'.) 此時 沒有 捎帶確認(piggy-backed ack), 有效的 接收窗口 是 4096 位元組, 有一個 最大段大小(max-segment-size) 的 選項, 請求 設置 mss 為 1024 位元組.
Csam 用類似的 形式 應答, 只是 增加了 一個 對 rtsg SYN 的 捎帶確認. 然後 Rtsg 確認 csam 的 SYN. `.' 意味著 沒有 設置 標誌. 這個 報文 不包含 數據, 因此 也就 沒有 數據的流序號. 注意這個 確認流序號 是一個 小整數(1). 當 tcpdump 第一次 發現 一個 tcp 會話時, 它 顯示 報文 攜帶的 流序號. 在 隨後收到的 報文里, 它 顯示 當前報文 和 最初那個 報文 的 流序號 之 差. 這 意味著 從第一個報文 開始, 以後的 流序號 可以 理解成 數據流 中的 相對位移 as relative byte positions in the conversation's data stream (with the first data byte each direction being `1'). `-S' 選項 能夠 改變 這個 特性, 直接 顯示 原始的 流序號.

在 第六行, rtsg 傳給 csam 19 個位元組 的 數據 (位元組 2 到 20). 報文中 設置了 PUSH 標誌. 第七行 csam 表明 它 收到了 rtsg 的 數據, 位元組序號是 21, 但不包括 第21個 位元組. 顯然 大多數 數據 在 socket 的 緩衝區內, 因為 csam 的 接收窗口 收到的 數據小於 19 個 位元組. 同時 csam 向 rtsg 發送了 一個位元組 的 數據. 第八和第九行 顯示 csam 發送了 兩個位元組 的 緊急數據 到 rtsg.

如果 捕捉區 設置的 過小, 以至於 tcpdump 不能 捕捉到 完整的 TCP 報頭, tcpdump 會 儘可能的 翻譯 已捕獲的 部分, 然後 顯示 ``[|tcp]'', 表明 無法 翻譯 其餘 部分. 如果 報頭 包含 一個 偽造的 選項 (one with a length that's either too small or beyond the end of the header), tcpdump 顯示 ``[bad opt]'' 並且 不再 翻譯 其他 選項部分 (因為 它 不可能 判斷出從哪兒 開始). 如果 報頭長度 表明 存在 選項, 但是 IP 數據報 長度 不夠, 不可能 真的 保存 選項, tcpdump 就顯示 ``[bad hdr length]''.

UDP 報文

UDP 格式 就象 這個 rwho 報文 顯示的:

actinide.who > broadcast.who: udp 84


就是說 把一個 udp 數據報 從 主機 actinide 的 who 埠 發送到 broadcast, Internet 廣播地址 的 who 埠. 報文 包含 84位元組 的 用戶數據.
某些 UDP 服務 能夠 識別出來(從 源目埠號 上), 因而 顯示出 更高層的 協議信息. 特別是 域名服務請求(RFC-1034/1035) 和 NFS 的 RPC 調用(RFC-1050).

UDP 域名服務請求 (Name Server Requests)

(注意: 以下的描述中 假設 你 熟悉 RFC-1035 說明的 域名服務協議. 如果你 不熟悉 這個協議, 下面的內容 就象是 天書.)

域名服務請求 的 格式 是

src > dst: id op? flags qtype qclass name (len)

h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)


主機 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<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: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<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


Jssmag.209 向 主機 helios 發起 12266 號 交易, 請求 8 個 報文(`<0-7>'). 行尾的 十六進位數 是 請求中 `userdata' 域 的 值.
Helios 用 8 個 512位元組 的 報文 應答. 跟在 交易號 後面的 `:digit' 給籌

責任編輯:徐明


[火星人 ] TCPDUMP中文手冊已經有715次圍觀

http://coctec.com/docs/program/show-post-72124.html