Sake:
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.
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.
Thanks, JC
-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sake Blok
Sent: Monday, August 24, 2009 4:45 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Analyzing a "broken" FTP session
On Mon, Aug 24, 2009 at 11:41:18AM -0700, Chivian, John wrote:
>
> At this point I am starting to lean toward it being a firewall
issue.
> I've been able to recreate the "broken session" using these same
two
> systems by repeatedly sandblasting the same data set from client to
server
> (using "mput *" over and over and over) but have not been able to
recreate
> it from another system on the same subnet as the server. I will
expand
> the packet capture data size to "-s 256" and make another set.
Be careful... if you have a fire and you take one of the three elements
(heat, air or fuel) away, the fire dies. But that does not mean that the
element that was taken away was (solely) responsible for the fire. I
have seen many cases in which two minor bugs in devices in itself did
not cause a problem, but together they did. I believe your issue to be
one like that too.
Also, when troubleshooting an issue, it is best to make the tracefiles
somewhere else, not on any of the systems under suspicion. As the server
side of the connection is under suspicion, I would suggest to configure
a span port on the switch to make the server side trace. Even better,
make a trace on the client, the firewall, a span port on the switch and
on the server (all at the same time) so that things can be compared.
That said, I do think the problem is on your server and the traces on
the firewall, the span-port and the server will probably show exactly
the same packets.
If you could provide the traces of your reproduced session, we can
verify that it is indeed the same issue...
Cheers,
Sake
________________________________________________________________________
___
Sent via: Wireshark-users mailing list
<wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
