tcpdump 与 wireshark 抓包分析

注：机翻，未校。

Wireshark vs. tcpdump: What’s the difference?

Wireshark and tcpdump both aid network administrators in packet analysis. Wireshark’s simple GUI contrasts with tcpdump’s speed and scripting abilities, which enhances management.

Wireshark 和 tcpdump 都可以帮助网络管理员进行数据包分析。Wireshark 的简单 GUI 与 tcpdump 的速度和脚本编写能力形成鲜明对比，从而增强了管理。

Network administrators often envision the path of network traffic like water flowing through pipes. Imagine being able to follow each water droplet’s journey across a system and see each droplet’s individual parts. Similarly, network analyzers, also called packet sniffers , intercept network traffic to display addressing information and content to administrators and troubleshooters.
网络管理员经常设想网络流量的路径，就像水流过管道一样。想象一下，能够跟踪每个水滴在系统中的旅程，并看到每个水滴的各个部分。同样，网络分析器（也称为数据包嗅探器）会拦截网络流量，以向管理员和故障排除者显示寻址信息和内容。

Network analyzers are crucial network management tools. Popular network analyzers include Wireshark and tcpdump, which show administrators MAC addresses, IP addresses and payload information. Wireshark and tcpdump help network administrators troubleshoot issues related to packet filters on routers, firewall settings and even failing network interface cards (NICs).
网络分析仪是至关重要的网络管理工具。常用的网络分析器包括 Wireshark 和 tcpdump，它们向管理员显示 MAC 地址、IP 地址和有效负载信息。Wireshark 和 tcpdump 可帮助网络管理员解决与路由器上的数据包过滤器、防火墙设置甚至网络接口卡（NIC）故障相关的问题。

Although Wireshark and tcpdump accomplish similar goals, they operate differently and serve different use cases. However, network administrators can integrate both tools, so it’s important to understand when and how to use each for troubleshooting and management tasks.
尽管 Wireshark 和 tcpdump 实现了类似的目标，但它们的操作方式不同，服务于不同的用例。但是，网络管理员可以集成这两种工具，因此了解何时以及如何使用每种工具执行故障排除和管理任务非常重要。

What’s the difference between Wireshark and tcpdump?

Wireshark 和 tcpdump 区别

At their core, Wireshark and tcpdump both capture and display network data packets. However, their UIs have some differences. Wireshark offers both a GUI and command-line component, while tcpdump operates only via a CLI.
从本质上讲，Wireshark 和 tcpdump 都捕获和显示网络数据包。但是，它们的 UI 有一些差异。Wireshark 提供 GUI 和命令行组件，而 tcpdump 仅通过 CLI 运行。

Wireshark’s GUI

Wireshark 图形用户界面

Wireshark users often rely on its easy-to-use GUI. Its capabilities include the following:
Wireshark 用户通常依赖其易于使用的 GUI。其功能包括：

Detailed packet analysis. 详细的数据包分析。
Advanced filtering. 高级过滤。
Comprehensive UI. 全面的用户界面。

Wireshark can show network administrators information about network packets, with clear delineations between Layer 2 and Layer 3 headers along with the payload. It displays traffic flow in real time for monitoring and saves captures into files network administrators can filter and analyze afterward.
Wireshark 可以向网络管理员显示有关网络数据包的信息，并在第 2 层和第 3 层标头以及有效载荷之间明确划分。它实时显示流量以进行监控，并将捕获的保存到文件中，网络管理员可以在之后进行过滤和分析。
在这里插入图片描述
The three panes in Wireshark’s UI display packet capture information.

Wireshark’s advanced filtering tool is essential because network captures can become large on busy networks. Network administrators might want to define packets before they start captures to ensure they receive desired results.
Wireshark 的高级过滤工具是必不可少的，因为在繁忙的网络上，网络捕获可能会变得很大。网络管理员可能希望在开始捕获之前定义数据包，以确保他们收到所需的结果。

在这里插入图片描述
Set up a capture filter to limit the capture to the necessary information.

Wireshark’s user-friendly UI makes it useful for most tasks. Network administrators can install it on their Linux, macOS or Windows systems. Once Wireshark captures packets, network administrators can select one to view detailed information, such as source and destination MAC addresses, IP addresses and port numbers. The bottom pane in the interface shows the packet’s contents. If the contents aren’t encrypted, network administrators can read the data, such as emails, files or print job content.
Wireshark 的用户友好 UI 使其对大多数任务都很有用。网络管理员可以将其安装在他们的 Linux、macOS 或 Windows 系统上。一旦 Wireshark 捕获数据包，网络管理员就可以选择一个来查看详细信息，例如源和目标 MAC 地址、IP 地址和端口号。界面的底部窗格显示数据包的内容。如果内容未加密，网络管理员可以读取数据，例如电子邮件、文件或打印作业内容。

在这里插入图片描述
Network administrators can view IP and content information in the lower panes with a single packet selected.

Wireshark also has a command-line option, which is useful for scripting or servers without a GUI. Follow these steps to use Wireshark for packet capturing:
Wireshark 还有一个命令行选项，这对于没有 GUI 的脚本或服务器很有用。按照以下步骤使用 Wireshark 进行数据包捕获：

Launch Wireshark to begin.
启动 Wireshark 开始。
Select the NIC on which to capture traffic.
选择要捕获流量的 NIC。
Set capture filters to limit results to the desired protocols.
设置捕获过滤器以将结果限制为所需的协议。
Select Start capturing packets . Several results appear quickly. Don’t run the capture longer than necessary to prevent excessive results.
选择 “开始捕获数据包”。几个结果很快出现。运行捕获的时间不要超过必要的时间，以防止产生过多的结果。
Select Stop capturing packets to end the capture.
选择 “停止捕获数据包” 以结束捕获。
Select a specific packet to see details.
选择特定数据包以查看详细信息。

Wireshark’s start and stop buttons.

Wireshark’s interface consists of the following panes:
Wireshark 的界面由以下窗格组成：

Packet list. 数据包列表。
Packet details. 数据包详细信息。
Packet bytes. 数据包已交换。

Detailed packet information is crucial because it displays addressing and protocol information.
详细的数据包信息至关重要，因为它显示寻址和协议信息。

Wireshark also includes extensive documentation.
Wireshark 还包括大量文档。

Tcpdump CLI

Tcpdump 命令行界面

Unlike Wireshark, tcpdump – also known as WinDump on Windows – is solely a CLI tool. The tcpdump utility captures packets from the command line. It can display the capture in real time without saving the results, or network administrators can configure the utility to write to a file.
与 Wireshark 不同，tcpdump（在 Windows 上也称为 WinDump）只是一个 CLI 工具。tcpdump 实用程序从命令行捕获数据包。它可以在不保存结果的情况下实时显示捕获，或者网络管理员可以将实用程序配置为写入文件。

