Bug 129219 - ftp client after kernel-2.6.7-1.494.2.2 no longer works to wu-ftpd server
ftp client after kernel-2.6.7-1.494.2.2 no longer works to wu-ftpd server
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Depends On:
  Show dependency treegraph
Reported: 2004-08-05 06:13 EDT by Kevin Taylor
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-16 02:04:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kevin Taylor 2004-08-05 06:13:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040615 Firefox/0.9

Description of problem:
Using kernel-2.6.6-1.435.2.3, the ftp client connects fine to a
wu-ftpd server, after upgrading to kernel-2.6.7-1.494.2.2, it no
longer works.

Nothing else changed on the system but the kernel.

This message appears in the wu-ftp server logs:

Aug  5 06:08:40 6D:eosdata ftpd[14880656]: lost connection to hostname

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. ftp to a wu-ftp server, client hangs

Actual Results:  client hangs

Expected Results:  ftp login banner

Additional info:
Comment 1 Kevin Taylor 2004-08-05 08:39:06 EDT
hmm...this may be localized to wuftpd on irix, but something in the
kernel update made this start to fail.
Comment 2 Thomas Woerner 2004-08-05 10:23:11 EDT
this is not a ftp problem, then
Comment 3 Rik van Riel 2004-08-05 10:27:17 EDT
Could you get us 'netstat' output of the ftp connection, shown from
both the client and the server side ?

If there's something wrong with the network layer, chances are we
should be able to see the differences easily...
Comment 4 Kevin Taylor 2004-08-05 10:35:01 EDT
The server doesn't log anything in the netstat output, probably
because the connection opens and closes too fast for me to really
catch it. This is the syslog entry on the server.

Aug  5 10:33:45 6T:serverhost wuftpd[8456007]: connect from clienthost
Aug  5 10:33:45 6D:serverhost ftpd[8456007]: lost connection to
clienthost [xxx.xxx.xxx.xxx]

The client, however, seems to think it's connected to the server.

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address        
tcp        0      0 clienthost:1034 serverhost:ftp ESTABLISHED 
Comment 5 Rik van Riel 2004-08-05 10:48:32 EDT
OK, that looks like a networking problem indeed...
Comment 6 Angelyn W. Moore 2004-08-06 19:25:53 EDT
I have the same experience with NcFTPD.

ftp under 2.6.6-1.435.2.3 to NcFTPd works
ftp under 2.6.7-1.494.2.2 to NcFTP does not work

ftp under 2.6.6-1.435.2.3 to vsftpd works
ftp under 2.6.7-1.494.2.2 to vsftpd works
Comment 7 Need Real Name 2004-08-09 12:00:44 EDT
This is probably a duplicate of Bug 129204.
Comment 8 Angelyn W. Moore 2004-08-10 14:05:07 EDT
Indeed, putting net.ipv4.tcp_default_win_scale=0 into /etc/sysctl.conf
has me successfully connecting to the NcFTPd server in question, under
Comment 9 Kevin Taylor 2004-08-11 06:00:32 EDT
Confirmed for me too. I did this dynamically and it solved the issue.
Comment 10 Kevin Taylor 2004-08-18 07:00:22 EDT
Ok, I can now connect with ftp, but the data transfer is extremely
slow...and when I ctrl-c out of an ftp client session I get a
Segmentation fault.

Same real issue as before, 2.6.6 kernel works ok (I can ftp the
kernel-sourcecode package from the server in about 7 seconds), 2.6.7
kernel takes forever. It grabs a big chunk of data to start, then
transfers about  1k every few seconds the rest of the time.
Comment 11 Kevin Taylor 2004-08-18 07:48:17 EDT
not sure if this info will help, but the machines having problems are
using the e1000 driver.
Comment 12 Kevin Taylor 2004-08-20 06:23:57 EDT
The speed problem seems to have been fixed with kernel-2.6.8-1.521
Comment 13 Dave Jones 2004-11-27 17:32:39 EST
mass update for old bugs:

Is this still a problem in the 2.6.9 based kernel update ?
Comment 14 Need Real Name 2004-11-28 16:57:24 EST
I no longer have an FC2 system to test with (they've both been
upgraded to FC3), but FC3 no longer appears to have the
net.ipv4.tcp_default_win_scale sysctl:

$ uname -r

$ /sbin/sysctl net.ipv4.tcp_default_win_scale
error: 'net.ipv4.tcp_default_win_scale' is an unknown key

Everything does appear to work fine, though.

P.S. This looks like a duplicate of Bug 129204 .
Comment 15 Dave Jones 2005-04-16 02:04:45 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

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