参考地址：http://blog.sina.com.cn/s/blog_539739ea0101heer.html
上周同事在现场遇到一个问题 ：windows系统能够与所有PLC正常通讯，但嵌入式网关设备和Linux系统无法与部分PLC(192.168.1.13)通讯，PING也不通。
同事在现场做了两个测试：
测试1：
在原有的环境上,在交换机中接入一台笔记本A(WIN7).
A可以PING通PLC和工业通讯网关，工业通讯网关可以PING通A，但PING不能PLC.
测试2:
去掉工业通讯网关，笔记本A(安装了WIN7和Ubuntu双系统，两个操作系统中使用的网卡以及IP地址、子网掩码等完全一样)在Ubuntu系统中也PING不通PLC，在WIN系统中可以PING通。
同事反馈此问题后，通过google查询了相关的一些资料后，解决了问题，下面将分析的过程和最终的解决办法分享出来，给遇到此类问题的同学一些帮助。
ping这种网络层的链路检测机制是无法识别源操作系统的。
因此从描述的现象来看，应该是与ping这个动作发起的操作系统是无关的。
这里多说几句，ping报文倒是可以检测目的地址的操作系统类型的。
一般来说，通过目的地址返回的TTL值即可判断目的地址的操作系统类型：
LINUX 64
WIN2K/NT 128
WINDOWS 系列 32
UNIX 系列 255
既然ping的目的地址并不识别源的类型，那么引起这种现象的原因会是什么？
可能会有几种原因，我目前只能说出两种：
1） 目的地址的系统设置造成了这种现象。
2） 交换机（只能是可网管型交换机）通过访问控制列表（ACL）设置了允许范围的IP范围。
3） 其他，暂不清楚。
由于现场网络环境为标准以太网环境，而且另外一位同事将现场截获的报文查看后说PLC返回的arp报文为 IEEE802.3 SNAP 格式的报文。因此，按照以太网协议这条线索向下分析和追踪。
查阅了官方的一些资料后，了解到历史上以太网帧格式有五种:
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标准互不兼容.
4.802.3/802.2 LLC：这是IEEE 正式的802.3标准，它由Ethernet V2发展而来。它将Ethernet V2帧头的协议类型字段替换为帧长度字段(取值为0000-05dc;十进制的1500)；并加入802.2 LLC头用以标志上层协议，LLC头中包含DSAP，SSAP以及Crontrol字段.
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中的实现.
目前，有四种不同格式的以太网帧在使用，它们分别是：
●Ethernet II即DIX 2.0：Xerox与DEC、Intel在1982年制定的以太网标准帧格式。Cisco名称为：ARPA。
●Ethernet 802.3 raw：Novell在1983年公布的专用以太网标准帧格式。Cisco名称为：Novell-Ether。
●Ethernet 802.3 SAP：IEEE在1985年公布的Ethernet 802.3的SAP版本以太网帧格式。Cisco名称为：SAP。
●Ethernet 802.3 SNAP：IEEE在1985年公布的Ethernet 802.3的SNAP版本以太网帧格式。Cisco名称为：SNAP。
4种以太网的帧格式如下图：
不同格式的以太网帧的各字段定义都不相同，彼此也不兼容。
Ethernet中存在这四种Frame那些网络设备又是如何识别的呢? 如何区分EthernetII与其他三种格式的Frame？
1）如果帧头跟随source mac地址的2 bytes的值大于1500,则此Frame为EthernetII格式；
2）接着比较紧接着的两bytes如果为0xFFFF则为Novell Ether类型的Frame；
3）如果为0xAAAA则为Ethernet SNAP格式的Frame；
4）如果都不是则为Ethernet 802.3/802.2格式的帧。
4种以太网帧格式的汇总图例如下：
在实际应用中， 我们会发现这几种帧格式的常用场合：
大多数应用的以太网数据包是 Ethernet V2 的帧 （如 HTTP、FTP、 SMTP、 POP3 等应用） ；
而交换机之间的 BPDU （桥协议数据单元） 数据包则是 IEEE802.3的帧；
VLAN Trunk 协议如 802.1Q和Cisco 的 CDP（思科发现协议）等则是采用 IEEE802.3 SNAP 的帧。
从上面的这句话“不同格式的以太网帧的各字段定义都不相同，彼此也不兼容。”那么我们是否可以这么猜测：PLC的系统和笔记本的系统之间是否会存在使用的以太网帧格式不兼容，所以无法通讯。
但可能会有同学会说：如果不兼容，那么应该所有PLC都不通才对啊，而且对同一PLC来说，为何Windows能通，而Linux不通呢？
我们是否可以进一步猜测：
PLC中可能存在以太网类型的设置！！！
Windows可识别多种以太网帧格式！！！
Linux默认只识别一种以太网帧格式！！！
按照上面的猜测思路，查询了PLC的配置手册（上面忘记说了，现场的PLC全是施耐德旗下的莫迪康（MODICON）的PLC，对外提供ModbusTCP的通讯协议。），在莫迪康（MODICON）PLC的配置软件中找到了以太网模块的配置。莫迪康（MODICON）PLC真的存在以太网类型的配置（下图的左下角）：以太网II 和 802.3
此现场的问题终于找到了原因，解决此问题的办法如下：
1. 修改现场莫迪康（MODICON）PLC的以太网配置，采用以太网 II。
2. 如果现场莫迪康（MODICON）PLC无法进行修改，那么为通讯网关增加对以太网帧格式802.3 SNAP的支持。
3. 采用Windows内核的通讯网关与现场的莫迪康（MODICON）PLC进行通讯。
问题算是解决了，还请各位PLC专家及个PLC厂家告知，市面上哪些厂家的PLC有类似的以太网类型配置？