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

的IP，而MAC地址是伪造的，则当A接收到伪造的ARP应答后，就会更新本地的ARP缓存，这样在A 看来B的IP地址没有变，而它的MAC地址已经不是原来那个了。

由于局域网的网络流通不是根据IP地址进行，而是按照MAC地址进行传输。

所以，那个伪造出来的MAC地址在A上被改变成一个不存在的MAC地址，这样就会造成网络不通，导致A不能Ping通B！这就是一个简单的ARP欺骗。

【实验体会】这次实验最大的感触是体会到了网络通信过程的趣味性。

在做ping同学IP的实验时，我发现抓到的包之间有紧密的联系，相互的应答过程很像实际生活中人们之间的对话。

尤其是ARP帧，为了获得对方的MAC地址，乐此不疲地在网络中广播“谁有IP为XXX的主机？”，如果运气好，会收到网桥中某个路由器发来的回复“我知道，XXX的MAC地址是YYY！”。

另外，通过ping同学主机的实验，以及对实验过程中问题的分析，使我对之前模糊不清的一些概念有了全面的认识，如交换机、路由器的区别与功能，局域网各层次的传输顺序与规则等。

还有一点就是，Wireshark不是万能的，也会有错误、不全面的地方，这时更考验我们的理论分析与实践论证能力。

成绩优良中及格不及格教师签名：日期：【实验作业】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字节最小帧长的实验结果符合我们的分析，下面我们验证最大帧长。