From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 23:59:59 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 29B0E16A417 for ; Mon, 11 Dec 2006 23:59:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outB.internet-mail-service.net [216.240.47.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FB3843DAC for ; Mon, 11 Dec 2006 23:56:49 +0000 (GMT) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 11 Dec 2006 15:43:21 -0800 Received: from [10.251.18.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id kBBNw53w031252; Mon, 11 Dec 2006 15:58:06 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <457DF081.2050306@elischer.org> Date: Mon, 11 Dec 2006 15:57:53 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Max Laier References: <457DCD47.5090004@elischer.org> <457DD658.7010707@freebsd.org> <457DE28D.1010106@elischer.org> <200612120045.41425.max@love2party.net> In-Reply-To: <200612120045.41425.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: addition to ipfw.. 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: Mon, 11 Dec 2006 23:59:59 -0000 Max Laier wrote: > On Monday 11 December 2006 23:58, Julian Elischer wrote: >> Andre Oppermann wrote: >>> Julian Elischer wrote: >>>> in ipfw layer 2 processing, the packet is passed to the firewall >>>> as if it was a layer 3 IP packet but the ether header is also made >>>> available. >>>> >>>> I would like to add something similar in the case where a vlan tag >>>> is also on the packet.. >>>> >>>> basically I have a change where: >>>> >>>> If we are processing layer 2 packets (in ether or bridge code) >>>> AND a sysctl says to do it, >>>> and it is a vlan packet, >>>> >>>> Then the vlan header is also held back so that the packet can be >>>> processed and examined as an IP packet. It is >>>> (in the same way the ether header is) reattached when the packet is >>>> accepted. >>>> >>>> This allows me to filter packets that are traversing my bridge, >>>> even though they are encapsulated in a vlan. >>>> >>>> I have patches to allow this. I need this function. does anyone >>>> else? >>> Please have the ipfw code examine the vlan tag in the mbuf instead of >>> fiddling with the mbuf contents. >> The ipfw will be ignoring the vlan contents.. the patch is to move the >> 'start of ip header' pointer past the vlan header.. (if asked) so that >> it can identifu the IP packet. >> >> part of the patch is to make sure all the code uses this pointer >> instead of the case now where some code uses it and some uses mtod(). >> >> This could be used in conjunction with vlan keyword that would look at >> the vlan header, but that is a different feature.. > > I understand you do have a patch? Let's see it, so we are clear what we > are talking about. I think that w/o a ipfw feature to identify the vlan > number, it is pretty useless. Of course, it would enable you to do some > basic sanity checks, but real filtering needs to know the vlan it is > concerned with. BTW, what speaks against plugging the bridge into the > vlan on either side and bridge the vlan interfaces together? Actually I HAD a patch on Friday but lost it due to a raid crash (grrr mfi card on a dell 2950).. but I'm 'retyping it in' and hope to have one to show in a day or so.. At least no-one has said "That's a stupid idea" which is what I was looking for.