From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: Updated all rpms from updates.redhat.com Installed 2.4.3-12 kernel rpms .i686. IPchains flushed (no firewall). wu-ftpd is enabled in xinetd.d 'ftp localhost' gives message "connection refused". same result if attemp ftp from another computer. Have had same results on 4 different machines. Booting with previous kernel 2.4.2-2 ftp works normally. Version-Release number of selected component (if applicable): kernel version 2.4.3-12 How reproducible: Always Steps to Reproduce: 1. Update 7.1 to new kernel 2.4.3-12 2. ftp localhost (or ip address) 3. Actual Results: got the message "connection refused" Expected Results: should have gotten connection to wu-ftpd server with a login prompt. Additional info:
Works fine here. There must be some configuration problem at your end. Is wu-ftpd really running and listening on local interface? Is the TCP wrapper library configured to accept in.ftpd connections? What is logged?
IPchains flushed (no firewall) -> if you selected "high firewall" mode, the default is "reject" so if you don't have any "allow" rules........
Reporter wrote it would work with kernel 2.4.2-2 which doesn't sound as if default ipchains rules would be the cause of it.
More info: ipchains input, output, forward all set to ACCEPT following is exact result (logged in as root for these tests) [root@med etc]# ftp localhost Connected to localhost.localdomain. 421 Service not available, remote server has closed connection ftp> quit The above indicates that the server is running, but something else is wrong. Something else strange (on all 4 machines): If I boot on the previous kernel (at the prompt type 'linux1' that brings me up into kernel 2.4.2-2 and ftp works normally. If I edit lilo.conf and change 'default=linux' to 'default=linux1' save it, and run lilo. The next boot does come up showing the old kernel version in /proc/version as it should, but ftp does not work. It only works if I MANUALLY type linux1 at the boot prompt. It should bring up the kernel associated with the label 'linux1' exactly the same as if I type in the command manually. This may be a lilo problem. These things occur on all 4 machines. These machines were all fine before the kernel upgrade, even after installing all the other upgraded rpms (except kernel stuff).
New info: If I type 'linux' OR 'linux1' at the boot: prompt during reboot, ftp works fine. The key is MANUALLY specifying 'linux' or 'linux1'. This is looking more and more like a lilo issue.
Let's sum this up. You're saying that with default=linux1 (kernel-2.4.2-2) AND/OR default=linux (kernel-2.4.3-12) it does NOT work while when entering "linux1" at the LILO prompt, it works? Question 1: What do you have in /etc/hosts.allow and /etc/hosts.deny? Question 2: Is anything logged to /var/log/secure? If you add ftpd server flags -L -l to /etc/xinet.d/wu-ftpd and run "service wu-ftpd restart", anything logged then?
Again, manually specifying 'linux' at the boot: prompt, works. let it automatically start, it does NOT work. No entry in either hosts.deny or hosts.allow. In /var/log/secure: START: ftp pid=3449 from 127.0.0.1 EXIT: ftp pid=3449 duration=0(sec)
This is NOT a kernel but, its a lilo bug Installed lilo version 21.7.5 and all is fine.
Since a lilo upgrade has solved your problem, I'm closing this bug report out.