Bug 20989 - rcp and similar commands hang after a short time
Summary: rcp and similar commands hang after a short time
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rsh   
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
medium
high
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-11-17 00:40 UTC by David Mills
Modified: 2007-04-18 16:29 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-11-28 03:53:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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-27 04:27 UTC, David Mills
no flags Details

Description David Mills 2000-11-17 00:40:34 UTC
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 21:54:50 UTC
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-27 04:27:16 UTC
Created attachment 5730 [details]
The output of tcpdump during problem occurrence

Comment 3 David Mills 2000-11-27 04:36:13 UTC
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
fine).

Comment 4 David Mills 2000-11-27 04:46:01 UTC
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 10:51:25 UTC
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
ftp://ftp.scyld.com/pub/diag/.


Comment 6 David Mills 2000-11-27 12:31:02 UTC
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
this?

Comment 7 Pekka Savola 2000-11-27 14:01:02 UTC
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-28 03:53:30 UTC
I added the line you suggested to /etc/modules.conf and things now work
considerably better.

Thanks!


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