hemphill@nrl-aic (Gavin Hemphill) (07/01/86)
This message is empty.
hemphill@NRL-AIC.ARPA (Gavin Hemphill) (07/01/86)
Sorry about the previous empty message -- fumble fingers strikes again. Is it my imagination or are other people experiencing problems as well. I have noticed lately that I can't FTP files bigger than 20 or 30 KB. The symptoms are that after 6 or 7 minutes (clock time) the FTP connections (to wherever from nrl-aic) break, there are no messages or indications from the remote server just the "ftp>" prompt. Secondary to this when I try to open a new connection to the same host I'll get the "host unreachable" message, but if I telnet to any other host -- and from there FTP or telnet to my original destination I can get through, and after backing out of that a direct FTP will again get through. Anybody else had similar problems? If so, any pointers would be appreciated. G++
MRC@SIMTEL20.ARPA.UUCP (07/01/86)
Gavin -
You aren't the first person to have complained about this. I investigated
it as a TOPS-20 problem but then I got reports that it happened in FTP transfers
that didn't involve any TOPS-20 systems. I wish I knew what was the problem.
-- Mark --
-------dardy@NRL-CSS.ARPA (Hank Dardy) (07/01/86)
We see the same behavior here. Haven't figured out cause. Hank
brescia@BBNCCV.ARPA (Mike Brescia) (07/01/86)
You aren't the first person to have complained about this. I
investigated it as a TOPS-20 problem but then I got reports that it
happened in FTP transfers that didn't involve any TOPS-20 systems.
Can you name a site to which an FTP hangs from your host, and another to which
it does not fail? You could also list the gateway(s) through which your
connection passes.
Can you examine the TCP layer and IP layer statistics for signs of
retransmissions or missing acks (TCP) or discarded unreassembled fragments
(IP) or any other counters that are out of the mainstream?
I would like to see some indication from the host ends that the problem either
could or could not be caused by a gateway.
Mike Bresciagds@SRI-SPAM.ARPA.UUCP (07/12/86)
In article <8606302206.AA07389@nrl-aic>, hemphill@NRL-AIC.ARPA (Gavin Hemphill) writes: > > Sorry about the previous empty message -- fumble fingers strikes again. > > Is it my imagination or are other people experiencing problems as > well. I have noticed lately that I can't FTP files bigger than 20 or 30 KB. > The symptoms are that after 6 or 7 minutes (clock time) the FTP connections > (to wherever from nrl-aic) break, there are no messages or indications from > the remote server just the "ftp>" prompt. Secondary to this when I try to > open a new connection to the same host I'll get the "host unreachable" > message, but if I telnet to any other host -- and from there FTP or telnet > to my original destination I can get through, and after backing out of that > a direct FTP will again get through. Anybody else had similar problems? If > so, any pointers would be appreciated. > G++ Sounds like a couple of problems. The "host unreachable" message could be caused, if you are talking to an imp, by the bug in the imp driver that causes a destination host to be marked down because no packets can be deliv- ered to it. This can be fixed by changing the value of HOSTTIMER in /sys/netimp/if_imp.h from 128 to a smaller number (I used 1 instead of 0 because our imp was crashing and I did not want to deliver packets too quickly to it). The ftp lockup problems sound like the "bad file number" problems we were having a few months ago and a related problem with getting "connection error" messages telnetting from a tiu on a prnet to a vax on the arpanet. I discovered that the connection errors were coming when a gateway from the arpanet to the prnet was having trouble fragmenting a packet of odd byte length > 254. By changing the arpanet mtu on the vax from 982 (act- ually arpanet-pli mtu) to 254 the problem went away. Likewise, many of our bad file number and ftp lockup problems went away when I had the ethernet mtu changed from 1500 to 576. Next time this happens try and figure out to where you were trying to con- nect, and what (if any) gateways you had to go through to get there. If possible, monitor the tcp connection looking for a reset (by doing netstats this will show as a connection going from ESTABLISHED to not showing up at all). If you can turn on tcp debugging, look for a RST packet coming in.