以太网帧格式

浅谈以太网帧格式                                      

一、Ethernet帧格式的发展

1980 DEC,Intel,Xerox制订了Ethernet I的标准
1982 DEC,Intel,Xerox又制订了Ehternet II的标准
1982 IEEE开始研究Ethernet的国际标准802.3
 1983 迫不及待的Novell基于IEEE的802.3的原始版开发了专用的Ethernet帧格式
1985 IEEE推出IEEE 802.3规范,后来为解决EthernetII与802.3帧格式的兼容问题,
推出折衷的Ethernet SNAP格式

(其中早期的Ethernet I已经完全被其他帧格式取代了 ,所以现在Ethernet只能见到后面几种Ethernet的帧格式,
现在大部分的网络设备都支持这几种Ethernet的帧格式,
如:cisco的路由器再设定Ethernet接口时可以指定不同的以太网的帧格式:arpa,sap,snap,novell-ether)

二.各种不同的帧格式
 下面介绍一下各个帧格式 
1.Ethernet II
就是DIX以太网联盟推出的。。。。 它由6个字节的目的MAC地址,6个字节的源MAC地址,
2个字节的类型域(用于标示封装在这个Frame、里面 数据的类型)以上为Frame Header,
接下来是46--1500字节的数据,和4字节的帧校验
2.Novell Ethernet
它的帧头与Ethernet有所不同其中EthernetII帧头中的类型域变成了长度域,
 后面接着的两个字节为0xFFFF,用于标示这个帧是Novell Ether类型的Frame,
由于前面的0xFFFF站掉了两个字节所以数据域缩小为44-1498个字节,帧校验不变。
3.IEEE 802.3/802.2
 802.3的Frame Header和Ethernet II的帧头有所不同,EthernetII类型域变成了长度域。
 其中又引入802.2协议(LLC)在802.3帧头后面添加了一个LLC首部,
由DSAP(Destination Service Access Point)1 byte,SSAP(Source SAP),一个控制域--1 byte! SAP用于标示帧的上层协议。

4.Ethernet SNAP
 SNAP Frame与802.3/802.2 Frame的最大区别是增加了一个5 Bytes的SNAP ID
其中前面3个byte通常与源mac地址 的前三个bytes相同为厂商代码!
 有时也可设为0,后2 bytes与Ethernet II的类型域相同。。。


 三.如何区分不同的帧格式
  
Ethernet中存在这四种Frame那些网络设备又是如何识别的呢? 如何区分EthernetII与其他三种格式的Frame
如果帧头跟随source mac地址的2 bytes的值大于1500,则此Frame为EthernetII格式的
   
接着比较紧接着的两bytes如果为0xFFFF则为Novell Ether类型的Frame,
如果为0xAAAA则为Ethernet SNAP格式的Frame ,如果都不是则为Ethernet 802.3/802.2格式的帧

 几种以太网帧格式
 
 
相当长的一段时间里我都没搞明白一个很基础的问题---以太网的封装格式;最近查了查相关文档,总结如下;
 
首先说明一下,Ethernet和802.3并不是一回事,虽然我们经常混用这两个术语;
 
历史上以太网帧格式有五种:
 
1.Ethernet V1:这是最原始的一种格式,是由Xerox PARC提出的3Mbps CSMA/CD以太网标准的封装格式,
 后来在1980年由DEC,Intel和Xerox标准化形成Ethernet V1标准;
 
2.Ethernet V2(ARPA):这是最常见的一种以太网帧格式,也是今天以太网的事实标准,
 由DEC,Intel和Xerox在1982年公布其标准,主要更改了Ethernet V1的电气特性和物理接口,
 在帧格式上并无变化;Ethernet V2出现后迅速取代Ethernet V1成为以太网事实标准;
Ethernet V2帧头结构为6bytes的源地址+6bytes的目标地址+2Bytes的协议类型字段+数据。
 常见协议类型如下:
0800       IP
 0806       ARP
 8137       Novell IPX
 809b       Apple Talk
如果协议类型字段取值为0000-05dc(十进制的0-1500),则该帧就不是Ethernet V2(ARPA)类型了,而是下面讲到的三种802.3帧类型之一;
Ethernet可以支持TCP/IP,Novell IPX/SPX,Apple Talk Phase I等协议;RFC 894定义了IP报文在Ethernet V2上的封装格式;
 
