Re: [PATCH] Fix NAT TCP sequence adjustment

[Phil Oester <kernel@linuxace.com>]

On Wed, Apr 20, 2005 at 06:07:45PM +0200, Patrick McHardy wrote:
> IIRC I've seen an FTP client that continued issueing commands during a
> transfer, but I don't remeber which one exactly.

At this moment, multi-file FTP is broken for all clients -- should we fix
this first, and worry about potential statistical outliers later?

> >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.
> 
> You forget about the network, which can duplicate, delay and reorder
> packets. If we don't handle this is it will screw up the state.

I'm aware of that, but again I claim that it is irrelevant in this case
because the PORT commands will not be processed out of order (even if the
data packets are), and thus the adjustments will occur sequentially.

> >This is a very FTP-centric view, but can you think of other protocols 
> >helpers
> >which would not follow this sequential pattern?
> 
> No, but this function should do the right thing anyway.

Agreed, but IMHO my approach is currently the best available fix for a problem
which is affecting many people.  If further testing shows it can be improved,
that is great -- but I certainly don't think it's any worse than the current
broken behaviour.

> >>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.
> 
> It is. Assume a FTP control packet that contains a PORT command
> at some offset. The MTU changes and the packet is retransmitted
> as three seperate packets, with the PORT command contained in the
> third packet. The second packet will be incorrectly adjusted.
> Probably not a common condition, but easy to handle correctly,
> so why not.

Ok, another statistical outlier which can be thought about later.

Phil