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).
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
