On Wednesday 18 April 2007 22:58, Julian Elischer wrote: > I'm contemplating the following changes to functionality: > I'd like suggestions and comments... > > 1/ Commit capability
Isn't this already there with "set"s ? > In this change you declare a new firewall, > and modify/build it, and then you 'commit' it so that > the whole change is atomic. > I have a current bug at work where automatic changes > are made to teh firewall, but sometimes packets can arrive > between parts of a change and lead to odd behaviour. > For example if I have a reset rule after a skipto, > and as part of the change I replace the skipto with something else, > then for a moment, teh reset it exposed before the new rule is put > in. this leads to a spurious reset being sent out and terminating a > perfectly innocent session. I can code around these sorts of things > but I'd like to do: > > ipfw duplicate to 1 # make rule list 1 a copy of the current rules > ipfw rules 1 delete 1000 > ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... > ... (400 other changes) > ipfw commit 1 > > > or > ipfw new 1 # make rule list 1 a copy of the current rules > ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... > ... (400 other changes) > ipfw commit 1 > rules that are unchanged would maintain their statistics. > > possibly I would not need a rule list number if the ipfw program > would automatically write to the existing set if there is no new > (or duplicate) rule list, but would manipulate the 'growing' list > if it exists. (that way keeping the new behaviour as a superset > of the old behaviour). -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News
pgp9M36x0jp3M.pgp
Description: PGP signature