Date: Mon, 26 Feb 1996 12:12:14 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: phk@critter.tfs.com (Poul-Henning Kamp) Cc: jgreco@brasil.moneng.mei.com, imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) Message-ID: <199602261812.MAA15629@brasil.moneng.mei.com> In-Reply-To: <11758.825349418@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 04:43:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I use IPFW's accounting abilities in numerous places. > > I would like to hear more about this: ****** Note: I am not running it under -stable or -current, the following comments are relative to 2.0.5R/2.1.0R and what little I am aware of as far as the changes you have made. Since you have asked, I have gone into detail about what _I_ would like to see. > 1. is the present packet & byte count per rule enough ? Adequate for what I am doing. I am worried, however, about the potential for byte count rollover, I don't know if it's a 32-bit or 64-bit quantity. I would like to be able to leave a "cumulative" counter running... > 2. are you going to miss "bidir" much ? !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Owwwww. See below. I use it a lot :-( > 3. do we need a precise, atomic "read & reset" operation ? I am sampling hourly and my belief is that it takes less than a second to do, and a 1/3600 error is acceptable to me. However, for those folks who might be making more practical measurements (i.e. measuring NNTP traffic to various sites every 5 seconds), a read and reset operation would be great. I believe that the current implementation allows you to sample and clear (non-atomically) individual entries, but if I am wrong, I would also like to see that, preferably atomically. And as mentioned above I would like to leave a few cumulative counters running, sampling but NOT clearing them occasionally. So the answer is "Yes but not for me right now". > 4. anything else ? Okay, here's a problem I've been wanting to solve. I have a rule: ipfw adda bidirectional all from 0/0 to 0/0 via 204.95.219.1 that I use to give me a really rough guess about my T1 loading. The problem is, I handle multiple CIDR blocks. If I had a single CIDR block, I could do # Outbound traffic ipfw adda all from CIDR/20 to 0/0 via 204.95.219.1 # Inbound traffic ipfw adda all from 0/0 to CIDR/20 via 204.95.219.1 I can add multiple rules to deal with it but that seems echhy. There are also some firewalling things I can relate to this same problem. But I *know* the interface I want to watch! What I would LIKE to see: # Outbound traffic ipfw adda all from 0/0 to 0/0 sentvia 204.95.219.1 # Inbound traffic ipfw adda all from 0/0 to 0/0 rcvdvia 204.95.219.1 In other words, I would like the ability to specify the direction the packet was travelling on the "via" interface... it would pretty much kill the main use for "bidir" that I have, and give me a much more accurate idea of what's going on. How about IPFW issues? I know you didn't ask but as long as you're in the code, maybe some of these issues are of interest to you too. Is it possible to fill in the byte/packets dropped by a particular filter? (the fields in ipfw -s -a -n l are always 0) Last time I checked (2.0.5R), the "reject" keyword didn't produce a ICMP HOST_UNREACHABLE. Last time I checked (2.0.5R), the "log" (also l before reject/deny) panicked the box. I can't match specific icmp messages - i.e. I allow ping in both directions or I break ping in both directions. That bites. The "syn" protocol (to firewall TCP connections being opened in a direction) didn't seem to work. Maybe it was just me. Obviously I know you can't possibly address all of the above, but these are all issues that I believe lower the value of IPFW. Solving some/all of these problems would go a long way towards making IPFW look much more like a professional firewalling product and not just something hacked together. (not to mention increase the utility greatly!) Thanks for your efforts, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602261812.MAA15629>