Re: [PATCH] Fix NAT TCP sequence adjustment

[Phil Oester <kernel@linuxace.com>]

On Wed, Apr 20, 2005 at 05:03:40PM +0200, Patrick McHardy wrote:
> offset_before: 1000
> offset_after: -1000
> correction_pos: 1000000
> 
> Sequence number (pre-adjustment): 999500 (retransmit)
> Sequence number (post-adjustment): 1000500
> 
> if (seq - this_way->offset_before != this_way->correction_pos)
> 
> adjusted seq - offset_before = 999500 => passes the test
> adjusted seq - offset_after = 1001500 => not detected as retransmit.
> 
> You assume only identical retransmits of the packet that caused
> the last adjustment. It could also be an older packet or have
> different boundaries. 

Yes, and I believe this is a safe assumption. Take FTP for example.  Packets 
containing the PORT command traverse this function, but not packets containing
the file itself.  If a PORT packet is lost, you will not receive a PORT
packet for a different file before the first is retransmitted.  So it is safe
to assume that the adjustments are occurring sequentially -- not out of order.

So with this assumption, the above example becomes impossible - the 999500
retransmit would have been dealt with prior to a new correction_pos being
set.

This is a very FTP-centric view, but can you think of other protocols helpers
which would not follow this sequential pattern?

> This brings us to a different problem,
> the sequence number at which the correction occured should be
> stored, not the first sequence number contained in the packet.
> But this can be done in a seperate fix.

Given the above assumption, I don't think this is a concern.

Phil