关于tcpdump 的应用

tcpdump -i lo -S -e -nn -X -s 2000 icmp


选项(OPTIONS)
-a
试着把网络和广播地址转换成名称.
-c
当收到count报文后退出.
-d
把编译好的报文匹配模板(packet-matchingcode)翻译成可读形式,传往标准输出,然后退出.
-dd
把报文匹配模板 (packet-matchingcode)以C程序片断的形式输出.
-ddd
把报文匹配模板(packet- matchingcode)以十进制数形式输出(前面加上总数).
-e
每行都显示链路层报头.
-f
用数字形式显示'外部的'互联网地址,而不是字符形式(这个选项用来绕开脑壳坏光的SUN黄页服务器的问题---一般说来它翻译外部网络数字地址的时候会长期挂起

).
-F
把 file的内容用作过滤表达式.忽略命令行上的表达式.
-i
监听interface.如果不指定接口,tcpdump在系统的接口清单中,寻找号码最小,已经配置好的接口(loopback除外).选中的时候会中断连接.
-l
行缓冲标准输出.可用于捕捉数据的同时查看数据.例如,
``tcpdump-l|teedat''or``tcpdump-l>dat&tail-fdat''.
-n
别把地址转换成名字(就是说,主机地址,端口号等)
-N
不显示主机名字中的域名部分.例如,如果使用这个选项,tcpdump只显示 ``nic'',而不是``nic.ddn.mil''.
-O
禁止运行报文匹配模板的优化器.只有当你怀疑优化器有bug时才有用.
-p
禁止把接口置成promiscuous模式.注意,接口有可能因其他原因而处于promiscuous模式;因此,'-p'不能作为 `etherhost{local-hw-addr}或etherbroadcast'的简写

.
-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(远程过程调用 RemoteProcedureCall),rtp(实时应用协议Real-

TimeApplicationsprotocol),rtcp(实时应用控制协议Real- TimeApplicationscontrolprotocol),vat(可视音频工具VisualAudioTool),和wb(分布式白板

distributedWhiteBoard).
-S
显示绝对的,而不是相对的TCP序列号.
-t
禁止显示时戳标志.
-tt
显示未格式化的时戳标志.
-v
(稍微多一点)繁琐的输出.例如,显示IP数据报中的生存周期和服务类型.
-vv
更繁琐的输出.例如,显示NFS应答报文的附加域.
-w
把原始报文存进file,而不是分析和显示.它们可以以后用-r选项显示.如果file是``-'',就写往标准输出.
-x
以16进制数形式显示每一个报文(去掉链路层报头后).可以显示较小的完整报文,否则只显示snaplen个字节.
-X
安装字符串显示报文
expression
用来选择要转储的数据报.如果没有指定expression,就转储网络的全部报文.否则,只转储相对expression为`true'的数据报.
expression 一个或多个原语(primitive)组成.原语通常由一个标识(id,名称或数字),和标识前面的一个或多个修饰子(qualifier)组成.修饰子有三种不同的类型:

type
类型修饰子指出标识名称或标识数字代表什么类型的东西.可以使用的类型有host,net和 port.例如,`hostfoo',`net128.3',`port20'.如果不指定类型修饰子,就使

用缺省的host.


允许的 原语 有:

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 conversations 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 thats 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 给筹


19:23:51.687455 arp who-has 192.168.0.106 tell 192.168.0.100
19:23:51.825048 arp who-has 192.168.0.190 tell 192.168.0.100
19:23:51.825056 arp reply 192.168.0.190 is-at 90:e6:ba:21:79:e7
19:26:06.887441 arp who-has 192.168.0.109 tell 192.168.0.100
19:26:07.014569 arp who-has 192.168.0.190 tell 192.168.0.100
19:26:07.014576 arp reply 192.168.0.190 is-at 90:e6:ba:21:79:e7
19:28:01.076293 arp who-has 192.168.0.100 tell 192.168.0.1
19:30:01.055217 IP 192.168.0.100.138 > 192.168.0.255.138: NBT UDP PACKET(138)
19:31:08.923035 arp who-has 192.168.0.109 tell 192.168.0.100
19:31:49.653795 IP 192.168.0.100.138 > 192.168.0.255.138: NBT UDP PACKET(138)


15:06:10.641461 IP 192.168.0.190.33315 > 192.168.0.1.53: 26090+ A? www.memeshu.com. (33)
0x0000: 4500 003d 23cd 4000 4011 94d3 c0a8 00be
0x0010: c0a8 0001 8223 0035 0029 69c6 65ea 0100
0x0020: 0001 0000 0000 0000 0377 7777 076d 656d
0x0030: 6573 6875 0363 6f6d 0000 0100 01
15:06:10.654342 IP 192.168.0.1.53 > 192.168.0.190.33315: 26090 1/0/0 A 221.194.44.189 (49)
0x0000: 4500 004d 3ce9 0000 4011 bba7 c0a8 0001
0x0010: c0a8 00be 0035 8223 0039 ba54 65ea 8180
0x0020: 0001 0001 0000 0000 0377 7777 076d 656d
0x0030: 6573 6875 0363 6f6d 0000 0100 01c0 0c00
0x0040: 0100 0100 0005 9c00 04dd c22c bd