☰

ブリッジからキャプチャされたパケットのRAWデバイス（物理デバイス）情報を取得する

tag-icon • tag-icon linux bridge socket vlan
ブリッジからキャプチャされたパケットのRAWデバイス（物理デバイス）情報を取得する

以下に、私のフレームワークが通過したいネットワークデバイスのセットがあるとしましょう。

eth0(1) -> bond0(2) -> ブリッジ(3) -> vlan100(4). >>>（数字）は各ネットワークデバイスのifindexです。

私は生のソケット（インターフェイスにバインドされていません）を作成し、特定のパケットセットのみをキャプチャするためにソケットフィルタを接続しました。

各ネットワークデバイスでキャプチャされたフレームのコピーを取得します。これが期待されるか。

キャプチャされた各パケットのfrom.sll_ifindexを印刷します。

frame trapped from eth0 has from.sll_ifindex=1 
frame trapped from bond0 has from.sll_ifindex=2 
frame trapped from bridge has from.sll_ifindex=3 
frame trapped from vlan100 has from.sll_ifindex=4

次に、次のソケットオプションPACKET_ORIGDEVを設定し、次の結果を取得します。

frame trapped from eth0 has from.sll_ifindex=1
frame trapped from bond0 has from.sll_ifindex=1   >> acceptable since the originating device is eth0 whose ifindex is 1.
frame trapped from bridge has from.sll_ifindex=3  >> why is this not set to 1?
frame trapped from vlan100 has from.sll_ifindex=3 >> why is this not set to 1?

上記のシナリオでPACKET_ORIGDEVソケットオプションが果たす役割を理解するのに役立つ人はいますか？

答え1

bond0フレームがコア内からコア内に変換される方法は、他の2つのbridge変換とは異なります。繰り返す代わりにanother_round内部的には、__netif_receive_skb_core()フレームは内部的に渡されますbr_handle_frame_finish()。orig_devこの呼び出しパスはこの情報を保持しません。私は、入力ポートがブリッジファミリーの一部のnetfilterフックで利用可能なだけ記録されていると思います。ユーザー空間では使用できません。

PACKET_ORIGDEV、導入されると、カプセル化の事例を扱うためのものです。橋にも適用する必要があると主張するかもしれませんが、私の考えではこれは簡単に実装できる変更ではありません。関連する機能のいくつかは、受信経路で重要です。

関連情報