Provided by: manpages-zh_1.5.1-3_all bug

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 黄页服务器 的 问题 -- 一般说来 当它 芬
              外部网络 的 数字地址 时 会长期挂起).

       -Ffile 的内容 用作 过滤表达式. 忽略 命令行 上 的 表达式.

       -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     快速输出. 显示 较少的 幸樾畔, 输出行 会 短一点点.

       -rfile 中 读入 数据报 (文件 是用 -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, netport.  例如,
                     `host   foo',   `net  128.3',  `port  20'.   如果  不指定
                     类型修饰子, 就使用 缺省的 host .

              dir    方向修饰子  指出  相对于     的   传输方向   (数据是
                     传入还是传出  标识).  可以使用的 方向 有 src, dst, src or
                     dstsrc and dst.  例如, `src foo',  `dst  net  128.3',
                     `src  or  dst  port  ftp-data'.   如果 不指定 方向修饰子,
                     就使用 缺省的 src or dst .  对于 `null' 链路层 (就是说 象
                     slip  之类的  点到点  幸), 用 inboundoutbound 修饰子
                     指定 所需的 传输方向.

              proto  幸樾奘巫 要求 匹配 指定的幸. 可以使用的 幸 有:  ether,
                     fddi,  ip, arp, rarp, decnet, lat, sca, moprc, mopdl, tcpudp.  例如, `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, ornot 连接 杂 来 组建.
              例如,  `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,  则 逻
                     为 真.  本杂 可以用 srcdst 修饰.

              net net/len
                     如果 IP 地址 匹配 指定 网络掩码 的 net,  则  逻  为  真,
                     掩码 的 有效位宽 为 len.  本杂 可以用 srcdst 修饰.

              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, 则 逻 为 真.
                     上述的 任意一个 端口表达式 都可以 用 关键字 tcpudp 做
                     前缀, 就象:
                          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 ]
                     Protoether, 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
                     的 数据报.  这种 检查 隐含在  tcpudp  下标操作  中.
                     例如,  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, utcpctcp.  对于 ip 报文 不再 显示 更多的  链路信息.
       对于  TCP  报文,  在  类型  后面 显示 连接标识.  如果 报文 是 压缩过的,
       就显示出 它的 编码报头.  这种 特殊情况 以 *S+n*SA+n 的  形式  显示,
       这里的  n  是  流序号  (或者  流序号  和  ack)  的 变化总量.  如果 不是
       特殊情况, 就显示出 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
       Srcdst 是 源目IP地址和端口.  Flags 是 S (SYN), F (FIN), P (PUSH) 或
       R  (RST)  或 单独的 `.'(无标志), 或者是 它们的 组合.  Data-seqno 说明了
       本报文中的数据 在 流序号  中的  位置  (见下例).   Ack  是  在这条连接上
       信源机  希望  下一个 接收的 字节的 流序号 (sequence number).  Window 是
       在这条连接上  信源机  接收缓冲区  的  字节大小.   Urg  表明  报文内  是
       `紧急(urgent)'  数据.   Options 是 tcp 选项, 用 尖括号 括起 (例如, <mss
       1024>).

       Src, dstflags 肯定 存在.  其他域 依据 报文的 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)',   意思是  `从  流序号  firstlast,
       不包括 last, 有 nbytes 字节的 用户数据'.)   此时  没有  捎带确认(piggy-
       backed  ack),  有效的  接收窗口  是 4096 字节, 有一个 最大分段长度(max-
       segment-size) 的 选项, 请求 设置 mss 为 1024 字节.

       Csam 用类似的 形式 应答, 只是 增加了 一个  对  rtsg  SYN  的  捎带确认.
       然后  Rtsg  确认  csam  的  SYN.  `.' 意味着 没有 设置 标志.  这个 报文
       不包含 数据, 因此 也就 没有 数据的流序号.  注意这个  确认流序号  是一个
       小整数(1).  当 tcpdump 第一次 发现 一个 tcp 会话时, 它 显示 报文 携带的
       流序号. 在 随后收到的 报文里, 它 显示 当前 报文  和  最初那个  报文  的
       流序号  之  差.  这 意味着 从第一个报文 开始, 以后的 流序号 可以 理解成
       数据流 中的 相对位移 (每个报文 的 第一个 数据字节 从 '1'  计数).   `-S'
       选项 能够 改变 这个 特性, 直接 显示 允嫉 流序号.

       在  第六行,  rtsg  传给  csam 19 个字节 的 数据 (字节 2 到 20).  报文中
       设置了 PUSH 标志. 第七行 csam 表明 它 收到了 rtsg 的 数据, 字节序号  是
       21, 但不包括 第21个 字节.  显然 大多数 数据 在 socket 的 缓冲区内, 因为
       csam 的 接收窗口 收到的 数据 小于 19 个 字节. 同时 csam 向 rtsg  发送了
       一个字节  的  数据.  第八和第九行 显示 csam 发送了 两个字节 的 紧急数据
       到 rtsg.

       如果 捕捉区 设置的 过小, 以至于 tcpdump 不能 捕捉到  完整的  TCP  报头,
       tcpdump  会 尽可能的 芬 已捕获的 部分, 然后 显示 ``[|tcp]'', 表明 无法
       芬 其余 部分. 如果 报头 包含 有问题的 选项 (选项表 长度 太小 或者 超出
       报头范围), tcpdump 显示 ``[bad opt]'' 并且 不再 芬 其他 选项部分 (因为
       它 不可能 判断出 从哪儿 开始).  如果 报头长度 表明 存在 选项,  但是  IP
       数据报  长度  不够,  不可能  真的  保存 选项, tcpdump 就显示 ``[bad hdr
       length]''.

       UDP文

       UDP 格式 就象 这个 rwho 报文 显示的:
              actinide.who > broadcast.who: udp 84
       就是说 把一个 udp 数据报 从 主机 actinidewho 端口 发送到 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
       在第一行,  主机  sushiwrl 发送 号码为 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 (exactly once) 位.

       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 获得:

              ftp://ftp.ee.lbl.gov/tcpdump.tar.Z

