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

《以太网帧格式分析实验报告》由会员分享，可在线阅读，更多相关《以太网帧格式分析实验报告（9页珍藏版）》请在装配图网上搜索。

1、实验报告实验名称以太网帧格式分析队另姓名李王丁学号实验日期实验报告要求：1.实验目的2.实验要求3.实验环境4.实验作业5.问题及解决6.思考问题7.实验体会【实验目的】1. 复习Wireshark抓包工具的使用及数据包分析方法。2. 通过分析以太网帧了解以太网数据包传输原理。【实验要求】用Wireshark1.4.9截包，分析数据包。观察以太网帧，Ping同学的IP地址，得到自己和同学的mac地址。观察以太网广播地址，观察ARP请求的帧中目标mac地址的格式。用ping-l指定数据包长度，观察最小帧长和最大帧长。观察封装IP和ARP的帧中的类型字段。【实验环境】用以太网父换机连接起来的win

2、dows7操作系统的计算机，通过802.1x方式接入Internet。【实验中出现问题及解决方法】1. 在使用命令行ping-l0IP观察最小帧长时抓到了长度为42字节的帧，与理论上最小帧长64字节相差甚远。通过询问教贝和简单的分析，知道了缺少字节的原因是当Wireshark抓到这个ping请求包时，物理层还没有将填充（Trailer）字符加到数据段后面，也没有算出最后4字节的校验和序列，导致出现最小42字节的“半成品”帧。可以通过网卡的设置将这个过程提前。2. 在做ping同学主机的实验中，发现抓到的所有ping请求帧中IP数据部分的头校验和都是错误的。原本以为错误的原因与上一个问题有关，即

3、校验和错误是因为物理层还没有将填充字符加到数据段后面。但是这个想法很快被证明是错误的，因为在观察最大帧长时，不需要填充字符的帧也有同样的错误。一个有趣的现象是，封装在更里层的ICMP数据包的校验和都是正确的。这就表明IP层的头校验和错误并没有影响正常通信。进一步观察发现，这些出错的头校验和的值都是0x0000，这显然不是偶然的错误。虽然目前还没有得到权威的答案，但是可以推测，可能是这一项校验实际上并没有被启用。作为中间层的IP头的意义是承上启下，而校验的工作在更需要的上层的IMCP包和下层MAC头中都有，因此没有必要多此一举。【思考问题】1. 为什么可以ping到同宿舍（连接在同一个交换机上）

4、的主机而ping不到隔壁宿舍的主机？通常情况下，如果配置正确，设备都连接着同一个网络（互联网），而且没有防火墙等阻拦，就可以正常ping到同一网络中的任何主机。在第一次实验中，我们曾成功地ping到了的IP。在ping其他宿舍的IP时需要通过宿舍的父换机将ping请求先转发给楼层父换机，再由楼层父换机转发给目标IP所在的宿舍交换机。分析无法ping到隔壁宿舍主机的原因，很可能是楼层交换机设置了禁止内部ping的防火墙，阻止了本楼层父换机地址段内的主机相互ping对方。而同宿舍之所以可以相互ping到，是因为ping请求没有经过楼层交换机，直接由宿舍交换机转发给了目标IP主机。2. 什么是ARP

5、攻击？让我们继续分析4.1ARP原理,A得到ARP应答后，将B的MAC地址放入本机缓存。但是本机MAC缓存是有生存期的，生存期结束后，将再次重复上面的过程。（类似与我们所学的学习网桥）。然而，ARP协议并不只在发送了ARP请求才接收ARP应答。当计算机接收到ARP应答数据包的时候，就会对本地的ARP缓存进行更新，将应答中的IP和MAC地址存储在ARP缓存中。这时，我们假设局域网中的某台机器C冒充B向A发送一个自己伪造的ARP应答，即IP地址为B的IP,而MAC地址是伪造的，则当A接收到伪造的ARP应答后，就会更新本地的ARP缓存，这样在A看来B的IP地址没有变，而它的MAC地址已经不是原来那个

6、了。由于局域网的网络流通不是根据IP地址进行，而是按照MAC地址进行传输。所以，那个伪造出来的MAC地址在A上被改变成一个不存在的MAC地址，这样就会造成网络不通，导致A不能Ping通B!这就是一个简单的ARP欺骗。【实验体会】这次实验最大的感触是体会到了网络通信过程的趣味性。在做ping同学IP的实验时，我发现抓到的包之间有紧密的联系，相互的应答过程很像实际生活中人们之间的对话。尤其是ARP帧，为了获得对方的MAC地址，乐此不疲地在网络中广播“谁有IP为XXX的主机？”，如果运气好，会收到网桥中某个路由器发来的回复“我知道，XXX的MAC地址是YYY!”。另外，通过ping同学主机的实验,以

