> Actually my theory is that I have a "big pipe/small pipe" (Ethernet
> 100 Mbps --> 56 frame relay --> Ethernet 100 Mbps) type of
> environment/problem, and I think I am loosing (discarded) frames,
...and they're not getting retransmitted by TCP? (See "end-to-end
argument". :-))
There might be TCP statistics kept by the OS on one or the other side,
e.g. displayed by "netstat -s", to indicate how often a connection is
dropped due to timeouts.
That might not be sufficient information to get the provider to admit
that they're dropping packets, but it might at least indicate whether
you appear to be getting so many dropped packets that the connection is
torn down.
> but the provider doesn't send me any info on their managed
> devices, and I have no rights to the SNMP info on the routers for
> FR info ... thus the "twisted" way of having to capture everything at
> both ends, and - I hope - prooving that neither end is at fault, but
> that actually something leaves on ened and never reaches the
> other ==> timeouts and the likes ==> with FTP thinking "it's done".
Perhaps the FTP servers and clients you're using both suck, so that they
won't report a "connection timed out" error (or perhaps the OS on one
side or the other sucks and doesn't provide a "connection timed out"
indication on reads or writes) - I've certainly seen enough suckage in
UNIX utilities, for example, where they don't check for errors (and, as
per my previous mail, I put such a piece of suckage into at least one
utility - I'll look at adding more error checking to Ethereal this
weekend), but if you get so many dropped frames that the connection is
dropped, that shouldn't look like a completed transfer to the FTP client
or server, so hopefully they'd report it.
