ipfw changes being contemplated..

[Julian Elischer]

Max Laier wrote:
> 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 ?

kind of, but I expressed it badly..
see the next email.

> 
>>   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).
>