From owner-freebsd-net@FreeBSD.ORG Tue Dec 26 04:38:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82B8616A407; Tue, 26 Dec 2006 04:38:19 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 9A21113C473; Tue, 26 Dec 2006 04:38:16 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kBQ4c390000312; Tue, 26 Dec 2006 07:38:03 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kBQ4c1kA000311; Tue, 26 Dec 2006 07:38:01 +0300 (MSK) (envelope-from yar) Date: Tue, 26 Dec 2006 07:38:01 +0300 From: Yar Tikhiy To: Max Laier Message-ID: <20061226043800.GC81280@comp.chem.msu.su> References: <457DCD47.5090004@elischer.org> <20061224093951.GD49045@comp.chem.msu.su> <459032EA.1030601@elischer.org> <200612252239.59737.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612252239.59737.max@love2party.net> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, Andre Oppermann , Julian Elischer Subject: Re: [was] addition to ipfw (read vlans from bridge).. 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: Tue, 26 Dec 2006 04:38:19 -0000 On Mon, Dec 25, 2006 at 10:39:51PM +0100, Max Laier wrote: > On Monday 25 December 2006 21:22, Julian Elischer wrote: > > Yar Tikhiy wrote: > > > On Fri, Dec 22, 2006 at 12:39:06PM -0800, Julian Elischer wrote: > > >> Taking to heart comments by Andre and Max (Laier), > > >> I have redone this patch in a different manner. > > >> > > >> The aim is to be able to see inside vlans when bridging. > > >> Now, this is a 6.x patch to bridge.c because that is what we > > >> are using, but I will make a similar patch to if_bridge.c > > >> for 6 and 7 if this meets with approval. > > >> > > >> > > >> Basically if it is a vlan packet, take off the whole vlan header > > >> instead of just the ether header, but pass to ipfw, an ether header > > >> with the real protocol field substituted in. > > >> when finishing put back everything we removed before. > > >> > > >> > > >> The only addition I'd do to this would be to add a sysctl > > >> to turn it on if people thought it would be break POLA too much > > >> to have it work by default. > > > > > > Excuse me, but I'd like to second Andre's opinion. We should stop > > > fiddling with the mbuf contents in favour of teaching ipfw (or the > > > interface code between bridge and ipfw) of 802.1q (or its > > > generalisation.) Now that the 802.1q VLAN technology has been well > > > integrated in the general Ethernet framework by IEEE, there is very > > > litte sense left in such hacks. If ipfw is to stay L2-agnostic, > > > then let's just pass the offset of the IP header into the mbuf to > > > it. The 802.1q header is so nice and simple and easy to parse at > > > any level. So this patch can be OK in 6.x for the only sake of > > > preserving the pfil ABI, but it should die along with it. An > > > extended interface is apparently called for in HEAD. > > > > You are the one who complained that it should not be done in ipfw, > > and that we should do it the same way we currently handled the > > removal and re-addition of the ethernet header. So that's what I did. > > (in the bridge code), by teaching the ethernet header handling code > > to handle vlan tags as well. > > I'm not sure if you are mistaking Yar for me here. As for my concerns - > consider them withdrawn. I still don't like the idea that the code in > net*inet*/ip_fw2.c gets to know about VLAN internals, but if everybody > feels that it does belong there - fine. I hereby resign from this > thread. IMO ipfw should be taught of VLAN internals only if we are going to implement L2 filtering in it. But if not, a simple offset of the IP header computed at the link layer of the stack would do. That would allow for different VLAN or whatever encapsulations as well. -- Yar