Bug 54177

Summary: `cvs update` fails to get updates from cvs server
Product: [Retired] Red Hat Linux Reporter: Andrew Ferguson <andrew>
Component: cvsAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED NOTABUG QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
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: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Cut-down diff between 7.1 and 6.2's /sbin/ifup scripts none

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.org:/cvs/gnome login
2. cvs -d :pserver:anonymous.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.