3.RAW 802.3:这是1983年Novell发布其划时代的Netware/86网络套件时采用的私有以太网帧格式,
 该格式以当时尚未正式发布的802.3标准为基础;
 但是当两年以后IEEE正式发布802.3标准时情况发生了变化—IEEE在802.3帧头中又加入了802.2 LLC(Logical Link Control)头,
 这使得Novell的RAW 802.3格式跟正式的IEEE 802.3标准互不兼容;可以看到在Novell的RAW 802.3帧结构中并没有标志协议类型的字段,
 而只有Length字段(2bytes,取值为0000-05dc,即十进制的0-1500),因为RAW 802.3帧只支持IPX/SPX一种协议;
 
4.802.3/802.2 LLC:这是IEEE 正式的802.3标准,它由Ethernet V2发展而来。
 它将Ethernet V2帧头的协议类型字段替换为帧长度字段(取值为0000-05dc;十进制的1500);
 并加入802.2 LLC头用以标志上层协议,LLC头中包含DSAP,SSAP以及Crontrol字段;
 常见SAP值:
0         Null LSAP        [IEEE]
 4        SNA Path Control         [IEEE]
 6        DOD IP        [79,JBP]
 AA         SNAP        [IEEE]
 FE        Global DSAP        [IEEE]
 SAP值用以标志上层应用,但是每个SAP字段只有8bits长,
 而且其中仅保留了6比特用于标识上层协议,因此所能标识的协议数有限(不超过32种);
 并且IEEE拒绝为某些重要的协议比如ARP协议定义SAP值(奇怪的是同时他们却定义了IP的SAP值);
 因此802.3/802.2 LLC的使用有很大局限性;
 
5.802.3/802.2 SNAP:这是IEEE为保证在802.2 LLC上支持更多的上层协议同时更好的支持IP协议而发布的标准,
 与802.3/802.2 LLC一样802.3/802.2 SNAP也带有LLC头,但是扩展了LLC属性,
 新添加了一个2Bytes的协议类型域(同时将SAP的值置为AA),
 从而使其可以标识更多的上层协议类型;
 另外添加了一个3Bytes的OUI字段用于代表不同的组织,RFC 1042定义了IP报文在802.2网络中的封装方法和ARP协议在802.2 SANP中的实现;
 
今天的实际环境中大多数TCP/IP设备都使用Ethernet V2格式的帧。
 这是因为第一种大规模使用的TCP/IP系统(4.2/3 BSD UNIX)的出现时间介于RFC 894和RFC 1042之间,
 它为了避免不能和别的主机互操作的风险而采用了RFC 894的实现;
 也由于大家都抱着这种想法,所以802.3标准并没有如预期那样得到普及;
 
CISCO设备的Ethernet Interface默认封装格式是ARPA(Ethernet V2)

不同厂商对这几种帧格式通常有不同的叫法,比如:
Frame Type         Novel        Cisco
 Ethernet Version 2        Ethernet_II        arpa
 802.3 Raw        Ethernet_802.3        novell_ether
 IEEE 802.3/802.2        Ethernet_802.2        sap
 IEEE 802.3/802.2 SNAP        ETHERNET_SNAP        snap
**************************************************************************************************************************************

 

 

一、 以太网数据帧的格式分析

大家都知道我们目前的局域网大多数是以太网,但以太网有多种标准,其数据帧有多种格式,恐怕有许多人不是太清楚,本文的目的就是通过帧格式和Sniffer捕捉的数据包解码来区别它们。

以太网这个术语一般是指数字设备公司(Digital Equipment)、英特尔公司(Intel)和施乐公司(Xerox)在1982年联合公布的一个标准(实际上它是第二版本,第一版本早在1972年 就在施乐公司帕洛阿尔托研究中心PARC里产生了)。它是目前TCP/IP网络采用的主要的局域网技术。它采用一种称作CSMA/CD的媒体接入方法,其 意思是带冲突检测的载波侦听多路接入(Carrier Sense, Multiple Access with Collision Detection)。它的速率为10 Mb/s,地址为48 bit。

1985年,IEEE(电子电气工程师协会) 802委员会公布了一个稍有不同的标准集,其中802.3针对整个CSMA/CD网络,802.4针对令牌总线网络,802.5针对令牌环网络。这三者的 共同特性由802.2标准来定义,那就是802网络共有的逻辑链路控制(LLC)。不幸的是,802.2和802.3定义了一个与以太网不同的帧格式,加 上1983年Novell为其Netware开发的私有帧,这些给以太网造成了一定的混乱,也给我们学习以太网带来了一定的影响。

