From owner-cvs-src@FreeBSD.ORG Fri Mar 3 05:58:20 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 702ED16A420; Fri, 3 Mar 2006 05:58:20 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DEFB43D45; Fri, 3 Mar 2006 05:58:20 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.1/8.13.1) with ESMTP id k235wJqL010044; Fri, 3 Mar 2006 05:58:20 GMT (envelope-from csjp@repoman.freebsd.org) Received: (from csjp@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id k235wJ1B010043; Fri, 3 Mar 2006 05:58:19 GMT (envelope-from csjp) Message-Id: <200603030558.k235wJ1B010043@repoman.freebsd.org> From: "Christian S.J. Peron" Date: Fri, 3 Mar 2006 05:58:18 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/sys/net if_bridge.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2006 05:58:20 -0000 csjp 2006-03-03 05:58:18 UTC FreeBSD src repository Modified files: sys/net if_bridge.c Log: 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. Reviewed by: thompsa MFC after: 1 month Sponsored by: Seccuris Labs Revision Changes Path 1.55 +26 -10 src/sys/net/if_bridge.c