1
私はopenflowパケットを解析する際に、6633ポートを開いてOFパケットを待ちます。OF_packet_dataの長さがOF_IN_packetの長さを超えています
オープンフローのPACKET_INパケットでコードが破損しています。次の画像を参照してください。
私はミニネットを使ってトポロジーをシミュレートしています。
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バイトを読み込んだ後で解析を停止する必要があります。そして、次のパケットの解析を開始する必要があります。
なぜこのようなことが起こるのか説明できますか？
こんにちはChristopher、バッファを170バイトのセグメントに分割することをお勧めしますか？現在、バッファは、Openflowパケット全体が解析されたとき、すなわちOFType-OFPacketInを含む、バッファ内の次のセグメントを解析するために移動する。パケットインのデータが限界まで読み込まれるとすぐに、バッファが移動される次のセグメントの位置に移動します。最初のパケットが正しく解析され、バッファ全体が読み取られている、つまりすべての後続のセグメントが見えているという問題があります。170バイトのハードセグメントチェックが必要です。位置が次のセグメントを指しているか？ –
いいえ、何らかの理由で170バイト/ 342バイトがこのセグメントで送信されました。つまり、別のセグメントには残りの172バイトが含まれます。 TCPはストリーミングプロトコルであり、セグメントはパケットと必ずしも一致しない。 Javaアプリでは最初に14バイトを読み込んで合計長を取得し、さらに多くのバイト数を読み込んでください（既に合計長に含まれている場合は14バイト未満です）。現在のセグメントに多くのバイトがない場合は、これまでに読み込んだバイトを保存し、342バイトすべてを読み取るまで読み取りを続行する必要があります。その時点で、ペイロード全体を持ちます。 –
[Openflow spec] [1]を再読み込みした後、以前の私の仮定は間違っていたと思います。合計の長さは、メッセージのバイト数のように見えます。そのうちの「長さ」バイトだけがコントローラに送信されています。これは、OpenflowとTCPの長さの一致とWiresharkが不正な形式のbootpパケットを示しているという意味で、パケットが切り捨てられた場合に起こる可能性が高いと考えられます。結局、これは正常に見え、期待されるべきです。 [1]：https：//www.cs.princeton。edu/courses/archive/fall13/cos597E/papers/openflow-spec-v1.3.2.pdf –