Wireshark TS | Padding 和 Trailer 有啥关系

背景

惯例先说下背景，最起先是来自于一个 ARP 数据包分析，单说起 ARP 数据包组成是比较简单，但如下图所示，还是有些 Wireshark 技术点可以琢磨下，像是 Padding 和 Trailer 区别、相应的字节数大小、FCS 问题等等。

前期也查询过很多资料或是网上咨询，但一直还是有些疑问，刚好最近和 NPM 厂商的兄弟相互讨论了下，感觉对此又有了更深的理解。

分析

先从最简单的 ARP 数据包说起，以前的文章提到过：

14 字节 ( Ethernet II 首部长度 ) + 46 字节 ( 数据字段最小长度要求 ) + 4 字节 ( FCS ) = 64 字节
28 字节 ( ARP 请求或应答 ) + 18 字节 (Padding 填充数据 ) = 46 字节

因此 Padding 数据部分为 18 字节长度，如下图所示。

回到问题图：

因含有 802.1Q 字段的缘故，判断数据包取自 trunk 端口，而 802.1Q 字段为 4 字节长度，考虑到以太网帧 60 字节最小长度，Wireshark 解析会认为全 0 连续填充 (Padding) 的长度只需要 14 字节即可达到 18 字节的需求，即：

14 字节 ( Ethernet II 首部长度 ) + 28 字节 ( ARP 请求或应答 ) + 4 字节（ 802.1Q ）+ 14 字节 (Padding 填充数据 ) = 60 字节

而额外多出的数据标记成 Trailer（4字节）。

原理

在 wireshark_dissector_packet-eth.c 中部分说明如下：

• padding to meet the minimum 64 byte frame length.
• Add an Ethernet trailer - which, for some captures, might be the FCS rather than a pad-to-60-bytes trailer.
• Add the padding to the tree, unless it should be treated as part of the trailer and therefor be handed over to (one of) the ethernet-trailer dissectors.
• There can not have been padding when the length of the frame (including the trailer) is less than 60 bytes.
• any frame that big needs no trailer, as there’s no need to pad an Ethernet packet past 60 bytes.
• Calculate the amount of padding needed for a minimum sized frame.

可以认为 Trailer 是包含 Padding 的，什么时候解析成 Padding ？一般是当数据帧长度小于 60 字节，需要进行全 0 填充以达到 60 字节最小长度时的部分会被认为是 Padding。
而额外多出的部分，需结合 FCS （4字节）判断有无的情况下，确认是否属于 Trailer。再加上 Wireshark 强大的协议解析能力（ethernet-trailer dissectors），再确认属于哪一种 Trailer.

• Call all ethernet trailer dissectors to dissect the trailer if we actually have a trailer.
• No luck with the trailer dissectors, so just display the extra bytes as general trailer

Wireshark 解析器协议 Ethernet 部分，其中有三个相关选项：

1. Assume padding for short frames with trailer（ Never、Zeros、Any）

Never 选项是不考虑探测任何 Padding，在以太网 payload 之后的任何字节都被视为 Trailer。
Zeros (默认) 选项是为以太网帧最小长度连续填充全 0 字节的部分被视做 Padding，之外增加的部分被视为 Trailer.
Any 选项是为以太网帧最小长度填充任意字节的部分被视做 Padding，之外增加的部分被视为 Trailer.

2. Fixed ethernet trailer length

默认值 0 。考虑到 TAP 或是类似负载均衡的代理设备，可能在 Payload 之后 FCS 之前增加固定长度的 trailer（像是高精度时间戳等等）时，可调整该值进行具体分析。

If there’re some bytes left over, it could be a combination of:

• padding to meet the minimum 64 byte frame length
• an FCS, if present
• information inserted by TAPs or other network monitoring equipment.

3. Assume packets have FCS

默认不勾选。一般网卡都会剥离 FCS，所以 Wireshark 数据包分析时一般都没有 FCS 部分。可能存在 DPDK 技术下所抓取的数据包包含 FCS 的情况下，分析时可勾选打开该选项。

参考

wireshark_dissector_packet-eth.c
wireshark_dissectorpacket-ethertype.c

---

感谢阅读，更多技术文章可关注个人公众号：Echo Reply ，谢谢。