链路层数据包分析

DIX Ethernet V2 帧格式分析

包的总览

 

如图所示，这是我对宿舍网关进行ping命令的icmp报文

数据链路层的展开

 

可见书中十分典型的几个数据域：目的mac地址，源mac地址以及上层数据是关于什么协议的。该包的type域的值为：0x0800，所代表的就是ip协议。Arp的值是0806，RARP的值是8035

 

Mac地址中的IG位意思位individual/group，意思是该mac地址代表的是单播地址还是组播地址，LG位意思是local/group，意识是本地管理还是全球管理，一般来说可在以太网上进行数据传输的网卡都是全球管理，有的人不愿意去注册组织购买mac地址，可以选择本地管理，将LG位设置为1。

对于嗅探工具中小于最小帧长的情况分析

 

如图我对宿舍网关ping了一个一字节的数据包。

但是其无论是request还是reply数据包都是43字节。经过分析发现，除去数据链路层的14字节的头部，网络层的20字节的头部，以及icmp协议的8字节的头部，最终刚好剩下1字节的数据部分。可以看出我们的无论是ping出去的报文还是受到的报文，填充字段和冗余校验码舍弃了。以至于我们在数据包的尾部都没有看到padding以及冗余码的踪迹。主要原因在于嗅探工具与发送接收谁先工作，很明显在该例中数据包在接收和发送的过程中，无论是冗余码还是填充字段wireshark都没有获取到，但是其实这也有助于我们专心对内容进行分析。

为了防止偶然性，我又测试了ping20字节的数据包，发现其报文的大小为62字节，同样的，除去无关的包头之后，剩下的数据大小域20字节刚好吻合。

IEEE 802 帧格式分析

该实验我在GNS3中，对STP报文的SAP和CDP报文和SNAP进行解析。

STP报文

 

 

如图这是一个STP的BPDU报文，与EthernetII明显的不同就在于中间多了一个LLC子层。

对MAC子层的数据进行展开

 

我们发现该数据包当中有padding。该例与上述的例子又有所不同，他有八个字节的填充字段，但是它的总字段是60字节，主要是冗余码被去除了。同时我们可以看到它代表长度的字段，其字段值为38，刚好满足最小的数据大小。（在以太网中的最小数据大小是46字节，加上12字节的目的mac地址和12字节的源mac地址，以及2字节的上层协议字段和4字节的冗余码刚好是64字节，但是在802帧中加上了6字节的LLC子层，这就使得最小数据大小46，变为了38）

SAP---LLC子层的展开

 

因为该包是802帧的SAP类型，所以并没有组织ID字段和类型字段，我们还可以看到DSAP和SSAP的值都是0x42，以及固定的控制字段。

SNAP---LLC子层的展开

 

该包是pvst+的BPDU，我们可以看到其增加了组织ID和类型字段，组织ID为十进制的13，类型字段代表着封装pvst+的数据

总的来说，以太网的帧和802帧的主要差别就在于LLC子层，由于以太网的普及程度以及简洁的帧结构是我认为该帧结构被广泛使用的原因。同时因为链路层协议使用比例差距巨大，导致802帧中的LLC子层的各个字段显得十分无用。而反看以太网帧的仅仅使用了2字节的类型字段就能够很好的表明上层所使用的协议，以及封装的内容类型。

PPP帧结构分析以及协商分析

 

如图PPP的帧比较简单，主要分为两层，且从该例中我们发现wireshark并没有将0x7E定界符，以及冗余码显示出来。

第一层：

Address：取固定值

Control：取固定值

Protocol：表示该PPP帧的类型，主要关注的类型有

（1）0x8021：IPCP，表示NCP协商的是IP协议

（2）0x0021：internet protocol，表示该帧承载的是ip协议的数据

（3）0xc021：表示该PPP帧是LCP类型

（4）0xc023：表示该包是用作PAP认证的认证数据包

（5）0xc223：表示该包是用作CHAP认证的认证数据包

第二层：

第二层有许多信息，有普通的数据包，也有LCP，NCP或者PAP的这种与链路相关的配置包。上面的例子就是一个LCP的包。

 

如图表示的是LCP的报文格式，code字段表示了LCP的类型，identificater代表着一对数据包的标识，标识相同的数据包表明了它们正在互相协商一些参数。如MRU（最大接收单元）。Length代表着该LCP报文的长度。LCP包中又包含多个协商参数，每个协商参数有包含type，length，data三个字段。

 

 

一般来说物理链路的成功建立主要是依靠configure-request包和configure-ack包，一端发出包含自身的物理链路的参数的request包，如果对端接收其参数会回送ack包，代表其接收了request包的参数。其中ack包的内容同样包含之前协商完成的内容。如果对端发送的是Nak包的话，就代表对端否认其部分参数。如果返回的是Reject包，则代表有部分参数不能识别，比如我在一端设置了ppp认证，但是另一端并没有提供用户名和账号，这就使得认证方向被认证方发送configuration-request的时候，因为被认证方没有配置对应的认证命令（即没有配置发送用户名和密码的命令），这时被认证方就会发送reject包，因为某些参数不能识别于是表示拒绝，且reject数据包包含着没有协商成功的参数内容。于是request包的发送者就需要再次发送调整后的request。如果协商还是失败就会发送termination request，也就是终止请求，然后一般会回送termination ack标识断开确认。如下图是一个协商失败的例子：

 

失败的主要原因在于被认证方没有提供用户和密码，所以对端发送了reject的拒绝包，当被认证方再次发送请求包的时候，认证方直接发送termination request请求断开。

下图是reject包的具体内容，可以看见其协商项仅仅包含着授权协议这一个内容。同时也代表着双方只差这一项没有协商成功。

 

这样的请求和确认需要在两端进行。也就是物理链路的协商如果成功的话，起码要发送一对configure-request包。如下图所示：

 

 

配置PAP认证以及认证成功的例子

 

可以看到在被认证方在受到认证方的request请求之后，发送的不是reject包而是ack包，同时在发送ack包之后，发送了一个authenticate-request的PAP包，下图是其内容：

 

可以看到它的数据部分包含着对端的用户名和密码信息。表示这被认证方希望使用该信息进行pap的认证。

被认证方在接收认证请求之后进行验证，确认之后回送了一个authenticate-ack包，表示认证确认，下图是ack包的内容：

 

可以看见它除了有消息的长度还有，华为的欢迎语句。

配置chap及其认证成功后的情况

 

可以看到chap的典型的三个认证过程。其他与pap的流程差不多。chap在认证过程比较复杂不做讨论。