Date: Wed, 04 Feb 2015 14:33:28 +0300 From: Lev Serebryakov <lev@FreeBSD.org> To: Julian Elischer <julian@freebsd.org>, freebsd-ipfw@freebsd.org Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny Message-ID: <54D20388.7070009@FreeBSD.org> In-Reply-To: <54D1FE72.1020508@freebsd.org> References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> <54D1E4D4.10106@FreeBSD.org> <54D1FE72.1020508@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54D20388.7070009>