Martin/Sake:
Again, thanks for your time, efforts and expertise. While I
do not know exactly what version of firewall software (IOS?) is being run, I do
know that it is not the latest and greatest. We had a separate issue some
number of months ago in which we discovered that the TCP SACK option was not
making it through firewall. After some coordinated experimentation it was
discovered that if "FTP inspect" was turned off then SACK did make
make it through. (I don't pretend to understand why.)
My understanding is that Cisco supplied our service provider
with an "engineering" version of the firewall OS as a fix (so we
could have both) but that when the next production version came out it did not
contain that fix so I'm pretty sure we're still at the engineering version. I
will find out exactly what version we are at (if you think it is useful
information) and poke the service provider to poke Cisco to see if there is a
production version that addresses the issue.
It will take me some time to coordinate making the traces on
all systems simultaneously but I will certainly clip them to a manageable size
and post them when I do.
You guys are the best!
JC
From:
wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Martin
Visser
Sent: Monday, August 24, 2009 7:24 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Analyzing a "broken" FTP
session
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/
).
