Date: Tue, 12 Dec 2006 00:45:35 +0100 From: Max Laier <max@love2party.net> To: Julian Elischer <julian@elischer.org> Cc: freebsd-net@freebsd.org, Andre Oppermann <andre@freebsd.org> Subject: Re: addition to ipfw.. Message-ID: <200612120045.41425.max@love2party.net> In-Reply-To: <457DE28D.1010106@elischer.org> References: <457DCD47.5090004@elischer.org> <457DD658.7010707@freebsd.org> <457DE28D.1010106@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1206538.0GP4lc3s94 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 are talking about. I think that w/o a ipfw feature to identify the vlan=20 number, it is pretty useless. Of course, it would enable you to do some=20 basic sanity checks, but real filtering needs to know the vlan it is=20 concerned with. BTW, what speaks against plugging the bridge into the=20 vlan on either side and bridge the vlan interfaces together? =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 --nextPart1206538.0GP4lc3s94 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFfe2lXyyEoT62BG0RAjDpAJ0WPXFRL+CwM5CqxTie7hMUXPpC9QCdGhvP NVUq7tM6Io50kXpUpnmFYq8= =G3HE -----END PGP SIGNATURE----- --nextPart1206538.0GP4lc3s94--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612120045.41425.max>