web-dev-qa-db-ja.com

プログラムでtcpdumpキャプチャファイルを使用してOpenFlowパケットを解析する方法

私はOpenFlowパケットを使用しており、tcpdumpを介してネットワークを分析しています。

現在、WireShark GUIを使用して、生成されたキャプチャファイルを解析していますが、それは私のニーズに応えます。

ただし、WireSharkにAPIがあり、GUIではなくスクリプトを介して同じことができるかどうか疑問に思っていました（基本的に、特定のOpenFlowパラメーターを抽出し、システムをチェックするプロセスを自動化することを目指しています）

wiresharktcpdumpopenflow
4
spiritusozeans

WireSharkに代わるコマンドラインはtsharkです（tcpdumpと機能が似ています）。

このブログ 私が始めるのに十分でした。

サンプルのtsharkキャプチャコマンドは次のようになります（インターフェイスeth0を監視するとします）。

Sudo tshark -i eth0

コマンドとともにキャプチャフィルターを追加することもできます。

Sudo tshark -i eth0 "port 6633"

このコマンドは、ポート6633（OpenFlowコントローラーのデフォルトポート）との間のすべてのトラフィックをキャプチャします

トラフィックをキャプチャするだけでは不十分です。プログラムを介してキャプチャを分析するには、最初にキャプチャをわかりやすい形式に変換する必要があります。 XMLを入力します。

Sudo tshark -i eth0 -T pdml > dump.xml

これにより、キャプチャファイルがxmlファイルとして出力され、すべてのパケットとそのさまざまな属性がタグとして出力されます。

これは、その後、標準のxmlパーサーを使用して解析できます。

私が微調整したいくつかの追加事項：「ポート6633」を廃棄しました。また、-nオプションを追加しました（アドレスは解決されません）。結果としてキャプチャされる追加のパケットは、常にxmlパーサーによってフィルターで除外される場合があります。私のアプリケーションはさまざまなパケットのタイムスタンプをわずかに重要視していたので、フィルタリング/解決のために追加の遅延を引き起こしたくありませんでした。ここでの私の推論はひどく間違っているかもしれないことに注意してください（それはただの予感でした）。各パケットには、デバイスが同じタイムスタンプを受信したときに、ネットワークアダプタによってタイムスタンプが追加されます。したがって、そのようなトリックを使用してもタイムスタンプにまったく影響を与えない可能性が高いです。

したがって、私の最後のコマンドは次のとおりです。

Sudo tshark -n -i eth0 -T pdml > dump.xml

追記：WireSharkを使用してOpenFlowパケットをデバッグすることに慣れている場合は、おそらく表示フィルター「of」を使用します。ただし、これはtsharkで必要な有効なキャプチャフィルターではありません（キャプチャフィルターはtcpdumpで使用されるものと同様です）

PS：xmlパーサーが必要な場合は私に連絡してください（私はPythonを使用しました）

4
spiritusozeans

次の出力を確認してみてください。

Sudo tshark -O openflow_v4 -i eth0 port <openflow port>

このコマンドで使用可能なプロトコルを確認できます。

~] tshark -G protocols | grep openflow
OpenFlow        openflow        openflow
OpenFlow 1.0    openflow_v1     openflow_v1
OpenFlow 1.3    openflow_v4     openflow_v4
OpenFlow 1.4    openflow_v5     openflow_v5
2
Michael D