前言

来自于 Sharkfest Packet Challenge 中的一个数据包案例，Sharkfest 是 Wireshark 官方组织的一年一度的大会，致力于在 Wireshark 开发人员和用户社区之间分享知识、经验和最佳实践。印象中早期是一年一次，近几年发展成一年两次，一次貌似固定在美国，一次会在其他地区，像是欧洲或亚洲。Packet Challenge 是大会其中一个比较有意思的活动环节，通过一系列数据包案例设置关卡，参会人员进行分析挑战，测试综合分析能力。

题目信息

本次案例为 Sharkfest 2019 EU Packet Challenge 中的第三个题目 Do it Yourself，数据包跟踪文件为 DIY.pcapng 。

主要描述如下：

A developer programmed a microcontroller to send data via TCP. Something looks bad though…

1. What is the largest segment size that will work for both client and server?
2. Where was the capture taken (Client local/SPAN/TAP/Server local)?
3. What is the initial round trip time of the connection?
4. How many router hops are between client and server?
5. Why does the transmission of TCP data from 192.168.0.2 to 192.168.0.1 fail?

数据包信息

数据包跟踪文件基本信息如下：

λ capinfos DIY.pcapng
File name:           DIY.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   1210
File size:           1555 kB
Data size:           1499 kB
Capture duration:    4.495727 seconds
First packet time:   2017-03-27 19:02:12.959401
Last packet time:    2017-03-27 19:02:17.455128
Data byte rate:      333 kBps
Data bit rate:       2667 kbps
Average packet size: 1238.93 bytes
Average packet rate: 269 packets/s
SHA256:              4385a9ded3fdc9c7fa0c3015323ed6df10fb68e38dba07210ec0588bd65a5feb
RIPEMD160:           53562636f5037964e8b6a0bccb2cbf7648895e31
SHA1:                a0295d1e0ff87f0e4135f4bf1a87422ff562fc04
Strict time order:   True
Capture application: Sanitized by TraceWrangler v0.6.6 build 928
Number of interfaces in file: 1
Interface #0 info:
                     Name = DeviceNPF_{83DAFA6D-086A-4B8B-AA1D-562D69913D39}
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 262144
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Time resolution = 0x06
                     Operating system = 64-bit Windows 10, build 14393
                     Number of stat entries = 0
                     Number of packets = 1210

在 Win10 系统上通过 Wireshark 捕获，无截断，捕获数据包数量 1210 个，捕获持续时间为 4.49 秒，平均速率 2667 kbps ，并经过 TraceWrangler 匿名化工具编辑过。

关于 TraceWrangler 匿名化软件简介，可以查看之前的文章《Wireshark 提示和技巧 | 如何匿名化数据包》

会话信息显示如下，仅有一条 TCP 会话。

专家信息如下，可以看到有非常多数量的快速重传、重传以及 Dup ACK 信息，占比很高。

数据包分析

展开数据包文件信息，如下，可以看到确实有很多的重传信息，从 No.11 到最后 No.1210 全是如此。

1. What is the largest segment size that will work for both client and server?

对于客户端和服务器来说，最大的段大小是多少?

分析步骤

Segment 自然指的是 TCP Segment，可以通过增加 tcp.len 列，从大到小排序查看，该值也会体现在 Info 列 Len 值。

λ tshark -r DIY.pcapng -Y "tcp.len" -T fields -e tcp.len | sort -rn | uniq
1460
735
0

分析答案

对于客户端和服务器来说，最大的段大小是：1460 。

2. Where was the capture taken (Client local/SPAN/TAP/Server local)?

捕获是在哪里进行的(客户端本地/SPAN/TAP/服务器本地)?

分析步骤

在数据包列表上通过 Length 列中的信息可知答案，因为 54 字节小于以太网最小长度 60 字节的标准，所以判断数据包捕获是在客户端 192.168.0.1 上所进行。

因为 Wireshark 抓包位置如果是在本地，那么对于本地产生所发出的数据包，Wireshark 是在进网卡之前所抓取，而填充数据以及 FCS 一般是由网卡硬件/驱动程序完成，所以 54 字节的组成并不包含填充数据，即意味着本地抓取。

