Sniffer数据报文解码详解_wifi sniffer 包长度

Sniffer数据报文解码详解

数据报文分层

如下图所示，对于四层网络结构，其不同层次完成不通功能。每一层次有众多协议组成。


如上图所示在Sniffer的解码表中分别对每一个层次协议进行解码分析。链路层对应“DLC”；网络层对应“IP”；传输层对应“UDP”；应用层对对应的是“NETB”等高层协议。Sniffer可以针对众多协议进行详细结构化解码分析。并利用树形结构良好的表现出来。

以太报文结构

EthernetII以太网帧结构

Ethernet_II以太网帧类型报文结构为：目的MAC地址（6bytes）＋源MAC地址＋（6bytes）上层协议类型（2bytes）＋数据字段（46-1500bytes)＋校验（4bytes）。

Sniffer会在捕获报文的时候自动记录捕获的时间，在解码显示时显示出来，在分析问题时提供了很好的时间记录。
源目的MAC地址在解码框中可以将前3字节代表厂商的字段翻译出来，方便定位问题，例如网络上2台设备IP地址设置冲突，可以通过解码翻译出厂商信息方便的将故障设备找到，如00e0fc为华为，010042为Cisco等等。如果需要查看详细的MAC地址用鼠标在解码框中点击此MAC地址，在下面的表格中会突出显示该地址的16进制编码。
IP网络来说Ethertype字段承载的时上层协议的类型主要包括0x800为IP协议，0x806为ARP协议。

IEEE802.3以太网报文结构


上图为IEEE802.3SNAP帧结构，与EthernetII不通点是目的和源地址后面的字段代表的不是上层协议类型而是报文长度。并多了LLC子层。

IP协议

IP报文结构为IP协议头＋载荷，其中对IP协议头部的分析，时分析IP报文的主要内容之一，关于IP报文详细信息请参考相关资料。这里给出了IP协议头部的一个结构。
版本：4——IPv4
首部长度：单位为4字节，最大60字节
TOS：IP优先级字段
总长度：单位字节，最大65535字节
标识：IP报文标识字段
标志：占3比特，只用到低位的两个比特
MF（More Fragment）
MF=1，后面还有分片的数据包
MF=0，分片数据包的最后一个
DF（Don’t Fragment）
DF=1，不允许分片
DF=0，允许分片
段偏移：分片后的分组在原分组中的相对位置，总共13比特，单位为8字节
寿命：TTL（Time To Live）丢弃TTL=0的报文
协议：携带的是何种协议报文
1 ：ICMP
6 ：TCP
17：UDP
89：OSPF
头部检验和：对IP协议首部的校验和
源IP地址：IP报文的源地址
目的IP地址：IP报文的目的地址

上图为Sniffer对IP协议首部的解码分析结构，和IP首部各个字段相对应，并给出了各个字段值所表示含义的英文解释。如上图报文协议（Protocol）字段的编码为0x11，通过Sniffer解码分析转换为十进制的17，代表UDP协议。其他字段的解码含义可以与此类似，只要对协议理解的比较清楚对解码内容的理解将会变的很容易。

ARP协议

以下为ARP报文结构

ARP分组具有如下的一些字段：
HTYPE（硬件类型）。这是一个16比特字段，用来定义运行ARP的网络的类型。每一个局域网基于其类型被指派给一个整数。例如，以太网是类型1。ARP可使用在任何网络上。
PTYPE（协议类型）。这是一个16比特字段，用来定义协议的类型。例如，对IPv4协议，这个字段的值是0800。ARP可用于任何高层协议。
HLEN（硬件长度）。这是一个8比特字段，用来定义以字节为单位的物理地址的长度。例如，对以太网这个值是6。
PLEN（协议长度）。这是一个8比特字段，用来定义以字节为单位的逻辑地址的长度。例如，对IPv4协议这个值是4。
OPER（操作）。这是一个16比特字段，用来定义分组的类型。已定义了两种类型：ARP请求（1），ARP回答（2）。
SHA（发送站硬件地址）。这是一个可变长度字段，用来定义发送站的物理地址的长度。例如，对以太网这个字段是6字节长。
SPA（发送站协议地址）。这是一个可变长度字段，用来定义发送站的逻辑（例如，IP）地址的长度。对于IP协议，这个字段是4字节长。
THA（目标硬件地址）。这是一个可变长度字段，用来定义目标的物理地址的长度。例如，对以太网这个字段是6字节长。对于ARP请求报文，这个字段是全0，因为发送站不知道目标的物理地址。
TPA（目标协议地址）。这是一个可变长度字段，用来定义目标的逻辑地址（例如，IP地址）的长度。对于IPv4协议，这个字段是4字节长。

