Date: Mon, 28 Sep 1998 01:16:21 -0400 From: "Allen Smith" <easmith@beatrice.rutgers.edu> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: ark@eltex.ru, kev@lab321.ru, mike@smith.net.au, net@FreeBSD.ORG Subject: Re: Packet/traffic shapper ? Message-ID: <9809280116.ZM4030@beatrice.rutgers.edu> In-Reply-To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> "Re: Packet/traffic shapper ?" (Sep 26, 2:50am) References: <199809260502.HAA13908@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 26, 2:50am, Luigi Rizzo (possibly) wrote: > > > To get the idea, the most difficult part is the ipfw code to pass > > > RED parameters to the kernel! > > > > Nice... although given other capabilities that IpFilter has (including > > ones that I've patched into it, such as making ICMP messages look like > > they're coming from the supposed destination machine - allowing for > > what will look to other machines like a bridge, but is actually > > looking at higher-level information than just the MAC address), it'd > > be nicer if somebody adapted it and dummynet to work together. > > you just look like the right "somebody" ! Umm... I'm not very good at C. > seriously, i think it would be a fairly easy task to adapt ipfilter > to work with dummynet, as it was for ipfw, and i will be happy to help > you if you want to work a little bit on the adaptation (the main > obstacle for me would be to learn and understand the ipfilter code, you > seem to know it somehow having patched it). Well... the patches in question are not very difficult, due to how it's set up. (It's essentially a matter of adding one flag to mbufs in m_flags, a slight modification to ip_icmp.c, and a few alterations onto the ipfilter interpretation code (which isn't documented very well... sigh).) > All i had to do to support dummynet in ipfw > was to add a new return code to the ipfw call so that i > could decide to pass accepted packets to a pipe. > > Once you have done that, you just need to process the return code from > > (*fr_checkp)(...) > > in the same exact way it is done for > > (*ip_fw_chk_ptr)(...) > > e.g. in ip_input.c (look at the -stable code, since this is not in > -current yet). > > Actually, if we manage to make the kernel interfaces for ipfw and > ipfilter the same (they seem to be already 99% compatible) the > integration will come for free. The kernel interface for ipfilter is somewhat limited by the need to retain compatibility with multiple operating systems - solaris seems to be a particularly tough one, judging from the messages to the ipfilter mailing list. > So essentially, can you look at how hard would it be to add support for > multiple return codes to ipfilter ? Then when the dummynet code will be > in -current (hopefully soon) you will be able to use it. Well... I'll try to take a look at it, but I can't make any guarantees about how soon. There's also the problem that currently 3.0 doesn't run ipfilter... Darren is waiting for it to stabilize before working on ipfilter, which will probably be only at 3.1.1 or so from what he's said. -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9809280116.ZM4030>