1、通用基础

数据链路层头(Header)是数据链路层的控制信息的长度不是固定的,根据以太网数据帧的 格式的不同而不同,那么判断IEEE802.3、IEEE802.3 SNAP、Ethernet Version2、Netware 802.3 “Raw”这些数据帧的最主要依据也源于Header的变化。

从Sniffer捕捉数据包中也可以看出,Sniffer捕捉数据包的时候是掐头去尾的,不 要前面的前导码,也丢弃后面的CRC校验(注意它只是不在Decode里显示该区域,但并不代表它不去做数据包CRC校验),这就是很多人困惑为什么 Sniffer捕捉到的数据包长度跟实际长度不相符的原因。那么,Sniffer是如何来判断这些不同类型的以太网格式呢?

Sniffer可以判断出不同的以太网格式,这里需要注意的是,Sniffer在数据包解码 时有自己的格式,所以有Offset之说,offset ØE是指在Sniffer Hex解码窗口中从左向右第15位的数值。大家如果有点发懵的话,没有关系,看完后面的格式分析后再来分析前面提到的,相信一定能够明白?

下面我们通过一些具体的数据包来说明各种以太网格式的具体区别。

2、Ethernet Version2

以太网版本2是先于IEEE标准的以太网版本。

从数据包中可以看出,Ethernet V2通过在DLC头中2个字节的类型(Type)字段来辨别接收处理。类型字段是用来指定上层协议的(如0800指示IP、0806指示ARP等),它的 值一定是大于05FF的,它提供无连接服务的,本身不控制数据(DATA)的长度,它要求网络层来确保数据字段的最小包长度(46字节)。

Sniffer捕获的Ethernet V2帧的解码,可以看到在DLC层,源DLC地址后紧跟着就是以太网类型(Etehertype)值0800,代表上层封装的是IP报文,0800大于05FF,因而我们可以断定它是Ethernet V2的帧。

 

3、IEEE802.3

IEEE802.3把DLC层分隔成明显的两个子层:MAC层和LLC层,其中MAC层主要是指示硬件目的地址和源地址。LLC层用来提供一些服务:

– 通过SAP地址来辨别接收和发送方法

– 兼容无连接和面向连接服务

– 提供子网访问协议(Sub-network Access Protocol,SNAP),类型字段即由它的首部给出。

MAC层要保证最小帧长度不小于64字节,如果数据不满足64字节长度就必须进行填充。

是Sniffer捕获的IEEE802.3帧的解码,可以看到在DLC层源地址后紧跟着就是 802.3的长度(Length)字段0026,它小于05FF,可以肯定它不是Ethernet V2的帧,而接下来的Offset 0E处的值“4242”(代表DSAP和SSAP),既不是Novell 802.3 “Raw”的特征值“FFFF”,也不是IEEE 802.3 SNAP的特征值“AAAA”,因此它肯定是一个IEEE802.3的帧。

 

4、IEEE802.3 SNAP

SNAP (Sub-Network Access Protocol)子网访问协议,是逻辑链路控制(Logical Link Control)的一个子集,它允许协议不用通过服务访问点(SAP)即可实现IEEE兼容的MAC层功能,因此它在DSAP和SSAP域里的值是固定的 (AAAA)。也正源于此,它需要额外提供5个字节的头来指定接收方法,3个字节标识厂商代码,2个字节标识上层协议。

其MAC层保证数据帧长度不小于64字节,不足的话需要进行数据填充。

是Sniffer捕获的IEEE802.3 SNAP帧的解码,可以看到在DLC层源地址后紧跟着就是802.3的长度(Length)字段0175,它小于05FF,可以肯定它不是 Ethernet V2的帧,而接下来的Offset 0E处的值“AAAA”(代表DSAP和SSAP),这是IEEE 802.3 SNAP的特征值“AAAA”,因此可以断定它是一个IEEE802.3 SNAP的帧。

 

5、Novell Netware 802.3 “Raw”

虽然它的产生先于IEEE802.3规范,但已成为IEEE802.3规范的一部分。它仅使用DLC层的下半部,而不使用LLC。

