Ich analysiere Openflow-Pakete mit Java, indem ich den Port 6633 öffne und OF-Pakete abhöre.Länge von OF_packet_data, die die Gesamtlänge von OF_IN_packet überschreiten
Mein Code bricht für einige openflow PACKET_IN-Pakete. Siehe das folgende Bild.
Ich simuliere Topologie mit 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 Version: 2.0.2
Es folgt der Screenshot von wireshark-Capture.
Sie können diese Gesamtlänge beobachten (342) überschreitet Länge (170).
Aus diesem Grund analysiert mein Java-Code zusätzliche Paket-Bytes (wegen unpassender Datenlänge: 342), d. H. Bytes vom nächsten Paket, wodurch die folgenden analysierten Pakete beschädigt werden.
Es sollte aufhören zu lesen nach dem Lesen von 170 Bytes. Und dann sollte das Parsen für das nächste Paket beginnen.
Können Sie erklären, warum das passiert?
Hallo Christopher, schlagen Sie vor, den Puffer in 170-Byte-Segmente zu segmentieren? Momentan bewegt sich der Puffer weiter, um das nächste Segment im Puffer zu analysieren, wenn das gesamte Openflow-Paket geparst wird, dh einschließlich des OFType - OFPacketIn. Sobald also die Daten im Packet-In bis an ihr Limit gelesen werden, wird der Puffer verschoben zur nächsten Position des Segments. Das Problem, das gesehen wird, ist, dass das erste Paket korrekt analysiert wird und dann der gesamte Puffer gelesen wird, dh alle nachfolgenden Segmente. Sollte es eine harte 170-Byte-Segmentprüfung geben, und zwar sobald Ist erfüllt, Position wird auf nächstes Segment hingewiesen? –
Nein, aus welchem Grund auch immer, 170 Bytes/342 Bytes wurden in diesem Segment gesendet, was bedeutet, dass ein anderes Segment die verbleibenden 172 Bytes enthält. TCP ist ein Streaming-Protokoll und Segmente stimmen nicht notwendigerweise mit Paketen überein. Also sollte Ihre Java-Anwendung zuerst 14 Bytes lesen, um die Gesamtlänge zu erhalten und dann diese viel mehr Bytes lesen (weniger 14, wenn sie bereits in der Gesamtlänge enthalten sind). Wenn es im aktuellen Segment nicht so viele Bytes gibt, sollte es die Bytes, die es bisher gelesen hat, speichern und weiterlesen, bis es alle 342 Bytes gelesen hat. An diesem Punkt wird es die gesamte Nutzlast haben. –
Nachdem ich die [Openflow spec] [1] erneut gelesen habe, glaube ich, dass meine frühere Annahme falsch war. Die Gesamtlänge scheint die Anzahl der Bytes in der Nachricht zu sein, von denen nur "Längen" -Bytes an die Steuerung gesendet wurden. Dies scheint sinnvoller zu sein, da die Openflow- und TCP-Länge übereinstimmen und Wireshark ein fehlerhaftes Bootp-Paket anzeigt, was wahrscheinlich passieren würde, wenn das Paket abgeschnitten würde. Am Ende sieht das normal aus und sollte erwartet werden. [1]: https: //www.cs.princeton.edu/kurse/archiv/fall13/cos597E/papers/openflow-spec-v1.3.2.pdf –