主机 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' 域 的 值.