关于拿到一个数据包跟踪文件，如何判断捕获是在哪里，相关的技术文章可参考《Wireshark 提示和技巧 | 捕获点之 TCP 三次握手》。

分析答案

捕获是在哪里进行的(客户机本地/SPAN/TAP/服务器本地)?：客户端本地 。

3. What is the initial round trip time of the connection?

连接的初始往返时间(IRTT)是多少？

分析步骤

Initial Round Trip Time（IRTT），即该 TCP 流中起始 TCP 三次握手的时间。

当然这个 IRTT 值也会在这条 TCP 流中的绝大多数数据包中标识有。

λ tshark -r DIY.pcapng -Y "tcp.analysis.initial_rtt" -T fields -e tcp.analysis.initial_rtt | sort | uniq
0.001735000

分析答案

连接的初始往返时间(IRTT)是多少？：0.001735 秒。

4. How many router hops are between client and server?

客户端和服务器之间有多少路由跳数?

分析步骤

在网络中，数据包每过一个路由设备，TTL 值减 1 。在 2 题中确认了是在客户端本地所抓取的包，这样查看 No.2 SYN/ACK 数据包的 TTL 值即可。

λ tshark -r DIY.pcapng -Y "frame.number==2" -T fields -e ip.ttl
100

分析答案

客户端和服务器之间有多少路由跳数?：28 。

5. Why does the transmission of TCP data from 192.168.0.2 to 192.168.0.1 fail?

为什么从 192.168.0.2 到 192.168.0.1 的 TCP 数据传输失败?

分析步骤

从数据包跟踪文件的捕获点来说，这个问题可以说是为什么客户端 192.168.0.1 没有接受服务器端 192168.0.2 所发送的数据？

a. 现象
在 TCP 三次握手成功之后，No.4-No.10 服务器所发送的数据分段，客户端并没有接收，而是产生了一个 No.11 ACK 数据包仍请求服务器 Seq Num 1 的分段，之后服务器依次产生超时重传，但客户端仍未接受相应数据包，再之后不断循环该过程直至整个跟踪文件结束。

b. 可能原因
TCP CHECKSUM INCORRECT
问题比较诡异，可能是 No.4-No.10 数据分段有问题，尝试打开 TCP 协议中 Validate the TCP checksum if possible 选项，会发现出现了大量 TCP CHECKSUM INCORRECT 告警信息。

• 客户端 TCP CHECKSUM INCORRECT，首先客户端 TCP checksum 并不是问题。这是因为数据包是在客户端本地捕获，由于是网卡 CheckSum Offload 功能执行TCP/UDP/IP 校验和工作，所以 Wireshark 捕获时的客户端数据包的 TCP 校验和是随机填充的，因此校验和会提示不正确；
• 服务器端 TCP CHECKSUM INCORRECT，No.4 - No.9 数据分段校验和不正确，因此客户端协议栈未正常接收，而 No.10 数据分段校验和正常，客户端协议栈正常接收，但由于与期望 Seq Num 不一致，所以触发 No.11 客户端 DUP ACK。

以上为 TCP CHECKSUM INCORRECT 疑似原因的解释，符合数据包现象，但该答案并不一定准确，主要是该题目提供的信息很少，不能完全确认校验和问题是否是匿名化软件编辑数据包引发的额外不相关的问题（所有检验和都仅相差 1，譬如 No.4 校验和 0x07f5 不正确，0x07f4 正确）。

关于数据包 TCP Checksum ，相关的技术文章也可参考《Wireshark 提示和技巧 | 捕获点之 TCP 三次握手》。

IPTABLES
iptables 也有可能是导致该问题现象的原因。譬如匹配报文特定长度，阻断了 No.4 - No.9 数据分段（TCP Length 1460 字节），而接收了 No.10 数据分段（TCP Length 735 字节），进而触发 TCP DUP ACK，此后不断循环上述过程。

分析答案

为什么从 192.168.0.2 到 192.168.0.1 的 TCP 数据传输失败?：TCP 校验和或者 IPTABLES 。