上面为通过Sniffer解码的ARP请求和应答报文的结构。

PPPOE协议

PPPOE简介
简单来说我们可能把PPPOE报文分成两大块，一大块是PPPOE的数据报头，另一块则是PPPOE的净载荷（数据域），对于PPPOE报文数据域中的内容会随着会话过程的进行而不断改变。下图为PPPOE的报文的格式：

• 数据报文最开始的4位为版本域，协议中给出了明确的规定，这个域的内容填充0x01。
• 紧接在版本域后的4位是类型域，协议中同样规定，这个域的内容填充为0x01。
• 代码域占用1个字节，对于PPPOE 的不同阶段这个域内的内容也是不一样的。
• 会话ID点用2个字节，当访问集中器还未分配唯一的会话ID给用户主机的话，则该域内的内容必须填充为0x0000，一旦主机获取了会话ID后，那么在后续的所有报文中该域必须填充那个唯一的会话ID值。
• 长度域为2个字节，用来指示PPPOE数据报文中净载荷的长度。
• 数据域，有时也称之为净载荷域，在PPPOE的不同阶段该域内的数据内容会有很大的不同。在PPPOE的发现阶段时，该域内会填充一些Tag（标记）；而在PPPOE的会话阶段，该域则携带的是PPP的报文。

捕获报文测试用例图
如图所示，Radius Server IP地址为172.16.20.76。PPPOE用户Radius报文交互过程分析如下。

上图为PPPOE从发现阶段到PPP LCP协商，认证IPCP协商阶段和PPPOE会话阶段交互过程。
PPPOE发现阶段，PADI报文，Sniffer解码结构如下所示。

PPPOE会话阶段，Sniffer解码结构如下所示。

Radius协议

Radius报文简介
标准Radius协议包结构

图9 Radius包格式
Code：包类型；1字节；指示RADIUS包的类型。
1 Access- request 认证请求
2 Access- accept 认证响应
3 Access- reject 认证拒绝
4 Accounting-request 计费请求
5 Accounting-response 计费响应
*11 Access-challenge 认证挑战
Identifier： 包标识；1字节，取值范围为0 ～255；用于匹配请求包和响应包，同一组请求包和响应包的Identifier应相同。
Length： 包长度；2字节；整个包中所有域的长度。
Authenticator：16 字节长；用于验证RADIUS服务器传回来的请求以及密码隐藏算法上。
该验证字分为两种：
1、请求验证字—Request Authenticator
用在请求报文中,必须为全局唯一的随机值。
2、响应验证字—Response Authenticator
用在响应报文中，用于鉴别响应报文的合法性。
响应验证字＝MD5(Code+ID+Length+请求验证字+Attributes+Key)
Attributes：属性

图10 属性格式
属性域是TLV结构编码。

测试用例图
下图为用户端PPPOE，Radius Server和BAS交互的认证上线和下线的过程。

报文1：BAS请求Radius Server认证报文。
报文2：Radius Server回应BAS认证通过报文。
报文3：BAS计费请求报文。
报文4：Radius Server计费响应报文。
报文5：BAS计费结束报文。
报文6：Radius Server计费结束响应报文。
从中可以看出对于报文请求和响应是通过IP地址+Radius 协议域中ID号进行配对识别的。

上图显示了BAS发起的Radius认证请求（Code＝1）报文的结构。Radius报文是承载在UPD协议之上的，这里我没不关注上层报文的结构。
下图为PPPOE CHAP认证过程的Radius认证请求报文和PPPOE中CHAP认证的Challenge报文。通过比较可以方便看出BAS发出的Challenge值为“26fe8768341de68a72a1276771e1c1ca”与PPPOE中CHAP认证过程中BAS发给PPPOE用户的Challenge值是一致的。


下图为PPPOE用户发为BAS的经过CHAP加密后的用户密码和BAS发给Radius Server中认证请求报文用户秘密属性域的比较。可以看出在Radius 认证过程中，BAS设备将Challenge属性和用户加密后的密码发给Radius进行验证。


通过比较可以清楚了解协议各字段含义相互关系，为问题处理提供有效的手段。
下面为PPPOE用户Radius认证的Sniffer捕获的报文。