Bug 20989 - rcp and similar commands hang after a short time
rcp and similar commands hang after a short time
Product: Red Hat Linux
Classification: Retired
Component: rsh (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2000-11-16 19:40 EST by David Mills
Modified: 2007-04-18 12:29 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-11-27 22:53:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The output of tcpdump during problem occurrence (37.13 KB, application/octet-stream)
2000-11-26 23:27 EST, David Mills
no flags Details

  None (edit)
Description David Mills 2000-11-16 19:40:34 EST
When using rsync and similar commands that attempt to transfer files, after
a short time a file 
transfer hangs.  It essentially makes networking useless.
Comment 1 Pekka Savola 2000-11-20 16:54:50 EST
You should try to log this with tcpdump to see what's causing this.

This might also be a classic case of filtering ICMP destination unreachable: 
fragmentation needed but don't fragment bit set messages.  Is there filtering
done on ICMP between the endpoints?
Comment 2 David Mills 2000-11-26 23:27:16 EST
Created attachment 5730 [details]
The output of tcpdump during problem occurrence
Comment 3 David Mills 2000-11-26 23:36:13 EST
I started tcpdump before issuing a command that hung and stopped it several
minutes later.  I have attatched the output to this bug report.  If I leave the
command run for a very long time (tens of minutes) more of the file gets
transferred, but at a rate of probably less that 2kb/s.  My ethernet is 100MB/s
(a Toshiba 470CDT with a 3COM 10/100 PCMCIA card and a gateway 600 with a 3COM
10/100 PCI card connected via a crossover cable - it has worked for some time
with both machines running RedHat 5.2 then 6.1 then 6.2 but has failed ever
since I upgraded the Gateway to 7.0 - I updated the notebook first and it ran
Comment 4 David Mills 2000-11-26 23:46:01 EST
I believe that I have not altered the standard installation with regard
networking (other than the IP address and /etc/hosts to add some extra hosts). 
So I don't believe I have filtering on but how do I tell?

The amount of information that gets transferred before it slows down varies
considerably.  Somtimes just a few KB other times not till after tens of MB.
Comment 5 Pekka Savola 2000-11-27 05:51:25 EST
This looks pretty much like a classic half/full duplex problem.  The symptom of
it is that tranfers start going fast for about 0.5-2.0 seconds or so, and then
essentially time or are reduced to 0.5-30 Kbytes/sec like with you.

If this is the problem, this should also happen with other protocols, like ftp.

You might want to check your Gateway system's interface configurations
(/etc/modules.conf).  Did the driver change at upgrade?  Also, try to diagnose
the problem with mii-diag and friends, available from
Comment 6 David Mills 2000-11-27 07:31:02 EST
I got the diag programs from the above web site.  The output of vortex.diag
shows the MAC settings of the notebook to be running full-duplex and the gateway
to half-duplex.  So it seems the above comment is correct.  But how do I change
Comment 7 Pekka Savola 2000-11-27 09:01:02 EST
See /etc/modules.conf for options= line.  If there is no such line, the card is
in autonegotiation
state (if not forced otherwise in EEPROM with NIC DOS configuration floppy).

Something like:

options 3c59x options=4 full_duplex=1 

forces the card to 100/FD.  This varies from driver to driver.

Comment 8 David Mills 2000-11-27 22:53:30 EST
I added the line you suggested to /etc/modules.conf and things now work
considerably better.


Note You need to log in before you can comment on or make changes to this bug.