以太网帧格式分析实验报告

以太网帧格式

实 验 报 告实验名称 队 别 姓 名 李王丁 2.实验要求 6.思考问题 以太网帧格式分析 学 号 3.实验环境 7.实验体会 实验日期 4.实验作业

实验报告要求： 1.实验目的 5.问题及解决

【实验目的】 1.复习 Wireshark 抓包工具的使用及数据包分析方法。 2.通过分析以太网帧了解以太网数据包传输原理。 【实验要求】 用 Wireshark1.4.9 截包，分析数据包。 观察以太网帧，Ping 同学的 IP 地址，得到自己和同学的 mac 地址。 观察以太网广播地址，观察 ARP 请求的帧中目标 mac 地址的格式。 用 ping-l 指定数据包长度，观察最小帧长和最大帧长。 观察封装 IP 和 ARP 的帧中的类型字段。 【实验环境】 用以太网交换机连接起来的 windows 7 操作系统的计算机，通过 802.1x 方式接入 Internet。 【实验中出现问题及解决方法】 1.在使用命令行“ping -l 0 IP”观察最小帧长时抓到了长度为 42 字节的帧，与理论上最小帧长 64 字节相差甚远。通过询问教员和简单的分析，知道了缺少字节的原因是当 Wireshark 抓到这个 ping 请求 包时，物理层还没有将填充(Trailer)字符加到数据段后面，也没有算出最后 4 字节的校验和序列，导致 出现最小 42 字节的“半成品”帧。可以通过网卡的设置将这个过程提前。 2.在做 ping 同学主机的实验中， 发现抓到的所有 ping 请求帧中 IP 数据部分的头校验和都是错误的。 原本以为错误的原因与上一个问题有关，即校验和错误是因为物理层还没有将填充字符加到数据段后面。 但是这个想法很快被证明是错误的，因为在观察最大帧长时，不需要填充字符的帧也有同样的错误。一个 有趣的现象是，封装在更里层的 ICMP 数据包的校验和都是正确的。这就表明 IP 层的头校验和错误并没 有影响正常通信。进一步观察发现，这些出错的头校验和的值都是 0x0000,这显然不是偶然的错误。虽 然目前还没有得到权威的答案，但是可以推测，可能是这一项校验实际上并没有被启用。作为中间层的 IP 头的意义是承上启下，而校验的工作在更需要的上层的 IMCP 包和下层 MAC 头中都有，因此没有必要 多此一举。 【思考问题】 1.为什么可以 ping 到同宿舍(连接在同一个交换机上)的主机而 ping 不到隔壁宿舍的主机？ 通常情况下，如果配置正确，设备都连接着同一个网络(互联网),而且没有防火墙等阻拦，就可以 正常 ping 到同一网络中的任何主机。在第一次实验中，我们曾成功地 ping 到了 的 IP。 在 ping 其他宿舍的 IP 时需要通过宿舍的交换机将 ping 请求先转发给楼层交换机， 再由楼层交换机转 发给目标 IP 所在的宿舍交换机。分析无法 ping 到隔壁宿舍主机的

原因，很可能是楼层交换机设置了禁止 内部 ping 的防火墙，阻止了本楼层交换机地址段内的主机相互 ping 对方。而同宿舍之所以可以相互 ping 到，是因为 ping 请求没有经过楼层交换机，直接由宿舍交换机转发给了目标 IP 主机。 2.什么是 ARP 攻击？ 让我们继续分析 4.1 ARP 原理， A 得到 ARP 应答后， 将 B 的 MAC 地址放入本机缓存。 但是本机 MAC 缓存是有生存期的，生存期结束后，将再次重复上面的过程。(类似与我们所学的学习网桥)。 然而，ARP 协议并不只在发送了 ARP 请求才接收 ARP 应答。当计算机接收到 ARP 应答数据包的时 候，就会对本地的 ARP 缓存进行更新，将应答中的 IP 和 MAC 地址存储在 ARP 缓存中。 这时，我们假设局域网中的某台机器 C 冒充 B 向 A 发送一个自己伪造的 ARP 应答，即 IP 地址为 B

