sanyk's Blog

Happy coding

tcpdump man 手册页的详细中文翻译

sanyk posted @ 2010年1月07日 03:17 in linux man 文档翻译 with tags man tcpdump tcpdump linux man 文档翻译 , 10339 阅读

原文地址
=========
以下是本文档完整版本地址:http://sanyk.is-programmer.com/posts/14645.html
(nt: 出现这一提示是为了避免一些网络蜘蛛把文章分成几个页面给查看带来不悦)

 

中文版本
=========
 
TCPDUMP(8)                                        TCPDUMP(8)                                                                                         
 
名字
 
    tcpdump - 显示网络负载
 
用法概览
 
    tcpdump [ -AdDeflLnNOpqRStuUvxX ] [ -c count ]
           [ -C file_size ] [ -F file ]
           [ -i interface ] [ -m module ] [ -M secret ]
           [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ]
           [ -W filecount ]
           [ -E spi@ipaddr algo:secret,...  ]
           [ -y datalinktype ] [ -Z user ]
           [ expression ]
 

描述
 
    Tcpdump 将显示相应网络接口上,满足特定条件数据包的相关信息, 特定条件可通过布尔条件表达式来表达. 可以在启动tcpdump 时加入-w 选项, 这会使她把收到的
    包数据存入文件中, 以备后续分析(nt: 文件名字由此选项中的file 参数指定). 而-r 选项将会使tcpdump 直接从之前保存的包数据文件(nt: 通过-w 选项产生
    的文件)中读入数据包, 而不是从相应网络接口上获取数据包. 不管通过哪种方式读入数据包, tcpdump只会处理那些布尔条件表达式得到满足的数据包.

    如果启动时不带-c 选项, tcpdump会不停抓取数据包, 不过此过程中可被以下两个信号打断: SIGINT信号(例如, 当我们敲入中断控制符(nt: 按下ctrl键, 同时按下c键可
    产生此字符)), SIGTERM信号(一般可通过kill 命令产生(nt: kill(1) 表示可通过在终端中敲入man 1 kill 命令来查询到kill 的用法 ));
    如果启动时带上 -c选项, tcpdump只会抓取指定数目的数据包, 并且此过程也可被以上两个信号中断.

    当tcpdump 完成了数据包的抓取, 她会报告如下几种数据包的数目:
    ''captured''类型的数据包("被抓取的数据包", 其数目表示tcpdump已经收到并进行了处理的数据包个数);

    ''received by filter''类型数据包("匹配过滤条件的数据包", 其数目的含义随操作系统不同, 以及操作系统配置方式的不同而不同:
    比如, 如果在tcpdump启动命令行中指定一个过滤条件, 我们将会得到''received by filter''类型的包数目(nt | rt: 如果不指定过滤条件, 其含义未知, 需补充).
    在一些操作系统中, 此数目既包括与过滤条件匹配的数据包,也包括不匹配的, 并且与tcpdump是否对此包进行过读取和处理无关;
    在另一些操作系统中, 此数目仍然与是否对此包进行过读取和处理无关, 但只包含与过滤条件匹配的数据包;
    除此以外, 在其他一些操作系统中, 此数目却只包含匹配过滤条件并且被tcpdump处理过的数据包).

    ''dropped by kernel''类型数据包("被内核丢弃的数据包", 其数目含义如下: 如果操作系统不反馈此信息, 此数目将是0;
    如果操作系统反馈此信息, 此数目表示tcpdump 所在的操作系统对包的丢弃的数目, 而这些包或许是因为无缓冲空间, 或许是因为包的抓取机制而被丢弃了).

    对于支持SIGINFO 信号的系统, 比如BSD系列的操作系统(包括Mac OS X 和 Digital/Tru64 UNIX
    (nt: 一个64位,采用改进型卡内基-梅龙大学的Mach V2.5内核, 并装配了BSD 4.3,4.4的常用应用程序的操作系统),
    tcpdump 会在收到SIGINFO 信号时候, 显示出此'capture'类数据包的数目,并继续抓取数据包(通常, 可以通过
    键盘输入ctrl键盘加大写T键产生一个终端的'status'的字符, 从而发送此信号. 不过, 在一些系统上, 如Mac OS X, 此字符默认不
    能被ctrl加T来触发, 不过可通过stty命令来打开此功能).


    从网络接口上读取数据包也许需要特定的权限:

    在支持NIT 或者 BPF 的SunOS 3.x 或者 4.x操作系统中:

    (nt: NIT, Network Interface Tap, 网络接口分接头. BPF, BSD Packet Filter, BSD 分组过滤器.
    可理解为, 此二者分别提供了一种给应用输送指定数据包的机制, 不过BPF 可过滤网络接口上进入和发出的数据包,
    而NIT只能过滤进入的数据包)

        tcpdump需要对/dev/nit 和/dev/bpf* 文件有读的权限

    在支持DLPI 的Solaris 操作系统上:

    (nt: DLPI, Data Link Provider Interface, 可理解为, 对数据链路层向上层所提供功能的一个统一的描述.
    Solaris 为Sun Microsystems公司组装的一种UNIX 操作系统)

        此时, tcpdump 必须具有虚拟网络接口(nt: pseudo device, 虚拟网络接口, 可以理解成linux 系统下的any 网络接口, 即通过此接口可抓到系统中
        所有接口上的数据包), 比如, /dev/le. 不过在有的Solaris 版本中, 拥有读写这个虚拟接口的权限还不足以使tcpdump 工作在混杂模式(nt: promiscuous mode),
        从而也就不能真正使用上这个虚拟网络接口(nt: 可理解为, tcpdump能工作在混杂模式是能从虚拟网络接口接收数据包的另一个必要条件,
        而单拥有对此接口的读写权限还不够).

    在支持DLPI 的HP-UX 操作系统上:
    (nt: HP-UX, Hewlett Packard UniX, 惠普公司开发的一种UNIX 操作系统, 源于UNIX System V 操作系统,
    而后者又源自于BSD UNIX 系统. DLPI, 上文已有其说明)
        tcpdump 必须以root 身份来运行, 或者tcpdump 可执行程序文件被设置了 setuid标志.(nt: 一个程序文件如果被设置了 setuid标志,
        运行时该程序会拥有root权限)

    在支持网络侦听的 IRIX 操作系统上:
    (nt: IRIX, Silicon Graphics公司(美国硅图公司)开发的一种UNIX 操作系统, 源于UNIX System V 操作系统.)
        tcpdump 必须以root 身份来运行, 或者tcpdump 可执行程序文件被设置了 setuid标志.

    在LINUX 操作系统上:
        tcpdump 必须以root 身份来运行, 或者tcpdump 可执行程序文件被设置了 setuid标志(不过, 在以下情况下可不要求root 权限:
        所使用的发布版本中的内核支持 CAP_NET_RAW(nt: 网络包直接抓取) 功能,
        并且执行该功能的权限已被赋予当前的用户, 此外, 在用户登录时, 必须在其初始化进程中(initial process,中打开此功能

        (nt: 具体初始化进程, 需补充). 在这种情况下, 用户所拥有的 CAP_NET_RAW 权限可用于网络抓包, 而如果想要列举出系统中的网络接口则需要拥
        有CAP_NET_ADMIN 权限, 比如此时使用 tcpdump 的 -D 选项就需要此权限)

    在ULTRIX 和 Digital UNIX/Tru64 UNIX系统上:
        (nt: ULTRIX,  Digital Equipment Corporation's (DEC)公司开发的UNIX操作系统. UNIX/Tru64, 上文已描述)

        任何用户都可以使用tcpdump进行网络抓包. 不过, 如果没有通过pfconfig 命令打开网络接口的混杂接收模式, 任何用户(包括
        超级用户)都不能在接口上进行混杂模式抓包. 同样如果没有通过pfconfig 命令打开网络接口的全复制模式(nt: copy-all-mode, 可
        理解为, 此模式下可接收广播和单播数据包), 任何用户(包括超级用户)都不能在接口上接收或发送单播数据包.
        从而, 要在系统上对关键数据包的抓取必须把网络接口的混杂模式和全复制模式打开.

    在BSD(包括Mac OS X) 操作系统上:
        如果系统中没有备份BPF 设备(nt: cloning, 再生, 可理解为备份), 则tcpdump 需要有对/dev/bpf* 的读取权限,
        如果系统中有这样一个备份BPF 设备, 则需要对/dev/bpf 有读取权限.

        在带devfs 文件系统的BSD 系列操作系统中(包括Mac OS X), 则拥有对BPF 设备的读取权限只是进行网络抓包的一个前提, 还有其他条件
        必须被满足, 即在系统启动时配置devfs 中相应文件或文件夹的所有者和权限. 系统可能不会提供直接的配置方法, 这时我们必须
        另找方法来完成此配置.

    不过, 从数据包文件(nt:通过选项-w 产生的文件)中读取数据包不需要这些特殊权限.
 

选项
 
    -A  以ASCII码方式显示每一个数据包(不会显示数据包中链路层头部信息). 在抓取包含
        网页数据的数据包时, 可方便查看数据(nt: 即Handy for capturing web pages).

    -c  count
        tcpdump将在接受到count个数据包后退出.

    -C  file-size
        (nt: 此选项用于配合-w file 选项使用)
        该选项使得tcpdump 在把原始数据包直接保存到文件中之前, 检查此文件大小是否超过file-size. 如果超过了, 将关闭此文件,
        另创一个文件继续用于原始数据包的记录. 新创建的文件名与-w 选项指定的文件名一致, 但文件名后多了一个数字.
        该数字会从1开始随着新创建文件的增多而增加. file-size的单位是百万字节(nt: 这里指1,000,000个字节,
        并非1,048,576个字节, 后者是以1024字节为1k, 1024k字节为1M计算所得, 即1M=1024 * 1024 = 1,048,576)

    -d  以容易阅读的形式,在标准输出上打印出编排过的包匹配码, 随后tcpdump停止.(nt | rt: human readable, 容易阅读的,
        通常是指以ascii码来打印一些信息. compiled, 编排过的. packet-matching code, 包匹配码,含义未知, 需补充)

    -dd 以C语言的形式打印出包匹配码.

    -ddd    以十进制数的形式打印出包匹配码(会在包匹配码之前有一个附加的'count'前缀).

    -D  打印系统中所有tcpdump可以在其上进行抓包的网络接口. 每一个接口会打印出数字编号, 相应的接口名字, 以及可能的一个网络接口
        描述. 其中网络接口名字和数字编号可以用在tcpdump 的-i flag 选项(nt: 把名字或数字代替flag), 来指定要在其上抓包的网络
        接口.

        此选项在不支持接口列表命令的系统上很有用(nt: 比如, Windows 系统, 或缺乏 ifconfig -a 的UNIX系统); 接口的数字
        编号在windows 2000 或其后的系统中很有用, 因为这些系统上的接口名字比较复杂, 而不易使用.

        如果tcpdump编译时所依赖的libpcap库太老,-D 选项不会被支持, 因为其中缺乏 pcap_findalldevs()函数.

    -e  每行的打印输出中将包括数据包的数据链路层头部信息

    -E  spi@ipaddr algo:secret,...

        可通过spi@ipaddr algo:secret 来解密IPsec ESP包(nt | rt:IPsec Encapsulating Security Payload,
        IPsec 封装安全负载, IPsec可理解为, 一整套对ip数据包的加密协议, ESP 为整个IP 数据包或其中上层协议部分被加密后的数据,
        前者的工作模式称为隧道模式; 后者的工作模式称为传输模式 . 工作原理, 另需补充).

        需要注意的是, 在终端启动tcpdump 时, 可以为IPv4 ESP packets 设置密钥(secret).

        可用于加密的算法包括des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, 或者没有(none).
        默认的是des-cbc(nt: des, Data Encryption Standard, 数据加密标准, 加密算法未知, 另需补充).
        secret 为用于ESP 的密钥, 使用ASCII 字符串方式表达. 如果以 0x 开头, 该密钥将以16进制方式读入.

        该选项中ESP 的定义遵循RFC2406, 而不是 RFC1827. 并且, 此选项只是用来调试的, 不推荐以真实密钥(secret)来
        使用该选项, 因为这样不安全: 在命令行中输入的secret 可以被其他人通过ps 等命令查看到.

        除了以上的语法格式(nt: 指spi@ipaddr algo:secret), 还可以在后面添加一个语法输入文件名字供tcpdump 使用
        (nt:即把spi@ipaddr algo:secret,... 中...换成一个语法文件名). 此文件在接受到第一个ESP 包时会打开此
        文件, 所以最好此时把赋予tcpdump 的一些特权取消(nt: 可理解为, 这样防范之后, 当该文件为恶意编写时,
        不至于造成过大损害).

    -f  显示外部的IPv4 地址时(nt: foreign IPv4 addresses, 可理解为, 非本机ip地址), 采用数字方式而不是名字.
        (此选项是用来对付Sun公司的NIS服务器的缺陷(nt: NIS, 网络信息服务, tcpdump 显示外部地址的名字时会
        用到她提供的名称服务): 此NIS服务器在查询非本地地址名字时,常常会陷入无尽的查询循环).

        由于对外部(foreign)IPv4地址的测试需要用到本地网络接口(nt: tcpdump 抓包时用到的接口)
        及其IPv4 地址和网络掩码. 如果此地址或网络掩码不可用, 或者此接口根本就没有设置相应网络地址和网络
        掩码(nt: linux 下的 'any' 网络接口就不需要设置地址和掩码, 不过此'any'接口可以收到系统中所有接口的
        数据包), 该选项不能正常工作.

    -F  file
        使用file 文件作为过滤条件表达式的输入, 此时命令行上的输入将被忽略.

    -i  interface

        指定tcpdump 需要监听的接口.  如果没有指定, tcpdump 会从系统接口列表中搜寻编号最小的已配置好的接口(不包括 loopback 接口).
        一但找到第一个符合条件的接口, 搜寻马上结束.

        在采用2.2版本或之后版本内核的Linux 操作系统上, 'any' 这个虚拟网络接口可被用来接收所有网络接口上的数据包
        (nt: 这会包括目的是该网络接口的, 也包括目的不是该网络接口的). 需要注意的是如果真实网络接口不能工作在'混杂'模式(promiscuous)下,
        则无法在'any'这个虚拟的网络接口上抓取其数据包.

        如果 -D 标志被指定, tcpdump会打印系统中的接口编号,而该编号就可用于此处的interface 参数.

    -l  对标准输出进行行缓冲(nt: 使标准输出设备遇到一个换行符就马上把这行的内容打印出来).
        在需要同时观察抓包打印以及保存抓包记录的时候很有用. 比如, 可通过以下命令组合来达到此目的:
        ``tcpdump  -l  |  tee dat'' 或者 ``tcpdump  -l   > dat  &  tail  -f  dat''.
        (nt: 前者使用tee来把tcpdump 的输出同时放到文件dat和标准输出中, 而后者通过重定向操作'>', 把tcpdump的输出放到
        dat 文件中, 同时通过tail把dat文件中的内容放到标准输出中)

    -L  列出指定网络接口所支持的数据链路层的类型后退出.(nt: 指定接口通过-i 来指定)

    -m  module
        通过module 指定的file 装载SMI MIB 模块(nt: SMI,Structure of Management Information, 管理信息结构
        MIB, Management Information Base, 管理信息库. 可理解为, 这两者用于SNMP(Simple Network Management Protoco)
        协议数据包的抓取. 具体SNMP 的工作原理未知, 另需补充).

        此选项可多次使用, 从而为tcpdump 装载不同的MIB 模块.

    -M  secret
        如果TCP 数据包(TCP segments)有TCP-MD5选项(在RFC 2385有相关描述), 则为其摘要的验证指定一个公共的密钥secret.

    -n  不对地址(比如, 主机地址, 端口号)进行数字表示到名字表示的转换.

    -N  不打印出host 的域名部分. 比如, 如果设置了此选现, tcpdump 将会打印'nic' 而不是 'nic.ddn.mil'.

    -O  不启用进行包匹配时所用的优化代码. 当怀疑某些bug是由优化代码引起的, 此选项将很有用.

    -p  一般情况下, 把网络接口设置为非'混杂'模式. 但必须注意 , 在特殊情况下此网络接口还是会以'混杂'模式来工作; 从而, '-p' 的设与不设,
        不能当做以下选现的代名词:
        'ether host {local-hw-add}' 或  'ether broadcast'(nt: 前者表示只匹配以太网地址为host 的包, 后者表示匹配以太网地址为广播地址的数据包).

    -q  快速(也许用'安静'更好?)打印输出. 即打印很少的协议相关信息, 从而输出行都比较简短.

    -R  设定tcpdump 对 ESP/AH 数据包的解析按照 RFC1825而不是RFC1829(nt: AH, 认证头, ESP, 安全负载封装,
        这两者会用在IP包的安全传输机制中). 如果此选项被设置, tcpdump 将不会打印出'禁止中继'域(nt: relay prevention field). 另外,
         由于ESP/AH规范中没有规定ESP/AH数据包必须拥有协议版本号域,
        所以tcpdump不能从收到的ESP/AH数据包中推导出协议版本号.

    -r  file
        从文件file 中读取包数据. 如果file 字段为 '-' 符号, 则tcpdump 会从标准输入中读取包数据.

    -S  打印TCP 数据包的顺序号时, 使用绝对的顺序号, 而不是相对的顺序号.(nt: 相对顺序号可理解为, 相对第一个TCP 包顺序号的差距,
        比如, 接受方收到第一个数据包的绝对顺序号为232323, 对于后来接收到的第2个,第3个数据包, tcpdump会打印其序列号为1, 2分别
        表示与第一个数据包的差距为1 和 2. 而如果此时-S 选项被设置, 对于后来接收到的第2个, 第3个数据包会打印出其绝对顺序号:
        232324, 232325).

    -s  snaplen
        设置tcpdump的数据包抓取长度为snaplen, 如果不设置默认将会是68字节(而支持网络接口分接头(nt: NIT, 上文已有描述,
        可搜索'网络接口分接头'关键字找到那里)的SunOS系列操作系统中默认的也是最小值是96).
        68字节对于IP, ICMP(nt: Internet Control Message Protocol,
        因特网控制报文协议), TCP 以及 UDP 协议的报文已足够, 但对于名称服务(nt: 可理解为dns, nis等服务), NFS服务相关的
        数据包会产生包截短. 如果产生包截短这种情况, tcpdump的相应打印输出行中会出现''[|proto]''的标志(proto 实际会显示为
        被截短的数据包的相关协议层次). 需要注意的是, 采用长的抓取长度(nt: snaplen比较大), 会增加包的处理时间, 并且会减少
        tcpdump 可缓存的数据包的数量, 从而会导致数据包的丢失. 所以, 在能抓取我们想要的包的前提下, 抓取长度越小越好.
        把snaplen 设置为0 意味着让tcpdump自动选择合适的长度来抓取数据包.

    -T  type
        强制tcpdump按type指定的协议所描述的包结构来分析收到的数据包.  目前已知的type 可取的协议为:
        aodv (Ad-hoc On-demand Distance Vector protocol, 按需距离向量路由协议, 在Ad hoc(点对点模式)网络中使用),
        cnfp (Cisco  NetFlow  protocol),  rpc(Remote Procedure Call), rtp (Real-Time Applications protocol),
        rtcp (Real-Time Applications con-trol protocol), snmp (Simple Network Management Protocol),
        tftp (Trivial File Transfer Protocol, 碎文件协议), vat (Visual Audio Tool, 可用于在internet 上进行电
        视电话会议的应用层协议), 以及wb (distributed White Board, 可用于网络会议的应用层协议).

    -t     在每行输出中不打印时间戳

    -tt    不对每行输出的时间进行格式处理(nt: 这种格式一眼可能看不出其含义, 如时间戳打印成1261798315)

    -ttt   tcpdump 输出时, 每两行打印之间会延迟一个段时间(以毫秒为单位)

    -tttt  在每行打印的时间戳之前添加日期的打印

    -u     打印出未加密的NFS 句柄(nt: handle可理解为NFS 中使用的文件句柄, 这将包括文件夹和文件夹中的文件)

    -U    使得当tcpdump在使用-w 选项时, 其文件写入与包的保存同步.(nt: 即, 当每个数据包被保存时, 它将及时被写入文件中,
          而不是等文件的输出缓冲已满时才真正写入此文件)

           -U 标志在老版本的libcap库(nt: tcpdump 所依赖的报文捕获库)上不起作用, 因为其中缺乏pcap_cump_flush()函数.

    -v    当分析和打印的时候, 产生详细的输出. 比如, 包的生存时间, 标识, 总长度以及IP包的一些选项. 这也会打开一些附加的包完整性
          检测, 比如对IP或ICMP包头部的校验和.

    -vv   产生比-v更详细的输出. 比如, NFS回应包中的附加域将会被打印, SMB数据包也会被完全解码.

    -vvv  产生比-vv更详细的输出. 比如, telent 时所使用的SB, SE 选项将会被打印, 如果telnet同时使用的是图形界面,
          其相应的图形选项将会以16进制的方式打印出来(nt: telnet 的SB,SE选项含义未知, 另需补充).

    -w    把包数据直接写入文件而不进行分析和打印输出. 这些包数据可在随后通过-r 选项来重新读入并进行分析和打印.

    -W    filecount
          此选项与-C 选项配合使用, 这将限制可打开的文件数目, 并且当文件数据超过这里设置的限制时, 依次循环替代之前的文件, 这相当
          于一个拥有filecount 个文件的文件缓冲池. 同时, 该选项会使得每个文件名的开头会出现足够多并用来占位的0, 这可以方便这些
          文件被正确的排序.

    -x    当分析和打印时, tcpdump 会打印每个包的头部数据, 同时会以16进制打印出每个包的数据(但不包括连接层的头部).
          总共打印的数据大小不会超过整个数据包的大小与snaplen 中的最小值. 必须要注意的是, 如果高层协议数据没有snaplen 这么长,
          并且数据链路层(比如, Ethernet层)有填充数据, 则这些填充数据也会被打印.(nt: so for link  layers  that
          pad, 未能衔接理解和翻译, 需补充 )

    -xx   tcpdump 会打印每个包的头部数据, 同时会以16进制打印出每个包的数据, 其中包括数据链路层的头部.

    -X    当分析和打印时, tcpdump 会打印每个包的头部数据, 同时会以16进制和ASCII码形式打印出每个包的数据(但不包括连接层的头部).
          这对于分析一些新协议的数据包很方便.

    -XX   当分析和打印时, tcpdump 会打印每个包的头部数据, 同时会以16进制和ASCII码形式打印出每个包的数据, 其中包括数据链路层的头部.
          这对于分析一些新协议的数据包很方便.

    -y    datalinktype
          设置tcpdump 只捕获数据链路层协议类型是datalinktype的数据包

    -Z    user
          使tcpdump 放弃自己的超级权限(如果以root用户启动tcpdump, tcpdump将会有超级用户权限), 并把当前tcpdump的
          用户ID设置为user, 组ID设置为user首要所属组的ID(nt: tcpdump 此处可理解为tcpdump 运行之后对应的进程)

          此选项也可在编译的时候被设置为默认打开.(nt: 此时user 的取值未知, 需补充)


    条件表达式

        该表达式用于决定哪些数据包将被打印.  如果不给定条件表达式, 网络上所有被捕获的包都会被打印,
        否则, 只有满足条件表达式的数据包被打印.(nt: all packets, 可理解为, 所有被指定接口捕获的数据包).

        表达式由一个或多个'表达元'组成(nt: primitive, 表达元, 可理解为组成表达式的基本元素). 一个表达元通常由一个或多个
        修饰符(qualifiers)后跟一个名字或数字表示的id组成(nt: 即, 'qualifiers id').
        有三种不同类型的 修饰符:type, dir以及 proto.

        type 修饰符指定id 所代表的对象类型, id可以是名字也可以是数字. 可选的对象类型有: host, net, port 以及
            portrange(nt: host 表明id表示主机, net 表明id是网络, port 表明id是端口, 而portrange 表明id 是一个
            端口范围).  如, 'host foo', 'net 128.3', 'port 20', 'portrange 6000-6008'(nt: 分别表示主机 foo,
            网络 128.3, 端口 20, 端口范围 6000-6008). 如果不指定type 修饰符, id默认的修饰符为host.

        dir 修饰符描述id 所对应的传输方向, 即发往id 还是从id 接收(nt: 而id 到底指什么需要看其前面的type 修饰符).
            可取的方向为: src, dst, src 或 dst, src并且dst.(nt:
            分别表示, id是传输源, id是传输目的, id是传输源或者传输目的, id是传输源并且是传输目的). 例如, 'src foo',
            'dst net 128.3', 'src or dst port ftp-data'.(nt: 分别表示符合条件的数据包中, 源主机是foo, 目的网络
            是128.3, 源或目的端口为 ftp-data).
            如果不指定dir修饰符, id 默认的修饰符为src 或 dst.
            对于链路层的协议,比如SLIP(nt: Serial Line InternetProtocol, 串联线路网际网络协议), 以及linux下指定
            'any' 设备, 并指定'cooked'(nt | rt: cooked 含义未知, 需补充) 抓取类型, 或其他设备类型,
            可以用'inbound' 和 'outbount' 修饰符来指定想要的传输方向.

        proto 修饰符描述id 所属的协议. 可选的协议有: ether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, tcp
            以及 upd.
            (nt | rt: ether, fddi, tr, 具体含义未知, 需补充. 可理解为物理以太网传输协议, 光纤分布数据网传输协议,
            以及用于路由跟踪的协议.  wlan, 无线局域网协议; ip,ip6 即通常的TCP/IP协议栈中所使用的ipv4以及ipv6网络层协议;
            arp, rarp 即地址解析协议, 反向地址解析协议; decnet, Digital Equipment Corporation
            开发的, 最早用于PDP-11 机器互联的网络协议; tcp and udp, 即通常TCP/IP协议栈中的两个传输层协议).

            例如, `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange 7000-7009'
            分别表示 '从以太网地址foo 来的数据包','发往或来自128.3网络的arp协议数据包', '发送或接收端口为21的
            tcp协议数据包', '发送或接收端口范围为7000-7009的udp协议数据包'.

            如果不指定proto 修饰符, 则默认为与相应type匹配的修饰符. 例如, 'src foo' 含义是 '(ip or arp or
            rarp) src foo' (nt: 即, 来自主机foo的ip/arp/rarp协议数据包, 默认type为host),`net bar' 含义是
            `(ip  or  arp  or rarp) net bar'(nt: 即, 来自或发往bar网络的ip/arp/rarp协议数据包),
            `port 53' 含义是 `(tcp or udp) port 53'(nt: 即, 发送或接收端口为53的tcp/udp协议数据包).

            (nt: 由于tcpdump 直接通过数据链路层的 BSD 数据包过滤器或 DLPI(datalink provider interface, 数据链层提供者接口)
            来直接获得网络数据包, 其可抓取的数据包可涵盖上层的各种协议, 包括arp, rarp, icmp(因特网控制报文协议),
            ip, ip6, tcp, udp, sctp(流控制传输协议).

            对于修饰符后跟id 的格式,可理解为, type id 是对包最基本的过滤条件: 即对包相关的主机, 网络, 端口的限制;
            dir 表示对包的传送方向的限制; proto表示对包相关的协议限制)

            'fddi'(nt: Fiber Distributed Data Interface) 实际上与'ether' 含义一样: tcpdump 会把他们当作一种''指定
            网络接口上的数据链路层协议''. 如同ehter网(以太网), FDDI 的头部通常也会有源, 目的, 以及包类型, 从而可以像ether
            网数据包一样对这些域进行过滤. 此外, FDDI 头部还有其他的域, 但不能被放到表达式中用来过滤

            同样, 'tr' 和 'wlan' 也和 'ether' 含义一致, 上一段对fddi 的描述同样适用于tr(Token Ring) 和
            wlan(802.11 wireless LAN)的头部. 对于802.11 协议数据包的头部, 目的域称为DA, 源域称为 SA;
            而其中的 BSSID, RA, TA 域(nt | rt: 具体含义需补充)不会被检测(nt: 不能被用于包过虑表达式中).

        除以上所描述的表达元('primitive'), 还有其他形式的表达元, 并且与上述表达元格式不同. 比如: gateway, broadcast, less, greater
        以及算术表达式(nt: 其中每一个都算一种新的表达元). 下面将会对这些表达元进行说明.

        表达元之间还可以通过关键字and, or 以及 not 进行连接, 从而可组成比较复杂的条件表达式. 比如,
        `host foo and not port ftp and not port ftp-data'(nt: 其过滤条件可理解为, 数据包的主机为foo,
        并且端口不是ftp(端口21) 和ftp-data(端口20, 常用端口和名字的对应可在linux 系统中的/etc/service 文件中找到)).
        为了表示方便, 同样的修饰符可以被省略, 如'tcp dst port ftp or ftp-data or domain' 与以下的表达式
        含义相同'tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.(nt: 其过滤条件可理解为,
        包的协议为tcp, 目的端口为ftp 或 ftp-data 或 domain(端口53) ).


        可用的表达元有:
        (nt: True 在以下的描述中含义为: 相应条件表达式中只含有以下所列的一个特定表达元, 此时表达式为真, 即条件得到满足)

        dst host host
            如果IPv4/v6 数据包的目的域是host, 则与此对应的条件表达式为真.
            host 可以是一个ip地址, 也可以是一个主机名.
        src host host
            如果IPv4/v6 数据包的源域是host, 则与此对应的条件表达式为真.
            host 可以是一个ip地址, 也可以是一个主机名.
        host host

            如果IPv4/v6数据包的源或目的地址是 host, 则与此对应的条件表达式为真.
            以上的几个host 表达式之前可以添加以下关键字:ip, arp, rarp, 以及 ip6.比如:

        ip host host
            也可以表达为:
            ether proto \ip and host host(nt: 这种表达方式在下面有说明, 其中ip之前需要有\来转义,
            因为ip 对tcpdump 来说已经是一个关键字了.)

            如果host 是一个拥有多个IP 的主机, 那么任何一个地址都会用于包的匹配(nt: 即发向host 的数据包的目的地址
            可以是这几个IP中的任何一个, 从host 接收的数据包的源地址也可以是这几个IP中的任何一个).

        ether dst ehost
            如果数据包(nt: 指tcpdump 可抓取的数据包, 包括ip 数据包, tcp数据包)的以太网目标地址是ehost,
            则与此对应的条件表达式为真. Ehost 可以是/etc/ethers 文件中的名字
            或一个数字地址(nt: 可通过 man ethers 看到对/etc/ethers 文件的描述, 样例中用的是数字地址)

        ether src ehost
            果数据包的以太网源地址是ehost, 则与此对应的条件表达式为真.

        ether host ehost
            如果数据包的以太网源地址或目标地址是ehost, 则与此对应的条件表达式为真.

        gateway host
            如果数据包的网关地址是host, 则与此对应的条件表达式为真. 需要注意的是, 这里
            的网关地址是指以太网地址, 而不是IP 地址(nt | rt: I.e., 例如, 可理解为'注意'.
            the  Ethernet  source  or  destination address, 以太网源和目标地址, 可理解为, 指代上句中的'网关地址' ).
            host 必须是名字而不是数字, 并且必须在机器的'主机名-ip地址'以及'主机名-以太地址'两大映射关系中 有其条目
            (前一映射关系可通过/etc/hosts文件, DNS 或 NIS得到, 而后一映射关系可通过/etc/ethers 文件得到. nt: /etc/ethers
            并不一定存在 , 可通过man ethers 看到其数据格式, 如何创建该文件, 未知,需补充).
            也就是说host 的含义是 ether host ehost 而不是 host host, 并且ehost必须是名字而不是数字.
            目前, 该选项在支持IPv6地址格式的配置环境中不起作用(nt: configuration, 配置环境, 可理解为,通信双方的网络配置).

        dst net net
            如果数据包的目标地址(IPv4或IPv6格式)的网络号字段为 net, 则与此对应的条件表达式为真.
        net 可以是从网络数据库文件/etc/networks 中的名字, 也可以是一个数字形式的网络编号.

            一个数字IPv4 网络编号将以点分四元组(比如, 192.168.1.0), 或点分三元组(比如, 192.168.1 ), 或点分
            二元组(比如, 172.16), 或单一单元组(比如, 10)来表达;

            对应于这四种情况的网络掩码分别是:四元组:255.255.255.255(这也意味着对net 的匹配如同对主机地址(host)的匹配:地址的四个部分都用到了),
            三元组:255.255.255.0, 二元组: 255.255.0.0, 一元组:255.0.0.0.

            对于IPv6 的地址格式, 网络编号必须全部写出来(8个部分必须全部写出来); 相应网络掩码为:
            ff:ff:ff:ff:ff:ff:ff:ff, 所以IPv6 的网络匹配是真正的'host'方式的匹配(nt | rt | rc:地址的8个部分都会用到,
            是否不属于网络的字节填写0, 需接下来补充), 但同时需要一个网络掩码长度参数来具体指定前面多少字节为网络掩码
            (nt: 可通过下面的net net/len 来指定)

        src net net
            如果数据包的源地址(IPv4或IPv6格式)的网络号字段为 net, 则与此对应的条件表达式为真.

        net net
            如果数据包的源或目的地址(IPv4或IPv6格式)的网络号字段为 net, 则与此对应的条件表达式为真.

        net net mask netmask
            如果数据包的源或目的地址(IPv4或IPv6格式)的网络掩码与netmask 匹配, 则与此对应的条件表达式为真.
            此选项之前还可以配合src和dst来匹配源网络地址或目标网络地址(nt: 比如 src net net mask 255.255.255.0).
            该选项对于ipv6 网络地址无效.

        net net/len
            如果数据包的源或目的地址(IPv4或IPv6格式)的网络编号字段的比特数与len相同, 则与此对应的条件表达式为真.
            此选项之前还可以配合src和dst来匹配源网络地址或目标网络地址(nt | rt | tt: src net net/24, 表示需要匹配
            源地址的网络编号有24位的数据包).

        dst port port
            如果数据包(包括ip/tcp, ip/udp, ip6/tcp or ip6/udp协议)的目的端口为port, 则与此对应的条件表达式为真.
            port 可以是一个数字也可以是一个名字(相应名字可以在/etc/services 中找到该名字, 也可以通过man tcp 和man udp
            来得到相关描述信息 ). 如果使用名字, 则该名字对应的端口号和相应使用的协议都会被检查. 如果只是使用一个数字端口号,
            则只有相应端口号被检查(比如, dst port 513 将会使tcpdump抓取tcp协议的login 服务
            和udp协议的who 服务数据包, 而port domain 将会使tcpdump 抓取tcp协议的domain 服务数据包, 以及udp 协议的
            domain 数据包)(nt | rt: ambiguous name is used 不可理解, 需补充).

        src port port
            如果数据包的源端口为port, 则与此对应的条件表达式为真.

        port port
            如果数据包的源或目的端口为port, 则与此对应的条件表达式为真.

        dst portrange port1-port2
            如果数据包(包括ip/tcp, ip/udp, ip6/tcp or ip6/udp协议)的目的端口属于port1到port2这个端口范围(包括
        port1, port2), 则与此对应的条件表达式为真. tcpdump 对port1 和port2 解析与对port 的解析一致(nt:
           在dst port port 选项的描述中有说明).

        src portrange port1-port2
            如果数据包的源端口属于port1到port2这个端口范围(包括 port1, port2), 则与此对应的条件表达式为真.

        portrange port1-port2
            如果数据包的源端口或目的端口属于port1到port2这个端口范围(包括 port1, port2), 则与此对应的条件表达式为真.

            以上关于port 的选项都可以在其前面添加关键字:tcp 或者udp, 比如:
        tcp src port port
            这将使tcpdump 只抓取源端口是port 的tcp数据包.

        less length
            如果数据包的长度比length 小或等于length, 则与此对应的条件表达式为真. 这与'len <= length' 的含义一致.

        greater length
            如果数据包的长度比length 大或等于length, 则与此对应的条件表达式为真. 这与'len >= length' 的含义一致.

        ip proto protocol
            如果数据包为ipv4数据包并且其协议类型为protocol, 则与此对应的条件表达式为真.
            Protocol 可以是一个数字也可以是名字, 比如:icmp6, igmp, igrp(nt: Interior Gateway Routing Protocol,
            内部网关路由协议), pim(Protocol Independent Multicast, 独立组播协议, 应用于组播路由器),
            ah, esp(nt: ah, 认证头, esp 安全负载封装, 这两者会用在IP包的安全传输机制中 ), vrrp(Virtual Router
            Redundancy Protocol, 虚拟路由器冗余协议), udp, or tcp. 由于tcp , udp 以及icmp是tcpdump 的关键字,
            所以在这些协议名字之前必须要用\来进行转义(如果在C-shell 中需要用\\来进行转义). 注意此表达元不会把数据包中
            协议头链中所有协议头内容全部打印出来(nt: 实际上只会打印指定协议的一些头部信息, 比如可以用
            tcpdump -i eth0 'ip proto \tcp and host 192.168.3.144', 则只打印主机192.168.3.144 发出或接收的
            数据包中tcp 协议头所包含的信息)

        ip6 proto protocol
            如果数据包为ipv6数据包并且其协议类型为protocol, 则与此对应的条件表达式为真.
            注意此表达元不会把数据包中协议头链中所有协议头内容全部打印出来

        ip6 protochain protocol
            如果数据包为ipv6数据包并且其协议链中包含类型为protocol协议头, 则与此对应的条件表达式为真. 比如,
        ip6 protochain 6

            将匹配其协议头链中拥有TCP 协议头的IPv6数据包.此数据包的IPv6头和TCP头之间可能还会包含验证头, 路由头, 或者逐跳寻径选项头.
            由此所触发的相应BPF(Berkeley Packets Filter, 可理解为, 在数据链路层提供数据包过滤的一种机制)代码比较繁琐,
            并且BPF优化代码也未能照顾到此部分, 从而此选项所触发的包匹配可能会比较慢.

        ip protochain protocol
            与ip6 protochain protocol 含义相同, 但这用在IPv4数据包.

        ether broadcast
            如果数据包是以太网广播数据包, 则与此对应的条件表达式为真. ether 关键字是可选的.

        ip broadcast
            如果数据包是IPv4广播数据包, 则与此对应的条件表达式为真. 这将使tcpdump 检查广播地址是否符合全0和全1的一些约定,
            并查找网络接口的网络掩码(网络接口为当时在其上抓包的网络接口).

            如果抓包所在网络接口的网络掩码不合法, 或者此接口根本就没有设置相应网络地址和网络, 亦或是在linux下的'any'网络
            接口上抓包(此'any'接口可以收到系统中不止一个接口的数据包(nt: 实际上, 可理解为系统中所有可用的接口)),
            网络掩码的检查不能正常进行.


        ether multicast
            如果数据包是一个以太网多点广播数据包(nt: 多点广播, 可理解为把消息同时传递给一组目的地址, 而不是网络中所有地址,
            后者为可称为广播(broadcast)), 则与此对应的条件表达式为真. 关键字ether 可以省略. 此选项的含义与以下条件
            表达式含义一致:`ether[0] & 1 != 0'(nt: 可理解为, 以太网数据包中第0个字节的最低位是1, 这意味这是一个
            多点广播数据包).

        ip multicast
            如果数据包是ipv4多点广播数据包, 则与此对应的条件表达式为真.

        ip6 multicast
            如果数据包是ipv6多点广播数据包, 则与此对应的条件表达式为真.

        ether proto protocol
            如果数据包属于以下以太协议类型, 则与此对应的条件表达式为真.
            协议(protocol)字段, 可以是数字或以下所列出了名字: ip, ip6, arp, rarp, atalk(AppleTalk网络协议),
            aarp(nt: AppleTalk Address Resolution Protocol, AppleTalk网络的地址解析协议),
            decnet(nt: 一个由DEC公司所提供的网络协议栈), sca(nt: 未知, 需补充),
            lat(Local Area Transport, 区域传输协议, 由DEC公司开发的以太网主机互联协议),
            mopdl, moprc, iso(nt: 未知, 需补充), stp(Spanning tree protocol, 生成树协议, 可用于防止网络中产生链接循环),
            ipx(nt: Internetwork Packet Exchange, Novell 网络中使用的网络层协议), 或者
            netbeui(nt: NetBIOS Extended User Interface,可理解为, 网络基本输入输出系统接口扩展).

            protocol字段可以是一个数字或以下协议名之一:ip, ip6, arp, rarp, atalk, aarp, decnet, sca, lat,
            mopdl, moprc, iso, stp, ipx, 或者netbeui.
            必须要注意的是标识符也是关键字, 从而必须通过'\'来进行转义.

            (SNAP:子网接入协议 (SubNetwork Access Protocol))

            在光纤分布式数据网络接口(其表达元形式可以是'fddi protocol arp'), 令牌环网(其表达元形式可以是'tr protocol arp'),
            以及IEEE 802.11 无线局域网(其表达元形式可以是'wlan protocol arp')中, protocol
            标识符来自802.2 逻辑链路控制层头,
            在FDDI, Token Ring 或 802.1头中会包含此逻辑链路控制层头.

            当以这些网络上的相应的协议标识为过滤条件时, tcpdump只是检查LLC头部中以0x000000为组成单元标识符(OUI, 0x000000
            标识一个内部以太网)的一段'SNAP格式结构'中的protocol ID 域, 而不会管包中是否有一段OUI为0x000000的'SNAP格式
            结构'(nt: SNAP, SubNetwork Access Protocol,子网接入协议 ). 以下例外:

            iso    tcpdump 会检查LLC头部中的DSAP域(Destination service Access Point, 目标服务接入点)和
                SSAP域(源服务接入点).(nt: iso 协议未知, 需补充)

            stp 以及 netbeui
                tcpdump 将会检查LLC 头部中的目标服务接入点(Destination service Access Point);

            atalk
                tcpdump 将会检查LLC 头部中以0x080007 为OUI标识的'SNAP格式结构', 并会检查AppleTalk etype域.
                (nt: AppleTalk etype 是否位于SNAP格式结构中, 未知, 需补充).

                此外, 在以太网中, 对于ether proto protocol 选项, tcpdump 会为 protocol 所指定的协议检查
                以太网类型域(the Ethernet type field), 但以下这些协议除外:

            iso, stp, and netbeui
                tcpdump 将会检查802.3 物理帧以及LLC 头(这两种检查与FDDI, TR, 802.11网络中的相应检查一致);
                (nt: 802.3, 理解为IEEE 802.3, 其为一系列IEEE 标准的集合. 此集合定义了有线以太网络中的物理层以及数据
                链路层的媒体接入控制子层. stp 在上文已有描述)

            atalk
                tcpdump 将会检查以太网物理帧中的AppleTalk etype 域 , 同时也会检查数据包中LLC头部中的'SNAP格式结构'
                (这两种检查与FDDI, TR, 802.11网络中的相应检查一致)

            aarp   tcpdump 将会检查AppleTalk ARP etype 域, 此域或存在于以太网物理帧中, 或存在于LLC(由802.2 所定义)的
                'SNAP格式结构'中, 当为后者时, 该'SNAP格式结构'的OUI标识为0x000000;
                (nt: 802.2, 可理解为, IEEE802.2, 其中定义了逻辑链路控制层(LLC), 该层对应于OSI 网络模型中数据链路层的上层部分.
                LLC 层为使用数据链路层的用户提供了一个统一的接口(通常用户是网络层). LLC层以下是媒体接入控制层(nt: MAC层,
                对应于数据链路层的下层部分).该层的实现以及工作方式会根据不同物理传输媒介的不同而有所区别(比如, 以太网, 令牌环网,
                光纤分布数据接口(nt: 实际可理解为一种光纤网络), 无线局域网(802.11), 等等.)

            ipx    tcpdump 将会检查物理以太帧中的IPX etype域, LLC头中的IPX DSAP域,无LLC头并对IPX进行了封装的802.3帧,
                以及LLC 头部'SNAP格式结构'中的IPX etype 域(nt | rt: SNAP frame, 可理解为, LLC 头中的'SNAP格式结构'.
                该含义属初步理解阶段, 需补充).

        decnet src host
            如果数据包中DECNET源地址为host, 则与此对应的条件表达式为真.
            (nt:decnet, 由Digital Equipment Corporation 开发, 最早用于PDP-11 机器互联的网络协议)

        decnet dst host
            如果数据包中DECNET目的地址为host, 则与此对应的条件表达式为真.
            (nt: decnet 在上文已有说明)

        decnet host host
            如果数据包中DECNET目的地址或DECNET源地址为host, 则与此对应的条件表达式为真.
            (nt: decnet 在上文已有说明)

        ifname interface
            如果数据包已被标记为从指定的网络接口中接收的, 则与此对应的条件表达式为真.
            (此选项只适用于被OpenBSD中pf程序做过标记的包(nt: pf, packet filter, 可理解为OpenBSD中的防火墙程序))

        on interface
            与 ifname interface 含义一致.

        rnr num
            如果数据包已被标记为匹配PF的规则, 则与此对应的条件表达式为真.
            (此选项只适用于被OpenBSD中pf程序做过标记的包(nt: pf, packet filter, 可理解为OpenBSD中的防火墙程序))

        rulenum num
            与 rulenum num 含义一致.

        reason code
            如果数据包已被标记为包含PF的匹配结果代码, 则与此对应的条件表达式为真.有效的结果代码有: match, bad-offset,
            fragment, short, normalize, 以及memory.
            (此选项只适用于被OpenBSD中pf程序做过标记的包(nt: pf, packet filter, 可理解为OpenBSD中的防火墙程序))

        rset name
            如果数据包已被标记为匹配指定的规则集, 则与此对应的条件表达式为真.
            (此选项只适用于被OpenBSD中pf程序做过标记的包(nt: pf, packet filter, 可理解为OpenBSD中的防火墙程序))

        ruleset name
            与 rset name 含义一致.

        srnr num
            如果数据包已被标记为匹配指定的规则集中的特定规则(nt: specified PF rule number, 特定规则编号, 即特定规则),
            则与此对应的条件表达式为真.(此选项只适用于被OpenBSD中pf程序做过标记的包(nt: pf, packet filter, 可理解为
            OpenBSD中的防火墙程序))

        subrulenum num
            与 srnr 含义一致.

        action act
            如果包被记录时PF会执行act指定的动作, 则与此对应的条件表达式为真. 有效的动作有: pass, block.
            (此选项只适用于被OpenBSD中pf程序做过标记的包(nt: pf, packet filter, 可理解为OpenBSD中的防火墙程序))

            ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui
                与以下表达元含义一致:
            ether proto p
                p是以上协议中的一个.

            lat, moprc, mopdl
                与以下表达元含义一致:
            ether proto p
                p是以上协议中的一个. 必须要注意的是tcpdump目前还不能分析这些协议.

        vlan [vlan_id]
            如果数据包为IEEE802.1Q VLAN 数据包, 则与此对应的条件表达式为真.
            (nt: IEEE802.1Q VLAN, 即IEEE802.1Q 虚拟网络协议, 此协议用于不同网络的之间的互联).
            如果[vlan_id] 被指定, 则只有数据包含有指定的虚拟网络id(vlan_id), 则与此对应的条件表达式为真.
            要注意的是, 对于VLAN数据包, 在表达式中遇到的第一个vlan关键字会改变表达式中接下来关键字所对应数据包中数据的
            开始位置(即解码偏移). 在VLAN网络体系中过滤数据包时, vlan [vlan_id]表达式可以被多次使用. 关键字vlan每出现一次都会增加
            4字节过滤偏移(nt: 过滤偏移, 可理解为上面的解码偏移).

            例如:
            vlan 100 && vlan 200
            表示: 过滤封装在VLAN100中的VLAN200网络上的数据包
            再例如:
            vlan && vlan 300 && ip
            表示: 过滤封装在VLAN300 网络中的IPv4数据包, 而VLAN300网络又被更外层的VLAN封装


        mpls [label_num]
            如果数据包为MPLS数据包, 则与此对应的条件表达式为真.
            (nt: MPLS, Multi-Protocol Label Switch, 多协议标签交换, 一种在开放的通信网上利用标签引导数据传输的技术).

            如果[label_num] 被指定, 则只有数据包含有指定的标签id(label_num), 则与此对应的条件表达式为真.
            要注意的是, 对于内含MPLS信息的IP数据包(即MPLS数据包), 在表达式中遇到的第一个MPLS关键字会改变表达式中接下来关键字所对应数据包中数据的
            开始位置(即解码偏移). 在MPLS网络体系中过滤数据包时, mpls [label_num]表达式可以被多次使用. 关键字mpls每出现一次都会增加
            4字节过滤偏移(nt: 过滤偏移, 可理解为上面的解码偏移).

            例如:
            mpls 100000 && mpls 1024
            表示: 过滤外层标签为100000 而层标签为1024的数据包

            再如:
            mpls && mpls 1024 && host 192.9.200.1
            表示: 过滤发往或来自192.9.200.1的数据包, 该数据包的内层标签为1024, 且拥有一个外层标签.

        pppoed
            如果数据包为PPP-over-Ethernet的服务器探寻数据包(nt: Discovery packet,
            其ethernet type 为0x8863),则与此对应的条件表达式为真.
            (nt: PPP-over-Ethernet, 点对点以太网承载协议, 其点对点的连接建立分为Discovery阶段(地址发现) 和
            PPPoE 会话建立阶段 , discovery 数据包就是第一阶段发出来的包. ethernet type
            是以太帧里的一个字段,用来指明应用于帧数据字段的协议)

        pppoes
            如果数据包为PPP-over-Ethernet会话数据包(nt: ethernet type 为0x8864, PPP-over-Ethernet在上文已有说明, 可搜索
            关键字'PPP-over-Ethernet'找到其描述), 则与此对应的条件表达式为真.

            要注意的是, 对于PPP-over-Ethernet会话数据包, 在表达式中遇到的第一个pppoes关键字会改变表达式中接下来关键字所对应数据包中数据的
            开始位置(即解码偏移).

            例如:
            pppoes && ip
            表示: 过滤嵌入在PPPoE数据包中的ipv4数据包

        tcp, udp, icmp
            与以下表达元含义一致:
            ip proto p or ip6 proto p
            其中p 是以上协议之一(含义分别为:  如果数据包为ipv4或ipv6数据包并且其协议类型为 tcp,udp, 或icmp则与此对
            应的条件表达式为真)

        iso proto protocol
            如果数据包的协议类型为iso-osi协议栈中protocol协议, 则与此对应的条件表达式为真.(nt: [初解]iso-osi 网络模型中每
            层的具体协议与tcp/ip相应层采用的协议不同. iso-osi各层中的具体协议另需补充 )

            protocol 可以是一个数字编号, 或以下名字中之一:
            clnp, esis, or isis.
            (nt: clnp, Connectionless Network Protocol, 这是OSI网络模型中网络层协议 , esis, isis 未知, 需补充)

            clnp, esis, isis
            是以下表达的缩写
            iso proto p
            其中p 是以上协议之一


        l1, l2, iih, lsp, snp, csnp, psnp
            为IS-IS PDU 类型 的缩写.
            (nt: IS-IS PDU, Intermediate system to intermediate system Protocol Data Unit, 中间系统到
            中间系统的协议数据单元. OSI(Open Systems Interconnection)网络由终端系统, 中间系统构成.
            终端系统指路由器, 而终端系统指用户设备. 路由器形成的本地组称之为'区域'(Area)和多个区域组成一个'域'(Domain).
            IS-IS 提供域内或区域内的路由. l1, l2, iih, lsp, snp, csnp, psnp 表示PDU的类型, 具体含义另需补充)

        vpi n
            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 ,
            如果数据包为ATM数据包, 并且其虚拟路径标识为n,  则与此对应的条件表达式为真.
            (nt: ATM, Asychronous Transfer Mode, 实际上可理解为由ITU-T(国际电信联盟电信标准化部门)提出的一个与
            TCP/IP中IP层功能等同的一系列协议, 具体协议层次另需补充)

        vci n
            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 ,
            如果数据包为ATM数据包, 并且其虚拟通道标识为n,  则与此对应的条件表达式为真.
            (nt: ATM, 在上文已有描述)

        lane
            如果数据包为ATM LANE 数据包, 则与此对应的条件表达式为真. 要注意的是, 如果是模拟以太网的LANE数据包或者
            LANE逻辑单元控制包, 表达式中第一个lane关键字会改变表达式中随后条件的测试. 如果没有
            指定lane关键字, 条件测试将按照数据包中内含LLC(逻辑链路层)的ATM包来进行.

        llc
            如果数据包为ATM数据包, 则与此对应的条件表达式为真.  对于Solaris 操作系统上的SunATM设备 ,
            如果数据包为ATM数据包, 并且内含LLC则与此对应的条件表达式为真

        oamf4s
            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 , 如果数据包为ATM数据包
            并且是Segment OAM F4 信元(VPI=0 并且 VCI=3), 则与此对应的条件表达式为真.

            (nt: OAM,  Operation Administration and Maintenance, 操作管理和维护,可理解为:ATM网络中用于网络
            管理所产生的ATM信元的分类方式.

            ATM网络中传输单位为信元, 要传输的数据终究会被分割成固定长度(53字节)的信元,
            (初理解: 一条物理线路可被复用, 形成虚拟路径(virtual path). 而一条虚拟路径再次被复用, 形成虚拟信道(virtual channel)).
            通信双方的编址方式为:虚拟路径编号(VPI)/虚拟信道编号(VCI)).

            OAM F4 flow 信元又可分为segment 类和end-to-end 类, 其区别未知, 需补充.)

        oamf4e
            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 , 如果数据包为ATM数据包
            并且是 end-to-end OAM F4 信元(VPI=0 并且 VCI=4), 则与此对应的条件表达式为真.
            (nt: OAM 与 end-to-end OAM F4 在上文已有描述, 可搜索'oamf4s'来定位)

        oamf4
            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 , 如果数据包为ATM数据包
            并且是 end-to-end 或 segment OAM F4 信元(VPI=0 并且 VCI=3 或者 VCI=4), 则与此对应的条件表达式为真.
            (nt: OAM 与 end-to-end OAM F4 在上文已有描述, 可搜索'oamf4s'来定位)

        oam
            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 , 如果数据包为ATM数据包
            并且是 end-to-end 或 segment OAM F4 信元(VPI=0 并且 VCI=3 或者 VCI=4), 则与此对应的条件表达式为真.
            (nt: 此选项与oamf4重复, 需确认)

        metac
            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 , 如果数据包为ATM数据包
            并且是来自'元信令线路'(nt: VPI=0 并且 VCI=1, '元信令线路', meta  signaling circuit, 具体含义未知, 需补充),
            则与此对应的条件表达式为真.

        bcc
            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 , 如果数据包为ATM数据包
            并且是来自'广播信令线路'(nt: VPI=0 并且 VCI=2, '广播信令线路', broadcast signaling circuit, 具体含义未知, 需补充),
            则与此对应的条件表达式为真.

        sc
            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 , 如果数据包为ATM数据包
            并且是来自'信令线路'(nt: VPI=0 并且 VCI=5, '信令线路', signaling  circuit, 具体含义未知, 需补充),
            则与此对应的条件表达式为真.

        ilmic
            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 , 如果数据包为ATM数据包
            并且是来自'ILMI线路'(nt: VPI=0 并且 VCI=16, 'ILMI', Interim Local Management Interface , 可理解为
            基于SNMP(简易网络管理协议)的用于网络管理的接口)
            则与此对应的条件表达式为真.


        connectmsg

            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 , 如果数据包为ATM数据包
            并且是来自'信令线路'并且是Q.2931协议中规定的以下几种消息: Setup, Calling Proceeding, Connect,
            Connect Ack, Release, 或者Release Done. 则与此对应的条件表达式为真.
            (nt: Q.2931 为ITU(国际电信联盟)制定的信令协议. 其中规定了在宽带综合业务数字网络的用户接口层建立, 维护, 取消
            网络连接的相关步骤.)

        metaconnect
            如果数据包为ATM数据包, 则与此对应的条件表达式为真. 对于Solaris 操作系统上的SunATM设备 , 如果数据包为ATM数据包
            并且是来自'元信令线路'并且是Q.2931协议中规定的以下几种消息: Setup, Calling Proceeding, Connect,
            Connect Ack, Release, 或者Release Done. 则与此对应的条件表达式为真.


        expr relop expr
            如果relop 两侧的操作数(expr)满足relop 指定的关系, 则与此对应的条件表达式为真.
            relop 可以是以下关系操作符之一: >, <, <=, =, !=.
            expr 是一个算术表达式. 此表达式中可使用整型常量(表示方式与标准C中一致), 二进制操作符(+, -, *, /, &, |,
            <<, >>), 长度操作符, 以及对特定数据包中数据的引用操作符. 要注意的是, 所有的比较操作都默认操作数是无符号的,
            例如, 0x80000000 和 0xffffffff 都是大于0的(nt: 对于有符号的比较, 按照补码规则, 0xffffffff
            会小于0). 如果要引用数据包中的数据, 可采用以下表达方式:
            proto [expr : size]

            proto 的取值可以是以下取值之一:ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp,
            tcp, udp, icmp, ip6 或者  radio. 这指明了该引用操作所对应的协议层.(ether, fddi, wlan,
            tr, ppp, slip and link 对应于数据链路层, radio 对应于802.11(wlan,无线局域网)某些数据包中的附带的
            "radio"头(nt: 其中描述了波特率, 数据加密等信息)).
            要注意的是, tcp, udp 等上层协议目前只能应用于网络层采用为IPv4或IPv6协议的网络(此限制会在tcpdump未来版本中
            进行修改).  对于指定协议的所需数据, 其在包数据中的偏移字节由expr 来指定.

            以上表达中size 是可选的, 用来指明我们关注那部分数据段的长度(nt:通常这段数据
            是数据包的一个域), 其长度可以是1, 2, 或4个字节. 如果不给定size, 默认是1个字节. 长度操作符的关键字为len,
            这代码整个数据包的长度.

            例如, 'ether[0] & 1 != 0' 将会使tcpdump 抓取所有多点广播数据包.(nt: ether[0]字节的最低位为1表示
            数据包目的地址是多点广播地址). 'ip[0]  & 0xf  !=  5' 对应抓取所有带有选项的
            IPv4数据包. 'ip[6:2] & 0x1fff = 0'对应抓取没被破碎的IPv4数据包或者
            其片段编号为0的已破碎的IPv4数据包. 这种数据检查方式也适用于tcp和udp数据的引用,
            即, tcp[0]对应于TCP 头中第一个字节, 而不是对应任何一个中间的字节.

            一些偏移以及域的取值除了可以用数字也可用名字来表达. 以下为可用的一些域(协议头中的域)的名字: icmptype (指ICMP 协议头
            中type域), icmpcode (指ICMP 协议头code 域), 以及tcpflags(指TCP协议头的flags 域)

            以下为ICMP 协议头中type 域的可用取值:
            icmp-echoreply, icmp-unreach, icmp-sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert,
            icmp-routersolicit,  icmp-timx-ceed,  icmp-paramprob,  icmp-tstamp,  icmp-tstampreply,
            icmp-ireq,  icmp-ireqreply, icmp-maskreq, icmp-maskreply.

            以下为TCP 协议头中flags 域的可用取值:tcp-fin, tcp-syn,  tcp-rst,  tcp-push,
            tcp-ack, tcp-urg.

        借助括号以及相应操作符,可把表达元组合在一起使用(由于括号是shell的特殊字符, 所以在shell脚本或终端中使用时必须对括号进行
        转义, 即'(' 与')'需要分别表达成'\(' 与 '\)').
            有效的操作符有:
            否定操作 (`!' 或 `not')
            与操作(`&&' 或 `and')
            或操作(`||' 或 `or')

        否定操作符的优先级别最高. 与操作和或操作优先级别相同, 并且二者的结合顺序是从左到右. 要注意的是, 表达'与操作'时,
        需要显式写出'and'操作符, 而不只是把前后表达元并列放置(nt: 二者中间的'and' 操作符不可省略).

        如果一个标识符前没有关键字, 则表达式的解析过程中最近用过的关键字(往往也是从左往右距离标识符最近的关键字)将被使用.比如,
            not host vs and ace
            是以下表达的精简:
            not host vs and host ace
                而不是not (host vs or ace).(nt: 前两者表示, 所需数据包不是来自或发往host vs, 而是来自或发往ace.
                而后者表示数据包只要不是来自或发往vs或ac都符合要求)

        整个条件表达式可以被当作一个单独的字符串参数也可以被当作空格分割的多个参数传入tcpdump, 后者更方便些. 通常, 如果表达式
        中包含元字符(nt: 如正则表达式中的'*', '.'以及shell中的'('等字符), 最好还是使用单独字符串的方式传入. 这时,整个表达
        式需要被单引号括起来. 多参数的传入方式中, 所有参数最终还是被空格串联在一起, 作为一个字符串被解析.
 

使用例子
 
    打印所有进入或离开sundown的数据包.
    tcpdump host sundown

    打印helios 与 hot 或者与 ace 之间通信的数据包
    tcpdump host helios and \( hot or ace \)

    打印ace 与 任何其他主机之间通信的IP 数据包, 但不包括与helios之间的数据包.
    tcpdump ip host ace and not helios

    打印本地主机与Berkeley网络上的主机之间的所有通信数据包(nt: ucb-ether, 此处可理解为'Berkeley网络'的网络地址,
    此表达式最原始的含义可表达为: 打印网络地址为ucb-ether的所有数据包)
    tcpdump net ucb-ether

    打印所有通过网关snup的ftp数据包(注意, 表达式被单引号括起来了, 这可以防止shell对其中的括号进行错误解析)
    tcpdump 'gateway snup and (port ftp or ftp-data)'

    打印所有源地址或目标地址是本地主机的IP数据包
    (如果本地网络通过网关连到了另一网络, 则另一网络并不能算作本地网络.(nt: 此句翻译曲折,需补充).
    localnet 实际使用时要真正替换成本地网络的名字)

    tcpdump ip and not net localnet

    打印TCP会话中的的开始和结束数据包, 并且数据包的源或目的不是本地网络上的主机.(nt: localnet, 实际使用时要真正替换成本地网络的名字))
    tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'

    打印所有源或目的端口是80, 网络层协议为IPv4, 并且含有数据,而不是SYN,FIN以及ACK-only等不含数据的数据包.(ipv6的版本的表达式可做练习)
    tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

    (nt: 可理解为, ip[2:2]表示整个ip数据包的长度, (ip[0]&0xf)<<2)表示ip数据包包头的长度(ip[0]&0xf代表包中的IHL域, 而此域的单位为32bit, 要换算
    成字节数需要乘以4, 即左移2. (tcp[12]&0xf0)>>4 表示tcp头的长度, 此域的单位也是32bit, 换算成比特数为 ((tcp[12]&0xf0) >> 4) << 2, 
    即 ((tcp[12]&0xf0)>>2). ((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0 表示: 整个ip数据包的长度减去ip头的长度,再减去
    tcp头的长度不为0, 这就意味着, ip数据包中确实是有数据.
    对于ipv6版本只需考虑ipv6头中的'Payload Length' 与  'tcp头的长度'的差值, 并且其中表达方式'ip[]'需换成'ip6[]'.)

    打印长度超过576字节, 并且网关地址是snup的IP数据包
    tcpdump 'gateway snup and ip[2:2] > 576'

    打印所有IP层广播或多播的数据包, 但不是物理以太网层的广播或多播数据报
    tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

    打印除'echo request'或者'echo reply'类型以外的ICMP数据包( 比如,需要打印所有非ping 程序产生的数据包时可用到此表达式 .
    (nt: 'echo reuqest' 与 'echo reply' 这两种类型的ICMP数据包通常由ping程序产生))
    tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

    以下列出了tcp, ip, ipv6头的结构, 以方便查看(需要以等宽字体查看).

    TCP 头格式(rfc793)
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Source Port          |       Destination Port        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Acknowledgment Number                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Data |           |U|A|P|R|S|F|                               |
    | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
    |       |           |G|K|H|T|N|N|                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Checksum            |         Urgent Pointer        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Options                    |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             data                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    IPV4 头格式(rfc791)
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version|  IHL  |Type of Service|          Total Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Identification        |Flags|      Fragment Offset    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Time to Live |    Protocol   |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Options                    |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    IPV6 头格式(rfc2460)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version| Traffic Class |           Flow Label                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Payload Length        |  Next Header  |   Hop Limit   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                         Source Address                        +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                      Destination Address                      +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 

输出格式
 
    tcpdump 的输出格式与协议有关. 以下简要描述了大部分常用的格式及相关例子.

    链路层头

    对于FDDI网络, '-e' 使tcpdump打印出指定数据包的'frame control' 域, 源和目的地址, 以及包的长度.(frame control域
    控制对包中其他域的解析). 一般的包(比如那些IP datagrams)都是带有'async'(异步标志)的数据包,并且有取值0到7的优先级;
    比如 'async4'就代表此包为异步数据包,并且优先级别为4. 通常认为,这些包们会内含一个 LLC包(逻辑链路控制包); 这时,如果此包
    不是一个ISO datagram或所谓的SNAP包,其LLC头部将会被打印(nt:应该是指此包内含的 LLC包的包头).

    对于Token Ring网络(令牌环网络), '-e' 使tcpdump打印出指定数据包的'frame control'和'access control'域, 以及源和目的地址,
    外加包的长度. 与FDDI网络类似, 此数据包通常内含LLC数据包. 不管 是否有'-e'选项.对于此网络上的'source-routed'类型数据包(nt:
    意译为:源地址被追踪的数据包,具体含义未知,需补充), 其包的源路由信息总会被打印.


    对于802.11网络(WLAN,即wireless local area network), '-e' 使tcpdump打印出指定数据包的'frame control域,
    包头中包含的所有地址, 以及包的长度.与FDDI网络类似, 此数据包通常内含LLC数据包.

    (注意: 以下的描述会假设你熟悉SLIP压缩算法 (nt:SLIP为Serial Line Internet Protocol.), 这个算法可以在
    RFC-1144中找到相关的蛛丝马迹.)

    对于SLIP网络(nt:SLIP links, 可理解为一个网络, 即通过串行线路建立的连接, 而一个简单的连接也可看成一个网络),
    数据包的'direction indicator'('方向指示标志')("I"表示入, "O"表示出), 类型以及压缩信息将会被打印. 包类型会被首先打印.

    类型分为ip, utcp以及ctcp(nt:未知, 需补充). 对于ip包,连接信息将不被打印(nt:SLIP连接上,ip包的连接信息可能无用或没有定义.
    reconfirm).对于TCP数据包, 连接标识紧接着类型表示被打印. 如果此包被压缩, 其被编码过的头部将被打印.
    此时对于特殊的压缩包,会如下显示:
        *S+n 或者 *SA+n, 其中n代表包的(顺序号或(顺序号和应答号))增加或减少的数目(nt | rt:S,SA拗口, 需再译).
    对于非特殊的压缩包,0个或更多的'改变'将会被打印.'改变'被打印时格式如下:
        '标志'+/-/=n 包数据的长度 压缩的头部长度.
    其中'标志'可以取以下值:
        U(代表紧急指针), W(指缓冲窗口), A(应答), S(序列号), I(包ID),而增量表达'=n'表示被赋予新的值, +/-表示增加或减少.

    比如, 以下显示了对一个外发压缩TCP数据包的打印, 这个数据包隐含一个连接标识(connection identifier); 应答号增加了6,
    顺序号增加了49, 包ID号增加了6; 包数据长度为3字节(octect), 压缩头部为6字节.(nt:如此看来这应该不是一个特殊的压缩数据包).

    ARP/RARP 数据包

    tcpdump对Arp/rarp包的输出信息中会包含请求类型及该请求对应的参数. 显示格式简洁明了. 以下是从主机rtsg到主机csam的'rlogin'
    (远程登录)过程开始阶段的数据包样例:
        arp who-has csam tell rtsg
        arp reply csam is-at CSAM
    第一行表示:rtsg发送了一个arp数据包(nt:向全网段发送,arp数据包)以询问csam的以太网地址
    Csam(nt:可从下文看出来, 是Csam)以她自己的以太网地址做了回应(在这个例子中, 以太网地址以大写的名字标识, 而internet
    地址(即ip地址)以全部的小写名字标识).

    如果使用tcpdump -n, 可以清晰看到以太网以及ip地址而不是名字标识:
        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
    第一个数据包表明:以arp包的源以太地址是RTSG, 目标地址是全以太网段, type域的值为16进制0806(表示ETHER_ARP(nt:arp包的类型标识)),
    包的总长度为64字节.


    TCP 数据包

    (注意:以下将会假定你对  RFC-793所描述的TCP熟悉. 如果不熟, 以下描述以及tcpdump程序可能对你帮助不大.(nt:警告可忽略,
    只需继续看, 不熟悉的地方可回头再看.).


    通常tcpdump对tcp数据包的显示格式如下:
        src > dst: flags data-seqno ack window urgent options

    src 和 dst 是源和目的IP地址以及相应的端口. flags 标志由S(SYN), F(FIN), P(PUSH, R(RST),
    W(ECN CWT(nt | rep:未知, 需补充))或者 E(ECN-Echo(nt | rep:未知, 需补充))组成,
    单独一个'.'表示没有flags标识. 数据段顺序号(Data-seqno)描述了此包中数据所对应序列号空间中的一个位置(nt:整个数据被分段,
    每段有一个顺序号, 所有的顺序号构成一个序列号空间)(可参考以下例子). Ack 描述的是同一个连接,同一个方向,下一个本端应该接收的
    (对方应该发送的)数据片段的顺序号. Window是本端可用的数据接收缓冲区的大小(也是对方发送数据时需根据这个大小来组织数据).
    Urg(urgent) 表示数据包中有紧急的数据. options 描述了tcp的一些选项, 这些选项都用尖括号来表示(如 <mss 1024>).

    src, dst 和 flags 这三个域总是会被显示. 其他域的显示与否依赖于tcp协议头里的信息.

        这是一个从trsg到csam的一个rlogin应用登录的开始阶段.
        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主机的tcp端口login上(nt:udp协议的端口和tcp协议的端
        口是分别的两个空间, 虽然取值范围一致). S表示设置了SYN标志. 包的顺序号是768512, 并且没有包含数据.(表示格式
        为:'first:last(nbytes)', 其含义是'此包中数据的顺序号从first开始直到last结束,不包括last. 并且总共包含nbytes的
        用户数据'.) 没有捎带应答(nt:从下文来看,第二行才是有捎带应答的数据包), 可用的接受窗口的大小为4096bytes, 并且请求端(rtsg)
        的最大可接受的数据段大小是1024字节(nt:这个信息作为请求发向应答端csam, 以便双方进一步的协商).

    Csam 向rtsg 回复了基本相同的SYN数据包, 其区别只是多了一个' piggy-backed ack'(nt:捎带回的ack应答, 针对rtsg的SYN数据包).

    rtsg 同样针对csam的SYN数据包回复了一ACK数据包作为应答. '.'的含义就是此包中没有标志被设置. 由于此应答包中不含有数据, 所以
    包中也没有数据段序列号. 提醒! 此ACK数据包的顺序号只是一个小整数1. 有如下解释:tcpdump对于一个tcp连接上的会话, 只打印会话两端的
    初始数据包的序列号,其后相应数据包只打印出与初始包序列号的差异.即初始序列号之后的序列号, 可被看作此会话上当前所传数据片段在整个
    要传输的数据中的'相对字节'位置(nt:双方的第一个位置都是1, 即'相对字节'的开始编号). '-S'将覆盖这个功能, 
    使数据包的原始顺序号被打印出来.



    第六行的含义为:rtsg 向 csam发送了19字节的数据(字节的编号为2到20,传送方向为rtsg到csam). 包中设置了PUSH标志. 在第7行,
    csam 喊到, 她已经从rtsg中收到了21以下的字节, 但不包括21编号的字节. 这些字节存放在csam的socket的接收缓冲中, 相应地,
    csam的接收缓冲窗口大小会减少19字节(nt:可以从第5行和第7行win属性值的变化看出来). csam在第7行这个包中也向rtsg发送了一个
    字节. 在第8行和第9行, csam 继续向rtsg 分别发送了两个只包含一个字节的数据包, 并且这个数据包带PUSH标志.

    如果所抓到的tcp包(nt:即这里的snapshot)太小了,以至tcpdump无法完整得到其头部数据, 这时, tcpdump会尽量解析这个不完整的头,
    并把剩下不能解析的部分显示为'[|tcp]'. 如果头部含有虚假的属性信息(比如其长度属性其实比头部实际长度长或短), tcpdump会为该头部
    显示'[bad opt]'. 如果头部的长度告诉我们某些选项(nt | rt:从下文来看, 指tcp包的头部中针对ip包的一些选项, 回头再翻)会在此包中,
    而真正的IP(数据包的长度又不够容纳这些选项, tcpdump会显示'[bad hdr length]'.


    抓取带有特殊标志的的TCP包(如SYN-ACK标志, URG-ACK标志等).

    在TCP的头部中, 有8比特(bit)用作控制位区域, 其取值为:
        CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
    (nt | rt:从表达方式上可推断:这8个位是用或的方式来组合的, 可回头再翻)

    现假设我们想要监控建立一个TCP连接整个过程中所产生的数据包. 可回忆如下:TCP使用3次握手协议来建立一个新的连接; 其与此三次握手
    连接顺序对应,并带有相应TCP控制标志的数据包如下:
    1) 连接发起方(nt:Caller)发送SYN标志的数据包
    2) 接收方(nt:Recipient)用带有SYN和ACK标志的数据包进行回应
    3) 发起方收到接收方回应后再发送带有ACK标志的数据包进行回应


    0                            15                              31
    -----------------------------------------------------------------
    |          source port          |       destination port        |
    -----------------------------------------------------------------
    |                        sequence number                        |
    -----------------------------------------------------------------
    |                     acknowledgment number                     |
    -----------------------------------------------------------------
    |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
    -----------------------------------------------------------------
    |         TCP checksum          |       urgent pointer          |
    -----------------------------------------------------------------

    一个TCP头部,在不包含选项数据的情况下通常占用20个字节(nt | rt:options 理解为选项数据,需回译). 第一行包含0到3编号的字节,
    第二行包含编号4-7的字节.

    如果编号从0开始算, TCP控制标志位于13字节(nt:第四行左半部分).



    0             7|             15|             23|             31
    ----------------|---------------|---------------|----------------
    |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
    ----------------|---------------|---------------|----------------
    |               |  13th octet   |               |               |

    让我们仔细看看编号13的字节:

           |               |
           |---------------|
           |C|E|U|A|P|R|S|F|
           |---------------|
           |7   5   3     0|


    这里有我们感兴趣的控制标志位.  从右往左这些位被依次编号为0到7, 从而 PSH位在3号, 而URG位在5号.



    提醒一下自己, 我们只是要得到包含SYN标志的数据包. 让我们看看在一个包的包头中, 如果SYN位被设置, 到底
    在13号字节发生了什么:

           |C|E|U|A|P|R|S|F|
           |---------------|
           |0 0 0 0 0 0 1 0|
           |---------------|
           |7 6 5 4 3 2 1 0|


    在控制段的数据中, 只有比特1(bit number 1)被置位.

    假设编号为13的字节是一个8位的无符号字符型,并且按照网络字节号排序(nt:对于一个字节来说,网络字节序等同于主机字节序), 其二进制值
    如下所示:
    00000010

    并且其10进制值为:

    0*2^7 + 0*2^6 + 0*2^5 + 0*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2^0  =  2(nt: 1 * 2^6 表示1乘以2的6次方, 也许这样更
    清楚些, 即把原来表达中的指数7 6 ... 0挪到了下面来表达)

    接近目标了, 因为我们已经知道, 如果数据包头部中的SYN被置位, 那么头部中的第13个字节的值为2(nt: 按照网络序, 即大头方式, 最重要的字节
    在前面(在前面,即该字节实际内存地址比较小, 最重要的字节,指数学表示中数的高位, 如356中的3) ).

    表达为tcpdump能理解的关系式就是:
    tcp[13]  2

    从而我们可以把此关系式当作tcpdump的过滤条件, 目标就是监控只含有SYN标志的数据包:
    tcpdump -i xl0 tcp[13]  2 (nt: xl0 指网络接口, 如eth0)

    这个表达式是说"让TCP数据包的第13个字节拥有值2吧", 这也是我们想要的结果.


    现在, 假设我们需要抓取带SYN标志的数据包, 而忽略它是否包含其他标志.(nt:只要带SYN就是我们想要的). 让我们来看看当一个含有
    SYN-ACK的数据包(nt:SYN 和 ACK 标志都有), 来到时发生了什么:
    |C|E|U|A|P|R|S|F|
    |---------------|
    |0 0 0 1 0 0 1 0|
    |---------------|
    |7 6 5 4 3 2 1 0|

    13号字节的1号和4号位被置位, 其二进制的值为:
           00010010

    转换成十进制就是:

    0*2^7 + 0*2^6 + 0*2^5 + 1*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2   = 18(nt: 1 * 2^6 表示1乘以2的6次方, 也许这样更
    清楚些, 即把原来表达中的指数7 6 ... 0挪到了下面来表达)

    现在, 却不能只用'tcp[13]  18'作为tcpdump的过滤表达式, 因为这将导致只选择含有SYN-ACK标志的数据包, 其他的都被丢弃.
    提醒一下自己, 我们的目标是: 只要包的SYN标志被设置就行, 其他的标志我们不理会.

    为了达到我们的目标, 我们需要把13号字节的二进制值与其他的一个数做AND操作(nt:逻辑与)来得到SYN比特位的值. 目标是:只要SYN 被设置
    就行, 于是我们就把她与上13号字节的SYN值(nt: 00000010).

         00010010 SYN-ACK              00000010 SYN
    AND  00000010 (we want SYN)   AND  00000010 (we want SYN)
         --------                      --------
    =    00000010                 =    00000010

    我们可以发现, 不管包的ACK或其他标志是否被设置, 以上的AND操作都会给我们相同的值, 其10进制表达就是2(2进制表达就是00000010).
    从而我们知道, 对于带有SYN标志的数据包, 以下的表达式的结果总是真(true):

    ( ( value of octet 13 ) AND ( 2 ) )  ( 2 ) (nt: value of octet 13, 即13号字节的值)

    灵感随之而来, 我们于是得到了如下的tcpdump 的过滤表达式
    tcpdump -i xl0 'tcp[13] & 2  2'

    注意, 单引号或反斜杆(nt: 这里用的是单引号)不能省略, 这可以防止shell对&的解释或替换.


    UDP 数据包

    UDP 数据包的显示格式,可通过rwho这个具体应用所产生的数据包来说明:
        actinide.who > broadcast.who: udp 84

        其含义为:actinide主机上的端口who向broadcast主机上的端口who发送了一个udp数据包(nt: actinide和broadcast都是指Internet地址).
        这个数据包承载的用户数据为84个字节.

        一些UDP服务可从数据包的源或目的端口来识别,也可从所显示的更高层协议信息来识别. 比如, Domain Name service  requests(DNS 请求,
        在RFC-1034/1035中), 和Sun RPC calls to NFS(对NFS服务器所发起的远程调用(nt: 即Sun RPC),在RFC-1050中有对远程调用的描述).

    UDP 名称服务请求

    (注意:以下的描述假设你对Domain Service protoco(nt:在RFC-103中有所描述), 否则你会发现以下描述就是天书(nt:希腊文天书,
    不必理会, 吓吓你的, 接着看就行))

    名称服务请求有如下的格式:
    src > dst: id op? flags qtype qclass name (len)
    (nt: 从下文来看, 格式应该是src > dst: id op flags qtype qclass? name (len))
    比如有一个实际显示为:
    h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

    主机h2opolo 向helios 上运行的名称服务器查询ucbvax.berkeley.edu 的地址记录(nt: qtype等于A). 此查询本身的id号为'3'. 符号
    '+'意味着递归查询标志被设置(nt: dns服务器可向更高层dns服务器查询本服务器不包含的地址记录). 这个最终通过IP包发送的查询请求
    数据长度为37字节, 其中不包括UDP和IP协议的头数据. 因为此查询操作为默认值(nt | rt: normal one的理解), op字段被省略.
    如果op字段没被省略, 会被显示在'3' 和'+'之间. 同样, qclass也是默认值, C_IN, 从而也没被显示, 如果没被忽略, 她会被显示在'A'之后.

    异常检查会在方括中显示出附加的域: 如果一个查询同时包含一个回应(nt: 可理解为, 对之前其他一个请求的回应), 并且此回应包含权威或附加记录段, 
    ancount, nscout, arcount(nt: 具体字段含义需补充) 将被显示为'[na]', '[nn]', '[nau]', 其中n代表合适的计数. 如果包中以下
    回应位(比如AA位, RA位, rcode位), 或者字节2或3中任何一个'必须为0'的位被置位(nt: 设置为1), '[b2&3]=x' 将被显示, 其中x表示
    头部字节2与字节3进行与操作后的值.

    UDP 名称服务应答

    对名称服务应答的数据包,tcpdump会有如下的显示格式
    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条回答记录(nt | rt: answer records), 3条名称服务器记录,
    以及7条附加的记录. 第一个回答记录(nt: 3个回答记录中的第一个)类型为A(nt: 表示地址), 其数据为internet地址128.32.137.3.
    此回应UDP数据包, 包含273字节的数据(不包含UPD和IP的头部数据). op字段和rcode字段被忽略(nt: op的实际值为Query, rcode, 即
    response code的实际值为NoError), 同样被忽略的字段还有class 字段(nt | rt: 其值为C_IN, 这也是A类型记录默认取值)

    第二行表示: helios 对h2opolo 所发送的2号查询请求做了回应. 回应中, rcode编码为NXDomain(nt: 表示不存在的域)), 没有回答记录,
    但包含一个名称服务器记录, 不包含权威服务器记录(nt | ck: 从上文来看, 此处的authority records 就是上文中对应的additional
    records). '*'表示权威服务器回答标志被设置(nt: 从而additional records就表示的是authority records).
    由于没有回答记录, type, class, data字段都被忽略.

    flag字段还有可能出现其他一些字符, 比如'-'(nt: 表示可递归地查询, 即RA 标志没有被设置), '|'(nt: 表示被截断的消息, 即TC 标志
    被置位). 如果应答(nt | ct: 可理解为, 包含名称服务应答的UDP数据包, tcpdump知道这类数据包该怎样解析其数据)的'question'段一个条
    目(entry)都不包含(nt: 每个条目的含义, 需补充),'[nq]' 会被打印出来.

    要注意的是:名称服务器的请求和应答数据量比较大, 而默认的68字节的抓取长度(nt: snaplen, 可理解为tcpdump的一个设置选项)可能不足以抓取
    数据包的全部内容. 如果你真的需要仔细查看名称服务器的负载, 可以通过tcpdump 的-s 选项来扩大snaplen值.

    SMB/CIFS 解码

    tcpdump 已可以对SMB/CIFS/NBT相关应用的数据包内容进行解码(nt: 分别为'Server Message Block Common', 'Internet File System'
    '在TCP/IP上实现的网络协议NETBIOS的简称'. 这几个服务通常使用UDP的137/138以及TCP的139端口). 原来的对IPX和NetBEUI SMB数据包的
    解码能力依然可以被使用(nt: NetBEUI为NETBIOS的增强版本).


    tcpdump默认只按照最简约模式对相应数据包进行解码, 如果我们想要详尽的解码信息可以使用其-v 启动选现. 要注意的是, -v 会产生非常详细的信息,
    比如对单一的一个SMB数据包, 将产生一屏幕或更多的信息, 所以此选项, 确有需要才使用.

    关于SMB数据包格式的信息, 以及每个域的含义可以参看www.cifs.org 或者samba.org 镜像站点的pub/samba/specs/ 目录. linux 上的SMB 补丁
    (nt | rt: patch)由 Andrew Tridgell (tridge@samba.org)提供.


    NFS 请求和回应

    tcpdump对Sun NFS(网络文件系统)请求和回应的UDP数据包有如下格式的打印输出:
        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发送了一个'交换请求'(nt: transaction), 此请求的id为6709(注意, 主机名字后是交换
    请求id号, 而不是源端口号). 此请求数据为112字节, 其中不包括UDP和IP头部的长度. 操作类型为readlink(nt: 即此操作为读符号链接操作),
    操作参数为fh 21,24/10.73165(nt: 可按实际运行环境, 解析如下, fd 表示描述的为文件句柄, 21,24 表示此句柄所对应设
    备的主/从设备号对, 10表示此句柄所对应的i节点编号(nt:每个文件都会在操作系统中对应一个i节点, 限于unix类系统中),
    73165是一个编号(nt: 可理解为标识此请求的一个随机数, 具体含义需补充)).

    第二行中, wrl 做了'ok'的回应, 并且在results 字段中返回了sushi想要读的符号连接的真实目录(nt: 即sushi要求读的符号连接其实是一个目录).

    第三行表明: sushi 再次请求 wrl 在'fh 9,74/4096.6878'所描述的目录中查找'xcolors'文件. 需要注意的是, 每行所显示的数据含义依赖于其中op字段的
    类型(nt: 不同op 所对应args 含义不相同), 其格式遵循NFS 协议, 追求简洁明了.



    如果tcpdump 的-v选项(详细打印选项) 被设置, 附加的信息将被显示. 比如:
        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, length, 以及fragmentation 域, 但在此例中, 都略过了(nt: 可理解为,简洁起见, 做了删减))
    在第一行, sushi 请求wrl 从文件 21,11/12.195(nt: 格式在上面有描述)中, 自偏移24576字节处开始, 读取8192字节数据.
    Wrl 回应读取成功; 由于第二行只是回应请求的开头片段, 所以只包含1472字节(其他的数据将在接着的reply片段中到来, 但这些数据包不会再有NFS
    头, 甚至UDP头信息也为空(nt: 源和目的应该要有), 这将导致这些片段不能满足过滤条件, 从而没有被打印). -v 选项除了显示文件数据信息, 还会显示
    附加显示文件属性信息: file type(文件类型, ''REG'' 表示普通文件), file mode(文件存取模式, 8进制表示的), uid 和gid(nt: 文件属主和
    组属主), file size (文件大小).

    如果-v 标志被多次重复给出(nt: 如-vv), tcpdump会显示更加详细的信息.

    必须要注意的是, NFS 请求包中数据比较多, 如果tcpdump 的snaplen(nt: 抓取长度) 取太短将不能显示其详细信息. 可使用
    '-s 192'来增加snaplen, 这可用以监测NFS应用的网络负载(nt: traffic).

    NFS 的回应包并不严格的紧随之前相应的请求包(nt: RPC operation). 从而, tcpdump 会跟踪最近收到的一系列请求包, 再通过其
    交换序号(nt: transaction ID)与相应请求包相匹配. 这可能产生一个问题, 如果回应包来得太迟, 超出tcpdump 对相应请求包的跟踪范围,
    该回应包将不能被分析.


    AFS 请求和回应

    AFS(nt: Andrew 文件系统, Transarc , 未知, 需补充)请求和回应有如下的答应

    src.sport > dst.dport: rx packet-type
    src.sport > dst.dport: rx packet-type service call call-name args
    src.sport > dst.dport: rx packet-type service reply call-name args

    elvis.7001 > pike.afsfs:
       rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
       new fid 536876964/1/1 ".newsrc"
    pike.afsfs > elvis.7001: rx data fs reply rename

    在第一行, 主机elvis 向pike 发送了一个RX数据包.
    这是一个对于文件服务的请求数据包(nt: RX data packet, 发送数据包 , 可理解为发送包过去, 从而请求对方的服务), 这也是一个RPC
    调用的开始(nt: RPC, remote procedure call). 此RPC 请求pike 执行rename(nt: 重命名) 操作, 并指定了相关的参数:
    原目录描述符为536876964/1/1, 原文件名为 '.newsrc.new', 新目录描述符为536876964/1/1, 新文件名为 '.newsrc'.
    主机pike 对此rename操作的RPC请求作了回应(回应表示rename操作成功, 因为回应的是包含数据内容的包而不是异常包).

    一般来说, 所有的'AFS RPC'请求被显示时, 会被冠以一个名字(nt: 即decode, 解码), 这个名字往往就是RPC请求的操作名.
    并且, 这些RPC请求的部分参数在显示时, 也会被冠以一个名字(nt | rt: 即decode, 解码, 一般来说也是取名也很直接, 比如,
    一个interesting 参数, 显示的时候就会直接是'interesting', 含义拗口, 需再翻).

    这种显示格式的设计初衷为'一看就懂', 但对于不熟悉AFS 和 RX 工作原理的人可能不是很
    有用(nt: 还是不用管, 书面吓吓你的, 往下看就行).

    如果 -v(详细)标志被重复给出(nt: 如-vv), tcpdump 会打印出确认包(nt: 可理解为, 与应答包有区别的包)以及附加头部信息
    (nt: 可理解为, 所有包, 而不仅仅是确认包的附加头部信息), 比如, RX call ID(请求包中'请求调用'的ID),
    call number('请求调用'的编号), sequence number(nt: 包顺序号),
    serial number(nt | rt: 可理解为与包中数据相关的另一个顺信号, 具体含义需补充), 请求包的标识. (nt: 接下来一段为重复描述,
    所以略去了), 此外确认包中的MTU协商信息也会被打印出来(nt: 确认包为相对于请求包的确认包, Maximum Transmission Unit, 最大传输单元).

    如果 -v 选项被重复了三次(nt: 如-vvv), 那么AFS应用类型数据包的'安全索引'('security index')以及'服务索引'('service id')将会
    被打印.

    对于表示异常的数据包(nt: abort packet, 可理解为, 此包就是用来通知接受者某种异常已发生), tcpdump 会打印出错误号(error codes).
    但对于Ubik beacon packets(nt: Ubik 灯塔指示包, Ubik可理解为特殊的通信协议, beacon packets, 灯塔数据包, 可理解为指明通信中
    关键信息的一些数据包), 错误号不会被打印, 因为对于Ubik 协议, 异常数据包不是表示错误, 相反却是表示一种肯定应答(nt: 即, yes vote).

    AFS 请求数据量大, 参数也多, 所以要求tcpdump的 snaplen 比较大, 一般可通过启动tcpdump时设置选项'-s 256' 来增大snaplen, 以
    监测AFS 应用通信负载.

    AFS 回应包并不显示标识RPC 属于何种远程调用. 从而, tcpdump 会跟踪最近一段时间内的请求包, 并通过call number(调用编号), service ID
    (服务索引) 来匹配收到的回应包. 如果回应包不是针对最近一段时间内的请求包, tcpdump将无法解析该包.


    KIP AppleTalk协议

    (nt | rt: DDP in UDP可理解为, DDP, The AppleTalk Data Delivery Protocol,
    相当于支持KIP AppleTalk协议栈的网络层协议, 而DDP 本身又是通过UDP来传输的,
    即在UDP 上实现的用于其他网络的网络层,KIP AppleTalk是苹果公司开发的整套网络协议栈).

    AppleTalk DDP 数据包被封装在UDP数据包中, 其解封装(nt: 相当于解码)和相应信息的转储也遵循DDP 包规则.
    (nt:encapsulate, 封装, 相当于编码, de-encapsulate, 解封装, 相当于解码, dump, 转储, 通常就是指对其信息进行打印).

    /etc/atalk.names 文件中包含了AppleTalk 网络和节点的数字标识到名称的对应关系. 其文件格式通常如下所示:
        number    name

        1.254     ether
        16.1      icsd-net
        1.254.110 ace

    头两行表示有两个AppleTalk 网络. 第三行给出了特定网络上的主机(一个主机会用3个字节来标识,
    而一个网络的标识通常只有两个字节, 这也是两者标识的主要区别)(nt: 1.254.110 可理解为ether网络上的ace主机).
    标识与其对应的名字之间必须要用空白分开. 除了以上内容, /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 文件不存在, 或者没有相应AppleTalk 主机/网络的条目, 数据包的网络地址将以数字形式显示).

    在第一行中, 网络144.1上的节点209通过2端口,向网络icsd-net上监听在220端口的112节点发送了一个NBP应用数据包
    (nt | rt:  NBP, name binding protocol, 名称绑定协议, 从数据来看, NBP服务器会在端口2提供此服务.
    'DDP port 2' 可理解为'DDP 对应传输层的端口2', DDP本身没有端口的概念, 这点未确定, 需补充).

    第二行与第一行类似, 只是源的全部地址可用'office'进行标识.
    第三行表示: jssmag网络上的149节点通过235向icsd-net网络上的所有节点的2端口(NBP端口)发送了数据包.(需要注意的是,
    在AppleTalk 网络中如果地址中没有节点, 则表示广播地址, 从而节点标识和网络标识最好在/etc/atalk.names有所区别.
    nt: 否则一个标识x.port 无法确定x是指一个网络上所有主机的port口还是指定主机x的port口).

    tcpdump 可解析NBP (名称绑定协议) and 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-net 中的节点112 通过220端口向网络jssmag 中所有节点的端口2发送了对'LaserWriter'的名称查询请求(nt:
    此处名称可理解为一个资源的名称, 比如打印机). 此查询请求的序列号为190.

    第二行表示: 网络jssmag 中的节点209 通过2端口向icsd-net.112节点的端口220进行了回应: 我有'LaserWriter'资源, 其资源名称
    为'RM1140', 并且在端口250上提供改资源的服务. 此回应的序列号为190, 对应之前查询的序列号.

    第三行也是对第一行请求的回应: 节点techpit 通过2端口向icsd-net.112节点的端口220进行了回应:我有'LaserWriter'资源, 其资源名称
    为'techpit', 并且在端口186上提供改资源的服务. 此回应的序列号为190, 对应之前查询的序列号.


    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: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的请求包, 请求helios
    回应8个数据包(这8个数据包的顺序号为0-7(nt: 顺序号与会话编号不同, 后者为一次完整传输的编号,
    前者为该传输中每个数据包的编号. transaction, 会话, 通常也被叫做传输)). 行尾的16进制数字表示
    该请求包中'userdata'域的值(nt: 从下文来看, 这并没有把所有用户数据都打印出来 ).

    Helios 回应了8个512字节的数据包. 跟在会话编号(nt: 12266)后的数字表示该数据包在该会话中的顺序号.
    括号中的数字表示该数据包中数据的大小, 这不包括atp 的头部. 在顺序号为7数据包(第8行)外带了一个'*'号,
    表示该数据包的EOM 标志被设置了.(nt: EOM, End Of Media, 可理解为, 表示一次会话的数据回应完毕).

    接下来的第9行表示, Jssmag.209 又向helios 提出了请求: 顺序号为3以及5的数据包请重新传送. Helios 收到这个
    请求后重新发送了这个两个数据包, jssmag.209 再次收到这两个数据包之后, 主动结束(release)了此会话.

    在最后一行, jssmag.209 向helios 发送了开始下一次会话的请求包. 请求包中的'*'表示该包的XO 标志没有被设置.
    (nt: XO, exactly once, 可理解为在该会话中, 数据包在接受方只被精确地处理一次, 就算对方重复传送了该数据包,
    接收方也只会处理一次, 这需要用到特别设计的数据包接收和处理机制).


    IP 数据包破碎
    (nt: 指把一个IP数据包分成多个IP数据包)

    碎片IP数据包(nt: 即一个大的IP数据包破碎后生成的小IP数据包)有如下两种显示格式.
    (frag id:size@offset+)
    (frag id:size@offset)
    (第一种格式表示, 此碎片之后还有后续碎片. 第二种格式表示, 此碎片为最后一个碎片.)

    id 表示破碎编号(nt: 从下文来看, 会为每个要破碎的大IP包分配一个破碎编号, 以便区分每个小碎片是否由同一数据包破碎而来).
    size 表示此碎片的大小 , 不包含碎片头部数据. offset表示此碎片所含数据在原始整个IP包中的偏移((nt: 从下文来看,
    一个IP数据包是作为一个整体被破碎的, 包括头和数据, 而不只是数据被分割).

    每个碎片都会使tcpdump产生相应的输出打印. 第一个碎片包含了高层协议的头数据(nt:从下文来看, 被破碎IP数据包中相应tcp头以及
    IP头都放在了第一个碎片中 ), 从而tcpdump会针对第一个碎片显示这些信息, 并接着显示此碎片本身的信息. 其后的一些碎片并不包含
    高层协议头信息, 从而只会在显示源和目的之后显示碎片本身的信息. 以下有一个例子: 这是一个从arizona.edu 到lbl-rtsg.arpa
    途经CSNET网络(nt: CSNET connection 可理解为建立在CSNET 网络上的连接)的ftp应用通信片段:
        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包的顺序号.

    第二, 从第一行的信息中, 可以发现arizona需要向rtsg发送308字节的用户数据, 而事实是, 相应IP包经破碎后会总共产生512字节
    数据(第一个碎片包含308字节的数据, 第二个碎片包含204个字节的数据, 这超过了308字节). 如果你在查找数据包的顺序号空间中的
    一些空洞(nt: hole,空洞, 指数据包之间的顺序号没有上下衔接上), 512这个数据就足够使你迷茫一阵(nt: 其实只要关注308就行,
    不必关注破碎后的数据总量).

    一个数据包(nt | rt: 指IP数据包)如果带有非IP破碎标志, 则显示时会在最后显示'(DF)'.(nt: 意味着此IP包没有被破碎过).


    时间戳

    tcpdump的所有输出打印行中都会默认包含时间戳信息.
    时间戳信息的显示格式如下
        hh:mm:ss.frac (nt: 小时:分钟:秒.(nt: frac未知, 需补充))
    此时间戳的精度与内核时间精度一致, 反映的是内核第一次看到对应数据包的时间(nt: saw, 即可对该数据包进行操作). 
    而数据包从物理线路传递到内核的时间, 以及内核花费在此包上的中断处理时间都没有算进来.

 

参考索引
 
    stty(1), pcap(3), bpf(4), nit(4P), pfconfig(8)
    (nt: stty(1) 可理解为, 通过在终端中输入'man 1 stty' 查看其详细的描述, 相关man 文档的安装, 另需补充)
 

创作者
 
    原创作者:
    Van  Jacobson, Craig Leres, Steven McCanne 以及美国加州加利福尼亚大学伯克利分校, 劳伦斯伯克利国家实验室的所有朋友们.

    tcpdump 目前由tcpdump.org 组织维护.
    当前最新版本可通过以下地址得到
    http://www.tcpdump.org/
    其原始版本可通过以下匿名ftp 得到.
    ftp://ftp.ee.lbl.gov/tcpdump.tar.Z

    tcpdump中IPv6/IPsec 的支持来源于 WIDE/KAME工程, 并且使用了Eric Young 提供的SSleay 库(Secure Socket Layer协议的一个开源实现)),
    同时也对此库做了特定的配置.
 

已知缺陷
 
   请把问题, 缺陷, 疑问, 以及想要的增强功能等发到以下地址:
    tcpdump-workers@tcpdump.org

    请把贡献源代码等发送到以下地址:
    patches@tcpdump.org

    NIT 不能提供对外出的网络负载进行监测, 而BPF可以. 我们推荐使用后者.
    (nt: NIT, Network Interface Tap, 网络接口分接头. BPF, BSD Packet Filter, BSD 分组过滤器.
    可理解为, 此二者分别提供了一种给应用输送指定数据包的机制, BPF 可过滤网络接口上进入和发出的数据包,
    而NIT只能过滤进入的数据包)

    在linux 2.0.x的内核上存在以下问题:

        环回网络接口上的数据包将会被显示两次;

        包过滤处理不能在内核中完成, 导致所有的数据包必须从内核拷贝出来, 以便在用户模式下进行包过滤;
        拷贝的范围是整个数据包, 而不仅仅是tcpdump的包抓取长度. 在2.0版本或之后版本的
        数据包抓取机制下, 如果只把部分数据包从内核拷贝到用户区, tcpdump将无法正确得到数据包的真正长度, 进而导致
        大多数IP数据包的处理出错.

        在一些点对点设备上抓包会出错.

    我们推荐使用2.2或更新的内核.

    名称服务器的反向查询数据包打印不正确:在回应数据段中如果有真正的请求信息, 此时会打印空的查询数据段.
    有些人认为这种反向查询数据段本身就有矛盾的地方, 与其修改tcpdump 还不如去修改产生这种反向查询的软件.
    (nt: 具体矛盾的地方未知, 另需补充)

    跨越日光节约时制(夏令时)中时间快慢改变点的数据包,其时间戳不准确(对时间快慢的调节将被忽略).

    在令牌环网上, 过滤表达式只会对令牌头中包含的域起作用, 而对于非令牌头中的域不能正常过滤.

    过滤表达式中如果出现了802.11协议头中以外的域, 对发往或来自目录服务器的802.11数据包不能正常过滤(nt: DS, 此处可理解为Directory
    Server, 需确认).

    在过滤表达式中使用ip6 proto protocol选项时, 应该打印整个数据包中协议头链的信息, 而目前没有这么做,
    而是提供了ip6 protochain protocol的选项来完成该功能.

    在过滤表达式中, 针对传输层头的算术表达式, 比如 tcp[0], 只能用在IPv4数据包上, 而不能用在IPv6数据包上.
 

 
                                2005年4月18日                              TCPDUMP(8)
 

英文版本
==========

 
        TCPDUMP(8)                                                                                           TCPDUMP(8)
 


NAME
 
       tcpdump - dump traffic on a network
 

SYNOPSIS
 
       tcpdump [ -AdDeflLnNOpqRStuUvxX ] [ -c count ]
               [ -C file_size ] [ -F file ]
               [ -i interface ] [ -m module ] [ -M secret ]
               [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ]
               [ -W filecount ]
               [ -E spi@ipaddr algo:secret,...  ]
               [ -y datalinktype ] [ -Z user ]
               [ expression ]
 

DESCRIPTION
 
       Tcpdump  prints  out  a  description  of  the  contents of packets on a network interface that match the
       boolean expression.  It can also be run with the -w flag, which causes it to save the packet data  to  a
       file  for  later  analysis,  and/or  with  the -r flag, which causes it to read from a saved packet file
       rather than to read packets from a network interface.  In all cases, only packets that match  expression
       will be processed by tcpdump.

       Tcpdump  will, if not run with the -c flag, continue capturing packets until it is interrupted by a SIG-
       INT signal (generated, for example, by typing  your  interrupt  character,  typically  control-C)  or  a
       SIGTERM  signal (typically generated with the kill(1) command); if run with the -c flag, it will capture
       packets until it is interrupted by a SIGINT or SIGTERM signal or the specified number  of  packets  have
       been processed.

       When tcpdump finishes capturing packets, it will report counts of:

              packets ``captured'' (this is the number of packets that tcpdump has received and processed);

              packets  ``received  by  filter''  (the meaning of this depends on the OS on which you're running
              tcpdump, and possibly on the way the OS was configured - if a filter was specified on the command
              line,  on  some  OSes  it  counts  packets  regardless of whether they were matched by the filter
              expression and, even if they were matched by the filter expression, regardless of whether tcpdump
              has  read  and  processed them yet, on other OSes it counts only packets that were matched by the
              filter expression regardless of whether tcpdump has read and processed them  yet,  and  on  other
              OSes it counts only packets that were matched by the filter expression and were processed by tcp-
              dump);

              packets ``dropped by kernel'' (this is the number of packets that were dropped, due to a lack  of
              buffer  space,  by  the packet capture mechanism in the OS on which tcpdump is running, if the OS
              reports that information to applications; if not, it will be reported as 0).

       On platforms that support the SIGINFO signal, such as most BSDs (including Mac OS X)  and  Digital/Tru64
       UNIX,  it  will report those counts when it receives a SIGINFO signal (generated, for example, by typing
       your ``status'' character, typically control-T, although on some platforms, such as Mac OS X, the ``sta-
       tus'' character is not set by default, so you must set it with stty(1) in order to use it) and will con-
       tinue capturing packets.

       Reading packets from a network interface may require that you have special privileges:

       Under SunOS 3.x or 4.x with NIT or BPF:
              You must have read access to /dev/nit or /dev/bpf*.

       Under Solaris with DLPI:
              You must have read/write access to the network pseudo device, e.g.  /dev/le.  On  at  least  some
              versions  of  Solaris, however, this is not sufficient to allow tcpdump to capture in promiscuous
              mode; on those versions of Solaris, you must be root, or tcpdump  must  be  installed  setuid  to
              root,  in  order to capture in promiscuous mode.  Note that, on many (perhaps all) interfaces, if
              you don't capture in promiscuous mode, you will not see any outgoing packets, so  a  capture  not
              done in promiscuous mode may not be very useful.

       Under HP-UX with DLPI:
              You must be root or tcpdump must be installed setuid to root.

       Under IRIX with snoop:
              You must be root or tcpdump must be installed setuid to root.

       Under Linux:
              You must be root or tcpdump must be installed setuid to root (unless your distribution has a ker-
              nel that supports capability bits such as CAP_NET_RAW and code to allow those capability bits  to
              be  given  to particular accounts and to cause those bits to be set on a user's initial processes
              when they log in, in which case you  must have CAP_NET_RAW in order to capture and  CAP_NET_ADMIN
              to enumerate network devices with, for example, the -D flag).

       Under ULTRIX and Digital UNIX/Tru64 UNIX:
              Any  user  may  capture network traffic with tcpdump.  However, no user (not even the super-user)
              can capture in promiscuous mode on an interface unless the super-user  has  enabled  promiscuous-
              mode  operation  on  that  interface using pfconfig(8), and no user (not even the super-user) can
              capture unicast traffic received by or sent by the machine on an interface unless the  super-user
              has enabled copy-all-mode operation on that interface using pfconfig, so useful packet capture on
              an interface probably requires that either promiscuous-mode or copy-all-mode operation,  or  both
              modes of operation, be enabled on that interface.

       Under BSD (this includes Mac OS X):
              You  must  have  read  access to /dev/bpf* on systems that don't have a cloning BPF device, or to
              /dev/bpf on systems that do.  On BSDs with a devfs (this includes Mac OS X), this  might  involve
              more than just having somebody with super-user access setting the ownership or permissions on the
              BPF devices - it might involve configuring devfs to set the ownership or permissions  every  time
              the  system  is  booted,  if the system even supports that; if it doesn't support that, you might
              have to find some other way to make that happen at boot time.

       Reading a saved packet file doesn't require special privileges.
 

OPTIONS
 
       -A     Print each packet (minus its link level header) in ASCII.  Handy for capturing web pages.

       -c     Exit after receiving count packets.

       -C     Before writing a raw packet to a savefile, check  whether  the  file  is  currently  larger  than
              file_size  and,  if so, close the current savefile and open a new one.  Savefiles after the first
              savefile will have the name specified with the -w flag, with a number after it, starting at 1 and
              continuing  upward.  The units of file_size are millions of bytes (1,000,000 bytes, not 1,048,576
              bytes).

       -d     Dump the compiled packet-matching code in a human readable form to standard output and stop.

       -dd    Dump packet-matching code as a C program fragment.

       -ddd   Dump packet-matching code as decimal numbers (preceded with a count).

       -D     Print the list of the network interfaces available on the system and on which tcpdump can capture
              packets.  For each network interface, a number and an interface name, possibly followed by a text
              description of the interface, is printed.  The interface name or the number can  be  supplied  to
              the -i flag to specify an interface on which to capture.

              This  can  be useful on systems that don't have a command to list them (e.g., Windows systems, or
              UNIX systems lacking ifconfig -a); the number can be useful on Windows 2000  and  later  systems,
              where the interface name is a somewhat complex string.

              The  -D  flag  will  not  be supported if tcpdump was built with an older version of libpcap that
              lacks the pcap_findalldevs() function.

       -e     Print the link-level header on each dump line.

       -E     Use spi@ipaddr algo:secret for decrypting IPsec ESP packets that are addressed to addr  and  con-
              tain  Security  Parameter Index value spi. This combination may be repeated with comma or newline
              separation.

              Note that setting the secret for IPv4 ESP packets is supported at this time.

              Algorithms may be des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, or none.  The default is
              des-cbc.   The ability to decrypt packets is only present if tcpdump was compiled with cryptogra-
              phy enabled.

              secret is the ASCII text for ESP secret key.  If preceded by 0x, then a hex value will be read.

              The option assumes RFC2406 ESP, not RFC1827 ESP.  The option is only for debugging purposes,  and
              the  use  of this option with a true `secret' key is discouraged.  By presenting IPsec secret key
              onto command line you make it visible to others, via ps(1) and other occasions.

              In addition to the above syntax, the syntax file name may be used to have tcpdump read  the  pro-
              vided file in. The file is opened upon receiving the first ESP packet, so any special permissions
              that tcpdump may have been given should already have been given up.

       -f     Print `foreign' IPv4 addresses numerically rather than symbolically (this option is  intended  to
              get  around serious brain damage in Sun's NIS server -- usually it hangs forever translating non-
              local internet numbers).

              The test for `foreign' IPv4 addresses is done using the IPv4 address and netmask of the interface
              on  which capture is being done.  If that address or netmask are not available, available, either
              because the interface on which capture is being done has no address or  netmask  or  because  the
              capture is being done on the Linux "any" interface, which can capture on more than one interface,
              this option will not work correctly.

       -F     Use file as input for the filter expression.  An additional expression given on the command  line
              is ignored.

       -i     Listen  on  interface.  If unspecified, tcpdump searches the system interface list for the lowest
              numbered, configured up interface (excluding loopback).  Ties are broken by choosing the earliest
              match.

              On  Linux systems with 2.2 or later kernels, an interface argument of ``any'' can be used to cap-
              ture packets from all interfaces.  Note that captures on the ``any'' device will not be  done  in
              promiscuous mode.

              If  the  -D  flag  is  supported,  an interface number as printed by that flag can be used as the
              interface argument.

       -l     Make stdout line buffered.  Useful if you want to see the data while capturing it.  E.g.,
              ``tcpdump  -l  |  tee dat'' or ``tcpdump  -l   > dat  &  tail  -f  dat''.

       -L     List the known data link types for the interface and exit.

       -m     Load SMI MIB module definitions from file module.  This option can be used several times to  load
              several MIB modules into tcpdump.

       -M     Use  secret  as a shared secret for validating the digests found in TCP segments with the TCP-MD5
              option (RFC 2385), if present.

       -n     Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.

       -N     Don't print domain name qualification of host names.  E.g., if you give this  flag  then  tcpdump
              will print ``nic'' instead of ``nic.ddn.mil''.

       -O     Do  not  run the packet-matching code optimizer.  This is useful only if you suspect a bug in the
              optimizer.

       -p     Don't put the interface into promiscuous mode.  Note that the interface might be  in  promiscuous
              mode for some other reason; hence, `-p' cannot be used as an abbreviation for `ether host {local-
              hw-addr} or ether broadcast'.

       -q     Quick (quiet?) output.  Print less protocol information so output lines are shorter.

       -R     Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829).  If specified,  tcp-
              dump  will not print replay prevention field.  Since there is no protocol version field in ESP/AH
              specification, tcpdump cannot deduce the version of ESP/AH protocol.

       -r     Read packets from file (which was created with the -w option).  Standard input is used if file is
              ``-''.

       -S     Print absolute, rather than relative, TCP sequence numbers.

       -s     Snarf snaplen bytes of data from each packet rather than the default of 68 (with SunOS's NIT, the
              minimum is actually 96).  68 bytes is adequate for IP, ICMP, TCP and UDP but may truncate  proto-
              col  information  from  name  server and NFS packets (see below).  Packets truncated because of a
              limited snapshot are indicated in the output with ``[|proto]'', where proto is the  name  of  the
              protocol  level  at  which  the  truncation has occurred.  Note that taking larger snapshots both
              increases the amount of time it takes to process packets and, effectively, decreases  the  amount
              of  packet buffering.  This may cause packets to be lost.  You should limit snaplen to the small-
              est number that will capture the protocol information you're interested in.  Setting snaplen to 0
              means use the required length to catch whole packets.

       -T     Force  packets  selected  by  "expression" to be interpreted the specified type.  Currently known
              types are aodv (Ad-hoc On-demand Distance Vector protocol), cnfp (Cisco  NetFlow  protocol),  rpc
              (Remote Procedure Call), rtp (Real-Time Applications protocol), rtcp (Real-Time Applications con-
              trol protocol), snmp (Simple Network Management Protocol), tftp (Trivial File Transfer Protocol),
              vat (Visual Audio Tool), and wb (distributed White Board).

       -t     Don't print a timestamp on each dump line.

       -tt    Print an unformatted timestamp on each dump line.

       -ttt   Print a delta (in micro-seconds) between current and previous line on each dump line.

       -tttt  Print a timestamp in default format proceeded by date on each dump line.

       -u     Print undecoded NFS handles.

       -U     Make  output  saved via the -w option ``packet-buffered''; i.e., as each packet is saved, it will
              be written to the output file, rather than being written only when the output buffer fills.

              The -U flag will not be supported if tcpdump was built with an  older  version  of  libpcap  that
              lacks the pcap_dump_flush() function.

       -v     When  parsing  and  printing,  produce  (slightly more) verbose output.  For example, the time to
              live, identification, total length and options in an IP packet are printed.  Also  enables  addi-
              tional packet integrity checks such as verifying the IP and ICMP header checksum.

              When  writing  to a file with the -w option, report, every 10 seconds, the number of packets cap-
              tured.

       -vv    Even more verbose output.  For example, additional fields are printed from NFS reply packets, and
              SMB packets are fully decoded.

       -vvv   Even  more  verbose  output.  For example, telnet SB ... SE options are printed in full.  With -X
              Telnet options are printed in hex as well.

       -w     Write the raw packets to file rather than parsing and printing  them  out.   They  can  later  be
              printed with the -r option.  Standard output is used if file is ``-''.

       -W     Used in conjunction with the -C option, this will limit the number of files created to the speci-
              fied number, and begin overwriting files from the beginning, thus creating a  'rotating'  buffer.
              In  addition,  it  will  name  the  files with enough leading 0s to support the maximum number of
              files, allowing them to sort correctly.

       -x     When parsing and printing, in addition to printing the headers of each packet, print the data  of
              each  packet  (minus  its link level header) in hex.  The smaller of the entire packet or snaplen
              bytes will be printed.  Note that this is the entire link-layer packet, so for link  layers  that
              pad  (e.g.  Ethernet),  the  padding  bytes  will also be printed when the higher layer packet is
              shorter than the required padding.

       -xx    When parsing and printing, in addition to printing the headers of each packet, print the data  of
              each packet, including its link level header, in hex.

       -X     When  parsing and printing, in addition to printing the headers of each packet, print the data of
              each packet (minus its link level header) in hex and ASCII.  This is very handy for analysing new
              protocols.

       -XX    When  parsing and printing, in addition to printing the headers of each packet, print the data of
              each packet, including its link level header, in hex and ASCII.

       -y     Set the data link type to use while capturing packets to datalinktype.

       -Z     Drops privileges (if root) and changes user ID to user and the group ID to the primary  group  of
              user.

              This behavior can also be enabled by default at compile time.

        expression
              selects  which packets will be dumped.  If no expression is given, all packets on the net will be
              dumped.  Otherwise, only packets for which expression is `true' will be dumped.

              The expression consists of one or more primitives.  Primitives usually consist of an id (name  or
              number) preceded by one or more qualifiers.  There are three different kinds of qualifier:

              type   qualifiers  say  what  kind  of thing the id name or number refers to.  Possible types are
                     host, net , port and portrange.  E.g., `host foo',  `net  128.3',  `port  20',  `portrange
                     6000-6008'.  If there is no type qualifier, host is assumed.

              dir    qualifiers specify a particular transfer direction to and/or from id.  Possible directions
                     are src, dst, src or dst and src and dst.  E.g., `src foo', `dst net 128.3', `src  or  dst
                     port  ftp-data'.  If there is no dir qualifier, src or dst is assumed.  For some link lay-
                     ers, such as SLIP and the ``cooked'' Linux capture mode used for the  ``any''  device  and
                     for  some other device types, the inbound and outbound qualifiers can be used to specify a
                     desired direction.

              proto  qualifiers restrict the match to a particular protocol.  Possible protos are: ether, fddi,
                     tr,  wlan,  ip,  ip6,  arp,  rarp,  decnet,  tcp and udp.  E.g., `ether src foo', `arp net
                     128.3', `tcp port 21', `udp portrange 7000-7009'.  If there is  no  proto  qualifier,  all
                     protocols  consistent  with  the  type  are assumed.  E.g., `src foo' means `(ip or arp or
                     rarp) src foo' (except the latter is not legal syntax), `net bar' means  `(ip  or  arp  or
                     rarp) net bar' and `port 53' means `(tcp or udp) port 53'.

              [`fddi'  is  actually  an  alias for `ether'; the parser treats them identically as meaning ``the
              data link level used on the specified network interface.''  FDDI  headers  contain  Ethernet-like
              source and destination addresses, and often contain Ethernet-like packet types, so you can filter
              on these FDDI fields just as with the analogous Ethernet fields.  FDDI headers also contain other
              fields, but you cannot name them explicitly in a filter expression.

              Similarly,  `tr'  and  `wlan'  are aliases for `ether'; the previous paragraph's statements about
              FDDI headers also apply to Token Ring and 802.11 wireless LAN headers.  For 802.11  headers,  the
              destination address is the DA field and the source address is the SA field; the BSSID, RA, and TA
              fields aren't tested.]

              In addition to the above, there are some special `primitive' keywords that don't follow the  pat-
              tern:  gateway,  broadcast, less, greater and arithmetic expressions.  All of these are described
              below.

              More complex filter expressions are built up by using the words and, or and not to combine primi-
              tives.  E.g., `host foo and not port ftp and not port ftp-data'.  To save typing, identical qual-
              ifier lists can be omitted.  E.g., `tcp dst port ftp or ftp-data or domain' is exactly  the  same
              as `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.

              Allowable primitives are:

              dst host host
                     True  if  the  IPv4/v6  destination  field  of  the packet is host, which may be either an
                     address or a name.

              src host host
                     True if the IPv4/v6 source field of the packet is host.

              host host
                     True if either the IPv4/v6 source or destination of the packet is host.

                     Any of the above host expressions can be prepended with the keywords, ip,  arp,  rarp,  or
                     ip6 as in:
                          ip host host
                     which is equivalent to:
                          ether proto \ip and host host
                     If host is a name with multiple IP addresses, each address will be checked for a match.

              ether dst ehost
                     True  if  the  Ethernet  destination  address  is  ehost.  Ehost may be either a name from
                     /etc/ethers or a number (see ethers(5) for numeric format).

              ether src ehost
                     True if the Ethernet source address is ehost.

              ether host ehost
                     True if either the Ethernet source or destination address is ehost.

              gateway host
                     True if the packet used host as a gateway.   I.e.,  the  Ethernet  source  or  destination
                     address  was host but neither the IP source nor the IP destination was host.  Host must be
                     a name and must be found both by the machine's host-name-to-IP-address  resolution  mecha-
                     nisms  (host name file, DNS, NIS, etc.) and by the machine's host-name-to-Ethernet-address
                     resolution mechanism (/etc/ethers, etc.).  (An equivalent expression is
                          ether host ehost and not host host
                     which can be used with either names or numbers for host / ehost.)  This  syntax  does  not
                     work in IPv6-enabled configuration at this moment.

              dst net net
                     True  if  the  IPv4/v6 destination address of the packet has a network number of net.  Net
                     may be either a name from the networks database (/etc/networks, etc.) or a network number.
                     An  IPv4 network number can be written as a dotted quad (e.g., 192.168.1.0), dotted triple
                     (e.g., 192.168.1), dotted pair (e.g, 172.16), or single number (e.g., 10); the netmask  is
                     255.255.255.255  for  a  dotted  quad  (which  means  that  it's  really  a  host  match),
                     255.255.255.0 for a dotted triple, 255.255.0.0 for a dotted pair, or 255.0.0.0 for a  sin-
                     gle  number.   An  IPv6  network  number  must  be  written  out  fully;  the  netmask  is
                     ff:ff:ff:ff:ff:ff:ff:ff, so IPv6 "network" matches are really always host matches,  and  a
                     network match requires a netmask length.

              src net net
                     True if the IPv4/v6 source address of the packet has a network number of net.

              net net
                     True  if either the IPv4/v6 source or destination address of the packet has a network num-
                     ber of net.

              net net mask netmask
                     True if the IPv4 address matches net with the specific netmask.  May be qualified with src
                     or dst.  Note that this syntax is not valid for IPv6 net.

              net net/len
                     True  if  the  IPv4/v6 address matches net with a netmask len bits wide.  May be qualified
                     with src or dst.

              dst port port
                     True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a destination port  value
                     of  port.   The  port  can  be  a  number  or a name used in /etc/services (see tcp(7) and
                     udp(7)).  If a name is used, both the port number and protocol are checked.  If  a  number
                     or  ambiguous name is used, only the port number is checked (e.g., dst port 513 will print
                     both tcp/login traffic and udp/who traffic, and port domain will print both tcp/domain and
                     udp/domain traffic).

              src port port
                     True if the packet has a source port value of port.

              port port
                     True if either the source or destination port of the packet is port.

              dst portrange port1-port2
                     True  if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a destination port value
                     between port1 and port2.  port1 and port2 are interpreted in the same fashion as the  port
                     parameter for port.

              src portrange port1-port2
                     True if the packet has a source port value between port1 and port2.

              portrange port1-port2
                     True if either the source or destination port of the packet is between port1 and port2.

                     Any of the above port or port range expressions can be prepended with the keywords, tcp or
                     udp, as in:
                          tcp src port port
                     which matches only tcp packets whose source port is port.

              less length
                     True if the packet has a length less than or equal to length.  This is equivalent to:
                          len <= length.

              greater length
                     True if the packet has a length greater than or equal to length.  This is equivalent to:
                          len >= length.

              ip proto protocol
                     True if the packet is an IPv4 packet (see ip(4P)) of protocol type protocol.  Protocol can
                     be  a number or one of the names icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, or tcp.
                     Note that the identifiers tcp, udp, and icmp are also keywords and  must  be  escaped  via
                     backslash  (\),  which  is \\ in the C-shell.  Note that this primitive does not chase the
                     protocol header chain.

              ip6 proto protocol
                     True if the packet is an IPv6 packet of protocol type protocol.  Note that this  primitive
                     does not chase the protocol header chain.

              ip6 protochain protocol
                     True  if the packet is IPv6 packet, and contains protocol header with type protocol in its
                     protocol header chain.  For example,
                          ip6 protochain 6
                     matches any IPv6 packet with TCP protocol header in the protocol header chain.  The packet
                     may  contain,  for  example,  authentication  header, routing header, or hop-by-hop option
                     header, between IPv6 header and TCP header.  The BPF code emitted  by  this  primitive  is
                     complex  and cannot be optimized by BPF optimizer code in tcpdump, so this can be somewhat
                     slow.

              ip protochain protocol
                     Equivalent to ip6 protochain protocol, but this is for IPv4.

              ether broadcast
                     True if the packet is an Ethernet broadcast packet.  The ether keyword is optional.

              ip broadcast
                     True if the packet is an IPv4 broadcast packet.  It checks for  both  the  all-zeroes  and
                     all-ones broadcast conventions, and looks up the subnet mask on the interface on which the
                     capture is being done.

                     If the subnet mask of the interface on which the capture is being done is  not  available,
                     either  because the interface on which capture is being done has no netmask or because the
                     capture is being done on the Linux "any" interface, which can capture  on  more  than  one
                     interface, this check will not work correctly.

              ether multicast
                     True  if the packet is an Ethernet multicast packet.  The ether keyword is optional.  This
                     is shorthand for `ether[0] & 1 != 0'.

              ip multicast
                     True if the packet is an IPv4 multicast packet.

              ip6 multicast
                     True if the packet is an IPv6 multicast packet.

              ether proto protocol
                     True if the packet is of ether type protocol.  Protocol can be a  number  or  one  of  the
                     names  ip,  ip6, arp, rarp, atalk, aarp, decnet, sca, lat, mopdl, moprc, iso, stp, ipx, or
                     netbeui.  Note these identifiers are also keywords and must be escaped via backslash  (\).

                     [In  the  case  of FDDI (e.g., `fddi protocol arp'), Token Ring (e.g., `tr protocol arp'),
                     and IEEE 802.11 wireless LANS (e.g., `wlan protocol arp'), for most  of  those  protocols,
                     the  protocol identification comes from the 802.2 Logical Link Control (LLC) header, which
                     is usually layered on top of the FDDI, Token Ring, or 802.11 header.

                     When filtering for most protocol identifiers on  FDDI,  Token  Ring,  or  802.11,  tcpdump
                     checks  only the protocol ID field of an LLC header in so-called SNAP format with an Orga-
                     nizational Unit Identifier (OUI) of 0x000000, for encapsulated Ethernet; it doesn't  check
                     whether the packet is in SNAP format with an OUI of 0x000000.  The exceptions are:

                      iso    tcpdump  checks  the DSAP (Destination Service Access Point) and SSAP (Source Ser-
                             vice Access Point) fields of the LLC header;

                     stp and netbeui
                             tcpdump checks the DSAP of the LLC header;

                      atalk  tcpdump checks for a SNAP-format packet with an OUI of 0x080007 and the  AppleTalk
                             etype.

                     In  the  case of Ethernet, tcpdump checks the Ethernet type field for most of those proto-
                     cols.  The exceptions are:

                     iso, stp, and netbeui
                             tcpdump checks for an 802.3 frame and then checks the LLC header as  it  does  for
                             FDDI, Token Ring, and 802.11;

                      atalk  tcpdump  checks  both for the AppleTalk etype in an Ethernet frame and for a SNAP-
                             format packet as it does for FDDI, Token Ring, and 802.11;

                      aarp   tcpdump checks for the AppleTalk ARP etype in either an Ethernet frame or an 802.2
                             SNAP frame with an OUI of 0x000000;

                      ipx    tcpdump  checks  for  the  IPX etype in an Ethernet frame, the IPX DSAP in the LLC
                             header, the 802.3-with-no-LLC-header encapsulation of IPX, and the IPX etype in  a
                             SNAP frame.

              decnet src host
                     True if the DECNET source address is host, which may be an address of the form ``10.123'',
                     or a DECNET host name.  [DECNET host name support is only available on ULTRIX systems that
                     are configured to run DECNET.]

              decnet dst host
                     True if the DECNET destination address is host.

              decnet host host
                     True if either the DECNET source or destination address is host.

              ifname interface
                     True  if  the  packet  was  logged as coming from the specified interface (applies only to
                     packets logged by OpenBSD's pf(4)).

              on interface
                     Synonymous with the ifname modifier.

              rnr num
                     True if the packet was logged as matching the specified PF rule number  (applies  only  to
                     packets logged by OpenBSD's pf(4)).

              rulenum num
                     Synonymous with the rnr modifier.

              reason code
                     True  if  the  packet  was logged with the specified PF reason code.  The known codes are:
                     match, bad-offset, fragment, short, normalize, and memory (applies only to packets  logged
                     by OpenBSD's pf(4)).

              rset name
                     True  if  the  packet  was logged as matching the specified PF ruleset name of an anchored
                     ruleset (applies only to packets logged by pf(4)).

              ruleset name
                     Synonymous with the rset modifier.

              srnr num
                     True if the packet was logged as matching the specified PF  rule  number  of  an  anchored
                     ruleset (applies only to packets logged by pf(4)).

              subrulenum num
                     Synonymous with the srnr modifier.

              action act
                     True  if PF took the specified action when the packet was logged.  Known actions are: pass
                     and block (applies only to packets logged by OpenBSD's pf(4)).

              ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui
                     Abbreviations for:
                          ether proto p
                     where p is one of the above protocols.

              lat, moprc, mopdl
                     Abbreviations for:
                          ether proto p
                     where p is one of the above protocols.  Note that tcpdump does not currently know  how  to
                     parse these protocols.

              vlan [vlan_id]
                     True if the packet is an IEEE 802.1Q VLAN packet.  If [vlan_id] is specified, only true if
                     the packet has the specified vlan_id.  Note that the first  vlan  keyword  encountered  in
                     expression  changes the decoding offsets for the remainder of expression on the assumption
                     that the packet is a VLAN packet.  The vlan [vlan_id] expression may  be  used  more  than
                     once,  to  filter  on VLAN hierarchies.  Each use of that expression increments the filter
                     offsets by 4.

                     For example:
                          vlan 100 && vlan 200
                     filters on VLAN 200 encapsulated within VLAN 100, and
                          vlan && vlan 300 && ip
                     filters IPv4 protocols encapsulated in VLAN 300 encapsulated within any higher order VLAN.

              mpls [label_num]
                     True  if  the  packet  is  an  MPLS packet.  If [label_num] is specified, only true is the
                     packet has the specified label_num.  Note that  the  first  mpls  keyword  encountered  in
                     expression  changes the decoding offsets for the remainder of expression on the assumption
                     that the packet is a MPLS-encapsulated IP packet.  The mpls [label_num] expression may  be
                     used  more  than  once,  to  filter  on  MPLS  hierarchies.   Each  use of that expression
                     increments the filter offsets by 4.

                     For example:
                          mpls 100000 && mpls 1024
                     filters packets with an outer label of 100000 and an inner label of 1024, and
                          mpls && mpls 1024 && host 192.9.200.1
                     filters packets to or from 192.9.200.1 with an inner label of 1024 and any outer label.

              pppoed True if the packet is a PPP-over-Ethernet Discovery packet (Ethernet type 0x8863).

              pppoes True if the packet is a PPP-over-Ethernet Session packet  (Ethernet  type  0x8864).   Note
                     that  the  first pppoes keyword encountered in expression changes the decoding offsets for
                     the remainder of expression on the assumption that the packet is a PPPoE session packet.

                     For example:
                          pppoes && ip
                     filters IPv4 protocols encapsulated in PPPoE.

              tcp, udp, icmp
                     Abbreviations for:
                          ip proto p or ip6 proto p
                     where p is one of the above protocols.

              iso proto protocol
                     True if the packet is an OSI packet of protocol type protocol.  Protocol can be  a  number
                     or one of the names clnp, esis, or isis.

              clnp, esis, isis
                     Abbreviations for:
                          iso proto p
                     where p is one of the above protocols.

              l1, l2, iih, lsp, snp, csnp, psnp
                     Abbreviations for IS-IS PDU types.

              vpi n  True if the packet is an ATM packet, for SunATM on Solaris, with a virtual path identifier
                     of n.

              vci n  True if the packet is an ATM packet, for SunATM on Solaris, with a virtual channel identi-
                     fier of n.

              lane   True  if  the  packet  is an ATM packet, for SunATM on Solaris, and is an ATM LANE packet.
                     Note that the first lane keyword encountered in expression changes the tests done  in  the
                     remainder of expression on the assumption that the packet is either a LANE emulated Ether-
                     net packet or a LANE LE Control packet.  If lane isn't specified, the tests are done under
                     the assumption that the packet is an LLC-encapsulated packet.

              llc    True  if  the  packet  is an ATM packet, for SunATM on Solaris, and is an LLC-encapsulated
                     packet.

              oamf4s True if the packet is an ATM packet, for SunATM on Solaris, and is a segment OAM  F4  flow
                     cell (VPI=0 & VCI=3).

              oamf4e True  if  the  packet is an ATM packet, for SunATM on Solaris, and is an end-to-end OAM F4
                     flow cell (VPI=0 & VCI=4).

              oamf4  True if the packet is an ATM packet, for SunATM on Solaris, and is a segment or end-to-end
                     OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).

              oam    True if the packet is an ATM packet, for SunATM on Solaris, and is a segment or end-to-end
                     OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).

              metac  True if the packet is an ATM packet, for SunATM on Solaris, and is  on  a  meta  signaling
                     circuit (VPI=0 & VCI=1).

              bcc    True  if the packet is an ATM packet, for SunATM on Solaris, and is on a broadcast signal-
                     ing circuit (VPI=0 & VCI=2).

              sc     True if the packet is an ATM packet, for SunATM on Solaris, and is on a signaling  circuit
                     (VPI=0 & VCI=5).

              ilmic  True  if  the  packet  is  an ATM packet, for SunATM on Solaris, and is on an ILMI circuit
                     (VPI=0 & VCI=16).

              connectmsg
                     True if the packet is an ATM packet, for SunATM on Solaris, and is on a signaling  circuit
                     and  is  a  Q.2931  Setup, Call Proceeding, Connect, Connect Ack, Release, or Release Done
                     message.

              metaconnect
                     True if the packet is an ATM packet, for SunATM on Solaris, and is  on  a  meta  signaling
                     circuit and is a Q.2931 Setup, Call Proceeding, Connect, Release, or Release Done message.

              expr relop expr
                     True if the relation holds, where relop is one of >, <, >=, <=, =,  !=,  and  expr  is  an
                     arithmetic  expression composed of integer constants (expressed in standard C syntax), the
                     normal binary operators [+, -, *, /, &, |, <<, >>], a length operator, and special  packet
                     data  accessors.  Note that all comparisons are unsigned, so that, for example, 0x80000000
                     and 0xffffffff are > 0.  To access data inside the packet, use the following syntax:
                          proto [ expr : size ]
                     Proto is one of ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp, ip6
                     or  radio,  and indicates the protocol layer for the index operation.  (ether, fddi, wlan,
                     tr, ppp, slip and link all refer to the link layer. radio refers  to  the  "radio  header"
                     added  to  some 802.11 captures.)  Note that tcp, udp and other upper-layer protocol types
                     only apply to IPv4, not IPv6 (this will be fixed in the future).  The byte  offset,  rela-
                     tive  to  the  indicated protocol layer, is given by expr.  Size is optional and indicates
                     the number of bytes in the field of interest; it can be either  one,  two,  or  four,  and
                     defaults  to  one.  The length operator, indicated by the keyword len, gives the length of
                     the packet.

                     For example, `ether[0] & 1 != 0' catches all multicast traffic.  The expression  `ip[0]  &
                     0xf  !=  5'  catches all IPv4 packets with options.  The expression `ip[6:2] & 0x1fff = 0'
                     catches only unfragmented IPv4 datagrams and frag zero of fragmented IPv4 datagrams.  This
                     check  is  implicitly  applied  to the tcp and udp index operations.  For instance, tcp[0]
                     always means the first byte of the TCP header, and never means the first byte of an inter-
                     vening fragment.

                     Some  offsets  and  field  values may be expressed as names rather than as numeric values.
                     The following protocol header field offsets are available:  icmptype  (ICMP  type  field),
                     icmpcode (ICMP code field), and tcpflags (TCP flags field).

                     The  following  ICMP  type field values are available: icmp-echoreply, icmp-unreach, icmp-
                     sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert, icmp-routersolicit,  icmp-timx-
                     ceed,  icmp-paramprob,  icmp-tstamp,  icmp-tstampreply,  icmp-ireq,  icmp-ireqreply, icmp-
                     maskreq, icmp-maskreply.

                     The following TCP flags field values are available: tcp-fin, tcp-syn,  tcp-rst,  tcp-push,
                     tcp-ack, tcp-urg.

              Primitives may be combined using:

                     A  parenthesized  group  of primitives and operators (parentheses are special to the Shell
                     and must be escaped).

                     Negation (`!' or `not').

                     Concatenation (`&&' or `and').

                     Alternation (`||' or `or').

              Negation has highest precedence.  Alternation and concatenation have equal precedence  and  asso-
              ciate left to right.  Note that explicit and tokens, not juxtaposition, are now required for con-
              catenation.

              If an identifier is given without a keyword, the most recent keyword is assumed.  For example,
                   not host vs and ace
              is short for
                   not host vs and host ace
              which should not be confused with
                   not ( host vs or ace )

              Expression arguments can be passed to tcpdump as either a single argument or  as  multiple  argu-
              ments, whichever is more convenient.  Generally, if the expression contains Shell metacharacters,
              it is easier to pass it as a single, quoted argument.  Multiple arguments are  concatenated  with
              spaces before being parsed.
 

EXAMPLES
 
       To print all packets arriving at or departing from sundown:
              tcpdump host sundown

       To print traffic between helios and either hot or ace:
              tcpdump host helios and \( hot or ace \)

       To print all IP packets between ace and any host except helios:
              tcpdump ip host ace and not helios

       To print all traffic between local hosts and hosts at Berkeley:
              tcpdump net ucb-ether

       To  print  all ftp traffic through internet gateway snup: (note that the expression is quoted to prevent
       the shell from (mis-)interpreting the parentheses):
              tcpdump 'gateway snup and (port ftp or ftp-data)'

       To print traffic neither sourced from nor destined for local hosts (if you gateway  to  one  other  net,
       this stuff should never make it onto your local net).
              tcpdump ip and not net localnet

       To  print  the  start and end packets (the SYN and FIN packets) of each TCP conversation that involves a
       non-local host.
              tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'

       To print all IPv4 HTTP packets to and from port 80, i.e. print only packets that contain data, not,  for
       example, SYN and FIN packets and ACK-only packets.  (IPv6 is left as an exercise for the reader.)
              tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

       To print IP packets longer than 576 bytes sent through gateway snup:
              tcpdump 'gateway snup and ip[2:2] > 576'

       To print IP broadcast or multicast packets that were not sent via Ethernet broadcast or multicast:
              tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

       To print all ICMP packets that are not echo requests/replies (i.e., not ping packets):
              tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
 
OUTPUT FORMAT
 
       The  output  of  tcpdump is protocol dependent.  The following gives a brief description and examples of
       most of the formats.

       Link Level Headers

       If the '-e' option is given, the link level header is printed out.  On Ethernets, the source and  desti-
       nation addresses, protocol, and packet length are printed.

       On  FDDI  networks,  the  '-e' option causes tcpdump to print the `frame control' field,  the source and
       destination addresses, and the packet length.  (The `frame control' field governs the interpretation  of
       the  rest  of  the  packet.  Normal packets (such as those containing IP datagrams) are `async' packets,
       with a priority value between 0 and 7; for example, `async4'.  Such packets are assumed  to  contain  an
       802.2 Logical Link Control (LLC) packet; the LLC header is printed if it is not an ISO datagram or a so-
       called SNAP packet.

       On Token Ring networks, the '-e' option causes tcpdump to print the `access control' and `frame control'
       fields,  the  source and destination addresses, and the packet length.  As on FDDI networks, packets are
       assumed to contain an LLC packet.  Regardless of whether the '-e' option is specified or not, the source
       routing information is printed for source-routed packets.

       On  802.11  networks,  the  '-e'  option  causes tcpdump to print the `frame control' fields, all of the
       addresses in the 802.11 header, and the packet length.  As on FDDI networks, packets are assumed to con-
       tain an LLC packet.

       (N.B.:  The  following  description assumes familiarity with the SLIP compression algorithm described in
       RFC-1144.)

       On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound), packet type, and  compres-
       sion  information are printed out.  The packet type is printed first.  The three types are ip, utcp, and
       ctcp.  No further link information is printed for ip packets.  For TCP packets, the  connection  identi-
       fier  is  printed  following  the type.  If the packet is compressed, its encoded header is printed out.
       The special cases are printed out as *S+n and *SA+n, where n is the amount by which the sequence  number
       (or  sequence  number  and  ack)  has  changed.   If  it is not a special case, zero or more changes are
       printed.  A change is indicated by U (urgent pointer), W (window), A (ack), S (sequence number),  and  I
       (packet  ID),  followed  by a delta (+n or -n), or a new value (=n).  Finally, the amount of data in the
       packet and compressed header length are printed.

       For example, the following line shows an outbound compressed TCP packet,  with  an  implicit  connection
       identifier;  the  ack  has  changed by 6, the sequence number by 49, and the packet ID by 6; there are 3
       bytes of data and 6 bytes of compressed header:
              O ctcp * A+6 S+49 I+6 3 (6)

       ARP/RARP Packets

       Arp/rarp output shows the type of request and its arguments.  The format is intended to be self explana-
       tory.  Here is a short sample taken from the start of an `rlogin' from host rtsg to host csam:
              arp who-has csam tell rtsg
              arp reply csam is-at CSAM
       The  first line says that rtsg sent an arp packet asking for the Ethernet address of internet host csam.
       Csam replies with its Ethernet address (in this example, Ethernet addresses are  in  caps  and  internet
       addresses in lower case).

       This would look less redundant if we had done 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

       If  we had done tcpdump -e, the fact that the first packet is broadcast and the second is point-to-point
       would be visible:
              RTSG Broadcast 0806  64: arp who-has csam tell rtsg
              CSAM RTSG 0806  64: arp reply csam is-at CSAM
       For the first packet this says the Ethernet source address is RTSG,  the  destination  is  the  Ethernet
       broadcast address, the type field contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.

       TCP Packets

       (N.B.:The following description assumes familiarity with the TCP protocol described in RFC-793.  If  you
       are not familiar with the protocol, neither this description nor tcpdump will be of much use to you.)

       The general format of a tcp protocol line is:
              src > dst: flags data-seqno ack window urgent options
       Src  and  dst  are  the  source and destination IP addresses and ports.  Flags are some combination of S
       (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo), or a single `.' (no flags).   Data-seqno
       describes  the portion of sequence space covered by the data in this packet (see example below).  Ack is
       sequence number of the next data expected the other direction on this connection.  Window is the  number
       of  bytes of receive buffer space available the other direction on this connection.  Urg indicates there
       is `urgent' data in the packet.  Options are tcp options enclosed in angle brackets (e.g., <mss  1024>).

       Src, dst and flags are always present.  The other fields depend on the contents of the packet's tcp pro-
       tocol header and are output only if appropriate.

       Here is the opening portion of an rlogin from host rtsg to host 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
       The first line says that tcp port 1023 on rtsg sent a packet to port login on  csam.   The  S  indicates
       that  the SYN flag was set.  The packet sequence number was 768512 and it contained no data.  (The nota-
       tion is `first:last(nbytes)' which means `sequence numbers first up to but not including last  which  is
       nbytes bytes of user data'.)  There was no piggy-backed ack, the available receive window was 4096 bytes
       and there was a max-segment-size option requesting an mss of 1024 bytes.

       Csam replies with a similar packet except it includes a piggy-backed ack for rtsg's SYN.  Rtsg then acks
       csam's SYN.  The `.' means no flags were set.  The packet contained no data so there is no data sequence
       number.  Note that the ack sequence number is a small integer (1).  The first time tcpdump  sees  a  tcp
       `conversation',  it  prints the sequence number from the packet.  On subsequent packets of the conversa-
       tion, the difference between the current packet's sequence number and this initial  sequence  number  is
       printed.  This means that sequence numbers after the first can be interpreted as relative byte positions
       in the conversation's data stream (with the first data byte each direction being `1').  `-S' will  over-
       ride this feature, causing the original sequence numbers to be output.

       On  the  6th  line, rtsg sends csam 19 bytes of data (bytes 2 through 20 in the rtsg -> csam side of the
       conversation).  The PUSH flag is set in the packet.  On the 7th line, csam says it's received data  sent
       by  rtsg  up to but not including byte 21.  Most of this data is apparently sitting in the socket buffer
       since csam's receive window has gotten 19 bytes smaller.  Csam also sends one byte of data  to  rtsg  in
       this packet.  On the 8th and 9th lines, csam sends two bytes of urgent, pushed data to rtsg.

       If  the snapshot was small enough that tcpdump didn't capture the full TCP header, it interprets as much
       of the header as it can and then reports ``[|tcp]'' to indicate the remainder could not be  interpreted.
       If  the  header  contains a bogus option (one with a length that's either too small or beyond the end of
       the header), tcpdump reports it as ``[bad opt]'' and does not interpret any further options (since  it's
       impossible  to  tell  where  they start).  If the header length indicates options are present but the IP
       datagram length is not long enough for the options to actually be there, tcpdump reports  it  as  ``[bad
       hdr length]''.

       Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.)

       There are 8 bits in the control bits section of the TCP header:

              CWR | ECE | URG | ACK | PSH | RST | SYN | FIN

       Let's  assume that we want to watch packets used in establishing a TCP connection.  Recall that TCP uses
       a 3-way handshake protocol when it initializes a new connection; the connection sequence with regard  to
       the TCP control bits is

              1) Caller sends SYN
              2) Recipient responds with SYN, ACK
              3) Caller sends ACK

       Now  we're  interested in capturing packets that have only the SYN bit set (Step 1).  Note that we don't
       want packets from step 2 (SYN-ACK), just a plain initial SYN.  What we need is a correct filter  expres-
       sion for tcpdump.

       Recall the structure of a TCP header without options:

        0                            15                              31
       -----------------------------------------------------------------
       |          source port          |       destination port        |
       -----------------------------------------------------------------
       |                        sequence number                        |
       -----------------------------------------------------------------
       |                     acknowledgment number                     |
       -----------------------------------------------------------------
       |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
       -----------------------------------------------------------------
       |         TCP checksum          |       urgent pointer          |
       -----------------------------------------------------------------

       A  TCP  header usually holds 20 octets of data, unless options are present.  The first line of the graph
       contains octets 0 - 3, the second line shows octets 4 - 7 etc.

       Starting to count with 0, the relevant TCP control bits are contained in octet 13:

        0             7|             15|             23|             31
       ----------------|---------------|---------------|----------------
       |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
       ----------------|---------------|---------------|----------------
       |               |  13th octet   |               |               |

       Let's have a closer look at octet no. 13:

                       |               |
                       |---------------|
                       |C|E|U|A|P|R|S|F|
                       |---------------|
                       |7   5   3     0|

       These are the TCP control bits we are interested in.  We have numbered the bits in this octet from 0  to
       7, right to left, so the PSH bit is bit number 3, while the URG bit is number 5.

       Recall  that  we want to capture packets with only SYN set.  Let's see what happens to octet 13 if a TCP
       datagram arrives with the SYN bit set in its header:

                       |C|E|U|A|P|R|S|F|
                       |---------------|
                       |0 0 0 0 0 0 1 0|
                       |---------------|
                       |7 6 5 4 3 2 1 0|

       Looking at the control bits section we see that only bit number 1 (SYN) is set.

       Assuming that octet number 13 is an 8-bit unsigned integer in network byte order, the  binary  value  of
       this octet is

              00000010

       and its decimal representation is

          7     6     5     4     3     2     1     0
       0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2  =  2

       We're  almost  done, because now we know that if only SYN is set, the value of the 13th octet in the TCP
       header, when interpreted as a 8-bit unsigned integer in network byte order, must be exactly 2.

       This relationship can be expressed as
              tcp[13]  2

       We can use this expression as the filter for tcpdump in order to watch packets which have only SYN set:
              tcpdump -i xl0 tcp[13]  2

       The expression says "let the 13th octet of a TCP datagram have the decimal value 2",  which  is  exactly
       what we want.

       Now, let's assume that we need to capture SYN packets, but we don't care if ACK or any other TCP control
       bit is set at the same time.  Let's see what happens to octet 13 when a TCP datagram  with  SYN-ACK  set
       arrives:

            |C|E|U|A|P|R|S|F|
            |---------------|
            |0 0 0 1 0 0 1 0|
            |---------------|
            |7 6 5 4 3 2 1 0|

       Now bits 1 and 4 are set in the 13th octet.  The binary value of octet 13 is

                   00010010

       which translates to decimal

          7     6     5     4     3     2     1     0
       0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2   = 18

       Now  we  can't just use 'tcp[13]  18' in the tcpdump filter expression, because that would select only
       those packets that have SYN-ACK set, but not those with only SYN set.  Remember that we  don't  care  if
       ACK or any other control bit is set as long as SYN is set.

       In  order  to  achieve  our  goal, we need to logically AND the binary value of octet 13 with some other
       value to preserve the SYN bit.  We know that we want SYN to be set in any case, so we'll  logically  AND
       the value in the 13th octet with the binary value of a SYN:


                 00010010 SYN-ACK              00000010 SYN
            AND  00000010 (we want SYN)   AND  00000010 (we want SYN)
                 --------                      --------
            =    00000010                 =    00000010

       We  see  that  this AND operation delivers the same result regardless whether ACK or another TCP control
       bit is set.  The decimal representation of the AND value as well as the result of this  operation  is  2
       (binary 00000010), so we know that for packets with SYN set the following relation must hold true:

              ( ( value of octet 13 ) AND ( 2 ) )  ( 2 )

       This points us to the tcpdump filter expression
                   tcpdump -i xl0 'tcp[13] & 2  2'

       Note  that  you  should use single quotes or a backslash in the expression to hide the AND ('&') special
       character from the shell.

       UDP Packets

       UDP format is illustrated by this rwho packet:
              actinide.who > broadcast.who: udp 84
       This says that port who on host actinide sent a udp datagram to port who on host broadcast, the Internet
       broadcast address.  The packet contained 84 bytes of user data.

       Some  UDP services are recognized (from the source or destination port number) and the higher level pro-
       tocol information printed.  In particular, Domain Name service  requests  (RFC-1034/1035)  and  Sun  RPC
       calls (RFC-1050) to NFS.

       UDP Name Server Requests

       (N.B.:The  following  description  assumes  familiarity  with  the  Domain Service protocol described in
       RFC-1035.  If you are not familiar with the protocol, the following description will appear to be  writ-
       ten in greek.)

       Name server requests are formatted as
              src > dst: id op? flags qtype qclass name (len)
              h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
       Host  h2opolo asked the domain server on helios for an address record (qtype=A) associated with the name
       ucbvax.berkeley.edu.  The query id was `3'.  The `+' indicates the recursion desired flag was set.   The
       query  length  was 37 bytes, not including the UDP and IP protocol headers.  The query operation was the
       normal one, Query, so the op field was omitted.  If the op had been anything else, it  would  have  been
       printed  between the `3' and the `+'.  Similarly, the qclass was the normal one, C_IN, and omitted.  Any
       other qclass would have been printed immediately after the `A'.

       A few anomalies are checked and may result in extra fields enclosed in square brackets:  If a query con-
       tains  an  answer,  authority  records  or  additional records section, ancount, nscount, or arcount are
       printed as `[na]', `[nn]' or  `[nau]' where n is the appropriate count.  If any of the response bits are
       set  (AA,  RA  or rcode) or any of the `must be zero' bits are set in bytes two and three, `[b2&3=x]' is
       printed, where x is the hex value of header bytes two and three.

       UDP Name Server Responses

       Name server responses are formatted as
              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)
       In the first example, helios responds to query id 3 from h2opolo with 3 answer records,  3  name  server
       records  and 7 additional records.  The first answer record is type A (address) and its data is internet
       address 128.32.137.3.  The total size of the response was 273 bytes, excluding UDP and IP headers.   The
       op (Query) and response code (NoError) were omitted, as was the class (C_IN) of the A record.

       In the second example, helios responds to query 2 with a response code of non-existent domain (NXDomain)
       with no answers, one name server and no authority records.  The `*'  indicates  that  the  authoritative
       answer bit was set.  Since there were no answers, no type, class or data were printed.

       Other  flag  characters  that might appear are `-' (recursion available, RA, not set) and `|' (truncated
       message, TC, set).  If the `question' section doesn't contain exactly one entry, `[nq]' is printed.

       Note that name server requests and responses tend to be large and the default snaplen of  68  bytes  may
       not capture enough of the packet to print.  Use the -s flag to increase the snaplen if you need to seri-
       ously investigate name server traffic.  `-s 128' has worked well for me.


       SMB/CIFS decoding

       tcpdump now includes fairly extensive SMB/CIFS/NBT decoding for data on UDP/137,  UDP/138  and  TCP/139.
       Some primitive decoding of IPX and NetBEUI SMB data is also done.

       By  default  a  fairly  minimal decode is done, with a much more detailed decode done if -v is used.  Be
       warned that with -v a single SMB packet may take up a page or more, so only use -v if  you  really  want
       all the gory details.

       For  information  on  SMB  packet  formats  and  what  all  te  fields  mean  see  www.cifs.org  or  the
       pub/samba/specs/ directory on your favorite samba.org mirror site.  The  SMB  patches  were  written  by
       Andrew Tridgell (tridge@samba.org).


       NFS Requests and Replies

       Sun NFS (Network File System) requests and replies are printed as:
              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
       In  the  first  line, host sushi sends a transaction with id 6709 to wrl (note that the number following
       the src host is a transaction id, not the source port).  The request was 112 bytes,  excluding  the  UDP
       and   IP   headers.    The   operation  was  a  readlink  (read  symbolic  link)  on  file  handle  (fh)
       21,24/10.731657119.  (If one is lucky, as in this  case,  the  file  handle  can  be  interpreted  as  a
       major,minor  device  number pair, followed by the inode number and generation number.)  Wrl replies `ok'
       with the contents of the link.

       In the third line, sushi asks wrl to lookup the name `xcolors' in directory file  9,74/4096.6878.   Note
       that  the  data printed depends on the operation type.  The format is intended to be self explanatory if
       read in conjunction with an NFS protocol spec.

       If the -v (verbose) flag is given, additional information is printed.  For example:

              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 also prints the IP header TTL, ID, length, and fragmentation fields, which have  been  omitted  from
       this  example.)   In  the  first line, sushi asks wrl to read 8192 bytes from file 21,11/12.195, at byte
       offset 24576.  Wrl replies `ok'; the packet shown on the second line is the first fragment of the reply,
       and  hence is only 1472 bytes long (the other bytes will follow in subsequent fragments, but these frag-
       ments do not have NFS or even UDP headers and so might not be printed, depending on the  filter  expres-
       sion  used).   Because the -v flag is given, some of the file attributes (which are returned in addition
       to the file data) are printed: the file type (``REG'', for regular file), the file mode (in octal),  the
       uid and gid, and the file size.

       If the -v flag is given more than once, even more details are printed.

       Note  that  NFS  requests  are  very  large  and  much  of the detail won't be printed unless snaplen is
       increased.  Try using `-s 192' to watch NFS traffic.

       NFS reply packets do not explicitly identify  the  RPC  operation.   Instead,  tcpdump  keeps  track  of
       ``recent''  requests,  and  matches  them  to the replies using the transaction ID.  If a reply does not
       closely follow the corresponding request, it might not be parsable.

       AFS Requests and Replies

       Transarc AFS (Andrew File System) requests and replies are printed as:

              src.sport > dst.dport: rx packet-type
              src.sport > dst.dport: rx packet-type service call call-name args
              src.sport > dst.dport: rx packet-type service reply call-name args

              elvis.7001 > pike.afsfs:
                   rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
                   new fid 536876964/1/1 ".newsrc"
              pike.afsfs > elvis.7001: rx data fs reply rename
       In the first line, host elvis sends a RX packet to pike.  This was a RX data packet  to  the  fs  (file-
       server)  service,  and  is  the start of an RPC call.  The RPC call was a rename, with the old directory
       file id of 536876964/1/1 and an  old  filename  of  `.newsrc.new',  and  a  new  directory  file  id  of
       536876964/1/1  and  a  new filename of `.newsrc'.  The host pike responds with a RPC reply to the rename
       call (which was successful, because it was a data packet and not an abort packet).

       In general, all AFS RPCs are decoded at least by RPC call name.  Most AFS RPCs have at least some of the
       arguments decoded (generally only the `interesting' arguments, for some definition of interesting).

       The  format  is intended to be self-describing, but it will probably not be useful to people who are not
       familiar with the workings of AFS and RX.

       If the -v (verbose) flag is given twice, acknowledgement packets and additional  header  information  is
       printed,  such  as  the  the  RX call ID, call number, sequence number, serial number, and the RX packet
       flags.

       If the -v flag is given twice, additional information is printed, such as the the  RX  call  ID,  serial
       number, and the RX packet flags.  The MTU negotiation information is also printed from RX ack packets.

       If the -v flag is given three times, the security index and service id are printed.

       Error  codes  are  printed  for  abort packets, with the exception of Ubik beacon packets (because abort
       packets are used to signify a yes vote for the Ubik protocol).

       Note that AFS requests are very large and many of the arguments  won't  be  printed  unless  snaplen  is
       increased.  Try using `-s 256' to watch AFS traffic.

       AFS  reply  packets  do  not  explicitly  identify  the  RPC operation.  Instead, tcpdump keeps track of
       ``recent'' requests, and matches them to the replies using the call number and service ID.  If  a  reply
       does not closely follow the corresponding request, it might not be parsable.


       KIP AppleTalk (DDP in UDP)

       AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated and dumped as DDP packets (i.e.,
       all the UDP header information is discarded).  The file /etc/atalk.names is used to translate  AppleTalk
       net and node numbers to names.  Lines in this file have the form
              number    name

              1.254          ether
              16.1      icsd-net
              1.254.110 ace
       The first two lines give the names of AppleTalk networks.  The third line gives the name of a particular
       host (a host is distinguished from a net by the 3rd octet in the number - a net  number  must  have  two
       octets and a host number must have three octets.)  The number and name should be separated by whitespace
       (blanks or tabs).  The /etc/atalk.names file may contain blank lines or comment  lines  (lines  starting
       with a `#').

       AppleTalk addresses are printed in the form
              net.host.port

              144.1.209.2 > icsd-net.112.220
              office.2 > icsd-net.112.220
              jssmag.149.235 > icsd-net.2
       (If  the  /etc/atalk.names doesn't exist or doesn't contain an entry for some AppleTalk host/net number,
       addresses are printed in numeric form.)  In the first example, NBP (DDP port 2) on net 144.1 node 209 is
       sending  to  whatever is listening on port 220 of net icsd node 112.  The second line is the same except
       the full name of the source node is known (`office').  The third line is a send from  port  235  on  net
       jssmag  node  149  to broadcast on the icsd-net NBP port (note that the broadcast address (255) is indi-
       cated by a net name with no host number - for this reason it's a good idea to keep node  names  and  net
       names distinct in /etc/atalk.names).

       NBP  (name binding protocol) and ATP (AppleTalk transaction protocol) packets have their contents inter-
       preted.  Other protocols just dump the protocol name (or number if no name is registered for the  proto-
       col) and packet size.

       NBP packets are formatted like the following examples:
              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
       The  first line is a name lookup request for laserwriters sent by net icsd host 112 and broadcast on net
       jssmag.  The nbp id for the lookup is 190.  The second line shows a reply for this request (note that it
       has  the  same  id) from host jssmag.209 saying that it has a laserwriter resource named "RM1140" regis-
       tered on port 250.  The third line is another reply to the same request saying host techpit  has  laser-
       writer "techpit" registered on port 186.

       ATP packet formatting is demonstrated by the following example:
              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  initiates transaction id 12266 with host helios by requesting up to 8 packets (the `<0-7>').
       The hex number at the end of the line is the value of the `userdata' field in the request.

       Helios responds with 8 512-byte packets.  The `:digit' following the transaction  id  gives  the  packet
       sequence number in the transaction and the number in parens is the amount of data in the packet, exclud-
       ing the atp header.  The `*' on packet 7 indicates that the EOM bit was set.

       Jssmag.209 then requests that packets 3 & 5 be  retransmitted.   Helios  resends  them  then  jssmag.209
       releases the transaction.  Finally, jssmag.209 initiates the next request.  The `*' on the request indi-
       cates that XO (`exactly once') was not set.


       IP Fragmentation

       Fragmented Internet datagrams are printed as
              (frag id:size@offset+)
              (frag id:size@offset)
       (The first form indicates there are more fragments.  The second indicates this is the last fragment.)

       Id is the fragment id.  Size is the fragment size (in bytes) excluding the IP header.   Offset  is  this
       fragment's offset (in bytes) in the original datagram.

       The  fragment  information  is  output  for each fragment.  The first fragment contains the higher level
       protocol header and the frag info is printed after the protocol info.  Fragments after the first contain
       no higher level protocol header and the frag info is printed after the source and destination addresses.
       For example, here is part of an ftp from arizona.edu to  lbl-rtsg.arpa  over  a  CSNET  connection  that
       doesn't appear to handle 576 byte datagrams:
              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
       There are a couple of things to note here:  First, addresses in the 2nd line don't include port numbers.
       This is because the TCP protocol information is all in the first fragment and we have no idea  what  the
       port or sequence numbers are when we print the later fragments.  Second, the tcp sequence information in
       the first line is printed as if there were 308 bytes of user data when, in fact,  there  are  512  bytes
       (308  in  the  first frag and 204 in the second).  If you are looking for holes in the sequence space or
       trying to match up acks with packets, this can fool you.

       A packet with the IP don't fragment flag is marked with a trailing (DF).

       Timestamps

       By default, all output lines are preceded by a timestamp.  The timestamp is the current  clock  time  in
       the form
              hh:mm:ss.frac
       and  is  as  accurate  as  the kernel's clock.  The timestamp reflects the time the kernel first saw the
       packet.  No attempt is made to account for the time lag between when the Ethernet interface removed  the
       packet from the wire and when the kernel serviced the `new packet' interrupt.
 

SEE ALSO
 
       stty(1), pcap(3), bpf(4), nit(4P), pfconfig(8)
 

AUTHORS
 
       The original authors are:

       Van  Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, Univer-
       sity of California, Berkeley, CA.

       It is currently being maintained by tcpdump.org.

       The current version is available via http:

              http://www.tcpdump.org/

       The original distribution is available via anonymous ftp:

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

       IPv6/IPsec support is added by WIDE/KAME project.  This program uses Eric Young's SSLeay library,  under
       specific configuration.
 

BUGS
 
       Please send problems, bugs, questions, desirable enhancements, etc. to:

              tcpdump-workers@tcpdump.org

       Please send source code contributions, etc. to:

              patches@tcpdump.org

       NIT doesn't let you watch your own outbound traffic, BPF will.  We recommend that you use the latter.

       On Linux systems with 2.0[.x] kernels:

              packets on the loopback device will be seen twice;

              packet filtering cannot be done in the kernel, so that all packets must be copied from the kernel
              in order to be filtered in user mode;

              all of a packet, not just the part that's within the snapshot length, will  be  copied  from  the
              kernel (the 2.0[.x] packet capture mechanism, if asked to copy only part of a packet to userland,
              will not report the true length of the packet; this would cause most IP packets to get  an  error
              from tcpdump);

              capturing on some PPP devices won't work correctly.

       We recommend that you upgrade to a 2.2 or later kernel.

       Some  attempt should be made to reassemble IP fragments or, at least to compute the right length for the
       higher level protocol.

       Name server inverse queries are not dumped correctly: the (empty) question  section  is  printed  rather
       than  real query in the answer section.  Some believe that inverse queries are themselves a bug and pre-
       fer to fix the program generating them rather than tcpdump.

       A packet trace that crosses a daylight savings time change will give skewed time stamps (the time change
       is ignored).

       Filter  expressions  on  fields other than those in Token Ring headers will not correctly handle source-
       routed Token Ring packets.

       Filter expressions on fields other than those in 802.11 headers will not correctly  handle  802.11  data
       packets with both To DS and From DS set.

       ip6  proto  should  chase  header chain, but at this moment it does not.  ip6 protochain is supplied for
       this behavior.

       Arithmetic expression against transport layer headers, like tcp[0], does not work against IPv6  packets.
       It only looks at IPv4 packets.
 

 

                                                 18 April 2005                                       TCPDUMP(8)

 

符号约定
========
 
越少越好(目前只有一个):
nt:  即note的缩写, 表示翻译时的补充说明部分
 

Avatar_small
law assignment help 说:
2020年10月03日 14:38

You must have some basics knowledge about the functions so you can work on these things. I always do my best to learn new things and try to do new things.


登录 *


loading captcha image...
(输入验证码)
or Ctrl+Enter