BUGS

       请把 臭虫 报告 传往 tcpdump@ee.lbl.gov.

       NIT 不允许 监视 你自己的 传出数据, BPF 可以. 我们 建议 你 使用 后者.

       应该 试着 重组 IP 分片, 至少可以 为 更高层的 幸 计算出 正确的 长度.

       名字服务逆向询问  转储的  不正确:  打印出 (空的)问题部分, 而实际上 询问
       放在了 回答部分. 有人  认为  这种  逆向询问  本身就是  bug,  应该  修改
       产生问题 的 程序, 而非 tcpdump.

       苹果 Ethertalk DDP 的 报文 应该 象 KIP DDP 的 报文 一样 容易 转储, 事实
       却 不是 这样. 即使 我们 有意 作点什么 来 促销 Ethertalk (我们没有), LBL
       也不允许  Ethertalk  出现在  它的  任何网络上,  所以  我们  没办法 测试
       这些代码.

       如果  报文的  路径上  出现  夏时制时间  变化,  可能  导致  时戳   混乱.
       (这个时间变化将忽略)

       操作  FDDI  报头的 过滤器表达式 假设 所有的 FDDI 报文 被封装在 以太报文
       中.  这对 IP, ARP 和 DECNET Phase IV 无疑是 正确的, 但对  某些  幸  如
       ISO CLNS 不正确. 因此, 过滤器 有可能会 糊里糊涂的 的 接收 一些 并不真正
       匹配 过滤器表达式 的 报文.

[<xuming@users.sourceforge.net>

[2003/05/13

Linuxanhttp://cmpp.linuxforum.net

                                 30 June 1997                       TCPDUMP(8)