以太网帧格式

【实验作业】

1 观察并分析通常的以太网帧

1.1 以太网帧格式

目前主要有两种格式的以太网帧：Ethernet II（DIX 2.0）和IEEE 802.3。我们接触过的IP、ARP、EAP和QICQ协议使用Ethernet II帧结构，而STP协议则使用IEEE 802.3帧结构。

Ethernet II是由Xerox与DEC、Intel（DIX）在1982年制定的以太网标准帧格式，后来被定义在RFC894中。IEEE 802.3是IEEE 802委员会在1985年公布的以太网标准封装结构（可以看出二者时间相差不多，竞争激烈），RFC1042规定了该标准（但终究二者都写进了IAB管理的RFC文档中）。

下图分别给出了Ethernet II和IEEE 802.3的帧格式：

⑴ 前导码（Preamble）：由0、1间隔代码组成，用来通知目标站作好接收准备。以太网帧则使用8个字节的0、1间隔代码作为起始符。IEEE 802.3帧的前导码占用前7个字节，第8个字节是两个连续的代码1，名称为帧首定界符（SOF），表示一帧实际开始。

⑵ 目标地址和源地址（Destination Address & Source Address）：表示发送和接收帧的工作站的地址，各占据6个字节。其中，目标地址可以是单址，也可以是多点传送或广播地址。

以太网帧格式

⑶ 类型（Type）或长度（Length）：这两个字节在Ethernet II帧中表示类型（Type），指定接收数据的高层协议类型。而在IEEE 802.3帧中表示长度（Length），说明后面数据段的长度。

⑷ 数据（Data）：在经过物理层和逻辑链路层的处理之后，包含在帧中的数据将被传递给在类型段中指定的高层协议。该数据段的长度最小应当不低于46个字节，最大应不超过1500字节。如果数据段长度过小，那么将会在数据段后自动填充（Trailer）字符。相反，如果数据段长度过大，那么将会把数据段分段后传输。在IEEE 802.3帧中该部分还包含802.2的头部信息。

⑸ 帧校验序列（FSC）：包含长度为4个字节的循环冗余校验值（CRC），由发送设备计算产生，在接收方被重新计算以确定帧在传送过程中是否被损坏。

1.2 实例分析

Ⅰ．Ethernet II帧分析

这一帧的长度是60字节，小于最小帧长64字节。对比1.1帧结构可以发现，前导码（Preamble）的8个字节已经被去除，因而实际帧长是68字节。目的地址（Destination Address）为[5c:26:0a:7e:3b:c7]，源地址（Source Address）为[f0:de:f1:ab:41:d8]。类型（Type）为[0x0800]，表示该帧封装的高层协议类型是IP协议。数据（Data）为[45 00 00 65]，因为长度低于46个字节，该数据段自动填充（Trailer）了一段字符。对比1.1帧结构可以发现，该帧没有帧校验序列（FSC），可能是抓到包时校验序列已经被底层去除（但是第5周802.1x接入实验中的EAPOE协议帧中有帧校验序列）。

Ⅱ．IEEE 802.3帧分析

这一帧的长度也是60字节，前导码的8个字节同样已经被去除，因而实际帧长也是68字节。目的地址为[01:80:c2:00:00:00]（解析为网桥间的生成树），源地址为[3c:e5:a6:f7:a9:f8]。长度（Length）为39字节，表示该帧封装的上层协议数据总长度为39字节。数据为[42 42 00 00]，因为数据长度为39字节低于46个字节，因此自动填充了一段字符。该帧同样没有帧校验序列。

2 ping同学的IP地址，分析帧，得到自己和同学的mac地址

开始做这个实验时，尝试去ping隔壁宿舍同学的IP地址[10.104.137.124]，但结果却不如人愿，无法ping到其主机，结果如下图：

以太网帧格式

同时用Wireshark抓包，得到了如下结果：

分析无法ping到的原因，本机一直广播发送ARP请求，询问哪个端口有[10.104.137.124]这台机器，但是却没有回应。这个问题作为思考题1进行分析。

