Date: Sat, 18 Dec 2004 01:31:35 +0100 From: Max Laier <max@love2party.net> To: freebsd-ipfw@freebsd.org, jon@abccomm.com Subject: Re: Using tables for MAC addresses in ipfw2 Message-ID: <200412180131.42527.max@love2party.net> In-Reply-To: <8eea040804121715267807440d@mail.gmail.com> References: <8eea040804121715267807440d@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart4148511.vnttWTyFbD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 18 December 2004 00:26, Jon Simola wrote: > I do a lot of filtering based on MAC addresses for our DSL network, > and the table support in IPFW is close to what I'm looking for. I've > taken a quick glimpse through the code (I'm familiar with the ipfw > code pre ipfw2) and I don't see any major hangups to implementing a > similar table support for MAC addresses. > > What the situation is is that we are a DSL reseller for the regional > telco. All of our customers have their connections bridged over the > ATM network and appear on a fast ethernet port on a Cisco 5505. That > is the only place we gain access (The ATM and Cisco are telco owned). > I have my FreeBSD 5.2.1 router plugged into that port and working > fine, but at any time I have 50 or so rules specifically blocking MAC > addresses of customers who haven't paid or have viral activity. > > Does adding MAC tables sound like a logical course of action? Can > anyone suggest a different idea, possibly better overall? It might be a good idea to change the existing tables to store a generic=20 struct sockaddr instead of a sturct sockaddr_in. This way it will be possib= le=20 to store IPv6- and maybe even MAC-addresses into the tables. It should be a= =20 good idea to add some descriptive data to the table head to define what kin= d=20 of addresses are in the table. Other than that, it seems doable. If it is a good idea to have (radix tree) tables for MAC filtering remains = to=20 be seen. As you might have many MAC addresses from the same vendor (=3Dwith= the=20 same prefix) the tree will not balance and you might end up with the same o= r=20 even more overhead. It is certainly *not* a good idea to reimplement the=20 table code for MAC, IPv6 and whatnot. =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 --nextPart4148511.vnttWTyFbD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBw3puXyyEoT62BG0RAgdBAJwJJ+G2+xWi/2VCNckpbCMr12v+1ACfRqmL qVeo0H3Nh4yOhLP0Xe4sqvQ= =4APz -----END PGP SIGNATURE----- --nextPart4148511.vnttWTyFbD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200412180131.42527.max>