Date: Sat, 16 Dec 2006 04:45:56 +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: <200612160446.02644.max@love2party.net> In-Reply-To: <4583119B.20608@elischer.org> References: <457DCD47.5090004@elischer.org> <200612120045.41425.max@love2party.net> <4583119B.20608@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612160446.02644.max>