7、及对实验过程中问题的分析，使我对之前模糊不清的一些概念有了全面的认识，如交换机、路由器的区别与功能，局域网各层次的传输顺序与规则等。还有一点就是，Wireshark不是万能的，也会有错误、不全面的地方，这时更考验我们的理论分析与实践论证能力。成绩优中及格不及格日期:教师签名:【实验作业】1观察并分析通常的以太网帧1.1以太网帧格式目前主要有两种格式的以太网帧：EthernetII（DIX2.0）和IEEE802.3。我们接触过的IP、ARP、EAP和QICQ协议使用EthernetII帧结构，而STP协议则使用IEEE802.3帧结构。EthernetII是由Xerox与DEC、Intel（D

8、IX）在1982年制定的以太网标准帧格式，后来被定义在RFC894中。IEEE802.3是IEEE802委员会在1985年公布的以太网标准封装结构（可以看出二者时间相差不多，竞争激烈），RFC1042规定了该标准（但终究二者都写进了IAB管理的RFC文档中）。下图分别给出了EthernetII和IEEE802.3的帧格式：ElhQTll.61S662SourceTVP=FCSIEEEH716624-15004S右FD&BlinciCionSou丽Adkfr-jSS&0S.2Hoadwrand口创曰res前导码（Preamble）：由0、1间隔代码组成，用来通知目标站作好接收准备。以太网帧则使用

9、8个字节的0、1间隔代码作为起始符。IEEE802.3帧的前导码占用前7个字节，第8个字节是两个连续的代码1，名称为帧首定界符（SOF）,表示一帧实际开始。（2）目标地址和源地址（DestinationAddress&SourceAddress）:表示发送和接收帧的工作站的地址,各占据6个字节。其中，目标地址可以是单址，也可以是多点传送或广播地址。类型（Type）或长度（Length）:这两个字节在EthernetII帧中表示类型（Type）,指定接收数据的高层协议类型。而在IEEE802.3帧中表示长度（Length），说明后面数据段的长度。数据（Data）:在经过物理层和逻辑链路层的处理之

10、后，包含在帧中的数据将被传递给在类型段中指定的高层协议。该数据段的长度最小应当不低于46个字节，最大应不超过1500字节。如果数据段长度过小，那么将会在数据段后自动填充（Trailer）字符。相反，如果数据段长度过大，那么将会把数据段分段后传输。在IEEE802.3帧中该部分还包含802.2的头部信息。帧校验序列（FSC）:包含长度为4个字节的循环冗余校验值（CRC），由发送设备计算产生,在接收方被重新计算以确定帧在传送过程中是否被损坏。1.2实例分析I.EthernetII帧分析出FrameE:60bytesanwireH80bitsL6Qbytescaptured180bits)Ether

