前言

来自于 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 = \Device\NPF_{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 TimeIRTT即该 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 INCORRECTNo.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 。