1
我使用java通過打開6633端口並偵聽OF數據包來解析openflow數據包。OF_packet_data的長度超過OF_IN_packet的總長度
我的代碼打破了一些openflow PACKET_IN數據包。看到下面的圖片。
我模擬使用mininet的拓撲。
mn --mac --switch ovsk,protocols=OpenFlow13 --controller remote,ip=172.23.107.166,port=6633 --ipbase=2.2.2.0/24 --topo linear,10
Mininet vesion:2.2.1rc1
Openvswitch版本:2.0.2
以下是Wireshark捕獲的屏幕截圖。
你可以看到,總長度(342)被超過長度(170)。
由於這個原因,我的java代碼正在解析額外的分組字節(因爲不適當的數據長度:342),即來自下一個分組的字節,從而下面的分組被解析。
它應該在讀取170個字節後停止解析。然後解析下一個數據包應該開始。
你能解釋爲什麼會發生這種情況?
克里斯托弗嗨,你在暗示分割出緩衝到170個字節段?目前,緩衝區移動到解析緩衝區中的下一個段時,整個OpenFlow的數據包進行解析,即包括OFType - OFPacketIn ..所以只要在分組中的數據讀取到它的極限,緩衝移動到下一段的位置..這是被視爲問題是第一個數據包被正確解析,然後讀取整個緩衝區,即所有後續段..如果有一個硬170字節段檢查,只要它是否滿足,位置指向下一個段? –
不,無論出於何種原因,在該段中發送了170字節/ 342字節,這意味着另一段將包含剩餘的172字節。 TCP是一種流媒體協議,段不一定與數據包重合。 所以,你的Java應用程序應該先讀14個字節獲得的總長度,然後讀取更多的字節(少14,如果他們已經包含在總長度)。如果當前段中沒有那麼多字節,那麼它應該保存到目前爲止讀取的字節,並繼續讀取,直到它讀取了所有342個字節。此時,它將具有整個有效載荷。 –
重新閱讀[Openflow規範] [1]後,我認爲我之前的假設是錯誤的。總長度似乎是消息中的字節數,其中只有「長度」字節已發送到控制器。這似乎更有意義,因爲Openflow和TCP長度匹配以及Wireshark指示格式錯誤的bootp數據包,這可能會在數據包被截斷時發生。所以最後,這看起來很正常,應該是可以預料的。 [1]:HTTPS://www.cs.princeton。edu/courses/archive/fall13/cos597E/papers/openflow-spec-v1.3.2.pdf –