Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 54177 - `cvs update` fails to get updates from cvs server
`cvs update` fails to get updates from cvs server
Product: Red Hat Linux
Classification: Retired
Component: cvs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-09-30 11:57 EDT by Andrew Ferguson
Modified: 2007-04-18 12:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-18 22:35:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Cut-down diff between 7.1 and 6.2's /sbin/ifup scripts (3.39 KB, text/plain)
2001-10-17 18:43 EDT, Andrew Ferguson
no flags Details

  None (edit)
Description Andrew Ferguson 2001-09-30 11:57:11 EDT
Description of Problem:
After upgrading my Redhat 6.2 box to Redhat 7.1 some network clients are no longer able to connect. cvs update, the folding@home client, 
and ftp uploads more than a few kb all exhibit this behavior (they fail with a timeout). When I run `cvs login` cvs connects and authenticates 
with the server. Following that with `cvs update` fails to update any files, timing out. From `netstate -n` I can see that a connection has been 
established with the CVS server (and in the case of folding@home, with the folding@home server, or with ftp, everything works until more 
than a few kb are uploaded). `rpm -q cvs` reports cvs-1.11-3, `rpm -q ftp` is ftp-0.17-7 and `rpm -q xinetd` reports xinetd-2.3.3-1. The kernel 
is 2.4.9-ac9 with ext3 0.9.9 and lm_sensors 2.6.1 patches (no firewall options enabled). Mozilla, irc, ssh, ftp downloads all work fine.

Hmm, it seems that large pop3 messages also cause problems for fetchmail (fetchmail-5.9.0-0.7.1), but smaller ones are just fine.

I suspect xinetd, but only because that's the most visible network change from 6.2 -> 7.1, but I really don't know. (All xinetd services are 

[Interestingly, I wasn't able to get this bug report to submit from Mozilla or Netscape on this box, might be the same bug in yet another form]

How Reproducible:
Every time.

Steps to Reproduce:
1. cvs -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome login
2. cvs -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome update

Actual Results:
Connection times out.

Expected Results:
CVS should start updating changed files and listing those that haven't.
Comment 1 Andrew Ferguson 2001-10-17 18:42:39 EDT
Ok, I finally worked this down to a difference in the /sbin/ifup scripts. When I
replaced the 7.1 script with the 6.2 script, everything works *perfectly*. I
have attached a diff between the two scripts that I have cut down to the
possible problem areas. I'll investigate exactly which change caused it (and how
I can fix my config files to make it work) when I get some more time.
Comment 2 Andrew Ferguson 2001-10-17 18:43:44 EDT
Created attachment 34321 [details]
Cut-down diff between 7.1 and 6.2's /sbin/ifup scripts
Comment 3 Andrew Ferguson 2001-10-18 22:35:02 EDT
Apparently the 6.2 network setup hard-coded the mtu for all devices to 1390. 
The MTU setting for the 7.1 scripts was 1500 in my config file. Changing to 
1390 resulted in a perfectly working network connection with the 7.1 scripts. 
After some experimentation, I settled on 1400, which works perfectly and is 
about 7% faster for doing CVS updates than an MTU of 1390 in my setup.

Closing as NOTABUG.

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