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
signature.asc
Description: OpenPGP digital signature
