[grsec] [Bug 2516] Getting "421 Login Timeout" immediately upon connect

[Thomas Oppel]

First good news:
The symptom fix provided by TJ Saunders workes with us, too:
http://bugs.proftpd.org/attachment.cgi?id=2185&action=view
Tried it with proftpd 1.2.10-4 from sid.

Well, what I did two hours back, was to get the recent proftpd 1.2.10-5 (with mod_delay 0.4) from Debian unstable (sid), and try to recompile it for our productive Debian testing (sarge) environments.
As http://www.grsecurity.net was too busy at that moment, to give me the recent uffical 2.4.28 patch, I had an unpatched, unconfigured vanilla kernel source tree, which made configure complain and exit, because cpp was moped not to read from _configured_ kernel sources.
This gave me an idea.

I usually have /usr/include/linux softlinked to /usr/src/linux-[kernelversion]-grsec/include/linux.
This time it was linked to /usr/src/linux-2.4.28/include/linux vanilla.

Short try and check:
Our proftpd 1.2.10-5 - without the symtom fix - runs (since more than two hours).
I've tried the 'date --set' check, one hour back, two hours back, logged in/not: Login accepted.
I've tried it setting time ahead: '421 Login Timeout', which is obviously okay.
And then reconnected: login successful.
AHA!

To  Marc-Christian Petersen on grsecurity:
The proftpd packages you run on your grsec patched boxen, are they compiled with cpp reading from grsec patched kernel sources?

> Hmm, this looks odd. Anyway, I cannot reproduce this behaviour. We have 
> uncountable 2.4-grsec machines in production and some of them even with 
> proftpd running (from debian sid) w/o any problems (though I use 2.4-WOLK and 
> not mainline ;)

To TJ Saunders at proftp-committers:
You have this 2.6.7-grsec box right? Same question to you.

If Marc's are not but TJ's were, the question is, why does it happen with 1.2.9-19 and 1.2.10-4?
Does mod_delay 0.4 in 1.2.10-5 do the job unintendedly?

Beating about symptoms, I know, but the beast runs.

Cheers,
Thomas.