Page MenuHomeFreeBSD

if_bridge(4): ensure all traffic passing over the bridge is accounted for
ClosedPublic

Authored by kevans on Mar 17 2019, 7:39 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 24 2024, 12:45 PM
Unknown Object (File)
Dec 24 2023, 12:12 AM
Unknown Object (File)
Dec 20 2023, 1:41 AM
Unknown Object (File)
Dec 4 2023, 12:19 AM
Unknown Object (File)
Nov 1 2023, 12:44 PM
Unknown Object (File)
Oct 11 2023, 2:21 PM
Unknown Object (File)
Sep 9 2023, 11:50 PM
Unknown Object (File)
Sep 7 2023, 9:13 AM
Subscribers

Details

Summary

Consider a bridge0 with em0 and em1 members. Traffic rx'd by em0 and transmitted by bridge0 through em1 gets accounted for in IPACKETS/IBYTES and bridge0 bpf -- assuming it's not unicast traffic destined for em1. Unicast traffic destined for em1 traffic is not accounted for by any mechanism, and isn't pushed through bridge0's bpf machinery as any other packets that pass over the bridge do.

Fix this and simplify GRAB_OUR_PACKETS by bailing out early if it was rx'd by the interface that it was addressed for. Everything else there is relevant for any traffic that came in from one member that's being directed at another member of the bridge -- it should be visible via bpf on the bridge, it should increment IPACKETS/IBYTES because the traffic -is- flowing over the bridge, and it should go ahead and trigger on the physical interface because it's locally destined traffic.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable