On Mon, Aug 24, 2009 at 03:14:29PM -0700, Chivian, John wrote:
>
> When you say "the server" do you mean the FTPD server application or
> the IP stack that it uses for a transport? Forgive the question if it
> seems silly but I am trying to understand all that I'm seeing and
> hearing.
That's not a silly question, it can be very hard to agree on what some
words actually mean. By "the server", I meant the Linux box running the
ftp daemon. So, the whole system. But if we break down the server into
smaller components, I believe the incoming packets travel the following
road (this is somewhat uncharted territory for me, as I am a networking
guy):
NIC -> libpcap -> security modules -> IP layer -> TCP layer -> FTPd
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).
Since the packets are passing the security modules and the IP layer
before hitting the TCP layer, I suspect these layers to mangle the
packets in such a way that the TCP layer does not see them as valid
anymore and rejecting them.
> Also, in one of your previous messages you mentioned noting that "the
> router" seemed to be "application or TCP aware". Can I ask what you saw
> in the packets that made you draw this conclusion? If I learn nothing
> else from all this but how to make that determination myself I think I
> will be in MUCH better shape next time something like this comes along.
A router will forward frames back and forth, it will not buffer tcp data
until it has been acknowledged, while in your traces it can be seen that
there is a device in between the client and the server that actually does
buffer tcp data. Have another look at the combined pcap that I sent
earlier and see if you can agree on my findings
Cheers,
Sake