802.3 “Raw”帧通过在DLC头中2个字节的长度(Length)字段来标记数据帧长度,而在长度字段后紧跟着就是两个字节的十六进制值FFFF,它是用来标识IPX协议头的开始。为了确保最小数据帧长度为64字节,MAC层会进行填充数据区域来确保最小长度。

在所有工作站都使用同一种数据帧类型情况下不会有什么问题,但如果是在混合以太网帧类型环境 中,Novell的这种以太网帧会造成负面影响:当Novell发出广播帧时,其FF字段正好是IEEE802.3帧中的服务访问点(SAP)域,它的 “FF”值代表着广播SAP,因此所有的工作站(不管是不是Netware工作站)都会拷贝,这会造成不必要的广播影响。

Sniffer捕获的Netware 802.3 “RAW”帧的解码,可以看到在DLC层源地址后紧跟着就是802.3的长度(Length)字段0120,它小于05FF,可以肯定它不是 Ethernet V2的帧,而接下来的Offset 0E处的值“FFFF”(代表IPX协议的开始),这是Netware 802.3 “Raw”的特征值“FFFF”,因此可以断定它是一个Novell 802.3 “Raw”的帧。

 

二、 Ethernet V2帧与IEEE 802.3帧的比较

因为这两种帧是我们在现在的局域网里最常见的两种帧,因此,我们对它们进行一些比较。

Ethernet V2可以装载的最大数据长度是1500字节,而IEEE 802.3可以装载的最大数据是1492字节(SNAP)或是1497字节; Ethernet V2不提供MAC层的数据填充功能,而IEEE 802.3不仅提供该功能,还具备服务访问点(SAP)和SNAP层,能够提供更有效的数据链路层控制和更好的传输保证。那么我们可以得出这样的结 论:Ethernet V2比IEEE802.3更适合于传输大量的数据,但Ethernet V2缺乏数据链路层的控制,不利于传输需要严格传输控制的数据,这也正是IEEE802.3的优势所在,越需要严格传输控制的应用,越需要用 IEEE802.3或SNAP来封装,但IEEE802.3也不可避免的带来数据装载量的损失,因此该格式的封装往往用在较少数据量承载但又需要严格控制 传输的应用中。

在实际应用中,我们会发现,大多数应用的以太网数据包是Ethernet V2的帧(如HTTP、FTP、SMTP、POP3等应用),而交换机之间的BPDU(桥协议数据单元)数据包则是IEEE802.3的帧,VLAN Trunk协议如802.1Q和Cisco的CDP(思科发现协议)等则是采用IEEE802.3 SNAP的帧。大家有兴趣的话,可以利用Sniffer等协议分析工具去捕捉数据包,然后解码查看是不是这样的。

来自: http://support.huawei.com/ecommunity/bbs/10154435.html


1         以太网相关背景
以太网这个术语通常是指由DEC,Intel和Xerox公司在1982年联合公布的一个标准,它是当今TCP/IP采用的主要的局域网技术,它采用一种称作CSMA/CD的媒体接入方法。几年后,IEEE802委员会公布了一个稍有不同的标准集,其中802.3针对整个CSMA/CD网络,802.4针对令牌总线网络,802.5针对令牌环网络;此三种帧的通用部分由802.2标准来定义,也就是我们熟悉的802网络共有的逻辑链路控制(LLC)。由于目前CSMA/CD的媒体接入方式占主流,因此本文仅对以太网和IEEE 802.3的帧格式作详细的分析。
在TCP/IP世界中,以太网IP数据报文的封装在RFC 894中定义,IEEE802.3网络的IP数据报文封装在RFC 1042中定义。标准规定:
1)主机必须能发送和接收采用RFC 894(以太网)封装格式的分组;
2)主机应该能接收RFC 1042(IEEE 802.3)封装格式的分组;
3)主机可以发送采用RFC 1042(IEEE 802.3)封装格式的分组。如果主机能同时发送两种类型的分组数据,那么发送的分组必须是可以设置的,而且默认条件下必须是RFC 894(以太网)。
最常使用的封装格式是RFC 894定义的格式,俗称EthernetII或者Ethernet DIX。下面,我们就以EthernetII称呼RFC 894定义的以太帧,以IEEE802.3称呼RFC 1042定义的以太帧。
2         帧格式
Ethernet II和IEEE802.3的帧格式分别如下。
Ethernet II帧格式:
----------------------------------------------------------------------------------------------
| 前序     | 目的地址   | 源地址   | 类型     | 数据          | FCS   |
----------------------------------------------------------------------------------------------
| 8 byte   |   6 byte   | 6 byte  | 2 byte   | 46~1500 byte   | 4 byte|



