OF_packet_data的長度超過OF_IN_packet的總長度

我使用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個字節後停止解析。然後解析下一個數據包應該開始。

你能解釋爲什麼會發生這種情況？

來源

2016-07-22 raptor

170個字節的TCP段長度就是 - 當前段的字節數。由於openflow總長度爲342字節，因此其數據跨越多個TCP段，因此您的java代碼需要能夠處理此問題。

來源

2016-08-02 17:43:01

克里斯托弗嗨，你在暗示分割出緩衝到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 –

OF_packet_data的長度超過OF_IN_packet的總長度

回答

相關問題