From owner-freebsd-net@FreeBSD.ORG Sat Dec 16 03:46:17 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 0716416A504; Sat, 16 Dec 2006 03:46:17 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A22043C9F; Sat, 16 Dec 2006 03:44:31 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.66.9.214] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GvQUt38Oh-0006ti; Sat, 16 Dec 2006 04:46:04 +0100 From: Max Laier Organization: FreeBSD To: Julian Elischer Date: Sat, 16 Dec 2006 04:45:56 +0100 User-Agent: KMail/1.9.4 References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org> In-Reply-To: <4583119B.20608@elischer.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart14406339.KWBK0YeLvI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612160446.02644.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 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: Sat, 16 Dec 2006 03:46:17 -0000 --nextPart14406339.KWBK0YeLvI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 15 December 2006 22:20, Julian Elischer wrote: > Max, further to your comment.. > > 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? > > I have placed the following patch files: > http://www.freebsd.org/~julian/vlstrip-7.diff > http://www.freebsd.org/~julian/vlstrip-6.diff > > which implement the ability to look within vlans when being used > on a bridge. > > I have done SOME testing with this but would certainly appreciate > another set of eyes.. > the next change would be lyered on top of this change and would be the > addition of a rule: > > ipfw add 100 {operation} ip from any to any vlan {vlan_id}[-{vlan_id}] > > e.g. > ipfw add 1000 skipto 4000 ip from any to any vlan 100-200 > > This, as it is will probably not work for the cases where vlans are > decoded by the hardware. I'm guessing that at some stage we need to > add the ability to cope with that too.. I remember that someone added > some capacity to do that to bpf recently.. (?) I think.. There is M_VLANTAG and m_pkthdr.ether_vtag for hardware support. You=20 could even reuse those for this. i.e. emulate hardware support for ipfw=20 in the pfil hook. If you want to look at the vlan tag later, you can=20 always use those then. > I hope I've found all the places where the old code cared that the ip > header was teh first thing in the mbuf.. > if you see any places where that is stil assumed, let me know. I don't like the implementation for this reason. It feels hackish to me. = =20 What is the reason that you didn't duplicate the ethernet header approach=20 in ip_fw_pfil.c? Speed? Did you measure? It is certainly easier to=20 properly strip off the vlan header in the pfil hook code and reattach it=20 when done (or trust the hardware to do it - if M_VLANTAG was set in the=20 first place). As an aside, I agree that the mtod mania isn't that great either and we=20 should probably do away with it. But that's orthogonal to the vlan=20 handling - I just don't like that to be pulled into *IP*fw. This might=20 just be me, however. > It's working for my testing here but I'm only using it to monitor > traffic on a tap, so the packets are discarded anyhow. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart14406339.KWBK0YeLvI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFg2v6XyyEoT62BG0RAhhYAJ9AIeGQR9Q/3H23XC4su0OnKGpkqwCfajp3 ExotDwOPO5Qz9GTcITEjae4= =pObz -----END PGP SIGNATURE----- --nextPart14406339.KWBK0YeLvI--