IEEE802.3一般帧格式
      --------------------------------------------------------------------------------------------------------------
       | 前序    | 帧起始定界符 | 目的地址   | 源地址 | 长度   | 数据          |FCS   |
        ------------------------------------------------------------------------------------------------------------
       | 7 byte  |     1 byte   | 2/6byte   |2/6 byte| 2 byte | 46~1500 byte  | 4 byte|
Ethernet II和IEEE802.3的帧格式比较类似,主要的不同点在于前者定义的2字节的类型,而后者定义的是2字节的长度;所幸的是,后者定义的有效长度值与前者定义的有效类型值无一相同,这样就容易区分两种帧格式了。
一、         前序字段
前序字段由8个(Ethernet II)或7个(IEEE802.3)字节的交替出现的1和0组成,设置该字段的目的是指示帧的开始并便于网络中的所有接收器均能与到达帧同步,另外,该字段本身(在Ethernet II中)或与帧起始定界符一起(在IEEE802.3中)能保证各帧之间用于错误检测和恢复操作的时间间隔不小于9.6毫秒。
二、         帧起始定界符字段
该字段仅在IEEE802.3标准中有效,它可以被看作前序字段的延续。实际上,该字段的组成方式继续使用前序字段中的格式,这个一个字节的字段的前6个比特位置由交替出现的1和0构成。该字段的最后两个比特位置是11,这两位中断了同步模式并提醒接收后面跟随的是帧数据。
当控制器将接收帧送入其缓冲器时,前序字段和帧起始定界符字段均被去除。类似地当控制器发送帧时,它将这两个字段(如果传输的是IEEE802.3帧)或一个前序字段(如果传输的是真正的以太网帧)作为前缀加入帧中。
三、         目的地址字段
目的地址字段确定帧的接收者。两个字节的源地址和目的地址可用于IEEE802.3网络,而6个字节的源地址和目的地址字段既可用于Ethernet II网络又可用于IEEE802.3网络。用户可以选择两字节或六字节的目的地址字段,但对IEEE802.3设备来说,局域网中的所有工作站必须使用同样的地址结构。目前,几乎所有的802.3网络使用6字节寻址,帧结构中包含两字节字段选项主要是用于使用16比特地址字段的早期的局域网。
四、         源地址字段
源地址字段标识发送帧的工作站。和目前地址字段类似,源地址字段的长度可以是两个或六个字节。只有IEEE802.3标准支持两字节源地址并要求使用的目的地址。Ethernet II和IEEE802.3标准均支持六个字节的源地址字段。当使用六个字节的源地址字段时,前三个字节表示由IEEE分配给厂商的地址,将烧录在每一块网络接口卡的ROM中。而制造商通常为其每一网络接口卡分配后字节。
五、         类型字段
两字节的类型字段仅用于Ethernet II帧。该字段用于标识数据字段中包含的高层协议,也就是说,该字段告诉接收设备如何解释数据字段。在以太网中,多种协议可以在局域网中同时共存,例如:类型字段取值为十六进制0800的帧将被识别为IP协议帧,而类型字段取值为十六进制8137的帧将被识别为IPX和SPX传输协议帧。因此,在Ethernet II的类型字段中设置相应的十六进制值提供了在局域网中支持多协议传输的机制。
在IEEE802.3标准中类型字段被替换为长度字段,因而EthernetII帧和IEEE802.3帧之间不能兼容。
六、         长度字段
用于IEEE802.3的两字节长度字段定义了数据字段包含的字节数。不论是在Ethernet II还是IEEE 802.3标准中,从前序到FCS字段的帧长度最小必须是64字节。最小帧长度保证有足够的传输时间用于以太网网络接口卡精确地检测冲突,这一最小时间是根据网络的最大电缆长度和帧沿电缆长度传播所要求的时间确定的。基于最小帧长为64字节和使用六字节地址字段的要求,意味着每个数据字段的最小长度为46字节。唯一的例外是吉比特以太网。在1000Mbit/s的工作速率下,原来的802.3标准不可能提供足够的帧持续时间使电缆长度达到100米。这是因为在1000Mbit/s的数据率下,一个工作站在发现网段另一端出现的任何冲突之前已经处在帧传输过程中的可能性很高。为解决这一问题,设计了将以太网最小帧长扩展为512字节的负载扩展方法。
对除了吉比特以太网之外的所有以太网版本,如果传输数据少于46个字节,应将数据字段填充至46字节。不过,填充字符的个数不包括在长度字段值中。同时支持以太网和IEEE802.3帧格式的网络接口卡通过这一字段的值区分这两种帧。也就是说,因为数据字段的最大长度为1500字节,所以超过十六进制数05DC的值说明它不是长度字段(IEEE802.3).而是类型字段(Ethernet II)。
七、         数据字段
如前所述,数据字段的最小长度必须为46字节以保证帧长至少为64字节,这意味着传输一字节信息也必须使用46字节的数据字段:如果填入该该字段的信息少于46字节,该字段的其余部分也必须进行填充。数据字段的最大长度为1500字节。
八、         校验序列字段
既可用于Ethernet II又可用于IEE802.3标准的帧校验序列字段提供了一种错误检测机制,每一个发送器均计算一个包括了地址字段、类型/长度字段和数据字段的循环冗余校验(CRC)码。发送器于是将计算出的CRC填入四字节的FCS字段。
虽然IEEE802.3标准必然要取代Ethernet II,但由于二者的相似以及Ethernet II作为IEEE802.3的基础这一事实,我们将这两者均看作以太网。
3         以太网帧结构的变种格式
以太网帧结构的变种,仅涉及到IEEE802.3帧。下图描述了IEEE802.3帧数据部分的结构,这个结构就是IEEE802.2定义的LLC(逻辑链路控制),LLC用来识别信息包中所承载的协议。LLC报头包含DSAP(destination service access point,目的服务访问点)、SSAP(source service access point,源服务访问点)和控制字段。
当DSAP和SSAP取特定值:0xff和0xaa时,会分别产生两个变种:Netware-以太网帧和以太网-SNAP帧;其他的取值均为纯802.3帧。

     -----------------------------------------------------------------------------------------------
      | 前序 | 帧起始定界符 | 目的地址   | 源地址   | 长度 | 数据   | FCS |
       -----------------------------------------------------------------------------------------------
                                                                   |            \
                                                                   |                \
                                                                   |                    \
                                                                   |                        \
                                                                   |                            \
                                                                   -------------------------------------- \
                                                                   | DSAP | SSAP | 控制 | 信息 |
                                                                   ---------------------------------------

