-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04.02.2015 14:11, Julian Elischer wrote:
> On 2/4/15 5:22 PM, Lev Serebryakov wrote: On 04.02.2015 08:13,
> Julian Elischer wrote:
> 
>>>> yes I think "keep-state" should be deprecated and replaced
>>>> or supplemented by 'save_state'  that does NOT do an
>>>> implicit 'check-state'.. I don't know whose idea that was but
>>>> it's just wrong. (if the state exists, maybe just replace
>>>> it..)
> Update, not replace :) See my Version-3 patch for "record-state"
> :) I meant a function that acts like 'keep-state' except it does
> not do a 'check-state'. Im suggesting adding yet-another command. a
> 'fixed' keep-state.
  Yep. Maybe, additional option? Which will work only on user level
and force to skip generation of O_PROBE_STATE? Now on KERNEL level
nothing force this check, it is additional opcode, added by user-level
"compiler".
  Only thing we need to make it work properly is in my last patch for
"record-state": add TCP state propagation to "install_state" function
to make it able to update existing state properly.
  and after that you don't need any additional opcodes for
"keep-but-not-check-state" command/option, it will be user-level change.


> I sort of know why they did it.. so that if the state for that
> session already exists, the original state rule is used and not the
> new rule. but ..it fires on other packets as well as the one you
> are working with.
  Yep, because O_PROBE_STATE is FIRST opcode always. It is matter of
compilation.

- -- 
// Lev Serebryakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJU0gOIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP/1sQAKMgZyk3BVCXB8Q+Rmvy/D0K
YhPICBbPqUWHw35HfXG0hgw66pa/SX0G68HO2LoxurbxFtu3pdsKA3X8ok4J3Yvb
374MPQcUYFxoUmvjjWUpNMGUBBm72TPk61cjUdsWWJoYWrLJmM0UMJ2wJREvS2D6
s0hUuFGBb/OaTW8aHWY2gAwViPDxR2gQmX8Pw6XpZLxR3ZyNcMTnx78jGn+8jykM
tLxmLjlOSAw4XfsbkiG6X7CmkgyFhcN/B6cpRNB8qsLSmG6rzBup6JrAcFYRq/63
LUj8Z0azwJoHqeLBKZ7RfcfqbB9PMdMTaufBPxQVclQntERkN4nEacT4LSRd1aoL
2zEKMV+PN8X4sL3h73laURLq5lHOVuJsG73YGR1n/IPtlkeeLu1zOADjPRd/0ZY+
kOWzvE00RGhb1mt2LNpL9qZQ8oIcf0r3pYuZKmV0vT7BnQ/Pw4lMjcPyHPSJyFgR
yn2fslDvytg8e/iPvHuOm6h8t6Um3bAbV2LrW4fHSgbhMPGt/nzwuRicMoj6o+Fx
r3q+ITM54QbodBZuS0Ie7IvCNZIfYwwp27GS1lZ8lEv1lYy4kVW9B3AOZzows5XW
YWjVz4xzYd3qaTQyoNij9NFJYVx52IXoAP23PFPDhbr1OFhomGVXQCgu/KS3JHOQ
kR5C1h4iKmkjLUCmDC/P
=sqjh
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Reply via email to