To capture packets with tcpdump, first, start the capture with a command and parameters. Use the following command to start a capture on the eth0 NIC and write the results to a file named dump.pcap.
要使用 tcpdump 捕获数据包，首先，使用命令和参数开始捕获。使用以下命令在 eth0 NIC 上启动捕获，并将结果写入名为 dump.pcap 的文件中。

$ tcpdump -i eth0 -w dump.pcap

Stop the capture. Use Ctrl+C to end the capture.
停止捕获。使用 Ctrl+C 结束捕获。
在这里插入图片描述
The tcpdump command writes capture results to a file. No output displays on the screen during the capture.

Refer to the tcpdump man page or the online documentation for details. The following shows a few common options:
有关详细信息，请参见 tcpdump 手册页或联机文档。下面显示了一些常见选项：

-i. Specify an interface on which to capture. Use any to capture on all available interfaces.
指定要捕获的接口。使用 any 在所有可用接口上捕获。
-D. List available devices from which to capture.
列出要从中捕获的可用设备。
Port 80. Filter capture by port number.
按端口号筛选捕获。
-n. Do not resolve IP addresses to names. Reports captures by IP address.
不要将 IP 地址解析为名称。按 IP 地址捕获的报告。
-w dump.pcap. Write the capture to a file named dump.pcap.
将捕获写入名为 dump.pcap 的文件。
-r dump.pcap. Read the capture from a file named dump.pcap.
从名为 dump.pcap 的文件中读取捕获。

Wireshark vs. tcpdump use cases

Wireshark 与 tcpdump 使用案例

Wireshark and tcpdump are both effective tools, but situations occur where one tool might be a better option. However, they have many overlapping features, so network administrators should use the tool they’re most comfortable with.
Wireshark 和 tcpdump 都是有效的工具，但在某些情况下，一种工具可能是更好的选择。但是，它们有许多重叠的功能，因此网络管理员应使用他们最熟悉的工具。

Wireshark use cases

Wireshark 使用案例

Network traffic identification. Network administrators might prefer to use Wireshark when they need to identify network traffic. Wireshark’s output shows source and destination addresses, which makes it easier to see the location from which traffic originates or which systems are on the segment.
网络流量识别。当网络管理员需要识别网络流量时，他们可能更喜欢使用 Wireshark。Wireshark 的输出显示源地址和目标地址，这样可以更轻松地查看流量的来源位置或段上哪些系统。
Performance management. Wireshark can help network administrators optimize performance management. For example, if network administrators receive numerous helpdesk messages about poor network performance on a specific segment, they can connect their laptops with Wireshark installed to that segment and start to pick up traffic. They might discover several file transfers in progress, such as replication jobs or users uploading files to servers. Network administrators can also identify failing NIC broadcasting errors or clutter that slows other traffic on the segment.
绩效管理。Wireshark 可以帮助网络管理员优化性能管理。例如，如果网络管理员收到大量有关特定网段上网络性能不佳的消息，他们可以将安装了 Wireshark 的笔记本电脑连接到该网段并开始接收流量。他们可能会发现正在进行的多个文件传输，例如复制作业或用户将文件上传到服务器。网络管理员还可以识别失败的 NIC 广播错误或杂乱无章，这些错误或杂乱会减慢分段上的其他流量。
Menus and filters. Wireshark’s Statistics menu contains many performance analysis features. Network administrators can display IO Graphs or use the Protocol Hierarchy view to see the percentages of each protocol found on the network. Another useful filter is IPv4 Statistics > Source and Destination Addresses, which shows specific nodes generating traffic.
菜单和过滤器。Wireshark 的 Statistics 菜单包含许多性能分析功能。网络管理员可以显示 IO 图形或使用协议层次结构视图来查看在网络上找到的每个协议的百分比。另一个有用的过滤器是 IPv4 统计信息 > 源地址和目标地址，它显示产生流量的特定节点。

Tcpdump use cases

Tcpdump 使用案例

Fast captures. Many network administrators use tcpdump for an initial capture because it’s fast, efficient and configurable.
快速捕获。许多网络管理员使用 tcpdump 进行初始捕获，因为它快速、高效且可配置。
Consistency. Administrators can script tcpdump for consistency.
一致性。管理员可以编写 tcpdump 脚本以确保一致性。
Later analysis. Because tcpdump can write to a file, administrators can capture a packet and analyze it later.
后期分析。由于 tcpdump 可以写入文件，因此管理员可以捕获数据包并在以后进行分析。

Wireshark and tcpdump integration

Wireshark 和 tcpdump 集成

Although Wireshark and tcpdump accomplish similar tasks, network administrators don’t have to limit themselves to one type of packet analyzer. Network administrators should familiarize themselves with both and know when to use one over the other.
尽管 Wireshark 和 tcpdump 可以完成类似的任务，但网络管理员不必将自己限制为一种类型的数据包分析器。网络管理员应熟悉这两者，并知道何时使用其中一个而不是另一个。

For example, network administrators can use tcpdump to write capture results to files and open and filter them with Wireshark. This is helpful for network administrators who capture packets with tcpdump on Linux servers without a GUI and analyze the results with Wireshark on their GUI-equipped Linux, macOS or Windows workstations.
例如，网络管理员可以使用 tcpdump 将捕获结果写入文件，并使用 Wireshark 打开和过滤它们。这对于在没有 GUI 的 Linux 服务器上使用 tcpdump 捕获数据包并在配备 GUI 的 Linux、macOS 或 Windows 工作站上使用 Wireshark 分析结果的网络管理员很有帮助。

在这里插入图片描述
Open the dump.pcap file generated by tcpdump in Wireshark for easier analysis.

Wrap-up

结束语

Network administrators often consider network analyzers as security tools. But these tools can help network teams troubleshoot, identify hosts, investigate network performance issues and more.
网络管理员通常将网络分析器视为安全工具。但这些工具可以帮助网络团队排除故障、识别主机、调查网络性能问题等。

Wireshark and tcpdump are two of the most essential packet analyzers. Wireshark is simple, cross-platform and offers advanced filtering capabilities, while tcpdump is fast, flexible and scriptable. Administrators can get better results when they know how and when to use each tool.
Wireshark 和 tcpdump 是两个最重要的数据包分析器。Wireshark 简单、跨平台并提供高级过滤功能，而 tcpdump 快速、灵活且可编写脚本。当管理员知道如何以及何时使用每个工具时，他们可以获得更好的结果。

via:

Wireshark vs. tcpdump: What’s the difference? | TechTarget By Damon Garn, Cogspinner Coaction
Published: 26 Jun 2024

https://www.techtarget.com/searchNetworking/answer/Wireshark-vs-tcpdump-Whats-the-difference

tcpdump 与 Wireshark 抓包分析

