1. 程式人生 > >西門子S7comm協議解析 —— 利用Wireshark對報文逐位元組進行解析詳細解析S7comm所含功能碼以及UserData功能(path3)

西門子S7comm協議解析 —— 利用Wireshark對報文逐位元組進行解析詳細解析S7comm所含功能碼以及UserData功能(path3)

好了開始搞UserData這一塊了。

接著上一篇繼續

西門子S7comm協議解析 —— 利用Wireshark對報文逐位元組進行解析詳細解析S7comm所含功能碼以及UserData功能(path2)

 

說起這個UserData是屬於西門子後期加的一些功能,也就是這些功能讓S7這個協議變得更加豐富,也是因為這些功能讓S7變得很臃腫,也不利用使用。

雙刃劍沒辦法去評判。

 

這個我就按照我抓包的順序進行介紹吧,可能不會介紹完,但是基本上你明白一個其他的也就差不多了。

可以利用它明白它的某塊欄位的含義就行了,暫時我沒必要去深入的去了解他的原理,所以有些地方講的不會太細請見諒。

1、讀系統狀態 — 44 1

為什麼我把44 1 專門的寫上去呢 其實UserData也有對應的功能碼 但是太雜亂

44 是功能的大體方向 1 是具體功能

發包

 

 

這個Header頭部跟其他的都一樣  我就直接把上一篇的複製過來,重點還是引數部分。

Byte[0] 為 協議ID  這個只要是S7comm協議一般都是指定0x32

Byte[1] 為 PDU型別  這個只要是Userdata都是07

Byte[2]Byte[3] 冗餘資料,通常為0×0000

Byte[6]Byte[7] 引數的總長度也就是parameter的長度

Byte[8]Byte[9] 資料的長度、也就是data部分資料的長度如果無即為0

Parameter部分

Byte[0] Byte[1] Byte[2] 00 01 12 引數頭部資訊

Byte[3] 04 為之後的資料個數

Byte[4] 11 對應的是Request 也就是請求的意思

Byte[5] 44 這個因為wireshark 幫我們解析了8位前四位 0100 對應的就是Request請求

說明PDU是從主機請求裝置的後四位0100 對應的是所屬型別也就是CPU功能

Byte[6] 01 前面44是規定了大的方向這個01就是具體要幹什麼了圖中01就是read szl

在這裡解釋一下szl 是什麼ssl縮寫是系統狀態 S7協議是德國西門子的德國狀態的是Z開頭的所以縮寫為 szl

Byte[7] 字面意思由主機指定順序

Data部分

Byte[0] FF 返回碼 返回碼常見如下表

0x00       Reserved 未定義,預留

0x01       Hardware error   硬體錯誤

0x03       Accessing the object not allowed 物件不允許訪問

0x05       Invalid address     無效地址,所需的地址超出此PLC的極限

0x06       Data type not supported     資料型別不支援

0x07       Data type inconsistent 日期型別不一致

0x0a       Object does not exist    物件不存在

0xff     Success  成功

Byte[1] 09 指的資料型別,通常有bit、byte等 常見資料型別如下表

0     NULL

3     BIT bit access, len is in bits

4     BYTE/WORD/DWORD     byte/word/dword access, len is in bits

5     INTEGER    integer access, len is in bits

6     DINTEGER  integer access, len is in bytes

7     REAL    real access, len is in bytes

9     OCTET STRING octet string, len is in bytes

Byte[2]Byte[3] 00 04 後面資料的個數

SZL部分

前四位為操作的物件是什麼 0000 為CPU 1100為cp 1000為fm 0100為im

中間0000 0000 0000 0000是wireshark解析錯了按照官方的應該為四位

後八位 表明的是區域性列表的序號 我們只需要關注最後兩位就行(0x00)下面是各類的序號圖

 這麼一來是不是看起來UserData這一塊也沒那麼難對吧,繼續來看回包吧。

回包

Header頭部不做描述了與之前都相同的自己對比就可以

Parameter部分

00 01 12 與發包一致

08  長度

12  對應的Response 迴應請求

84  前四位1000 對應的就是 Response  後四位 0100就是要讀CPU

01  讀系統狀態SZL

00  與發包一致

00  資料的編號

00  字譯最後一個數據單元

00  錯誤碼

Data部分

FF 返回碼

09  指的資料型別

00 e8 後面資料個數

SZL-ID 和 Index 跟發包是一樣的不做介紹了

00 02   是一個數據佔用多少bytes

00 70   轉換為10進製為112 代表了有112個SZL_data_tree (圖太大就沒截下去)

後面的PDU就不在分析了都是做讀取相關類的相關資訊、只不過是指定的區域性列表不同、index不同罷了。

2、時間設定 —— 47 1 

47 1對應的也就是讀時間

發包

 可以看出基本與讀SZL狀態是一樣的我在整體標記一下吧

回包

Parameter部分

Data部分

 3、寫時間 47 2

發包

與讀時間是一樣的只不過data部分是在發包階段。

因為要寫時間 那麼肯定發包的時候會攜帶時間資訊對吧,這個也很容易去理解。

回包

這麼一看是不是基本是一樣。

自己比對一下就OK了

 

未完待續..... 有一些眼痠了先放著吧明天在新增

&n