Bug 54177 - `cvs update` fails to get updates from cvs server
Summary: `cvs update` fails to get updates from cvs server
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: cvs   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-09-30 15:57 UTC by Andrew Ferguson
Modified: 2007-04-18 16:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-19 02:35:06 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)
Cut-down diff between 7.1 and 6.2's /sbin/ifup scripts (3.39 KB, text/plain)
2001-10-17 22:43 UTC, Andrew Ferguson
no flags Details

Description Andrew Ferguson 2001-09-30 15:57:11 UTC
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 
disabled.) 

[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 22:42:39 UTC
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 22:43:44 UTC
Created attachment 34321 [details]
Cut-down diff between 7.1 and 6.2's /sbin/ifup scripts

Comment 3 Andrew Ferguson 2001-10-19 02:35:02 UTC
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.