伯乐在线 / 陶仁邦

来源：伯乐在线专栏作者 - 陶仁邦

链接：http://blog.jobbole.com/101476/（链接已沉寂）

1 起因

前段时间，一直在调线上的一个问题：线上应用接受 POST 请求，请求 body 中的参数获取不全，存在丢失的状况。这个问题是偶发性的，大概发生的几率为 5%-10% 左右，这个概率已经相当高了。在排查问题的过程中使用到了 tcpdump 和 Wireshark 进行抓包分析。感觉这两个工具搭配起来干活，非常完美。所有的网络传输在这两个工具搭配下，都无处遁形。

为了更好、更顺手地能够用好这两个工具，特整理本篇文章，希望也能给大家带来收获。为大家之后排查问题，添一利器。

2 tcpdump 与 Wireshark 介绍

在网络问题的调试中，tcpdump 应该说是一个必不可少的工具，和大部分 linux 下优秀工具一样，它的特点就是简单而强大。它是基于 Unix 系统的命令行式的数据包嗅探工具，可以抓取流动在网卡上的数据包。

默认情况下，tcpdump 不会抓取本机内部通讯的报文。根据网络协议栈的规定，对于报文，即使是目的地是本机，也需要经过本机的网络协议层，所以本机通讯肯定是通过 API 进入了内核，并且完成了路由选择。【比如本机的 TCP 通信，也必须要 socket 通信的基本要素：src ip port dst ip port】

如果要使用 tcpdump 抓取其他主机 MAC 地址的数据包，必须开启网卡混杂模式，所谓混杂模式，用最简单的语言就是让网卡抓取任何经过它的数据包，不管这个数据包是不是发给它或者是它发出的。一般而言，Unix 不会让普通用户设置混杂模式，因为这样可以看到别人的信息，比如 telnet 的用户名和密码，这样会引起一些安全上的问题，所以只有 root 用户可以开启混杂模式，开启混杂模式的命令是：ifconfig en0 promisc, en0 是你要打开混杂模式的网卡。

Linux 抓包原理：

Linux 抓包是通过注册一种虚拟的底层网络协议来完成对网络报文 (准确的说是网络设备) 消息的处理权。当网卡接收到一个网络报文之后，它会遍历系统中所有已经注册的网络协议，例如以太网协议、x25 协议处理模块来尝试进行报文的解析处理，这一点和一些文件系统的挂载相似，就是让系统中所有的已经注册的文件系统来进行尝试挂载，如果哪一个认为自己可以处理，那么就完成挂载。

当抓包模块把自己伪装成一个网络协议的时候，系统在收到报文的时候就会给这个伪协议一次机会，让它来对网卡收到的报文进行一次处理，此时该模块就会趁机对报文进行窥探，也就是把这个报文完完整整的复制一份，假装是自己接收到的报文，汇报给抓包模块。

Wireshark 是一个网络协议检测工具，支持 Windows 平台、Unix 平台、Mac 平台，一般只在图形界面平台下使用 Wireshark，如果是 Linux 的话，直接使用 tcpdump 了，因为一般而言 Linux 都自带的 tcpdump，或者用 tcpdump 抓包以后用 Wireshark 打开分析。

在 Mac 平台下，Wireshark 通过 WinPcap 进行抓包，封装的很好，使用起来很方便，可以很容易的制定抓包过滤器或者显示过滤器，具体简单使用下面会介绍。Wireshark 是一个免费的工具，只要 google 一下就能很容易找到下载的地方。

所以，tcpdump 是用来抓取数据非常方便，Wireshark 则是用于分析抓取到的数据比较方便。

3 tcpdump 使用

3.1 语法

类型的关键字

host (缺省类型): 指明一台主机，如：host 210.27.48.2

net: 指明一个网络地址，如：net 202.0.0.0

port: 指明端口号，如：port 23

确定方向的关键字

src: src 210.27.48.2, IP 包源地址是 210.27.48.2

dst: dst net 202.0.0.0, 目标网络地址是 202.0.0.0

dst or src (缺省值)

dst and src

协议的关键字：缺省值是监听所有协议的信息包

fddi

ip

arp

rarp

tcp

udp

其他关键字

gateway

broadcast

less

greater

常用表达式：多条件时可以用括号，但是要用转义

非 : ! or “not” (去掉双引号)

且 : && or “and”

或 : || or “or”

3.2 选项

3.3 命令实践

1、直接启动 tcpdump，将抓取所有经过第一个网络接口上的数据包

2、抓取所有经过指定网络接口上的数据包

3、抓取所有经过 en0，目的或源地址是 10.37.63.255 的网络数据：

4、抓取主机 10.37.63.255 和主机 10.37.63.61 或 10.37.63.95 的通信：

5、抓取主机 192.168.13.210 除了和主机 10.37.63.61 之外所有主机通信的数据包：

6、抓取主机 10.37.63.255 除了和主机 10.37.63.61 之外所有主机通信的 ip 包

7、抓取主机 10.37.63.3 发送的所有数据：

8、抓取主机 10.37.63.3 接收的所有数据：

9、抓取主机 10.37.63.3 所有在 TCP 80 端口的数据包：

10、抓取 HTTP 主机 10.37.63.3 在 80 端口接收到的数据包：

11、抓取所有经过 en0，目的或源端口是 25 的网络数据

12、抓取所有经过 en0，网络是 192.168 上的数据包

13、协议过滤

14、抓取所有经过 en0，目的地址是 192.168.1.254 或 192.168.1.200 端口是 80 的 TCP 数据

15、抓取所有经过 en0，目标 MAC 地址是 00:01:02:03:04:05 的 ICMP 数据

16、抓取所有经过 en0，目的网络是 192.168，但目的主机不是 192.168.1.200 的 TCP 数据

17、只抓 SYN 包

18、抓 SYN, ACK

19、抓 SMTP 数据，抓取数据区开始为”MAIL” 的包，”MAIL” 的十六进制为 0x4d41494c

20、抓 HTTP GET 数据，”GET “的十六进制是 0x47455420

21、抓 SSH 返回，”SSH-“的十六进制是 0x5353482D

22、高级包头过滤如前两个的包头过滤，首先了解如何从包头过滤信息：

23、抓 DNS 请求数据

24、其他 - c 参数对于运维人员来说也比较常用，因为流量比较大的服务器，靠人工 CTRL+C 还是抓的太多，于是可以用 - c 参数指定抓多少个包。

3.4 抓个网站练练

想抓取访问某个网站时的网络数据。比如网站 http://www.baidu.com/ 怎么做？

1、通过 tcpdump 截获主机 www.baidu.com 发送与接收所有的数据包

2、访问这个网站

3、想要看到详细的 http 报文。怎么做？

4、分析抓取到的报文

4 tcpdump 抓取 TCP 包分析

