比较重要的是 -nn -i lo
查看端口流量:
tcpdump -nnnl -i lo "port 23558"
输出源或目的端口为13的udp数据报或icmpicmp分组:
tcpdump '(udp and port daytime) or icmp'
输出源或目的端口为80,并且设置syn标志的tcp分节:
tcpdump 'tcp and port 80 and tcp[13:1]& 2 != 0'
输出源端口在7001和7005之间的tcp分节:
tcpdump 'tcp and tcp[0:2] > 7000 and tcp[0:] <= 7005'
例題：如何使用 tcpdump 監聽 (1)來自 eth0 介面卡且 (2)通訊協定為 port 22 ，(3)目標來源為 192.168.1.100 的封包資料？
答： tcpdump -i eth0 -nn 'port 22 and src host 192.168.1.100'
tcp:
ip:
tcpdump
說實在的，對於 tcpdump 這個軟體來說，你甚至可以說這個軟體其實就是個駭客軟體， 因為他不但可以分析封包的流向，連封包的內容也可以進行『監聽』， 如果你使用的傳輸資料是明碼的話，不得了，在 router 上面就可能被人家監聽走了！ 很可怕吶！所以，我們也要來瞭解一下這個軟體啊！(註：這個 tcpdump 必須使用 root 的身份執行)
[root@linux ~]# tcpdump [-nn] [-i 介面] [-w 儲存檔名] [-c 次數] [-Ae]
[-qX] [-r 檔案] [所欲擷取的資料內容]
參數：
-nn：直接以 IP 及 port number 顯示，而非主機名與服務名稱
-i ：後面接要『監聽』的網路介面，例如 eth0, lo, ppp0 等等的介面；
-w ：如果你要將監聽所得的封包資料儲存下來，用這個參數就對了！後面接檔名
-c ：監聽的封包數，如果沒有這個參數， tcpdump 會持續不斷的監聽，
直到使用者輸入 [ctrl]-c 為止。
-A ：封包的內容以 ASCII 顯示，通常用來捉取 WWW 的網頁封包資料。
-e ：使用資料連接層 (OSI 第二層) 的 MAC 封包資料來顯示；
-q ：僅列出較為簡短的封包資訊，每一行的內容比較精簡
-X ：可以列出十六進位 (hex) 以及 ASCII 的封包內容，對於監聽封包內容很有用
-r ：從後面接的檔案將封包資料讀出來。那個『檔案』是已經存在的檔案，
並且這個『檔案』是由 -w 所製作出來的。
所欲擷取的資料內容：我們可以專門針對某些通訊協定或者是 IP 來源進行封包擷取，
那就可以簡化輸出的結果，並取得最有用的資訊。常見的表示方法有：
'host foo', 'host 127.0.0.1' ：針對單部主機來進行封包擷取
'net 192.168' ：針對某個網域來進行封包的擷取；
'src host 127.0.0.1' 'dst net 192.168'：同時加上來源(src)或目標(dst)限制
'tcp port 21'：還可以針對通訊協定偵測，如 tcp, udp, arp, ether 等
還可以利用 and 與 or 來進行封包資料的整合顯示呢！
範例一：以 IP 與 port number 捉下 eth0 這個網路卡上的封包，持續 3 秒
[root@linux ~]# tcpdump -i eth0 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
01:33:40.41 IP 192.168.1.100.22 > 192.168.1.11.1190: P 116:232(116) ack 1 win 9648
01:33:40.41 IP 192.168.1.100.22 > 192.168.1.11.1190: P 232:364(132) ack 1 win 9648
<==按下 [ctrl]-c 之後結束
6680 packets captured <==捉下來的封包數量
14250 packets received by filter <==由過濾所得的總封包數量
7512 packets dropped by kernel <==被核心所丟棄的封包
|
如果你是第一次看 tcpdump 的 man page 時，肯定一個頭兩個大，因為 tcpdump 幾乎都是分析封包的表頭資料，使用者如果沒有簡易的網路封包基礎，要看懂粉難吶！ 所以，至少您得要回到
網路基礎裡面去將 TCP 封包的表頭資料理解理解才好啊！ ^_^！至於那個範例一所產生的輸出範例中，我們可以約略區分為數個欄位， 我們以範例一當中那個特殊字體行來說明一下：
- 01:33:40.41：這個是此封包被擷取的時間，『時:分:秒』的單位；
- IP：透過的通訊協定是 IP ；
- 192.168.1.100.22 > ：傳送端是 192.168.1.100 這個 IP，而傳送的 port number 為 22，您必須要瞭解的是，那個大於 (>) 的符號指的是封包的傳輸方向喔！
- 192.168.1.11.1190：接收端的 IP 是 192.168.1.11， 且該主機開啟 port 1190 來接收；
- P 116:232(116)：這個封包帶有 PUSH 的資料傳輸標誌， 且傳輸的資料為整體資料的 116~232 byte，所以這個封包帶有 116 bytes 的資料量；
- ack 1 win 9648：ACK與 Window size 的相關資料。
最簡單的說法，就是該封包是由 192.168.1.100 傳到 192.168.1.11，透過的 port 是由 22 到 1190 ， 且帶有 116 bytes 的資料量，使用的是 PUSH 的旗標，而不是 SYN 之類的主動連線標誌。 呵呵！不容易看的懂吧！所以說，上頭才講請務必到
TCP 表頭資料的部分去瞧一瞧的啊！
再來，一個網路狀態很忙的主機上面，你想要取得某部主機對你連線的封包資料而已時， 使用 tcpdump 配合管線命令與正規表示法也可以，不過，畢竟不好捉取！ 我們可以透過 tcpdump 的表示法功能，就能夠輕易的將所需要的資料獨立的取出來。 在上面的範例一當中，我們僅針對 eth0 做監聽，所以整個 eth0 介面上面的資料都會被顯示到螢幕上， 不好分析啊！那麼我們可以簡化嗎？例如只取出 port 21 的連線封包，可以這樣做：
再來，一個網路狀態很忙的主機上面，你想要取得某部主機對你連線的封包資料而已時， 使用 tcpdump 配合管線命令與正規表示法也可以，不過，畢竟不好捉取！ 我們可以透過 tcpdump 的表示法功能，就能夠輕易的將所需要的資料獨立的取出來。 在上面的範例一當中，我們僅針對 eth0 做監聽，所以整個 eth0 介面上面的資料都會被顯示到螢幕上， 不好分析啊！那麼我們可以簡化嗎？例如只取出 port 21 的連線封包，可以這樣做：
[root@linux ~]# tcpdump -i eth0 -nn port 21 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 01:54:37.96 IP 192.168.1.11.1240 > 192.168.1.100.21: . ack 1 win 65535 01:54:37.96 IP 192.168.1.100.21 > 192.168.1.11.1240: P 1:21(20) ack 1 win 5840 01:54:38.12 IP 192.168.1.11.1240 > 192.168.1.100.21: . ack 21 win 65515 01:54:42.79 IP 192.168.1.11.1240 > 192.168.1.100.21: P 1:17(16) ack 21 win 65515 01:54:42.79 IP 192.168.1.100.21 > 192.168.1.11.1240: . ack 17 win 5840 01:54:42.79 IP 192.168.1.100.21 > 192.168.1.11.1240: P 21:55(34) ack 17 win 5840 |
瞧！這樣就僅提出 port 21 的資訊而已，且仔細看的話，你會發現封包的傳遞都是雙向的， client 端發出『要求』而 server 端則予以『回應』，所以，當然是有去有回啊！ 而我們也就可以經過這個封包的流向來瞭解到封包運作的過程。 舉例來說：
- 我們先在一個終端機視窗輸入『 tcpdump -i lo -nn 』 的監聽，
- 再另開一個終端機視窗來對本機 (127.0.0.1) 登入『ssh localhost』
那麼輸出的結果會是如何？
[root@linux ~]# tcpdump -i lo -nn 1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 2 listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes 3 11:02:54.253777 IP 127.0.0.1.32936 > 127.0.0.1.22: S 933696132:933696132(0) win 32767 <mss 16396,sackOK,timestamp 236681316 0,nop,wscale 2> 4 11:02:54.253831 IP 127.0.0.1.22 > 127.0.0.1.32936: S 920046702:920046702(0) ack 933696133 win 32767 <mss 16396,sackOK,timestamp 236681316 236681316,nop, wscale 2> 5 11:02:54.253871 IP 127.0.0.1.32936 > 127.0.0.1.22: . ack 1 win 8192 <nop, nop,timestamp 236681316 236681316> 6 11:02:54.272124 IP 127.0.0.1.22 > 127.0.0.1.32936: P 1:23(22) ack 1 win 8192 <nop,nop,timestamp 236681334 236681316> 7 11:02:54.272375 IP 127.0.0.1.32936 > 127.0.0.1.22: . ack 23 win 8192 <nop, nop,timestamp 236681334 236681334> |
上表顯示的頭兩行是 tcpdump 的基本說明，然後：
- 第 3 行顯示的是『來自 client 端，帶有 SYN 主動連線的封包』，
- 第 4 行顯示的是『來自 server 端，除了回應 client 端之外(ACK)，還帶有 SYN 主動連線的標誌；
- 第 5 行則顯示 client 端回應 server 確定連線建立 (ACK)
- 第 6 行以後則開始進入資料傳輸的步驟。
從第 3-5 行的流程來看，熟不熟悉啊？沒錯！那就是
三向交握 的基礎流程啦！夠有趣吧！ 不過 tcpdump 之所以被稱為駭客軟體之一可不止上頭介紹的功能吶！ 上面介紹的功能可以用來作為我們主機的封包連線與傳輸的流程分析， 這將有助於我們瞭解到封包的運作，同時瞭解到主機的防火牆設定規則是否有需要修訂的地方。
更神奇的使用要來啦！如果我們使用 tcpdump 在 router 上面監聽『明碼』的傳輸資料時， 例如 FTP 傳輸協定，你覺得會發生什麼問題呢？ 我們先在主機端下達『 tcpdump -i lo port 21 -nn -X 』然後再以 ftp 登入本機，並輸入帳號與密碼， 結果你就可以發現如下的狀況：
更神奇的使用要來啦！如果我們使用 tcpdump 在 router 上面監聽『明碼』的傳輸資料時， 例如 FTP 傳輸協定，你覺得會發生什麼問題呢？ 我們先在主機端下達『 tcpdump -i lo port 21 -nn -X 』然後再以 ftp 登入本機，並輸入帳號與密碼， 結果你就可以發現如下的狀況：
[root@linux ~]# tcpdump -i lo -nn -X 'port 21'
0x0000: 4500 0048 2a28 4000 4006 1286 7f00 0001 E..H*(@.@.......
0x0010: 7f00 0001 0015 80ab 8355 2149 835c d825 .........U!I./.%
0x0020: 8018 2000 fe3c 0000 0101 080a 0e2e 0b67 .....<.........g
0x0030: 0e2e 0b61 3232 3020 2876 7346 5450 6420 ...a220.(vsFTPd.
0x0040: 322e 302e 3129 0d0a 2.0.1)..
0x0000: 4510 0041 d34b 4000 4006 6959 7f00 0001 E..A.K@.@.iY....
0x0010: 7f00 0001 80ab 0015 835c d825 8355 215d ........./.%.U!]
0x0020: 8018 2000 fe35 0000 0101 080a 0e2e 1b37 .....5.........7
0x0030: 0e2e 0b67 5553 4552 2064 6d74 7361 690d ...gUSER.dmtsai.
0x0040: 0a .
0x0000: 4510 004a d34f 4000 4006 694c 7f00 0001 E..J.O@.@.iL....
0x0010: 7f00 0001 80ab 0015 835c d832 8355 217f ........./.2.U!.
0x0020: 8018 2000 fe3e 0000 0101 080a 0e2e 3227 .....>........2'
0x0030: 0e2e 1b38 5041 5353 206d 7970 6173 7377 ...8PASS.mypassw
0x0040: 6f72 6469 7379 6f75 0d0a ordisyou..
|
上面的輸出結果已經被簡化過了，你必須要自行在你的輸出結果當中搜尋相關的字串才行。 從上面輸出結果的特殊字體中，我們可以發現『該 FTP 軟體使用的是 vsftpd ，並且使用者輸入 dmtsai 這個帳號名稱，且密碼是 mypasswordisyou』 嘿嘿！你說可不可怕啊！如果使用的是明碼的方式來傳輸你的網路資料？ 所以我們才常常在講啊，網路是很不安全低！
另外你得瞭解，為了讓網路介面可以讓 tcpdump 監聽，所以執行 tcpdump 時網路介面會啟動在 『錯亂模式 (promiscuous)』，所以你會在 /var/log/messages 裡面看到很多的警告訊息， 通知你說你的網路卡被設定成為錯亂模式！別擔心，那是正常的。 至於更多的應用，請參考 man tcpdump 囉！
另外你得瞭解，為了讓網路介面可以讓 tcpdump 監聽，所以執行 tcpdump 時網路介面會啟動在 『錯亂模式 (promiscuous)』，所以你會在 /var/log/messages 裡面看到很多的警告訊息， 通知你說你的網路卡被設定成為錯亂模式！別擔心，那是正常的。 至於更多的應用，請參考 man tcpdump 囉！
【标 题】：tcpdump中文man
【关键字】：tcpdump,man
【来 源】：http://www.cublog.cn/u/11566/showart.php?id=214749
【关键字】：tcpdump,man
【来 源】：http://www.cublog.cn/u/11566/showart.php?id=214749
tcpdump中文man
tcpdump中文man
TCPDUMP
Section: Maintenance Commands (8)
Updated: 30 June 1997
Index Return to Main Contents
--------------------------------------------------------------------------------
名称 (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 可选报头, 用 尖括号括起 (例如, <mss 1024>).
Src, dst 和 flags 肯定 存在. 其他域 依据 报文的 tcp 报头 内容, 只输出 有必要 的 部分.
下面 是 从 主机 rtsg rlogin 到 主机 csam 的 开始部分.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
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' 给出了 交易过程中 报文的 序列号, 括弧内的 数字 是 报文的 数据量, 不包括 atp 报头. 报文 7 的 `*' 表明 设置了 EOM 位.
然后 Jssmag.209 请求 重传 第 3 & 5 报文. Helios 做了 重传后 jssmag.209 结束 这次 交易. 最后, jssmag.209 发起 下一次 交易请求. 请求中的 `*' 表明 没有 设置 XO (只有一次) 位.
IP 分片
分片的 Internet 数据报 显示为
(frag id:size@offset+)
(frag id:size@offset)
(第一种 形式 表明 还有 更多的 分片. 第二种 形式 表明 这是 最后 一片.)
Id 是 分片 标识号. Size 是 分片 大小 (字节), 不包括 IP 报头. Offset 是 该分片 在 原数据报 中 的 偏移 (单位是字节).
每一个 分片 的 信息 都可以 打印出来. 第一个 分片 包含了 高层 协议 报头, 显示 协议信息 后 显示 分片 的 信息. 第一个 分片以后的 分片 不再 含有高层协议 报头, 所以 在 源目地址 后面 只显示 分片 信息. 例如, 下面是 从 arizona.edu 到 lbl-rtsg.arpa 的 一部分 ftp 传输, 途经的 CSNET 看上去 处理不了 576 字节的 数据报:
arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560
这里 有几点 需要注意: 首先, 第二行的 地址 不包括 端口号. 这是因为 TCP 协议 信息 全部 装到了 第一个 分片内, 所以 显示后续分片的 时候 不可能 知道端口 或 流序号. 其次, 第一行的 tcp 流序号部分 看上去有 308 字节的 用户数据, 实际上 是 512 字节 (第一个 分片的 308 和 第二个 分片的 204 字节). 如果你 正在 寻找 流序号中 的 空洞, 或者 试图 匹配 报文的 确认(ack), 那你上当了.
如果 报文的 IP 标有 不要分片 标志, 显示时 在尾部 加上 (DF).
时戳
缺省情况下, 所有 输出行 的 前面 都有 时戳. 时戳 就是 当前时间, 显示格式为
hh:mm:ss.frac
精度 和 内核时钟 一样. 时戳 反映了 内核 收到 报文 的 时间. 从 以太接口 收到 报文 到 内核 响应 '报文就绪' 中断 有一个 滞后, 该 滞后 不被考虑.
另见 (SEE ALSO)
traffic(1C), nit(4P), bpf(4), pcap(3)
作者 (AUTHORS)
Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
当前 版本 可以 从 匿名ftp 获得:
Section: Maintenance Commands (8)
Updated: 30 June 1997
Index Return to Main Contents
--------------------------------------------------------------------------------
名称 (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 可选报头, 用 尖括号括起 (例如, <mss 1024>).
Src, dst 和 flags 肯定 存在. 其他域 依据 报文的 tcp 报头 内容, 只输出 有必要 的 部分.
下面 是 从 主机 rtsg rlogin 到 主机 csam 的 开始部分.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
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' 给出了 交易过程中 报文的 序列号, 括弧内的 数字 是 报文的 数据量, 不包括 atp 报头. 报文 7 的 `*' 表明 设置了 EOM 位.
然后 Jssmag.209 请求 重传 第 3 & 5 报文. Helios 做了 重传后 jssmag.209 结束 这次 交易. 最后, jssmag.209 发起 下一次 交易请求. 请求中的 `*' 表明 没有 设置 XO (只有一次) 位.
IP 分片
分片的 Internet 数据报 显示为
(frag id:size@offset+)
(frag id:size@offset)
(第一种 形式 表明 还有 更多的 分片. 第二种 形式 表明 这是 最后 一片.)
Id 是 分片 标识号. Size 是 分片 大小 (字节), 不包括 IP 报头. Offset 是 该分片 在 原数据报 中 的 偏移 (单位是字节).
每一个 分片 的 信息 都可以 打印出来. 第一个 分片 包含了 高层 协议 报头, 显示 协议信息 后 显示 分片 的 信息. 第一个 分片以后的 分片 不再 含有高层协议 报头, 所以 在 源目地址 后面 只显示 分片 信息. 例如, 下面是 从 arizona.edu 到 lbl-rtsg.arpa 的 一部分 ftp 传输, 途经的 CSNET 看上去 处理不了 576 字节的 数据报:
arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560
这里 有几点 需要注意: 首先, 第二行的 地址 不包括 端口号. 这是因为 TCP 协议 信息 全部 装到了 第一个 分片内, 所以 显示后续分片的 时候 不可能 知道端口 或 流序号. 其次, 第一行的 tcp 流序号部分 看上去有 308 字节的 用户数据, 实际上 是 512 字节 (第一个 分片的 308 和 第二个 分片的 204 字节). 如果你 正在 寻找 流序号中 的 空洞, 或者 试图 匹配 报文的 确认(ack), 那你上当了.
如果 报文的 IP 标有 不要分片 标志, 显示时 在尾部 加上 (DF).
时戳
缺省情况下, 所有 输出行 的 前面 都有 时戳. 时戳 就是 当前时间, 显示格式为
hh:mm:ss.frac
精度 和 内核时钟 一样. 时戳 反映了 内核 收到 报文 的 时间. 从 以太接口 收到 报文 到 内核 响应 '报文就绪' 中断 有一个 滞后, 该 滞后 不被考虑.
另见 (SEE ALSO)
traffic(1C), nit(4P), bpf(4), pcap(3)
作者 (AUTHORS)
Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
当前 版本 可以 从 匿名ftp 获得:
415
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