后来去ping本宿舍（连接着同一交换机）的主机IP[10.104.137.106]获得了成功，结果如下图：

接受到了长度为32字节的回复数据包。同时用Wireshark抓包，通过下面一个ping的回应帧，可以得到自己和同学的MAC地址，结果如下图：

得到目标地址（因为是回应帧，因此这是自己的MAC地址）为[5c:26:0a:7e:3b:c7]，解析的制造商为Dell（对应自己的Dell笔记本）。源地址（同学的MAC地址）为[f0:de:f1:ab:41:d8]，解析的制造商为Wistron（同学是联想笔记本，而网卡是第三方纬创集团，可见国产品牌还需提高整体实力）。

以太网帧格式

3 验证用其他方法得到的mac地址是否一致

获取本机MAC地址的方法有多种，这里使用方法“运行 -> cmd -> getmac”验证MAC地址。结果如下两图，分别在自己和同学的机器上获得本机MAC地址。

结果与ping得到的MAC地址相符，自己的MAC地址为[5c:26:0a:7e:3b:c7]，同学的MAC地址为

[f0:de:f1:ab:41:d8]。

4 观察ARP请求帧中目标MAC地址的格式(以太网广播地址)

4.1 ARP原理

假设A要给B发送一个数据包，需要在帧头中填写B的MAC地址。但是这时计算机A可能只知道B的IP地址却不知道B的MAC地址，于是，在A不知道B的MAC地址的情况下，A就广播一个ARP请求包，请求包中填有B的IP，B收到请求后回应ARP应答包给A，其中含有B的MAC地址，这样A就可以开始向B发送数据包了。

4.2 ARP请求帧地址分析

用Wireshark抓包得到大量ARP帧，其中一个请求帧如下图：

目标MAC地址为[ff:ff:ff:ff:ff:ff]，表示广播发送。观察发现不只这一帧如此，所有ARP请求帧的目标MAC地址都是[ff:ff:ff:ff:ff:ff]。这一点由ARP原理很好理解，因为ARP请求帧的作用就是寻找自己不知道MAC地址的目标，因此必须采取广播的方式达到希望的目的。

5 观察最大帧长和最小帧长

5.1 理论分析

以太网帧格式

这里有必要再重现一下以太网帧的标准格式。因为单就长度而言，Ethernet II和IEEE 802.3的帧并无区别，因此这里只通过前者进行分析。Ethernet II的帧格式如下图：

理论上的最大帧长和最小帧长可以很容易地由图得到：

最大帧长：8+6+6+2+1500+4=1526字节

最小帧长：8+6+6+2+46+4=72字节

这两个结果很出乎意料，因为课本（同样是理论）告诉我们，以太网帧的最大帧长是1518字节（或是802.1Q提出的1522字节），最小帧长是64字节，这是什么原因呢？

初步推测，当数据帧到达网卡时，在物理层上网卡要去掉8字节的前导码（Preamble），所以，实际抓到的包是去掉前导码之后的数据：

最大帧长：6+6+2+1500+4=1518字节

最小帧长：6+6+2+46+4=64字节

这与课本符合的很好，那么实际是否能得到理论分析的结果呢？

5.2 实验检验

我们采用ping -l size命令来进行验证。首先，通过命令行“ping -l -1（不可能存在的size）”可以得到ping -l的测试范围为[0-65500]。，结果如下图：

不难想象，最小帧长应该是size=0时取得。用过命令行“ping -l 0 10.104.137.106（同宿舍同学的主机IP地址）”观察最短帧长，结果如下图：

上图表示ping到了size=0的帧。同时用Wireshark抓包，获得了多组ping请求/回应数据包，每组的数据和长度都相同，其中的一组ping请求/回应帧如下图：

以太网帧格式

出乎意料的是，这两帧的长度都小于理论分析的64字节。不仅如此，每一组的请求帧（左侧）都是长度为42字节（出奇的小）的出错帧（IP数据包的头校验和错误）。这个结果不禁让我们开始怀疑之前理论分析的最小帧长，难道最小帧长是左边抓到的42字节？