TCP 传输控制协议是面向连接的可靠的传输层协议，在进行数据传输之前，需要在传输数据的两端（客户端和服务器端）创建一个连接，这个连接由一对插口地址唯一标识，即是在 IP 报文首部的源 IP 地址、目的 IP 地址，以及 TCP 数据报首部的源端口地址和目的端口地址。TCP 首部结构如下：

注意：通常情况下，一个正常的 TCP 连接，都会有三个阶段：1、TCP 三次握手；2、数据传送；3、TCP 四次挥手

其中在 TCP 连接和断开连接过程中的关键部分如下：

源端口号：即发送方的端口号，在 TCP 连接过程中，对于客户端，端口号往往由内核分配，无需进程指定；
目的端口号：即发送目的的端口号；
序号：即为发送的数据段首个字节的序号；
确认序号：在收到对方发来的数据报，发送确认时期待对方下一次发送的数据序号；
SYN：同步序列编号，Synchronize Sequence Numbers；
ACK：确认编号，Acknowledgement Number；
FIN：结束标志，FINish；

4.1 TCP 三次握手

三次握手的过程如下：

step1. 由客户端向服务器端发起 TCP 连接请求。Client 发送：同步序列编号 SYN 置为 1，发送序号 Seq 为一个随机数，这里假设为 X，确认序号 ACK 置为 0；

step2. 服务器端接收到连接请求。Server 响应：同步序列编号 SYN 置为 1，并将确认序号 ACK 置为 X+1，然后生成一个随机数 Y 作为发送序号 Seq（因为所确认的数据报的确认序号未初始化）；

step3. 客户端对接收到的确认进行确认。Client 发送：将确认序号 ACK 置为 Y+1，然后将发送序号 Seq 置为 X+1（即为接收到的数据报的确认序号）；

为什么是三次握手而不是两次对于 step3 的作用，假设一种情况，客户端 A 向服务器 B 发送一个连接请求数据报，然后这个数据报在网络中滞留导致其迟到了，虽然迟到了，但是服务器仍然会接收并发回一个确认数据报。但是 A 却因为久久收不到 B 的确认而将发送的请求连接置为失效，等到一段时间后，接到 B 发送过来的确认，A 认为自己现在没有发送连接，而 B 却一直以为连接成功了，于是一直在等待 A 的动作，而 A 将不会有任何的动作了。这会导致服务器资源白白浪费掉了，因此，两次握手是不行的，因此需要再加上一次，对 B 发过来的确认再进行一次确认，即确认这次连接是有效的，从而建立连接。
对于双方，发送序号的初始化为何值有的系统中是显式的初始化序号是 0，但是这种已知的初始化值是非常危险的，因为这会使得一些黑客钻漏洞，发送一些数据报来破坏连接。因此，初始化序号因为取随机数会更好一些，并且是越随机越安全。

tcpdump 抓 TCP 三次握手抓包分析

sudo tcpdump -n -S -i lo0 host 10.37.63.3 and tcp port 8080

接着再运行：

curl http: //10.37.63.3:8080/atbg/doc

控制台输出：

每一行中间都有这个包所携带的标志：

S=SYN，发起连接标志。

P=PUSH，传送数据标志。

F=FIN，关闭连接标志。

ack，表示确认包。

RST=RESET，异常关闭连接。

.，表示没有任何标志。

第 1 行：16:00:13.486776，从 10.37.63.3（client）的临时端口 61725 向 10.37.63.3（server）的 8080 监听端口发起连接，client 初始包序号 seq 为 1944916150，滑动窗口大小为 65535 字节（滑动窗口即 tcp 接收缓冲区的大小，用于 tcp 拥塞控制），mss 大小为 16344（即可接收的最大包长度，通常为 MTU 减 40 字节，IP 头和 TCP 头各 20 字节）。【seq=1944916150，ack=0，syn=1】

第 2 行：16:00:13.486850，server 响应连接，同时带上第一个包的 ack 信息，为 client 端的初始包序号 seq 加 1，即 1944916151，即 server 端下次等待接受这个包序号的包，用于 tcp 字节流的顺序控制。Server 端的初始包序号 seq 为 1119565918，mss 也是 16344。【seq=1119565918，ack=1944916151，syn=1】

第 3 行：15:46:13.084161，client 再次发送确认连接，tcp 连接三次握手完成，等待传输数据包。【ack=1119565919，seq=1944916151】

4.2 TCP 四次挥手

连接双方在完成数据传输之后就需要断开连接。由于 TCP 连接是属于全双工的，即连接双方可以在一条 TCP 连接上互相传输数据，因此在断开时存在一个半关闭状态，即有有一方失去发送数据的能力，却还能接收数据。因此，断开连接需要分为四次。主要过程如下：

step1. 主机 A 向主机 B 发起断开连接请求，之后主机 A 进入 FIN-WAIT-1 状态；

step2. 主机 B 收到主机 A 的请求后，向主机 A 发回确认，然后进入 CLOSE-WAIT 状态；

step3. 主机 A 收到 B 的确认之后，进入 FIN-WAIT-2 状态，此时便是半关闭状态，即主机 A 失去发送能力，但是主机 B 却还能向 A 发送数据，并且 A 可以接收数据。此时主机 B 占主导位置了，如果需要继续关闭则需要主机 B 来操作了；

step4. 主机 B 向 A 发出断开连接请求，然后进入 LAST-ACK 状态；

step5. 主机 A 接收到请求后发送确认，进入 TIME-WAIT 状态，等待 2MSL 之后进入 CLOSED 状态，而主机 B 则在接受到确认后进入 CLOSED 状态；

为何主机 A 在发送了最后的确认后没有进入 CLOSED 状态，反而进入了一个等待 2MSL 的 TIME-WAIT 主要作用有两个：

第一，确保主机 A 最后发送的确认能够到达主机 B。如果处于 LAST-ACK 状态的主机 B 一直收不到来自主机 A 的确认，它会重传断开连接请求，然后主机 A 就可以有足够的时间去再次发送确认。但是这也只能尽最大力量来确保能够正常断开，如果主机 A 的确认总是在网络中滞留失效，从而超过了 2MSL，最后也无法正常断开；

第二，如果主机 A 在发送了确认之后立即进入 CLOSED 状态。假设之后主机 A 再次向主机 B 发送一条连接请求，而这条连接请求比之前的确认报文更早地到达主机 B，则会使得主机 B 以为这条连接请求是在旧的连接中 A 发出的报文，并不看成是一条新的连接请求了，即使得这个连接请求失效了，增加 2MSL 的时间可以使得这个失效的连接请求报文作废，这样才不影响下次新的连接请求中出现失效的连接请求。

