IPFW: more "orthogonal? state operations, push into 11?

[Andrey V. Elsukov]

On 10.06.16 00:11, Lev Serebryakov 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).

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.

-- 
WBR, Andrey V. Elsukov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20160610/e5b35fc3/attachment.sig>