From owner-freebsd-current Mon Apr 30 12:31:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id A768E37B53A for ; Mon, 30 Apr 2001 12:31:08 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.2/8.11.2) with ESMTP id f3UJV1g16519; Mon, 30 Apr 2001 13:31:01 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200104301931.f3UJV1g16519@orthanc.ab.ca> From: Lyndon Nerenberg Organization: The Frobozz Magic Homing Pigeon Company To: "Andrey A. Chernov" Cc: current@FreeBSD.ORG Subject: Re: ipfw: several equal rules under same number bug In-reply-to: Your message of "Sun, 29 Apr 2001 08:11:32 +0400." <20010429081131.A49808@nagual.pp.ru> Date: Mon, 30 Apr 2001 13:31:01 -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Andrey" == Andrey A Chernov writes: Andrey> I think it is very contr-intuitive way, better action will Andrey> be "replace" if number is the same. Nonsense. This is what 'add' and 'delete' are for. Andrey> For example "ipfw delete" takes number as an argument, Andrey> what rule it suppose to delete, if the number is the same? Andrey> I.e. how can I delete specific rule if all have the same Andrey> number? Etc, etc. You can't, in which case you shouldn't use that facility. However, for those cases where you *do* want to act on a grouped set of rules, sharing rulesnumbers provides that ability. For example, I have a set of rules that count all in- and out-bound traffic to each IP address on an internal network. All of these are under a single rule number. This makes it trivial to do things like take periodic snapshots of the counters: ipfw show 2000 > $somefile; ipfw reset 2000 This takes care of 512 individual rule entries in one simple operation. Now if you want to make some useful changes to ipfw, find someone to commit the fix in bin/18550. And get rid of the needlessly verbose usage message ipfw spits out when it fails to parse a command. It would be a lot more useful if ipfw printed (only) the failed command. At least I might have a chance of seeing what the error is, instead of having the usage message cause any useful information to scroll off the console while the machine boots. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message