Date: Sat, 11 Jun 2016 12:40:42 +0300 From: Lev Serebryakov <lev@FreeBSD.org> To: "Andrey V. Elsukov" <ae@FreeBSD.org>, freebsd-ipfw@freebsd.org Cc: "Alexander V. Chernikov" <melifaro@FreeBSD.org>, Julian Elischer <julian@freebsd.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? Message-ID: <575BDC9A.8000105@FreeBSD.org> In-Reply-To: <575A752B.1070304@FreeBSD.org> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <575A752B.1070304@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10.06.2016 11:07, Andrey V. Elsukov wrote: >>> In terms of ipfw(4) a state is represented by ipfw_flow_id >>> structure. To solve your task you just needs two states - one >>> for not translated flow and second - for translated. >> For what?! Logically it is one flow. NAT is kludge itself, of >> course, but, IMHO, logically it doesn't create new flow, or >> connection, whatever your name it. It hacks existing one. > > Your patch does exactly what I said - it creates state for > untranslated flow when you call record-state with deferred action. > Then after translation this flow has new addresses and ports, so > ipfw_install_or_update_state() will create new state, old state > will not updated (don't know for what purpose you have renamed > it). Why will ipfw_install_or_update_state() be called after translation with my patch and example? I'm using my patch more than year, and I don't have any problems with splitting of states or expiration of "right" ones, and I've checked dynamic states very carefully first several days after patch was complete (and I had problems with rules expiration in very first, unpublished, version of my patch). > Then when check-state/probe-state will be checked, both states can > be updated by lookup_dyn_rule_locked() depending from flow that > triggers this opcode. So, you introduced new implicit behavior > while thinking that resolve old wrong behavior. Sorry, I lost you here. Why untranslated flow will trigger check opcode? It will be mistake in ruleset, for sure! - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJXW9yaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePIKEP/jPPXByu7ufxZhoK7LJ7SY4Q VEmbrQ+FXvtwkQEHCLVeAPYjOkELVhyM+Z+mJijx4cnYibvmzS1Eh1pPYvsanios x3iec4rz86wli53rhxh19hzWRzmKAXHiw3xd+eIjvlgnIx+TTresn1fNeudVPpwU /iGlehzwAxaZXctjsQkwqJolZLtb8iy98OHE0W/Maj0sjJNj+4b6Cn52oi5Z70V4 DlJ5SbKpUr7NHRCLidA5YxLDQ2MHJimBHh/zoSisU7DmsvrQiJ8ETF5A6b9QFQNV WmKlrd3N+biXF2kXpq9fjTRet0BMhfLgkZk+l/GaY6vJ8C5k0cQuh1GD5ZbJ23D3 mgdE41LFX/m7iXpdc0DoKW8nF8yVJsgYvxnaIKN+i7VVKBp4MUIhsdF66k7KUewB /IHH3kPMdIBleQgfO92QLomCTyD0s31MqclPq3bm+AfI94ZuJonN2YSzgkO1HwXF 0xCsR9C/PxM7AYtiF9QEuaUOr/gVPZQUJlvUcJ2Lh2r9vsEB35qGkAuPTAZwufI7 nzeFNKiSJxv/PL3YmL1qHEQNHqdvt8OdaJ+IZacNl7PfnGsQ76P3O9BTj6QWGAAS 1uxW1qZGp2hcAbv1J5ctNOG9OFNLP7mnVTMIIoX9Ze8FITibJDo5pLfIMJuJv4cy F6G6phqgAAckRcOm3ab3 =fjEL -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?575BDC9A.8000105>