In adjust_tcp_sequence, we track the sequence number of any adjustments
in the correction_pos variable.  The seq stored is based upon the left
side of the window of the NAT box -- not of the original sender.

Later, in ip_nat_seq_adjust, we compare the correction_pos variable to
the seq of the original sender to determine whether this is a new packet
or a retransmission (i.e. should we apply offset_before or offset_after).
So we are comparing the post-adjustment seq to a pre-adjustment seq.

This works ok under normal circumstances, like a single FTP transfer, since
the before/after comparison luckily works out.  But in situations like
an FTP 'mget', it can fail depending on how many files are transferred.

For example, assume the strlen of the PORT command from the client is 26, and
it gets adjusted to 27 by the NAT box (sizediff=1).  Under this scenario,
the mget will fail to transfer file #26 since at that point the before/after
comparison in ip_nat_seq_adjust flips the other way, and the adjustment
becomes offset_before instead of the appropriate offset_after.  Obviously
for larger sizediffs, the failure comes earlier.

The solution is to store the client's seq number in correction_pos instead
of the seq of the NAT box.  The below makes this change, as well as cleans up a
number of broken DEBUGP statements and a couple of u32->u16 casts.  

As noted, without this patch an mget fails at (sizediff * strlen(PORT...).
With this patch, I have successfully transferred 500 files under both
scenarios: sizediff > 0 and < 0.

This closes bugzilla #308.

Phil

Signed-off-by: Phil Oester <kernel@linuxace.com>