From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 11:33:46 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26758C14; Wed, 4 Feb 2015 11:33:46 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id D9C606C6; Wed, 4 Feb 2015 11:33:45 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 04B5A5C002; Wed, 4 Feb 2015 14:33:29 +0300 (MSK) Message-ID: <54D20388.7070009@FreeBSD.org> Date: Wed, 04 Feb 2015 14:33:28 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julian Elischer , freebsd-ipfw@freebsd.org Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny 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> In-Reply-To: <54D1FE72.1020508@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 11:33:46 -0000 -----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-----