前言

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

题目信息

本次案例为 Sharkfest 2015 Packet Challenge 中的第三个题目 FTP ME, BABY（🙄 这名字真的是可以），数据包跟踪文件为 tcp-bigftp.pcapng 。

主要描述如下：

1. What TCP options are supported by both client and server in this trace file?
2. What Window Size(s) are advertised in each Window Update packet?
3. What operating system must be supported to use the downloaded file?
4. How much is the largest delay preceding a Window Update packet?
5. Why does Wireshark indicate the Window Scaling factor is ‐1 in some of the packets?

数据包信息

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

λ capinfos tcp-bigftp.pcapng
File name:           tcp-bigftp.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   6120
File size:           11 MB
Data size:           11 MB
Capture duration:    24.668708 seconds
First packet time:   2012-08-02 03:38:39.142142
Last packet time:    2012-08-02 03:39:03.810850
Data byte rate:      468 kBps
Data bit rate:       3748 kbps
Average packet size: 1888.69 bytes
Average packet rate: 248 packets/s
SHA256:              bfb28f553bea551a2023825ed6ec1aa2bb57a8893111c8baa804d2ee0a1b3929
RIPEMD160:           af787ba3f0cf4f933e35fba11b82276c482a1892
SHA1:                c416ef5f71076c7dc1dad7d5f4978d37b2ee41c6
Strict time order:   True
Capture oper-sys:    64-bit Windows 7 Service Pack 1, build 7601
Capture application: Dumpcap 1.8.1 (SVN Rev 43946 from /trunk-1.8)
Number of interfaces in file: 1
Interface #0 info:
                     Name = \Device\NPF_{6E79FEC0-FF79-4970-96E4-EEFF300A9B9F}
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 65535
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Time resolution = 0x06
                     Operating system = 64-bit Windows 7 Service Pack 1, build 7601
                     Number of stat entries = 1
                     Number of packets = 6120

λ

Winows 7 系统上直接通过 Wireshark 捕获，无截断，文件大小 11MB，捕获数据包数量 6120 个，捕获持续时间为 24.67秒，平均速率 3748 kbps。

协议分层信息统计如下，FTP 控制连接和数据连接等信息。

专家信息显示如下，异常简洁，并且无 Warning 级别信息，只有较多数量的 TCP window update 消息。

数据包分析

数据包跟踪文件初步展开信息如下，实际 TCP Stream 2 条，一条为 FTP 控制连接，一条为 FTP 数据连接。

λ tshark -r tcp-bigftp.pcapng -T fields -e tcp.stream | sort -n | uniq
0
1

1. What TCP options are supported by both client and server in this trace file?

在这个跟踪文件中，客户端和服务器均支持的 TCP options 是什么？

分析步骤

说到 TCP options ，又想起 TCP 首部报文格式图了，经典~ 可以看到 TCP options 是一个可变长度的可选字段。

一般客户端和服务器之间的 TCP 交互以 TCP 三次握手开始，之间所共同支持的 TCP options 也在此阶段进行协商。通过显示过滤表达式过滤出 SYN 和 SYN/ACK 即可

tcp.flags.syn == 1

客户端 No.8 和服务器 No.9 TCP options 细节信息，可见共同支持的有 MSS, Window Scale, SACK, TCP Timestamps 。

分析答案

在这个跟踪文件中，客户端和服务器均支持的 TCP options 是：MSS, Window Scaling, SACK, TCP Timestamps。

2. What Window Size(s) are advertised in each Window Update packet?

在每一个 Window 更新数据包中所通告的 Window Size 是什么。

分析步骤

首先注意的是指定的数据包类别，它是 Window Update packet，这样先通过显示过滤式筛选，共有 245 个数据包，占比 4.0%。

tcp.analysis.window_update

其次 Window Size 来自于通告 Window 和 Window size scaling facotor（也是 1 中 TCP Options ，客户端和服务器共同支持的结果）的乘积，即 33304 * 2 = 66608 。

