☰

获取桥上捕获的数据包的原始设备（物理设备）信息

tag-icon • tag-icon linux bridge socket vlan
获取桥上捕获的数据包的原始设备（物理设备）信息

让我们假设下面给出的是我的框架打算遍历的一组网络设备。

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帧从内核内部转换到内核内部的方式bridge与其他两种转换不同。而不是循环 foranother_round在内部__netif_receive_skb_core()，帧在内部转发br_handle_frame_finish()。orig_dev该调用路径不保留该信息。我认为输入端口的记录时间仅足以使其可供桥接系列的某些 netfilter 挂钩使用。它不可用于用户空间。

PACKET_ORIGDEV，当它被引入时，旨在涵盖封装案例。有人可能会说，它也应该适用于桥接，但在我看来，这并不是一个可以轻易实施的改变。一些涉及的功能在接收路径中很热。

相关内容