STM32F4+DP83848以太网通信指南系列（六）：Wireshark使用

1万 · 2019-7-4 09:32

本章为系列指南的第六章，这一章我们暂时离开Keil，离开STM32，离开C语言，这一章我们要去了解一些以太网相关的知识，特别是学习使用大名鼎鼎的调试以太网通信程序的利器：WireShark。

帧结构

我们从小就听说过计算机中全都是二进制的0和1，这个道理几乎连考不上三本的文科生都懂，但是很难有直观的感受，甚至连由16个bit，也就是16个二进制的0/1构成的十六进制0/F，再由两个十六进制的0/F形成的0x00/0xFF这种Byte（字节），都很难直观感受到，毕竟计算机世界太丰富了，各类色彩，图片，网站，视频，游戏充斥着我们的日常，所谓「乱花渐欲迷人眼，浅草才能没马蹄」，形形色色的计算机资源就是「乱花」，其背后单调的Byte才是「浅草」，我们在网络通信时只需要Byte的颗粒度，至于细化到bit的精度，只有在研究纯电子电路时才会涉及到。如果说如何传输bit是PHY层负责的问题，那么如何构造和解析Byte就是MAC层要肩负的责任了。

由Byte组成的一个个网络帧，势必要按照一定的格式进行排列，就像如果要你自己自己编排一个串口通信的协议，你也一定会考虑包头、包尾、校验位这些。

Ethernet V2协议在链路层规定了一个基本的帧结构，如下：

目标MAC	源MAC	类型	数据	循环冗余校验FCS
6字节	6字节	2字节	46-1500字节	4字节

因此，最小的帧长度是6 + 6 + 2 + 46 + 4 = 64个Byte，最大长度是6 + 6 + 2 + 1500 + 4 = 1518个Byte。

上表最后4个Byte形成了一组循环冗余的CRC校验数据，很遗憾的是我们能通过软件手段监听出来的帧结构都不会含有这段数据，因为网卡在接受到报文后就会立即对数据进行校验，凡是不满足校验规则的数据包会直接丢弃，不会触发操作系统的以太网事件。因此你能监听到的报文都是符合规则的，网卡交给上层软件应用时也会自动将校验数据剥离。此外，具体的循环冗余CRC校验的算法是什么大家也不用管了，在使用STM32调用发包指令时，MAC层会帮我们计算好的。

1万 · 2019-7-4 09:33

一个典型的ARP帧报文如下：

ff ff ff ff ff ff 00 11 0e 0b 03 8a 08 06 00 01
08 00 06 04 00 01 00 11 0e 0b 03 8a c0 a8 01 c7
00 00 00 00 00 00 c0 a8 01 fe 00 00 00 00 00 00
00 00 00 00 00 00 00 00 20 20 20 20

这是一个最简单的60Byte的ARP报文（另有4个FCS校验数据被网卡吞了，总长度64Byte），看上去是不是像是乱码，完全无法理解，别着急，下面介绍网络编程的神器WireShark。

1万 · 2019-7-4 09:33

WireShark·线路鲨鱼

这款名字里带有「鲨鱼」的软件，真的是名副其实，大鳄级的网络编程神器：精确到微妙级别的底层网络包监听，内置上千种网络协议，上下文分析得丝丝入扣，你通过它即可完全理解整个网络上正在发生了什么。无论是初学网络的思科学员想一窥网络的究竟，还是努力工作的程序员需要进行协议的分析，亦或是躲在阴暗处的黑客试图在交换机上刮起一场网络风暴，WireShark都能助你一臂之力。

WireShark为了能够监听到网络底层的数据包，在Windows上使用了叫做winpcap的技术，而winpcap又是使用了libpcap这个库，这样的调用关系其实是为了解决一件事：能在操作系统上层操作底层网络数据包。