一、Netware-以太网帧
Netware-以太网帧对IEEE802.3的数据字段进行了专门分隔以便传输NetWare类型的数据。实际使用的帧类型是在系统设置时通过将NetWare与特定类型的帧绑写而定义的。下图显示了Netware-以太网帧格式。图中的IPX=0xffff,也就是说,以太网帧中的DSAP=SSAP=0xff时,802.3帧就变成了Netware-以太网帧,用来承载NetWare类型的数据。由于不再有LLC字段,所以这种帧通常称为简化802.3。
对那些使用或考虑使用NetWare的人,在涉及帧类型时应该小心:Novell使用术语以太网-802.3,因此如果将NetWare设置为以太网-802.2帧,网络实际上是符合以太网-802.3标准的,也就是说,有LLC结构的。
        





   -----------------------------------------------------------------------------------------------
    | 前序   | 帧起始定界符 | 目的地址   | 源地址   | 长度   | 数据   | FCS |
   -----------------------------------------------------------------------------------------------
                                                                   |        \
                                                                   |             \
                                                                   |                \
                                                                   |                \
                                                                   |                   \
                                                                   -----------------------
                                                                   | IPX头 |   信息  |
                                                                   ------------------------

二、以太网-SNAP帧
以太网-SNAP帧与Netware-以太网帧不同,可以用于传输多种协议。因为在以太网-SNAP帧中包含以太网类型字段,故AppleTalk Phase II、NetWare及TCP/IP协议均能传输。因此,SNAP可以被看作一种扩展,它允许厂商创建自己的以太网传输协议。以太网-SNAP标准由IEEE802.1委员会制定以保证IEEE802.3局域网和以太网之间的互操作性。
下图显示了以太网-SNAP帧格式。尽管这种帧格式是基于IEEE802.3帧格式的,但它并不使用DSAP和SSAP信箱机制和控制字段。相反,在这些字段中使用特定的值表示该帧是SNAP帧。

