LinuxQuestions.org - [SOLVED] breaking ftp connections with vsftpd on -current

- Slackware (http://www.linuxquestions.org/questions/slackware-14/)

- - breaking ftp connections with vsftpd on -current (http://www.linuxquestions.org/questions/slackware-14/breaking-ftp-connections-with-vsftpd-on-current-4175425106/)

breaking ftp connections with vsftpd on -current

since a recent -current upgrade I've had this issue that ftp connections in my LAN would break as soon as a data connection was opened.

I am currently on RC4.

Symptoms: midnight commander refuses to enter a directory with a red popup saying

Code:

Error - cannot change directory

In the classical ftp client the problem can be triggered by using the ls command (active or passive mode irrelevant):

Code:

ftp> ls

200 PORT command successful. Consider using PASV.

150 Here comes the directory listing.

421 Service not available, remote server has closed connection

Code:

ftp> pa

Passive mode on.

ftp> ls

227 Entering Passive Mode (...).

150 Here comes the directory listing.

421 Service not available, remote server has closed connection

this happens for localhost and remote hosts, but not consistently for all directories.

I'm investigating, but maybe someone has an idea where else to look?

Update: normally started from inetd without tcp wrappers, i have tried standalone mode. result is the same.

Strace reveals that the vsftpd server process is killed by a SIGSYS signal. Internet studies reveal that this signal may be related to something called "seccomp filter sandboxing" which was newly introduced in vsftpd-3.0.0.

Reverting vsftpd back to 2.3.4 (ie. the package delivered in Slackware 13.37) solves the issue.

With regards to Slackware 14, how to proceed with this?

quick update: what I didn't know is the option

Code:

seccomp_sandbox=NO

which makes 3.0.0 work on my machine.

The other thing I found out: the issue is probably related to my kernel version (3.5.3) or config. Good news for Slackware 14.0: the issue is not present when booting the distro kernel.

Still investigating.

update: Chris has put out version 3.0.1 which solves the issue. I had a build issue though (that can be overcome). We'll see how this pans out.

I built vsftpd 3.0.1 using -Current SlackBuild and it's OK here

Strange. I found the linker choking on the command line created with the help of the script vsf_findlibs.sh. The script creates the following output on my system:

Code:

-lwrap

-lnsl

-lnsl

-lcrypt

-lcrypt

-lcrypt

-ldl

-lnsl

-lresolv

-lutil

/lib/libcap.so.2

-lssl -lcrypto

I had to replace "/lib/libcap.so.2" by "-lcap" to make it work. I'm on x86_64 and gcc-4.7.1_multilib-x86_64-1fix1_alien.

PS: just as I re-read my post it suddenly occurs to me that the missing $LIBDIRSUFFIX might be the problem.
PPS: confirmed

for those interested, there was another seccomp issue which has now been fixed upstream by version 3.0.2.

Regarding the build issue, it only occurs in a multilib environment. The correct way of fixing it is to replace all occurrences of /lib/ by /lib$LIBDIRSUFFIX/ in vsf_findlibs.sh, and by exporting the environment variable LIBDIRSUFFIX in the Slackbuild. But as I said, it only really causes a build problem in a multilib environment, not in the Slackware binary distribution.

Marking issue as solved.