ftp hang while trying to talk to cu20b.columbia.edu

David Herron -- Resident E-mail Hack (ukma!david@husc6.harvard.edu)
17 Feb 88 07:25:46 GMT

I'm experiencing some strange hangs while attempting to ftp files
from cu20b. Specifically, the pattern is that I make the connection,
log in as anonymous and david@ms.uky.edu as the password. Then I
start transferring some data (either a directory listing or an
actual get command) and after some short time (approximately 15K
worth of data has been transmitted) the transfer hangs and stops
doing things.

Running tcpdump to watch things and telling it to restrict itself
to the ftp port, sure enough the packets simply stop going by
after a time.

The local machines I have tried this from are an 11/750 with deuna
running mtxinu 4.3+nfs (we're one MR behind the current version),
uXavII's with DEQNA's and the same OS, Sun 3/something running 3.4,
and uVaxStation2000's with whatever the ether hardware is and
the next-to-current version of Ultrix. Our sequent didn't
know how to reach that network so I wasn't le to try from
that machine.

Using ping, I get an response times like 250 ms at best, 2500 ms
at worst, and 600-700 avg and with packet lossage at somewhere
between 5% to 30% depending on the tides, or some other somewhat
unrelated/unknown effect. I'm doing these transfers at night
most recently at 3AM on a saturday morning.

Our net is an ethernet attached to a proteon p4200 ip router which
is the gateway to suranet/nsfnet. From there we go through some
gateway in wash dc (maryland?) to get to net 10.

One thing we've noticed recently on our net is something which may
be rwho related broadcast storms. I haven't traced this down yet,
but will be doing some tracing on this in the next couple of days.
One thing I notice from ping is that occasionally there are
bursts of packets being lost and surrounding the lost packets
are long ping times.

um, some hard facts gathered with ping. I watched for about 5 or 6
minutes just now. Every minute like clockwork we'd experience some
packet loss, and generally for the next 20-30 seconds the ping
time would be much worse than the rest of the time. But there was
enough variance in the details of what happened, as well as variation
in other parts of the minute, that it's not completely clear what
is happening. I did see one extreme example in that time where
we lost about 40 packets and didn't have ANY pings come back for
about 30-40 seconds.

This does seem to be extreme lossage ... however, isn't tcp supposed
to be able to handle loss of packets and do re-transmissions? Why
is tcp getting wedged? Or possibly is it something in the way that ftp
works? (I must admit that I know very little about how ftp operates
other than it runs using two tcp channels, one for data transfers
and the other for commands).

Any ideas?

<---- David Herron -- The E-Mail guy		<david@ms.uky.edu>
<---- or:		 {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- It takes more than a good	memory to have good memories.

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:40:42 GMT