參考地址：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有類似的以太網類型配置？