Date: Sat, 28 Apr 2001 21:22:59 -0700 (PDT) From: David Wolfskill <david@catwhisker.org> To: ache@nagual.pp.ru, richw@webcom.com Cc: current@FreeBSD.ORG Subject: Re: ipfw: several equal rules under same number bug Message-ID: <200104290422.f3T4Mx724878@bunrab.catwhisker.org> In-Reply-To: <20010429081131.A49808@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
>Date: Sun, 29 Apr 2001 08:11:32 +0400 >From: "Andrey A. Chernov" <ache@nagual.pp.ru> >I think it is very contr-intuitive way, better action will be "replace" if >number is the same. We have _enough_ numbers to not compact rules in such >bad manner. >For example "ipfw delete" takes number as an argument, what rule it >suppose to delete, if the number is the same? I.e. how can I delete >specific rule if all have the same number? Etc, etc. I understand your stated concern, but the proposed "solution" is, to me, worse. I have at least one application where I generate ipfw rules in a script, for a set of subnets which I read from a file at execution time. I am able to use the numbers to group the firewall rules , so that for any given subnet, I can predict the order in which the rules will be applied. But since I don't really know the subnets until the script is running, I would need to make the script far more complicated if we required that each ipfw rule were uniquely numbered. (And since I want to get the ipfw rules in place very early in the boot sequence, additional complication is not exactly what appeals to me.) That said, I (personally) wouldn't have an objection to a mechanism (such as a sysctl) that would determine which of the two ways ipfw would behave, as long as I could retain the current behavior. I wouldn't even mind (again, for myself) if the default were to be changed to be the way you suggest. Cheers, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104290422.f3T4Mx724878>