前言
来自于 Sharkfest Packet Challenge 中的一个数据包案例，Sharkfest 是 Wireshark 官方组织的一年一度的大会，致力于在 Wireshark 开发人员和用户社区之间分享知识、经验和最佳实践。印象中早期是一年一次，近几年发展成一年两次，一次貌似固定在美国，一次会在其他地区，像是欧洲或亚洲。Packet Challenge 是大会其中一个比较有意思的活动环节，通过一系列数据包案例设置关卡，参会人员进行分析挑战，测试综合分析能力。
题目信息
本次案例为 Sharkfest 2015 Packet Challenge 中的第四个题目 WHATS UP? ，数据包跟踪文件为 whatsup.pcapng 。
主要描述如下：
- Why did a device send an ICMP Type 3/Code 4 packet in this trace file?
- What was the MTU size before the drop in size?
- What is the IP address of the router that can’t forward larger sized frames?
- What is the IP address of the host that adjusted its MTU?
- How many more frames would be required to send a 6,000‐byte file using the smaller MTU size than using the larger MTU size?
数据包信息
数据包跟踪文件基本信息如下：
λ capinfos whatsup.pcapng
File name: whatsup.pcapng
File type: Wireshark/... - pcapng
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: (not set)
Number of packets: 52
File size: 34 kB
Data size: 32 kB
Capture duration: 65.134372 seconds
First packet time: 2014-08-21 11:14:34.045564
Last packet time: 2014-08-21 11:15:39.179936
Data byte rate: 498 bytes/s
Data bit rate: 3989 bits/s
Average packet size: 624.65 bytes
Average packet rate: 0 packets/s
SHA256: f977684e55b4bd48479781547c4e510cb89367785917a4d94c743e93193fff2e
RIPEMD160: fa09efc58691773c2636bbd4d0f844a4f8eb8834
SHA1: d91aa2ab506b07ddb4653728c28983e2e996635c
Strict time order: True
Capture oper-sys: 64-bit Windows 8, build 9200
Capture application: Dumpcap 1.10.9 (v1.10.9-0-g6b041ab from master-1.10)
Number of interfaces in file: 1
Interface #0 info:
Name = \Device\NPF_{BD0C1124-CBA7-41BB-95BA-DB895B9631F2}
Encapsulation = Ethernet (1 - ether)
Capture length = 262144
Time precision = microseconds (6)
Time ticks per second = 1000000
Time resolution = 0x06
Operating system = 64-bit Windows 8, build 9200
Number of stat entries = 1
Number of packets = 52
Number of resolved IPv4 addresses in file: 1
λ
Winows 8 系统上直接通过 Wireshark 捕获，无截断，文件大小 34 KB，捕获数据包数量 52 个，捕获持续时间为 65.13 秒，平均速率 3989 bps。
会话信息统计如下，仅有一条 TCP 流。
专家信息显示如下，数据包总数量较少的情况下，Warning 数据包出现相对算是较多了，包括乱序、未捕获分段、D-SACK 等等。
数据包分析
数据包跟踪文件初步展开信息如下，Packet List 最右侧会有明显的黑红色告警信息的提示。
1. Why did a device send an ICMP Type 3/Code 4 packet in this trace file?
在这个跟踪文件中，为什么一个设备会发送一个 ICMP Type 3/Code 4 的数据包？
分析步骤
首先回顾一下 ICMP 数据包，Type 3/Code 4 描述如下
| TYPE | CODE | Description | Error |
|---|---|---|---|
| 3 | 4 | Fragmentation needed but no frag. bit set—需要进行分片但设置不分片比特 | x |
上述信息实际上已经描述的很清楚，因为该设备在转发数据包时，发现出向端口由于 MTU 相对小需要对数据包进行分片，但又由于该数据包标识有不分片设置，所以丢弃数据包的同时会通过 ICMP 发送一个 Type 3/Code 4 的消息给源端。
通过过滤后可知 No.19 为 ICMP Type 3/Code 4 的数据包，标识有目的地不可达(需要分片)的信息，并提示下一跳 MTU 为 1480。
原始数据包是哪个？展开 No.19 数据包细节如下，可简单通过 IP.ID 去找原数据包。
过滤对比可知，原始数据包为 No.18，MTU 为 1492 ，大于 1480 ，且由于 DF 置 1 的原因，不能分片。
分析答案
在这个跟踪文件中，为什么一个设备会发送一个 ICMP Type 3/Code 4 的数据包？：No.18 数据包由于 MTU 原因需要分片，但不允许分片。
2. What was the MTU size before the drop in size?
在数据包大小调小之前 MTU 大小是什么。
分析步骤
MTU 和 MSS 一直是网络协议数据包分析中一个比较有意思的话题，问题 2 也比较有意思，问的是数据包大小调小之前，基于 1 题的分析，可认为是 No.18 之前的 MTU。
从 TCP 三次握手可知，客户端和服务器本地的 MTU 都是 1500（1460 + 20 IP 首部 + 20 TCP 首部），而中间路径中服务器 -> 客户端传输方向的 MTU 也为 1500（1514-14 Ethernet 首部）。
分析答案
在数据包大小调小之前 MTU 大小是：1500。
3. What is the IP address of the router that can’t forward larger sized frames?
不能转发更大的帧的路由器的 IP 地址是什么?
分析步骤
实际上在题 1 中的分析中，已经标有该答案
稍微有点问题的地方是，该 IP 和原始数据包的目的 IP 均是同一个，疑似匿名化数据包该 IP 时弄错了。。。
分析答案
不能转发更大的帧的路由器的IP地址是：108.160.172.65。
4. What is the IP address of the host that adjusted its MTU?
调整 MTU 的主机的 IP 地址是什么？
分析步骤
在客户端收到 No.19 的 ICMP 消息之后，客户端 No.20 数据包中调整了 MTU 的大小，改为 1480（1494 - 14 Ethernet 首部 ）
分析答案
调整 MTU 的主机的 IP 地址是：192.168.1.71。
5. How many more frames would be required to send a 6,000‐byte file using the smaller MTU size than using the larger MTU size?
使用较小的 MTU 比使用较大的 MTU 发送 6000 字节的文件需要多多少数据帧?
分析步骤
较大 MTU 1500，MSS 1460，6000 字节文件大小的数据帧会分为 5 个（4 个 1460 字节+ 1 个 160 字节）
较小 MTU 1480，MSS 1440，6000 字节文件大小的数据帧会分为 5 个（4 个 1440 字节+ 1 个 240 字节）
所以从数据帧数量来说，并没有变化。
分析答案
使用较小的 MTU 比使用较大的 MTU 发送 6000 字节的文件需要多多少数据帧：0 个。
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