11、netTI?Src:istranl_ah:41:d31fC:de:f2:a.bi4j:d8.Dst:Dell_7e:3b3DestinaTion:EeLl_7e:31i:c7(5c:26:0a：re:3b:c7?：.iSourrc;iRstronl.ah;L:dSType：IF(00800)Trailer:0000000000000000000000000000000000000IiitimEtProtocol,Stc:10.104,137,106(10.104.137.106J.Dst:10.104.137.+1IiiterneiControLFrutocoi002085Sa00DOff99

12、000100Saouocoom00300DDO00DO0000000000000000ODOD駅26Oa7e3bcTfOdeflab41dS08QQ0D1D001c22440000400130d9加閃曲旳W胡4500这一帧的长度是60字节，小于最小帧长64字节。对比1.1帧结构可以发现，前导码（Preamble）的8个字节已经被去除，因而实际帧长是68字节。目的地址（DestinationAddress）为5c:26:0a:7e:3b:c7,源地址（SourceAddress）为f0:de:f1:ab:41:d8。类型（Type）为0x0800,表示该帧封装的高层协议类型是IP协议。数据（Da

13、ta）为45000065，因为长度低于46个字节，该数据段自动填充（Trailer）了一段字符。对比1.1帧结构可以发现，该帧没有帧校验序列（FSC），可能是抓到包时校验序列已经被底层去除（但是第5周802.1x接入实验中的EAPOE协议帧中有帧校验序列）。II.IEEE802.3帧分析这一帧的长度也是60字节，前导码的8个字节同样已经被去除，因而实际帧长也是68字节。目的地址为01:80:c2:00:00:00（解析为网桥间的生成树），源地址为3c:e5:a6:f7:a9:f8。长度（Length）为39字节，表示该帧封装的上层协议数据总长度为39字节。数据为42420000，因为数据长度为

14、39字节低于46个字节，因此自动填充了一段字符。该帧同样没有帧校验序列。2ping同学的IP地址，分析帧，得到自己和同学的mac地址开始做这个实验时，尝试去ping隔壁宿舍同学的IP地址10.104.137.124,但结果却不如人愿，无法ping到其主机，结果如下图：-回|l|=-JmJ一二正兰北北10.104.137LU.ILUQ.137：！=*137.13810.104.137.138137=LJg2一L二二L-1一i1J*OJ*TTJ*TT亠了访访访访32決法扶法.頁无无无无具n-la-l-J,阳干三丰三亠旳:-:JA-raw苣1垣员：C:?-；ndowsisystem32cmd.exe

15、CsUsgfDavidLecping-16.104.137丄？!.104.137.124的Ping统计宿息=数揣旬：已拎诀=乳己挎谕=令芙失=Mcmd-getmac”验证MAC地址。结果如下两图，分别在自己和同学的机器上获得本机MAC地址。CsUssrsUJavidLscctmac物理地扯持输名称LC幵开幵断“已已已结果与ping得到的MAC地址相符，自己的MAC地址为5c:26:0a:7e:3b:c7,同学的MAC地址为f0:de:fl:ab:41:d8。4观察ARP请求帧中目标MAC地址的格式（以太网广播地址）4.1 ARP原理假设A要给B发送一个数据包，需要在帧头中填写B的MAC地址。但

16、是这时计算机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地址的目标，因此必须采取广播的方

17、式达到希望的目的。5观察最大帧长和最小帧长5.1理论分析这里有必要再重现一下以太网帧的标准格式。因为单就长度而言，EthernetII和IEEE802.3的帧并无区别，因此这里只通过前者进行分析。EthernetII的帧格式如下图：ElhQTll.18624I&-1&0O4FY锯H1网IndianSourceTFPaFGS理论上的最大帧长和最小帧长可以很容易地由图得到：最大帧长：8+6+6+2+1500+4=1526字节最小帧长：8+6+6+2+46+4=72字节这两个结果很出乎意料，因为课本（同样是理论）告诉我们，以太网帧的最大帧长是1518字节（或是802.1Q提出的1522字节），最小帧

18、长是64字节，这是什么原因呢？初步推测，当数据帧到达网卡时，在物理层上网卡要去掉8字节的前导码（Preamble），所以，实际抓到的包是去掉前导码之后的数据：最大帧长：6+6+2+1500+4=1518字节最小帧长：6+6+2+46+4=64字节这与课本符合的很好，那么实际是否能得到理论分析的结果呢？5.2实验检验我们采用ping-lsize命令来进行验证。首先，通过命令行“ping-l-1（不可能存在的size）”可以得到ping-l的测试范围为0-65500。，结果如下图:不难想象，最小帧长应该是size=0时取得。用过命令行“ping-l010.104.137.106（同宿舍同学的主机I

19、P地址）”观察最短帧长，结果如下图：上图表示ping到了size=0的帧。同时用Wireshark抓包，获得了多组ping请求/回应数据包，每组的数据和长度都相同，其中的一组ping请求/回应帧如下图:Frame7;42bytesonwire(336bits：崔2byt亡黑captux亡tEtherneiII,Src:Dell_7&:3bzc7(SczSBOaiTe-SbicT).D田Destination:Wi3ircinI_ab:41：iiSCfQ：ile:fl:ati:41:d8)田Source:De21_7e:3b:c7(5c:26:Qa:7e:3b:cT)TypuJF卫閘日DCI：i

20、ElInternetFratoco1_Src:10.10-4.137-13B(LO104.137.138JVersiani4Headerleagth:20bytesDifferemialedServicesField:OkOOtDSCF0x00:DefaiTotalLength:28Idcntificaiicn:0x0592(1426)EilFlassz0:00Fraeaenroffser;0Timstolive:64FTOtogliIC乂fflBead?rcheeksuin:OicClLIi.jOl：n匚rriuct：shouldbe04dbSourccz10.104.137.13B(10.

21、104.L37.136JDestination:10.104.137.106(10.104.137.106)InternetCoairolMessageFratacol00000010If。血flab创朋弱前如花釦占0800|001C0592000040010000Oel66898aDa680030&96a0800f7990001006o出乎意料的是，这两帧的长度都小于理论分析的64字节。不仅如此，每一组的请求帧（左侧）都是长度为42字节（出奇的小）的出错帧（IP数据包的头校验和错误）。这个结果不禁让我们开始怀疑之前理论分析的最小帧长，难道最小帧长是左边抓到的42字节？在分析这个问题之前，我们

22、先用命令行“ping-l110.104.137.106”尝试ping下size=l的帧,抓包同样得到了多组等长的ping请求/回应帧，其中一组如下图：这两帧的长度同样出人意料：不只因为长度仍都小于64字节，而是对比上一组size=0的ping请求/回应帧，这一组size=1的请求帧增加了1字节（由42变为43），而回应帧的长度没有变化！（仍是60字节）。这个结果是不符合道理的。通过观察与分析，我们可以得出一个初步结论:Wireshark抓到的所有ping请求帧都是还未封装完成的帧，他们都没有将填充（Trailer）字符加到数据段后面就被抓包软件截获了，自然这些“半成品”被误认为是“残次品”处理

23、，IP数据的头校验和错误应该也与此有关。因此，实际的最小帧长应该是ping回应帧的60字节。问题仍然没有解决：为什么最小帧长是60字节而不是理论得出的64字节？对比以太网标准帧结构进一步观察，我们发现问题出在4字节的帧校验序列（FSC）上。当数据帧到达网卡时，在物理层上网卡先去掉8字节的前导码，然后对帧进行CRC检验，并通过帧校验序列判断。如果帧校验和错，就丢弃此帧。如果校验和正确，并且目的地址是否符合接收条件，就将帧交给上层做进一步处理，同时去掉这4字节的校验码。因此，实际抓到的包是去掉前导码和帧校验序列之后的数据：最大帧长：6+6+2+1500=1514字节最小帧长：6+6+2+46=60

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

25、最大帧长的临界值。结果如下二图：SJ莖珪長：C:ndCws5jst-ern32cirdexesUsoiaSDavitlLoopin?-11472-f10.104.137.106仕自自自自jing10.104.ll(i.lW4.1.37.1CIS1,104,137,1061B.11M.137.106IMMs朋回回回回snJ.LJ.InnLJJ.它：一1-0-H-0I.:、.1.1.1、二、二hlDMLlJcl-Lil篡7244442.11117=一一=sss居mimlnib/l11TTLTTL1ILTIL64646464同时用Wireshark抓包，获得了多组ping请求/回应数据包，其中的一组

26、ping请求/回应帧如下图:ping请求帧的长度为1514字节，这就是实际的最大帧长。数据部分长度为我们指定的size=1472字节，符合我们的分析。但是，IP头校验和仍然是错误的，因此可以判断错误的原因并不是我们之前所想象的那样，该帧还没有来得及加上填充字符（这一帧已经不需要填充字符）。ping回应帧的长度并不是1514字节，而是最小帧长60字节，这是为什么呢？观察ICMP协议数据包上面的IP分组（IPFragments）可以发现，回应帧的IP协议数据包被分为了两帧，我们请求的1472字节IMCP协议数据加上8字节的IMCP头部被分成了两段，分别被封装在第15、16帧中。结果如下图:Fram

27、e16:60onirc2帥bits-1,GObytescerti+：EthernetII,5rc:WistranL_8b:4i:d8(fO:de:fl:ab:41:cSInternetFratccol.Src:10.101.IS?.106(10.104.137.1CVersion:4Hracrr1ngth:20bytezDifferentiatedServicesField:OxDO(BSCPDelTotalLength；!2EIdsnt1fiea:,ion:0x7971(310S3)TFlags:Ox00Fegmuntoffset:1472Ti.ctolive:64Fratocol:ICMP

28、(1)三Headercheckiua:0xd8f3correct?Source:10.104.137.106(10.104.L37.LQ6Destination:10.104.137.138(3D.D4.137.13E?QIPFragnents(1480bytes):#15(1472).fl16(8)Vranie:iE.tRTA&d:m-LSM(8InrtE；KeassesbledIPlength:1480D000D00047e90001GO5e662636465666768D02D69Ba6bBe6d6e6f7077273747576776100206263465666768S96a6b6c

29、Ed6e6f7071003072737475767761S263646566676869氐00406b6c6d6e6f7071727374757677616263-8字节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。