Actually I did notice the TSval=0 change and was thinking about what it meant, and then promptly forgot about it. I was not aware of RFC1323, certainly could be the corner-case we are looking for, so that might well be the issue!
Regards, Martin
MartinVisser99@xxxxxxxxx
On Tue, Aug 25, 2009 at 10:15 AM, Sake Blok
<sake@xxxxxxxxxx> wrote:
On Tue, Aug 25, 2009 at 01:05:36AM +0200, Sake Blok wrote:
>
> In the tracefile made_on_server.pcap, there are packets sent to
> the server (your FTPd host) with a tcp seq of 127 (frame 62 and 63),
> but they seem to be rejected by the TCP layer (frame 64 and 65). The
> weird thing is that they are rejected with an ACK of 127, meaning that
> the TCP stack is awaiting data from seq 127 onwards (which was what the
> client was sending).
And then again, you learn something every day, there is more to TCP
sequence numbers then meets the eye :-)
In this case: TCP timestamps. They are used for a few things, one of
them being "Protect Against Sequencenumber Wrapping". For a full
explanation, read RFC 1323 (as I just did), but in short: A timestamp
option is added to the TCP header which should be monotone-increasing.
If a packet is received with a timestamp that is lower than one that has
been received earlier, the packet should be dropped and an ACK should be
sent back to the sender.
This is exactly what happens in your trace. The firewall sends a frame
with TSval=0 (frame 61) and then frame 62 and 63 contain a TSval of
4038448187. However, in a signed 32 bit integer, this value is negative
and therefore it is less then 0. So the TCP stack on the Linux server
drops these packets as if indeed they are delayed packets.
I think that it's a bug in the ASA that it sends out a frame with
TSval=0, so you could see whether your service provider is willing to
file a bug with Cisco.
In the mean time, chances are that disabling "ftp inspect" might solve
the issue as no layer7 processing will be done anymore for this traffic
by the ASA. This however lowers your security level as "ftp inspect"
also looks for protocol anonomalies. Another workaround could be to turn
of rfc 1323 support on the server (see:
http://mohammednv.wordpress.com/2009/05/27/disable-tcp-timestamping/ ).