在分析这个问题之前，我们先用命令行“ping -l 1 10.104.137.106”尝试ping一下size=1的帧，抓包同样得到了多组等长的ping请求/回应帧，其中一组如下图：

这两帧的长度同样出人意料：不只因为长度仍都小于64字节，而是对比上一组size=0的ping请求/回应帧，这一组size=1的请求帧增加了1字节（由42变为43），而回应帧的长度没有变化！（仍是60字节）。这个结果是不符合道理的。

通过观察与分析，我们可以得出一个初步结论：Wireshark抓到的所有ping请求帧都是还未封装完成的帧，他们都没有将填充（Trailer）字符加到数据段后面就被抓包软件截获了，自然这些“半成品”被误认为是“残次品”处理，IP数据的头校验和错误应该也与此有关。因此，实际的最小帧长应该是ping回应帧的60字节。

问题仍然没有解决：为什么最小帧长是60字节而不是理论得出的64字节？对比以太网标准帧结构进一步观察，我们发现问题出在4字节的帧校验序列（FSC）上。当数据帧到达网卡时，在物理层上网

以太网帧格式

卡先去掉8字节的前导码，然后对帧进行CRC检验，并通过帧校验序列判断。如果帧校验和错，就丢弃此帧。如果校验和正确，并且目的地址是否符合接收条件，就将帧交给上层做进一步处理，同时去掉这4字节的校验码。因此，实际抓到的包是去掉前导码和帧校验序列之后的数据：

最大帧长：6+6+2+1500=1514字节

最小帧长：6+6+2+46=60字节

最小帧长的实验结果符合我们的分析，下面我们验证最大帧长。究竟size等于多少可以取得最大帧长的帧，我们并不能简单得到。事实上，我们指定的size的值是ping帧封装的ICMP协议数据包的数据（Data）部分的长度。而所有头部（MAC头+IP头+ICMP头）的长度可以由上面size=0的60字节的回应帧得到，即为填充（Trailer）字段前面的数据长度：42字节。因此，最大帧长的size=1514-42=1472。 为了验证我们的结论，我们采用命令行“ping -l 1472 -f（设置数据包不分段） 10.104.137.106”和“ping -l 1473 -f 10.104.137.106”验证ping最大帧长的临界值。结果如下二图：

同时用Wireshark抓包，获得了多组ping请求/回应数据包，其中的一组ping请求/回应帧如下图：

以太网帧格式

ping请求帧的长度为1514字节，这就是实际的最大帧长。数据部分长度为我们指定的size=1472字节，符合我们的分析。但是，IP头校验和仍然是错误的，因此可以判断错误的原因并不是我们之前所想象的那样，该帧还没有来得及加上填充字符（这一帧已经不需要填充字符）。

ping回应帧的长度并不是1514字节，而是最小帧长60字节，这是为什么呢？观察ICMP协议数据包上面的IP分组（IP Fragments）可以发现，回应帧的IP协议数据包被分为了两帧，我们请求的1472字节IMCP协议数据加上8字节的IMCP头部被分成了两段，分别被封装在第15、16帧中。结果如下图： 字节ICMP头部

8字节数据

因为对方回应的IMCP协议数据包的长度为带头部的1480字节，超过了请求的1472字节，因此对方机器自动将数据分组，在第15帧中封装了8字节的IMCP头部和1464字节的数据，在第16帧中只封装了剩余的8字节数据。

实验说明，我们在命令行中增加的-f只是控制了本机发出的ping请求帧不分段（一旦分段就提示需要拆分数据包），而无法保证对方回应的ping数据不分段。

5.3 结论

实际传输的最大帧长：1518字节，最小帧长：64字节

能抓包得到的最大帧长：1514字节，最小帧长：60字节（不考虑未完成的帧）

6 观察封装IP和ARP的帧中的类型字段

任意选择ARP和IP各一帧如下图：

可知ARP协议的类型是[0x0806]，IP协议的类型是[0x0800]。

本文来源：https://www.bwwdw.com/article/4jl4.html