Subject: wuftpd 2.4.2 beta18 + VR6 patch hangs during login when server is full

From: Stephen Kwan <[email-masked]>
Date: Thu, 3 Sep 1998 11:52:06 -0400

Hi all,

I'm experiencing a problem with beta 18 + VR6 patch.  My configuration is:

Intel box running Linux kernel 2.0.35 with base Slackware 3.4.

The symptom is as follows:

I run my server in standalone mode (-W switch) from /etc/rc.d/rc.local
instead of running it off inetd.  When the server is full and someone tries
to log in, the server either returns the wrong message or simply freezes.
For example, using the base Linux ftp client, I get the following:

XXXX:~/tmp/wu-ftpd-2.4.2-beta-18$ ftp localhost
Connected to localhost.
220-Welcome to my FTP server!
220-
220-The local time is: Thu Sep  3 11:28:59 1998
220-
220-If you have problems logging in, please try using
220-a dash (-) as the first character of your password --
220-this will turn off the continuation messages that may
220-be confusing your ftp client.
220-
220 XXXX FTP server (Version wu-2.4.2-academ[BETA-18-VR6](1) Fri Aug 28
15:31:54 EDT 1998) ready.
Name (localhost:xxxx): anonymous
530-
530-********************************************************************
530-Sorry, there are too many anonymous users using the system at this
530-time.  Please try again later.
530-
530-********************************************************************
530-
331 Guest login ok, send your complete e-mail address as password.

At this point, the ftp client simply freezes.  Any input is ignored and
even crtl-C can't get me back out.  I had to open another session and kill
it.  This freezing also occurs with the ncftp client.

The interesting thing is that although the server is full, it still asks
for the password.  I believe this did not happen with the base wuftpd.  It
simply closes the connection.

Any input is appreciated.

--
Stephen Kwan
[email-masked]
(814)863-2975
http://host46.mrl.psu.edu/~skwan

 -- I am Pentium of Borg.  Division is futile.  You will be approximated. --

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 3 Sep 1998 12:13:18 -0400 (EDT)

> For example, using the base Linux ftp client, I get the following:

I don't think it's the daemon mode exactly.  Try editing
<wu-ftpd>/config.h change the line reading

#undef HELP_CRACKERS

to read

#define HELP_CRACKERS

then execute

sh build clean
sh build <system>

run the new daemon and let me know if it still causes the same problem.
I'm thinking it's the cleanup when the server is full and I'm attempting
to avoid giving any information away about user names or password or other
capabilities until _after_ a successful login.

----

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 3 Sep 1998 12:46:59 -0400 (EDT)

On Thu, 3 Sep 1998, Stephen Kwan wrote:

> instead of running it off inetd.  When the server is full and someone
> tries to log in, the server either returns the wrong message or simply
> freezes.  For example, using the base Linux ftp client, I get the
> following: 

Using base Linux ftp client and the daemon in inetd mode (just testing,
OK?) I get '530 Login incorrect.' which is what I expected.  After I
exceed the ftpaccess 'loginfails' limit, the ftp client tells me the
remote server closed the connection.  This is normal operation.

Repeating the same test without -w or -W (default: log to wtmp), I get the
same results.

Repeating the same test with -W (disable wtmp logging), I still get the
same results.

I cannot duplicate the problem you're reporting.  can you provide more
information?

----

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 3 Sep 1998 13:55:31 -0400 (EDT)

> For example, using the base Linux ftp client, I get the following:

OK!  I was finally able to recreate this problem.  It's not the standalone
daemon mode .. I was able to cause it in inetd mode as well.  The symptom

> 331 Guest login ok, send your complete e-mail address as password.

The ftp client was confused by a 3xx message following the 5xx.  I'll work
up a patch for VR7, in the meantime, the simplest solution is to not use
a message file for 'limit' or 'deny' in your ftpaccess file.

----