Re: [PATCH] Fix NAT TCP sequence adjustment

[Phil Oester <kernel@linuxace.com>]

On Mon, Apr 18, 2005 at 03:42:38AM +0200, Patrick McHardy wrote:
> We have six cases to consider

No...let's simplify it a bit.  At this point the only debate is over retransmit
handling, since I think we are in agreement that storing the client's seq in
correction_pos (not the adjusted seq) is appropriate.  So that solves 1/2 of 
the puzzle.

Since we now store the correct c_p as noted above, we are guaranteed that
ip_nat_seq_adjust will make the correct determination of whether a packet
is a retransmission.

Now assume a retransmit arrives, has offset_before added to it, and reaches
adjust_tcp_sequence.  With my proposed test:

	if (seq - this_way->offset_before != this_way->correction_pos)

which compares the pre-ip_nat_seq_adjust adjustment to the current c_p, I have
difficulty finding any scenario which this would fail to correctly find a
retransmit.

>  2.3. tcph->seq - offset_after > correction_pos &&
>       tcph->seq - offset_before <= correction_pos
> 
>   In this case we can't determine whether the packet is a retransmission
>   and what the original sequence number was.

I think you are failing to recognize that in the first transmit of a given
packet, offset_before and offset_after are adjusted, so that by the time the
retransmit arrives, the tests are different than they were on the first pass.
That possible?

If not, can you provide some sample seq/o_a/o_b numbers which you believe
would fail this test?  

Phil