TJ Saunders

This should now be fixed by https://github.com/proftpd/proftpd/commit/618d41a87f434ea6fe0c85d1fc9873192b76e3bd -- I also opportunistically updated the test to use the `test_setup()`, `test_cleanup()` helpers, to reduce some of the boilerplate. Thanks!

The best way to get more logging for such unexpected failures is [ProFTPD debug logging](http://www.proftpd.org/docs/howto/Debugging.html). It would also help us to see the `proftpd.conf` that you are using.

We _really_ should implement/address [Bug #3308](http://bugs.proftpd.org/show_bug.cgi?id=3308) before doing this, so that `prxs` can handle multi-file modules from GitHub, too.

I found the following to be a good place to start: $ find . -type f -name "*.c" -print | xargs grep -n 'buf\['

This issue may indeed be related to the version of the Perl modules in use. What does the following show for you? ```sh perl -MNet::FTP -e 'print $Net::FTP::VERSION, "\n";' ```

Also please be aware that there a lot of fixes currently being done for the regression tests as part of Issue #376...

For background reading material, see [How to Botch TLS Forward Secrecy](https://www.imperialviolet.org/2013/06/27/botchingpfs.html).

This feature is also useful for pods of `proftpd` running in k8s...

Your `` condition looks like it is trying to match an _IP address_, not a user name. The [docs](http://www.proftpd.org/docs/contrib/mod_ifsession.html#IfUser) talk of matching authenticated usernames with this; I think the issue...

Sorry; this is the correct link: http://www.proftpd.org/docs/howto/Debugging.html Another issue, though, is that with this: ``` Deny from 10.150.3.42 ``` Is that client, authenticating as user "10.150.3.42", actually _connecting from_ IP...