当然在 Packet List 视图中通过增加 Window size 信息列也可，全是 66608 。

分析答案

在每一个 Window 更新数据包中所通告的 Window Size 是：66608。

3. What operating system must be supported to use the downloaded file?

下载的文件必须支持什么操作系统?

分析步骤

首先分析在数据包跟踪文件中传输下载的是什么文件，通过控制连接可以看到客户端请求的是 kidsatbeach.jpg 文件。

问题中所描述的是下载，但实际 FTP 数据包中是上传，另外文件格式为 jpg，对于操作系统并没有多了解，必须支持什么操作系统？win 可以，linux 不行嘛？⁉️

分析答案

下载的文件必须支持什么操作系统：win。

答案暂且为 win 吧，也许是我的解题方向有问题。。。

4. How much is the largest delay preceding a Window Update packet?

在 Window 更新数据包之前的最大延迟是多少？

分析步骤

本题理解上同样会有点疑惑，以客户端某一个 Windows Update 数据帧为例 ，所说的之前延迟可能有几种：

1. 与上一个捕获数据帧的比较；
2. 与上一个显示数据帧的比较（基于TCP 流过滤）；
3. 与上一个同方向显示数据帧的比较（基于TCP 流过滤）。

本次解题以第 2 种思路分析，首先过滤出 TCP Stream 1 中所有的数据包，导出成一个新的 pcapng 文件。之后在新的 pcapng 文件中通过显示过滤表达式过滤出Windows Updata packet。

tcp.analysis.window_update

然后在 Packet List 视图中增加信息列，字段为 frame.time_delta ，如下，即为每一个 Window Update packet 与上一个捕获数据帧的时间差值。

此处是与上一个捕获数据帧的时间比较，是因为之前已经过滤出 TCP Stream 并另存为新文件，再经过 tcp.analysis.window_update 过滤出的结果。

通过从大到小排列，可知最大的延迟时间如下，为 0.006486 秒，No.6103 和 No.6102 的时间间隔。

分析答案

在 Window 更新数据包之前的最大延迟是：0.006486 秒。

5. Why does Wireshark indicate the Window Scaling factor is ‐1 in some of the packets?

为什么在某些数据包上 Wireshark 标识 Window Scaling Factor 值为 -1 ？

分析步骤

首先 Window Scaling Factor 为 TCP Options 中的一个字段，在 1 题中曾经说到一般客户端和服务器之间的 TCP 交互以 TCP 三次握手开始，之间所共同支持的 TCP options 也在此阶段进行协商。 而 Window Scaling Factor 的使用，有以下几种情况：

1. 客户端和服务器两端均支持的情况下，那么各自 SYN 或 SYN/ACK 所通告的 WS 值在后续数据交互时使用即可， Window size Scaling Factor 标识为该值；
2. 客户端和服务器，如有任意一端不支持或是两端都不支持的情况下， 那么在后续数据交互时使用时 Window size Scaling Factor 标识为 -2；
3. 还有一种特殊情况，在数据包跟踪文件中并没有捕获到 SYN 和 SYN/ACK 的情况下，也就是 Wireshark 无法判断是否使用了 Window Scaling Factor，那么会在后续数据交互时 Window size Scaling Factor 标识为 -1。

通过显示过滤表达式 tcp.window_size_scalefactor == -1 过滤出的结果，实际上都是 FTP 控制连接的数据包，因为在这一条 TCP Stream 0 下并没有捕获到 TCP 三次握手阶段的报文，所以 Window size Scaling Factor 标识为 -1。而 No.1 的 Window 16114 字节，因为 Window size Scaling Factor 未知，所以 Calculated window size 也为 16114 字节。

Window size Scaling Factor 值为 -1 只是 Wireshark 基于数据包跟踪文件上下文判断，未知实际 Factor 值的情况下标识为 -1，并不代表实际客户端和服务器的 TCP 连接不支持。

分析答案

为什么在某些数据包上 Wireshark 标识 Window Scaling Factor 值为 -1：因为未捕获到 TCP 三次握手 。