我们平时在C++，JAVA中谈论到的网络编程，其实所处的层级都是高层，回想一下那些Socket编程所讲到的知识，一般上来就会讲TCP/UDP，也就是处在高层应用开发的高度来讲，网络编程非TCP即UDP，别无其他。在《STM32F4+DP83848以太网通信指南第一章：知识储备》里我讲到以太网分为很多层（按照OSI模型有七层，按照TCP/IP协议有五层），除了应用层以外，我们还有很多底层的数据包跑在网络上（比如ARP数据包、ICMP数据包等），这些数据包大部分不是由一般编程人员通过各种网络应用程序发起的，那么它们是由谁发起的，又是由谁来负责接受和解析呢？这个答案是网卡、交换机，以及操作系统，这些数据包关系到网络的通路、拓扑、路由，用户层面一般不需要了解和控制，对操作系统来说，一般也是不会让用户随意触碰甚至自行构建网络帧的。

WireShark利用winpcap做到了监听底层网络包，它严格地限制了自己无法对网络数据进行修改、编辑、转发。一旦普通用户对以太网的了解更多一些，并且能够利用WireShark处理和转发网络包，那对于网络安全真是一件非常恐怖的事情。

1万 · 2019-7-4 09:33

说了这么多，其实都是在讲一些周边知识。WireShark的安装步骤我就不赘述了，下载和安装都是很简单的，现在我们来看看上面提到的那份看上去像乱码的ARP数据包，其实它就是我用WireShark捕获到的，上面的「乱码」只不过是我用十六进制的方式直接复制出来，接下来我们看看这份数据包在WireShark的帮助下会不会更清晰一点：

如上图所示，在WireShark的帮助下，数据包中每一个结构都清晰可见，WireShark帮助我们将一堆十六进制的Byte理解得就如同json数据一样清晰，其内置的数千种网络协议，使得WireShark对各种各样的网络包每一位的作用都了如指掌。在软件的下方区域点击任意一位Byte，它都会在中部区域将这一位的含义和作用清晰地显示出来。

1万 · 2019-7-4 09:34

我们再来看一个稍微复杂点的IPV4数据包，是我们常用的一个ping指令发出去的ICMP帧，在WireShark上显示74个Byte：

同样，WireShark帮助我们理解起来要非常清晰，截图其实并不能很好地体现，我们在使用WireShark的时候随时可以用鼠标点击任意字节，显示其含义。

1万 · 2019-7-4 09:34

广播和点对点

最后我们再介绍一些交换机的附带知识，我们知道网络帧一般会在开头的6个字节标明这个网络帧的接受设备的MAC地址，如果这个包要向局域网内所有设备进行广播，比如上面那个ARP包，这六个字节一般为FF FF FF FF FF FF，如果这个包要向一个特定的设备进行通信，这六个字节则为一个确定的MAC地址，比如上面那个ICMP包，其指向了交换机，交换机收到了以后需要向上行网络请求。

如果局域网内的主机A需要向主机B发送一个点对点的数据，那么封装后的以太网帧的前六个字节就为主机B的MAC地址，交换机收到后会查询自己的维护的映射表，比如找到自己的端口2上的设备的MAC地址就是B的地址，那么交换机就向端口2上的网线投送这个数据包，交换机其他端口上的设备就收不到这则数据包了。

那么我们在做以太网协议分析时，一般是处于主机C的位置来监听和分析A和B的通信，大多数情况下他们之间是点对点通信，主机C在局域网中是观察不到这些数据包的，因为交换机压根就不将A和B的通信数据转发给主机C。

这时候就要祭出又一款硬件神器了：带有端口镜像功能的网管型交换机

1万 · 2019-7-4 09:35

利用这种交换机，可以进入管理控制界面，配置端口映射，将设备A和设备B之间通信的双向数据全都转发给设备C，方便WireShark进行协议分析，最终我们可以根据分析出来的协议，在嵌入式STM32中编写自己的协议栈，实现DIY的设备D，与设备A进行通信，取代设备B。

上图就是我购买的一款网管型交换机中配置端口映射的界面。

1万 · 2019-7-4 09:35

小结

这一章我们对以太网的帧结构有了一个基本的认识，了解了网络上跑的各种数据包在MAC层的表现形式，能够运用WireShark观察一些简单的由各种十六进制数据组成的数据包，最后我们还了解了如何运用网管型交换机配置端口映射，在局域网中的C端监听A和B的通信。

以上，为下一步在STM32嵌入式设备中编写网络协议打下了基础。