-------------------------------------------------------------------------------------
| 前序   |定界符 | 目的地址   | 源地址   | 长度   | 数据   | FCS |
-------------------------------------------------------------------------------------
                                                        |         \
                                                        |              \
                                                       |                   \
                                                        |                        \
                                                        |                                 \
                                                        ------------------------------------------------
                                                        |DSAP|SSAP|控制|机构代码|类型|信息|
                                                        ------------------------------------------------

十六进制值AA被放置在DSAP和SSAP字段,而十六进制值03被放置在控制字段,这指明传输的是SNAP帧。将十六进制值03放置在控制字段表明使用无编码格式,这是SNAP帧支持的唯一一种格式。
机构代码字段指明在后续的以太网类型字段中放置的是由哪一个机构分配的值。在机构代码字段中的十六进制值00-00-00指明施乐公司分配了以太网类型字段的值。通过使用以太网-SNAP帧,可以按与原始的以太网帧类似的方式获得支持多协议的能力,原始以太网设置类型字段的目的与此相同。
4         帧判定
接收工作站可以通过判断以太帧的字段正确解释帧中承载的数据。为此,应首先检查跟在源地址之后的两个字节的值。如果该值大于1500,则必定是Ethernet II帧;否则该帧或者是纯IEEE802.3帧,或者是这种帧的变种。此时,必须检查更多的字节。
如果下面的两个字节取值十六进制FF:FF,则该帧是NetWare-以太网,这是因为在IPX头结构中前两个字节的校验和字段取值十六进制FF:FF;如果这两个字节取值为十六进制AA:AA,则表示是以太网-SANP帧;此外,这两个字节的任何其它取值均指示该帧纯802.3帧。 
5         IPX的四种以太帧封装格式
介绍了上面的四种以太帧的格式,现在以IPX报文为例,介绍如何利用四种以太帧的格式进行封装。
一、Ethernet II封装格式
-------------------------------------------------------------------------------------
| 前序   | 目的地址  | 源地址   | 0x8137   | IPX 数据报 | FCS   |
-------------------------------------------------------------------------------------
二、Netware-以太网帧
--------------------------------------------------------------------------------------------------------
| 前序   | 帧起始定界符 | 目的地址   | 源地址   | 长度   | IPX 数据报   | FCS |
---------------------------------------------------------------------------------------------------------
三、以太网-SNAP帧
---------------------------------------------------------------------------------------------------------------------------
|前序|定界符|目的地址|源地|长度|0xAA|0xAA|0x03|0x000000 |0x8137| IPX 报文 | FCS |
---------------------------------------------------------------------------------------------------------------------------
四、纯802.3帧
---------------------------------------------------------------------------------------------------------------------------
|前序|定界符|目的地址|源地|长度| 0xe0 | 0xe0| 0x03 | IPX 报文 | FCS |
---------------------------------------------------------------------------------------------------------------------------

 

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
  谷歌改良了ndk的开发流程,对于Windows环境下NDK的开发,如果使用的NDK是r7之前的版本,必须要安装Cygwin才能使用NDK。而在NDKr7开始,Google的Windows版的NDK提供了一个ndk-build.cmd的脚本,这样,就可以直接利用这个脚本编译,而不需要使用Cygwin了。只需要为Eclipse Android工程添加一个Builders,而为Eclipse配置的builder,其实就是在执行Cygwin,然后传递ndk-build作为参数,这样就能让Eclipse自动编译
