Date: Mon, 26 Feb 1996 21:44:14 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) Message-ID: <12319.825367454@critter.tfs.com> In-Reply-To: Your message of "Mon, 26 Feb 1996 12:12:14 CST." <199602261812.MAA15629@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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... yes, I would really love to make them 64 instead of 32, but right now the structure is 64bytes, and I'd hate to increase it to 128 :-( > > 2. are you going to miss "bidir" much ? > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > Owwwww. See below. I use it a lot :-( I thought so, it's just that we need a lot of special code to do it, and I think it is kind of messy anyway... > > 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. Ok, not bad to do. > So the answer is "Yes but not for me right now". OK, will think. > > 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 CIDR ? Uhm, Canned Indian Doughnut Rolls ? no, hmm, I guess, Contiguous Internet something ? > *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 Check out the strawman I just emailed, and actually you can do that in the present code: ipfw add count from any to any in via 204.95.219.1 ipfw add count from any to any out via 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. got it :-) > 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) It is :-) I can see that I'm about two days ahead of you still :-) > Last time I checked (2.0.5R), the "reject" keyword didn't produce a > ICMP HOST_UNREACHABLE. It only does in some cases, I'll have to check it out a bit. It's a mine- field, so I'm very careful. > Last time I checked (2.0.5R), the "log" (also l before reject/deny) panicked > the box. doesn't now. > I can't match specific icmp messages - i.e. I allow ping in both directions > or I break ping in both directions. That bites. Hmmm, noted. > The "syn" protocol (to firewall TCP connections being opened in a direction) > didn't seem to work. Maybe it was just me. It does now, better than ever I think. Sounds like you should take a peek on the ipfw.8 manpage of -stable or -current, you may just like it :-) > Obviously I know you can't possibly address all of the above, but these are try me :-) > 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!) I'm looking forward to your comments on the strawman I sent out! -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12319.825367454>