为什么断开连接请求报文只有三个，而不是四个因为在 TCP 连接过程中，确认的发送有一个延时（即经受延时的确认），一端在发送确认的时候将等待一段时间，如果自己在这段事件内也有数据要发送，就跟确认一起发送，如果没有，则确认单独发送。而我们的抓包实验中，由服务器端先断开连接，之后客户端在确认的延迟时间内，也有请求断开连接需要发送，于是就与上次确认一起发送，因此就只有三个数据报了。

5 Wireshark 分析 tcpdump 抓包结果

1、启动 8080 端口，tcpdump 抓包命令如下：

tcpdump -i lo0 -s 0 -n -S host 10.37.63.3 and port 8080 -w ./Desktop/tcpdump_10.37.63.3_8080_20160525.cap

# 然后再执行 curl

curl http: //10.37.63.3:8080/atbg/doc

2、使用 Wireshark 打开 tcpdump_10.37.63.3_8080_20160525.cap 文件

No. 1-4 行：TCP 三次握手环节；

No. 5-8 行：TCP 传输数据环节；

No. 9-13 行：TCP 四次挥手环节；

3、顺便说一个查看 http 请求和响应的方法：

弹窗如下图所示，上面红色部分为请求信息，下面蓝色部分为响应信息：

以上是 Wireshark 分析 tcpdump 的简单使用，Wireshark 更强大的是过滤器工具，大家可以自行去多研究学习 Wireshark，用起来还是比较爽的。

via:

聊聊 tcpdump 与 Wireshark 抓包分析 Linux 爱好者 2016 年 05 月 27 日 18:21

https://mp.weixin.qq.com/s/lVU_V2Kseec0nqdHa9c9ug

Wireshark 和 TcpDump 抓包分析心得

文 / 勇往直前的胖子

1. Wireshark 与 tcpdump 介绍

Wireshark 是一个网络协议检测工具，支持 Windows 平台和 Unix 平台，我一般只在 Windows 平台下使用 Wireshark ，如果是 Linux 的话，我直接用 tcpdump 了，因为我工作环境中的 Linux 一般只有字符界面，且一般而言 Linux 都自带的 tcpdump ，或者用 tcpdump 抓包以后用 Wireshark 打开分析。

在 Windows 平台下， Wireshark 通过 WinPcap 进行抓包，封装的很好，使用起来很方便，可以很容易的制定抓包过滤器或者显示过滤器，具体在下面介绍。 Wireshark 是一个免费的工具，只要 google 一下就能很容易找到下载的地方。

tcpdump 是基于 Unix 系统的命令行式的数据包嗅探工具。如果要使用 tcpdump 抓取其他主机 MAC 地址的数据包，必须开启网卡混杂模式，所谓混杂模式，用最简单的语言就是让网卡抓取任何经过它的数据包，不管这个数据包是不是发给它或者是它发出的，点击【 http://en.wikipedia.org/wiki/Promiscuous_mode 】获取更多有关混杂模式的资料。一般而言， Unix 不会让普通用户设置混杂模式，因为这样可以看到别人的信息，比如 telnet 的用户名和密码，这样会引起一些安全上的问题，所以只有 root 用户可以开启混杂模式，开启混杂模式的命令是： ifconfig eth0 promisc, eth0 是你要打开混杂模式的网卡。肯定有人要问如果在 windows 下要不要打开混杂模式， windows 下网卡没有什么混杂模式不混杂模式，在于应用程序本身，如使用 Wireshark 抓包的时候可以通过设置为在混杂模式下抓包（这就是为什么该死的 ARP 欺骗病毒可以猖狂的原因）。 tcpdump 当然也可以指定抓包过滤器，而且其过滤器语言非常著名，叫做 Berkeley 包过滤，简称 BPF 语言。

2. 简单的例子

我们通过访问 www.google.com.hk 这个网址来看看抓包结果。

2.1 tcpdump

前面说过一般情况下 Linux 都自带了 tcpdump ，但是如果发生了小概率事件，发现没有 tcpdump 的话，可以到 http://www.tcpdump.org 下载源代码，编译安装。
使用 root 用户登录，运行 tcpdump 命令就可以开始抓包。这里说明一下，如果使用 SSH 登录到远程 Linux ，然后直接运行 tcpdump ，会发现抓到大量的数据包，速度快的都看不清楚，这是因为 tcpdump 抓到的包发送给远程的终端显示，同时又抓了这个包，再显示，再抓取，造成了循环抓取。当然，这样抓包没有任何意义，除了证明你的网络是通的。
因为没有打开网卡的混杂模式，所以如果本机没有任何进程访问网络，是抓不到包的，如果在字符界面下，用 wget http://www.google.com.hk 访问网址，如果有 GUI ，可以打开 firefox 浏览器访问 http://www.google.com.hk 。
默认情况下， tcpdump 会选择第一块网卡，也就是 eth0 ，进行抓包，每行显示一个抓取的数据包，如：

0.003183 192.168.21.137 72.14.203.147 TCP 38039 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=36941509 TSER=0 WS=6

0.011707 72.14.203.147 192.168.21.137 TCP http > 38039 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460

0.011770 192.168.21.137 72.14.203.147 TCP 38039 > http [ACK] Seq=1 Ack=1 Win=5840 Len=0

以上三个数据包就是著名的 TCP 三次握手的数据包，其中 38039 是客户端的 TCP 端口， http 的默认端口是 80 ，如果 tcpdump 在 /etc/services 中发现端口对应的服务名称，那么会自动的转为名字，所以这里会显示为 http 。表示客户端的 38039 端口和服务器端的 http 端口进行 TCP 三次握手。
前面提到 tcpdump 默认选择第一块网卡进行抓包，我们可以使用 -i 参数指定通过哪一个网卡抓包，如（ # 表示我输入的命令， Linux 下 root 用户的提示符就是 # ）：

\# tcpdump –i eth1

或者

\#tcpdump –i any

如果想知道我们可以通过哪几个网卡抓包，可以使用 -D 参数，如：

\# tcpdump –D

1.eth0

2.any

3.lo

因为我的机器上只有一个网卡，因此只有 eth0 ，如果有多块网卡活动的话，会有 eth1 ， eth2 依次下去。 any 的意思是通过任意一块网卡进行抓包， lo 是回环接口。（关于 TCP 三次握手和回环接口等网络问题，请参考《 TCP/IP 协议详解》）。
默认情况下， tcpdump 抓包结果显示在屏幕（严格点，专业点应该说是标准输出）上，显然这不利于进一步的数据分析，因此我们需要将抓包结果存放在文件中。可是使用 -w 命令将结果保存在文件中，如：

\# tcpdump –w google.cap

这句命令将抓包结果存放在 google.cap 文件中，结束以后可以用 Wireshark 打开查看。同事， tcpdump 出了抓包，还可以使用 -r 参数制定抓包数据文件，结合过滤器对抓包数据分析，如：

