From owner-freebsd-stable Mon Feb 26 12:45:57 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA14716 for stable-outgoing; Mon, 26 Feb 1996 12:45:57 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA14697 Mon, 26 Feb 1996 12:45:53 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr9mM-0003x0C; Mon, 26 Feb 96 12:44 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id VAA12321; Mon, 26 Feb 1996 21:44:16 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Joe Greco cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 12:12:14 CST." <199602261812.MAA15629@brasil.moneng.mei.com> Date: Mon, 26 Feb 1996 21:44:14 +0100 Message-ID: <12319.825367454@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-stable@freebsd.org Precedence: bulk > > 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.