Date: Wed, 17 May 2006 00:11:28 +0000 (UTC) From: "Christian S.J. Peron" <csjp@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/net if_bridge.c Message-ID: <200605170011.k4H0BSVO010832@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
csjp 2006-05-17 00:11:27 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_6)
sys/net if_bridge.c
Log:
MFC revision 1.55
Slightly re-worked bpf(4) code associated with bridging: if we have a
destination interface as a member of our bridge or this is a unicast packet,
push it through the bpf(4) machinery.
For broadcast or multicast packets, don't bother with the bpf(4) because it will
be re-injected into ether_input. We do this before we pass the packets through
the pfil(9) framework, as it is possible that pfil(9) will drop the packet or
possibly modify it, making it very difficult to debug firewall issues on the
bridge.
Further, implemented IFF_MONITOR for bridge interfaces. This does much the same
thing that it does for regular network interfaces: it pushes the packet to any
bpf(4) peers and then returns. This bypasses all of the bridge machinery,
saving mutex acquisitions, list traversals, and other operations performed by
the bridging code.
This change to the bridging code is useful in situations where individuals use a
bridge to multiplex RX/TX signals from two interfaces, as is required by some
network taps for de-multiplexing links and transmitting the RX/TX signals
out through two separate interfaces. This behaviour is quite common for network
taps monitoring links, especially for certain manufacturers.
Revision Changes Path
1.11.2.29 +26 -10 src/sys/net/if_bridge.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605170011.k4H0BSVO010832>