\# tcpdump –r google.cap http

这句命令的意思是让 tcpdump 读取 google.cap 文件，把其中 http 协议的数据包都给过滤出来。关于过滤器在下面详细介绍。

2.2 Wireshark

我在 windows 系统中使用 Wireshark 的，首先熟悉一下界面，图 1 是使用 Wireshark 打开 google.cap 文件的界面，
图 1 Wireshark 界面
图 1 中标注出三快区域， R1 区域用来显示简单的数据包信息，我们用 tcpdump 抓包的时候，默认情况下也是显示成这样的； R2 区域用来显示选中的数据包的详细信息，细心一点会发现他是按照 TCP/IP 四层结构显示的，第一行是数据链路层的信息，第二行是网络层信息（ IP 协议），第三行是传输层信息（ TCP 协议），第四行是应用层信息（ HTTP 协议），可以展开每一行用来观察具体的内容； R3 区域是用来显示此数据包的真实面目。我们在 R1 和 R2 区域看到的信息都是 Wireshark 整理以后给我们看的，抓包的真实数据实际上是一堆二进制序列，用 ultraedit 打开 google.cap 文件可以看到就是一些数字，如图 2 所示。

在这里插入图片描述

图 2 抓包文件长的样子
使用 Wireshark 抓包非常容易，直接点击按钮（工具栏第三个按钮）、（工具栏第一个按钮）就开始抓包了，会发现只要一点击这个按钮，立刻就显示抓到包了，这是因为 Wireshark 默认在混杂模式下抓包，只要经过网卡的数据包都抓取下来（当然这台机器要连在网络中，如果没有数据流过当然没有包可抓），点击按钮停止此次抓包。
如果机器上安装了多块网卡， Wireshark 默认选择第一张网卡抓包，如果等抓包完成了，这是发现选错了网卡是一件极度郁闷的事情。点击按钮可以在抓包之前选择抓哪张网卡。

在这里插入图片描述

图 3 选择网卡
我机器上只有一张网卡，另外两个是安装 Vmware 时的虚拟网卡，可以看到虽然 Packets 上面已经有数据了，实际上需要点击 Start 才开始抓包。
解决了选择网卡的问题以后，考虑如果过滤抓包内容，点击菜单栏上的 ” Capture” > “Options” 可以看到制定抓包规则的界面，如图 4 所示。

在这里插入图片描述

图 4 制定抓包规则
图 4 可以看到 Caputre packets in promiscuous mode ，默认是选中的，表示 Wireshark 默认在混杂模式下抓包。同样可以选择通过哪张网卡抓包，不过这些都不是重点，最重要的是 Caupture Fileter 这里，点击该按钮，可以看到弹出一些预定义好的过滤器。比如选择 “ HTTP TCP port (80) ”，下面 Filter string: tcp port http 就是过滤器的表示。表示抓 tcp 协议的，端口为 80 的数据包（ http 协议的默认端口是 80 ）。

3. 过滤器（ BPF 语言）的使用

主要介绍一下在 tcpdump 中的过滤器使用，因为懂了这个就可以得心应手的使用 wireshark 了。
从最简单的开始， BPF 语言主要有一个标志或者数字和限定词组成，限定词有三种：

第一种：指定类型

host, 定义抓取哪个 IP 地址（也可以给它 mac 地址，格式是 00:00:00:00:00:00 ）的数据包，比如我想抓有关 192.168.0.148 这个 IP 地址的数据包，那么就写成 tcpdump host 192.168.0.148, host 是限定词， 192.168.0.148 就是标志。这条命令会抓取从发出或者向 192.168.0.148 发送的数据包。

net, 定义抓取某个网络的数据包，给出网络号就行了，它根据给的网络号字节数是 1,2,3 来判断 A 类地址， B 类地址或者 C 类地址，比如 tcpdump net 10.1.1 ，它就认为这是一个 C 类地址。

port ，指定端口，比如 tcpdump host and port 22, 这是抓端口为 22 的数据包，不管是 TCP 还是 UDP 的，这里我稍微早一点的给出了逻辑操作， and J ，如果只想抓 TCP 的，那么可以写 tcpdump host 192.168.0.148 and tcp port 22 。

portrange ，顾名思义，这个是指定端口范围的，用连字符 ”-” 指定范围，比如 tcpdump port 1025-8080

第二种：指定方向

我们之前的命令都是说 “这条命令会抓取从 192.168.0.148 发出或者向 192.168.0.148 发送”，所以，如果指向抓从发出的数据包可以使用限定词 src, 命令： tcpdump src host 192.168.0.148 ，反过来，想抓发向 192.168.0.148 的数据包，使用限定词 dst, 命令： tcpdump dst host 192.168.0.148 。

第三种：指定协议

我们知道网络协议有 N 种。。。我列一下常用的几种，其他的可以去 google 一下

ether 和 fddi, 以太网协议

tr, TR 协议

ip, IP 协议

ip6 ，IPv6 协议

arp, ARP 协议

好了，最后还需要注意的是逻辑运算， and, or, not （与，或，非），上面已经有一个例子了，这里就不再罗嗦了，和普通的编程语言没有什么不同。
除此之外，还有更加牛 X 的功能，比如指定 TCP 中的某个标识位是什么，这种应用我一般很少用，不再罗嗦了。

Linux tcpdump命令详解

posted on 2012-01-14 23:54 ggjucheng

简介

用简单的话来定义tcpdump，就是：dump the traffic on a network，根据使用者的定义对网络上的数据包进行截获的包分析工具。tcpdump可以将网络中传送的数据包的“头”完全截获下来提供分析。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息。

实用命令实例

默认启动

普通情况下，直接启动tcpdump将监视第一个网络接口上所有流过的数据包。

监视指定网络接口的数据包

如果不指定网卡，默认tcpdump只会监视第一个网络接口，一般是eth0。

监视指定主机的数据包

打印所有进入或离开sundown的数据包。也可以指定IP，例如截获所有210.27.48.1的主机收到的和发出的所有的数据包。

打印helios与hot或者与ace之间通信的数据包：

tcpdump host helios and \( hot or ace \)

截获主机210.27.48.1和主机210.27.48.2或210.27.48.3的通信：

tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \)

打印ace与任何其他主机之间通信的IP数据包，但不包括与helios之间的数据包：

tcpdump ip host ace and not helios

如果想要获取主机210.27.48.1除了和主机210.27.48.2之外所有主机通信的IP包，使用命令：

tcpdump ip host 210.27.48.1 and ! 210.27.48.2

截获主机hostname发送的所有数据：

tcpdump -i eth0 src host hostname

监视所有送到主机hostname的数据包：

tcpdump -i eth0 dst host hostname

监视指定主机和端口的数据包

如果想要获取主机210.27.48.1接收或发出的telnet包，使用如下命令：

tcpdump tcp port 23 and host 210.27.48.1

对本机的UDP 123端口进行监视（123为ntp的服务端口）。

监视指定网络的数据包

打印本地主机与Berkeley网络上的主机之间的所有通信数据包（nt: ucb-ether，此处可理解为'Berkeley网络’的网络地址，此表达式最原始的含义可表达为：打印网络地址为ucb-ether的所有数据包）。

打印所有通过网关snup的ftp数据包（注意，表达式被单引号括起来了，这可以防止shell对其中的括号进行错误解析）：

tcpdump 'gateway snup and (port ftp or ftp-data)'

打印所有源地址或目标地址是本地主机的IP数据包：

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)'

打印长度超过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 request'与'echo reply'这两种类型的ICMP数据包通常由ping程序产生）：

tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

tcpdump与Wireshark

Wireshark（以前是ethereal）是Windows下非常简单易用的抓包工具。但在Linux下很难找到一个好用的图形化抓包工具。还好有Tcpdump。我们可以用Tcpdump + Wireshark的完美组合实现：在Linux里抓包，然后在Windows里分析包。

tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

tcp：ip icmp arp rarp和tcp、udp、icmp这些选项等都要放到第一个参数的位置，用来过滤数据报的类型。
-i eth1：只抓经过接口eth1的包。
-t：不显示时间戳。
-s 0：抓取数据包时默认抓取长度为68字节。加上-S 0后可以抓到完整的数据包。
-c 100：只抓取100个数据包。
dst port ! 22：不抓取目标端口是22的数据包。
src net 192.168.1.0/24：数据包的源网络地址为192.168.1.0/24。
-w ./target.cap：保存成cap文件，方便用ethereal（即wireshark）分析。

使用tcpdump抓取HTTP包

tcpdump -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854

0x4745为"GET"前两个字母"GE"，0x4854为"HTTP"前两个字母"HT"。

tcpdump对截获的数据并没有进行彻底解码，数据包内的大部分内容是使用十六进制的形式直接打印输出的。显然这不利于分析网络故障，通常的解决办法是先使用带-w参数的tcpdump截获数据并保存到文件中，然后再使用其他程序（如Wireshark）进行解码分析。当然也应该定义过滤规则，以避免捕获的数据包填满整个硬盘。

输出信息含义

首先我们注意一下，基本上tcpdump总的输出格式为：系统时间来源主机.端口 > 目标主机.端口数据包参数。

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：从下文来看，第二行才是有捎带应答的数据包），可用的接受窗口的大小为4096字节，并且请求端（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控制标志的数据包如下：

连接发起方（Caller）发送SYN标志的数据包。
接收方（Recipient）用带有SYN和ACK标志的数据包进行回应。
发起方收到接收方回应后再发送带有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

这个表达式是说“让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

灵感随之而来，我们于是得到了如下的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 protocol（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的简称）。原来的对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，可理解为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选项除了显示文件数据信息，还会显示附加显示文件属性信息：文件类型（'REG'表示普通文件），文件存取模式（8进制表示的），uid和gid（nt：文件属主和组属主），文件大小。

如果-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（包顺序号）、serial number（可理解为与包中数据相关的另一个顺信号，具体含义需补充）、请求包的标识。（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可理解为特殊的通信协议，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，转储，通常就是指对其信息进行打印）。

（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收到这个请求后重新发送了这2个数据包，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，即可对该数据包进行操作）。而数据包从物理线路传递到内核的时间，以及内核花费在此包上的中断处理时间都没有算进来。

命令使用

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 ]
```
以下是部分选项的详细说明：

常用选项
- -A：以ASCII码方式显示每一个数据包（不会显示数据包中链路层头部信息）。在抓取包含网页数据的数据包时，可方便查看数据（nt：即Handy for capturing web pages）。
- -c count：tcpdump将在接收到count个数据包后退出。
- -C file-size：此选项用于配合-w file选项使用。当tcpdump把原始数据包直接保存到文件中时，会检查文件大小是否超过file-size。如果超过，将关闭当前文件并创建一个新文件继续保存数据包。新文件名与-w选项指定的文件名一致，但文件名后会多一个数字，该数字从1开始，随着新文件的创建而递增。file-size的单位是百万字节（nt：这里指1,000,000字节，而不是1,048,576字节）。
- -d：以容易阅读的形式，在标准输出上打印出编译后的包匹配码，随后tcpdump停止。（nt \| rt：human readable，容易阅读的，通常是指以ASCII码来打印一些信息。compiled，编译过的。packet-matching code，包匹配码，含义未知，需补充）。
- -dd：以C语言的形式打印出包匹配码。
- -ddd：以十进制数的形式打印出包匹配码（会在包匹配码之前有一个附加的'count'前缀）。
- -D：打印系统中所有tcpdump可以在其上进行抓包的网络接口。每个接口会打印出数字编号、相应的接口名字，以及可能的一个网络接口描述。网络接口名字和数字编号可以用在tcpdump的-i flag选项中，来指定在其上抓包的网络接口。此选项在不支持接口列表命令的系统（如Windows系统）上很有用；接口的数字编号在Windows 2000或其后的系统中很有用，因为这些系统上的接口名字比较复杂，不易使用。如果tcpdump编译时所依赖的libpcap库版本太老，-D选项将不被支持，因为其中缺乏pcap_findalldevs()函数。
- -e：每行的打印输出中将包括数据包的数据链路层头部信息。
- -E spi@ipaddr algo:secret,...：可通过spi@ipaddr algo:secret来解密IPsec ESP包（nt \| rt：IPsec，封装安全负载，IPsec可理解为，一整套对IP数据包的加密协议，ESP为整个IP数据包或其中上层协议部分被加密后的数据，前者的工作模式称为隧道模式；后者的工作模式称为传输模式。工作原理，另需补充）。需要注意的是，在终端启动tcpdump时，可以为IPv4 ESP packets设置密钥（secret）。可用于加密的算法包括des-cbc、3des-cbc、blowfish-cbc、rc5-cbc、cast128-cbc，或者没有（none）。默认的是des-cbc（nt：des，数据加密标准，加密算法未知，另需补充）。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地址），采用数字方式而不是名字（nt：此选项是用来对付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指定的文件装载SMI MIB模块（nt：SMI，结构化管理信息，MIB，管理信息库。可理解为，这两者用于SNMP（简单网络管理协议）协议数据包的抓取。具体SNMP的工作原理未知，另需补充）。此选项可多次使用，从而为tcpdump装载不同的MIB模块。
- -M secret：如果TCP数据包（TCP segments）有TCP-MD5选项（在RFC 2385中有相关描述），则为其摘要的验证指定一个公共的密钥secret。
- -n：不对地址（比如，主机地址，端口号）进行数字表示到名字表示的转换。
- -N：不打印出主机的域名部分。比如，如果设置了此选项，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：因特网控制报文协议）、TCP以及UDP协议的报文已足够，但对于名称服务（nt：可理解为dns、nis等服务）、NFS服务相关的数据包会产生包截短。如果产生包截短这种情况，tcpdump的相应打印输出行中会出现'[|proto]'的标志（proto实际会显示为被截短的数据包的相关协议层次）。需要注意的是，采用长的抓取长度（nt：snaplen比较大），会增加包的处理时间，并且会减少tcpdump可缓存的数据包的数量，从而会导致数据包的丢失。所以，在能抓取我们想要的包的前提下，抓取长度越小越好。把snaplen设置为0意味着让tcpdump自动选择合适的长度来抓取数据包。
- -T type：强制tcpdump按type指定的协议所描述的包结构来分析收到的数据包。目前已知的type可取的协议为：
  - aodv（nt：按需距离向量路由协议，在Ad hoc（点对点模式）网络中使用），
  - cnfp（Cisco NetFlow protocol），
  - rpc（远程过程调用），
  - rtp（实时应用协议），
  - rtcp（实时应用控制协议），
  - snmp（简单网络管理协议），
  - tftp（简单文件传输协议，碎文件协议），
  - vat（可视音频工具，可用于在internet上进行电视电话会议的应用层协议），
  - wb（分布式白板，可用于网络会议的应用层协议）。
- -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更详细的输出。比如，telnet时所使用的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的取值未知，需补充）。
tcpdump条件表达式

该表达式用于决定哪些数据包将被打印。如果不给定条件表达式，网络上所有被捕获的包都会被打印，否则，只有满足条件表达式的数据包被打印。（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 or dst、src and 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 or dst。
- proto：描述id所属的协议。可选的协议有：ether、fddi、tr、wlan、ip、ip6、arp、rarp、decnet、tcp以及udp。（nt | rt：ether，fddi，tr，具体含义未知，需补充。可理解为物理以太网传输协议，光纤分布数据网传输协议，以及用于路由跟踪的协议。wlan，无线局域网协议；ip，ip6即通常的TCP/IP协议栈中所使用的ipv4以及ipv6网络层协议；arp，rarp即地址解析协议，反向地址解析协议；decnet，Digital Equipment Corporation开发的，最早用于PDP-11机器互联的网络协议；tcp和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无线局域网）的头部。对于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/services文件中找到））。

为了表示方便，相同的修饰符可以被省略，例如：
```
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））。

