From owner-freebsd-net@FreeBSD.ORG Sun Oct 22 03:39:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D2CC16A407 for ; Sun, 22 Oct 2006 03:39:55 +0000 (UTC) (envelope-from prvs=julian=44322f810@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 109ED43D60 for ; Sun, 22 Oct 2006 03:39:54 +0000 (GMT) (envelope-from prvs=julian=44322f810@elischer.org) Received: from unknown (HELO [192.168.2.5]) ([10.251.60.42]) by a50.ironport.com with ESMTP; 21 Oct 2006 20:39:54 -0700 Message-ID: <453AE809.4030107@elischer.org> Date: Sat, 21 Oct 2006 20:39:53 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Max Laier References: <453977CA.8020807@elischer.org> <200610210358.51403.max@love2party.net> In-Reply-To: <200610210358.51403.max@love2party.net> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: more on pfil and bridging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 03:39:55 -0000 Max Laier wrote: > On Saturday 21 October 2006 03:28, Julian Elischer wrote: >> The more I look at this the more I think that it is broken. >> >> Instead of the bridge registering a separate filter queue for itself, >> it is using the queues set up by the IP stack. >> >> It should register its own stack and each filter type should >> register their own filter functions for that level on the stack. >> >> is there a reason that this is not done? If the answer is simply >> ENOTIME then I will volunteer to go through it and do it properly. > > I guess so. > >> suggested changes: >> >> I propose to create filter queues for if_ethersubr.c and if_bridge.c >> distinguished by slightly different keys. I also propose to rename >> inet_pfil_hook to be inet_pfil_head (or inet_pfil_hooks). >> >> I would also look at following the documentation by seeing whether >> we shouldn't be using a DLT/KEY instead of PFIL_AF and AF_INET >> as the key type/key. > > I think if_ethersubr.c and if_bridge.c should pass to the same pfil hook. > And I'd vote for the current - very sophisticated - if_bridge.c filtering > to stay, at least as opt-in. Otherwise it will be tricky to support > stateful filtering in pf on transparent bridges. Ather and bridge need to be distinguishable. Believe me. I do this in a product and I need to tell them apart. > >> The Direction argument should be expanded to be a generic 'flags' >> argument where two of the flags are direction. >> Other flags can be: >> WAIT_OK: (It's already defined to be there) >> HOST_ORDER: Fields in the header have been swapped to host order. >> >> The ipfw code would supply different entry points for bridge >> and Ethernet supplied packets. >> >> the ipfw args struct should grow a 'flags' field that can >> indicate (for example) that the IP header fields have not been >> put in host order (or have) and that the packet is from a bridge >> rather than just being layer2. >> >> ipfw would grow a 'bridge' keyword to check that flag. > > I don't think that is necessary. Right now we also have a mode to pass > bridged packets as "normal" L2 packets. ipfw doesn't discriminate > between packets from if_ethersubr.c and if_bridge.c - and I don't see why > it should. If discrimination is required one can still fall back on the > L3decap in if_bridge.c - see above. I really need to distinguish between the two cases. >