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