借助括号以及相应操作符，可把表达元组合在一起使用（由于括号是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或ace都符合要求）。

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

附录：tcpdump的表达元

（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或ip6/udp协议）的目的端口为port，则与此对应的条件表达式为真。port可以是一个数字也可以是一个名字（相应名字可以在/etc/services中找到该名字，也可以通过man tcp和man udp来得到相关描述信息）。如果使用名字，则该名字对应的端口号和相应使用的协议都会被检查。如果只是使用一个数字端口号，则只有相应端口号被检查（nt \| rt：ambiguous name is used不可理解，需补充）。
- src port port：如果数据包的源端口为port，则与此对应的条件表达式为真。
- port port：如果数据包的源或目的端口为port，则与此对应的条件表达式为真。
- dst portrange port1-port2：如果数据包（包括ip/tcp、ip/udp、ip6/tcp或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：内部网关路由协议）、pim（nt：独立组播协议，应用于组播路由器）、ah、esp（nt：ah，认证头，esp安全负载封装，这两者会用在IP包的安全传输机制中）、vrrp（nt：虚拟路由器冗余协议）、udp，或者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头之间可能还会包含验证头、路由头，或者逐跳寻径选项头。
- 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，子网接入协议）。以下例外：
    - iso：tcpdump会检查LLC头部中的DSAP域（Destination service Access Point，目标服务接入点）和SSAP域（Source service Access Point，源服务接入点）。
    - 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、netbeui：tcpdump将会检查802.3物理帧以及LLC头（这两种检查与FDDI、TR、802.11网络中的相应检查一致）；（nt：802.3，可理解为IEEE 802.3，其为一系列IEEE标准的集合。此集合定义了有线以太网络中的物理层以及数据链路层的媒体接入控制子层。LLC层为使用数据链路层的用户提供了一个统一的接口（通常用户是网络层）。LLC层以下是媒体接入控制层（nt：MAC层，对应于数据链路层的下层部分）。该层的实现以及工作方式会根据不同物理传输媒介的不同而有所区别（比如，以太网、令牌环网、光纤分布数据接口（nt：实际上可理解为一种光纤网络）、无线局域网（802.11）等等）。
    - 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帧，可理解为，LLC头部中的'SNAP格式结构’。该含义属初步理解阶段，需补充）。
    - decnet：tcpdump会检查LLC头部的SSAP和DSAP字段。
- 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 和 MPLS
- 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：表示过滤封装在VLAN 100中的VLAN 200网络上的数据包。
    - vlan && vlan 300 && ip：表示过滤封装在VLAN 300网络中的IPv4数据包，而VLAN 300网络又被更外层的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，且拥有一个外层标签。
PPPoE
- 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 或 ip6 proto p（其中p是以上协议之一，nt：如果数据包为ipv4或ipv6数据包并且其协议类型为tcp、udp、或icmp则与此对应的条件表达式为真）
- iso proto protocol：如果数据包的协议类型为iso-osi协议栈中protocol协议，则与此对应的条件表达式为真。（nt：[初解]iso-osi网络模型中每层的具体协议与tcp/ip相应层采用的协议不同。iso-osi各层中的具体协议另需补充）
  - protocol可以是一个数字编号，或以下名字中之一：
    - clnp（Connectionless Network Protocol，这是OSI网络模型中网络层协议）
    - esis
    - isis （nt：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的类型，具体含义另需补充）
ATM 相关
- 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））。
- 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和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：将会抓取所有多点广播数据包。（nt：ether[0]字节的最低位为1表示数据包目的地址是多点广播地址）
  - ip[0] & 0xf != 5：对应抓取所有带有选项的IPv4数据包。
  - ip[6:2] & 0x1fff = 0：对应抓取没被破碎的IPv4数据包或者其片段编号为0的已破碎的IPv4数据包。（nt：这种数据检查方式也适用于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

via:

Wireshark 和 TcpDump 抓包分析心得_用 wireshark 分析 tcp 协议特性心得体会 300 字 - CSDN 博客 勇往直前的胖子于 2010-12-14 20:19:00 发布
https://blog.csdn.net/zrzlj/article/details/6076219
Linux tcpdump 命令详解 - ggjucheng - 博客园 posted on 2012-01-14 23:54 ggjucheng
https://www.cnblogs.com/ggjucheng/archive/2012/01/14/2322659.html