文章系列 视频驱动V4L2子系统驱动架构 - 驱动框架 视频驱动V4L2子系统驱动架构 - ioctl 基于linux4.6.3,最后会附上一张ioctl调用总图,分析代码还是要用图来说明,这样更清晰一点,我就是这么分析的,不过平时分析的图很随便,而且很大,所以就不能在这里呈现,我在这里会贴出一个简略图 ioctl详解 进入ioctl都是从cdev-ops-ioctl进入的,一般的驱动cdev都是驱动自己初始化的,在v4l2架构中,cdev都已经初始化完成,不需要驱动开发者来初始化,下面是v4l2的cde
杂谈 最近在研究gradle ,插件化~自己碰到的坑很多.今天先总结一下 以下这三个都研究过,原理都是一样的,区别就在于用哪个更方便. 在这里我会讲述一下,这里面的原理和自己爬的坑,以便大家理解,还有少爬坑~~ 原理是需要懂得~ 不然,你遇到错误不会解决,并且你始终会是初级工程师~ 首先,按照顺序,介绍下目前三种热修复的方式: 1.Nuwa (基于gradle写的脚本,操作起来比较麻烦,需要拷贝和运行命令行~) https://github.com/jasonross/Nuwa 2.andfix (看过~
题记——  难过了,悄悄走一走;         伤心了,默默睡一觉;         优雅不是训练出来的,而是一种阅历;         淡然不是伪装出来的,而是一种沉淀;         时间飞逝,老去的只是我们的容颜;         时间仿佛一颗灵魂,越来越动人; 1、简述:     在多线程的世界中,是那么的神奇 与 高效以及合理; 2、创建线程池实例     官方推荐使用Executors类工厂方法来创建线程池管理,Executors类是官方提供的一个工厂类,里面封装了好多功能不一样的线程池,
书接上回,我们已经了解了一些关于适配的一些相关概念,接下来我们会了解一下,在设置布局时我们应该注意的地方。 尽量不去设定具体的尺寸值。 为了确保布局适应各种尺寸的屏幕,在保证功能实现的前提下,最好不要写死一些尺寸,这样的硬编码,我们最好使用“match_parent”,”wrap_content”,”weight”这些不用指定具体的尺寸值的参数,这样视图就会根据自身需要的空间去充填。这样就可以让布局去适应各种屏幕的尺寸,当屏幕有旋转时也不会受到影响。 这里我们重点说一下“weight”,用过 LiearL

艺术般的波浪点击反馈效果 - 2016-07-24 17:07:27

Material Design之Rippledrawable 使用与简单封装(向下兼容至selector) 前言 Android 5.0问世以来,谷歌所推崇的Material Design得到业界的一致好评,其良好的UI规范与交互确实让界面交互友好和漂亮了不少,Rippledrawable便是其中之一,本博客今天着重讲如何将它运用到我们自己的项目中,并且封装得简单易用。 我们都知道,我们在之前做按钮或者布局的反馈效果,一般都用selector来实现,分别指定按下或正常状态的两种颜色即可,我们点击的效果也本
ubuntu环境 首先确定是否安装了Git管理工具 sudo apt-get install git 我选择SSH方式,比较安全方便,只需一次配置 1- 使用ssh命令连接github.com的SSH服务,登录名为git@github.com(所有GitHub用户共享此SSH用户名)。 wangxiong @Dell :~/Public/GitHubRepository/PaPaPlayer $ ssh - T git @github .com The authenticity of host 'gith
         每次看到iOS的远程消息推送,总是感觉很头大,即便后来项目都做完了,还是觉得摸不着远程推送的脉门,网上介绍的资料虽多,但不是写的太简单了,就是写的太详细了,不能一下抓住要点,今天终于能够抽出点时间,来扒一扒这其中究竟有怎样的奥秘。     根据苹果掌控一切的习惯,消息推送也当然不能例外,不论你在哪里推送,也不论你用什么方式推送,都必须首先把消息发给苹果的消息推送服务器APNs(Apple Push Notification Service),然后再由APNs发给指定的设备,也就是说消息推
Day02 Html、Css实战和WebView实现手机显示网页 1.html与css实战 1.1 程序猿小网页 先来看一下效果图 编程用图如下 实现代码如下 !DOCTYPE htmlhtml head meta charset="utf-8" title/title style #pic{ position: relative; float: left; } #text{ width: 400; height: 200; position: relative; float: left; font-si
前言 或许你知道了jni的简单调用,其实不算什么百度谷歌一大把,虽然这些jni绝大多数情况下都不会让我们安卓工程师来弄,毕竟还是有点难,但是我们还是得打破砂锅知道为什么这样干吧,至少也让我们知道调用流程和数据类型以及处理方法,或许你会有不一样的发现。 其实总的来说从java的角度来看.h文件就是java中的interface(插座),然后.c/.cpp文件呢就是实现类罢了,然后数据类型和java还是有点出入我们还是得了解下(妈蛋,天气真热不适合生存了)。 今天也给出一个JNI动态注册native方法的例子