vsftpd 2.2.0 - FTP clients (PASV) not working after upgrade from 2.1.0

Sat Aug 22 10:32:06 UTC 2009

On 20/08/2009, at 9:41 PM, Richard Toohey wrote:

> Hi, all.  Hopefully this is the right list; apologies if not.
>
> Wondering if anyone else has seen this or if something peculiar to  
> my set-up.
>
> Server is i386 FreeBSD 7.2, ports upgraded with portmaster.
>
> vsftpd upgraded from 2.0.5 (or .6) to 2.1.0 no problems.
>
> Upgraded to 2.2.0 and ftp clients have started to fail - first  
> noticed on Windows/Internet Explorer, but also OpenBSD/Firefox 3.0.x.
>
> If I try a command line line, no such issues (from the logs, the  
> command line clients are using EPSV.)
>
> Firefox 3.5 on Mac gives me 500 OOPS: priv_sock_get_cmd
>
> Google gave me this:  http://www.mail-archive.com/debian-bugs- 
> dist at lists.debian.org/msg673507.html
>
> I crank up the logging with log_ftp_protocol=YES and I see the same  
> behaviour as reported to the Debian list:
>
> Thu Aug 20 21:10:04 2009 [pid 73929] FTP command: Client "XXX. 
> 72.27.XXX", "USER xxxxxxx"
> Thu Aug 20 21:10:04 2009 [pid 73929] [xxxxxxx] FTP response: Client  
> "XXX.72.27.XXX", "331 Please specify the password."
> Thu Aug 20 21:10:04 2009 [pid 73929] [xxxxxxx] FTP command: Client  
> "XXX.72.27.XXX", "PASS <password>"
> Thu Aug 20 21:10:04 2009 [pid 73928] [xxxxxxx] OK LOGIN: Client  
> "XXX.72.27.XXX"
> Thu Aug 20 21:10:04 2009 [pid 73933] [xxxxxxx] FTP response: Client  
> "XXX.72.27.XXX", "230 Login successful."
> Thu Aug 20 21:10:04 2009 [pid 73933] [xxxxxxx] FTP command: Client  
> "XXX.72.27.XXX", "SYST"
> Thu Aug 20 21:10:04 2009 [pid 73933] [xxxxxxx] FTP response: Client  
> "XXX.72.27.XXX", "215 UNIX Type: L8"
> Thu Aug 20 21:10:04 2009 [pid 73933] [xxxxxxx] FTP command: Client  
> "XXX.72.27.XXX", "PWD"
> Thu Aug 20 21:10:04 2009 [pid 73933] [xxxxxxx] FTP response: Client  
> "XXX.72.27.XXX", "257 "/usr/home/xxxxxxx""
> Thu Aug 20 21:10:04 2009 [pid 73933] [xxxxxxx] FTP command: Client  
> "XXX.72.27.XXX", "TYPE I"
> Thu Aug 20 21:10:04 2009 [pid 73933] [xxxxxxx] FTP response: Client  
> "XXX.72.27.XXX", "200 Switching to Binary mode."
> Thu Aug 20 21:10:04 2009 [pid 73933] [xxxxxxx] FTP command: Client  
> "XXX.72.27.XXX", "PASV"
>
> ... and the log ends there (if I use an FTP command line client,  
> there's an EPSV rather than a PASV, and things continue.)
>
> I've gone back to 2.1.0 in the meantime.
>
> Any advice, cluesticks, etc., welcomed.  I appreciate there may be  
> a lot more information required, but a "yes, seen this" or a "no,  
> all good here, it's something else in your configuration" will help  
> a lot at this point.
>
> Thanks.

If anyone follows this trail, here's where I've got to:

I *am* seeing the same problem as the Debian report above - the real  
issue is pasv_address not just PASV.

The following work I did against the 2.2.0 source downloaded from the  
vsftpd site (seems identical to the FreeBSD port for the chunk I'm  
looking at, but obviously worth mentioning.)

My /usr/local/etc/vsftpd.conf (*not* all the settings from there,  
just a selection that might be different from defaults)

anonymous_enable=NO
local_enable=YES
background=YES
listen=YES
pasv_min_port=17000
pasv_max_port=18000
pasv_address=22.33.44.55
use_localtime=YES
log_ftp_protocol=YES

If I take out pasv_address, it will work (but clients that check the  
server response will not work because the returned IP does not match  
the one they connected to, which I think is the point of pasv_address.)

I tried using a domain name, and the pasv_addr_resolve option, no  
difference.

The following fudge makes things go (I am *not* suggesting this is a  
good idea, just hoping that it might give someone a clue!)

postlogin.c
========

  584   if (tunable_pasv_address != 0)
  585   {
! 586 //    /* Report passive address as specified in configuration */
! 587 //    if (vsf_sysutil_inet_aton(tunable_pasv_address,  
s_p_sockaddr) == 0)
! 588 //    {
! 589 //      die("invalid pasv_address");
! 590 //    }
  591   }
  592   else
  593   {
  594     vsf_sysutil_sockaddr_clone(&s_p_sockaddr, p_sess- 
 >p_local_addr);
  595   }
  596   str_alloc_text(&s_pasv_res_str, "Entering Passive Mode (");
  597   if (!is_ipv6)
  598   {
! 599     //str_append_text(&s_pasv_res_str, vsf_sysutil_inet_ntop 
(s_p_sockaddr));
! 600     str_append_text(&s_pasv_res_str, tunable_pasv_address);
  601   }
  602   else

So I commented out lines 586-590 and line 599 and added line 600 to  
force the IP I want to go out in the server response.

make
./vsftpd /usr/local/etc/vsftpd.conf

And try the client again (FireFox 3.5 on Mac) - all good, and the  
logs say ...

Sat Aug 22 22:05:54 2009 [pid 65324] [xxxxxxx] FTP response: Client  
"121.72.0.211", "200 Switching to Binary mode."
Sat Aug 22 22:05:54 2009 [pid 65324] [xxxxxxx] FTP command: Client  
"121.72.0.211", "PASV"
[before my change, the server would respond with 500 OOPS:  
priv_sock_get_cmd here, with my change, we get the expected line]
Sat Aug 22 22:05:54 2009 [pid 65324] [xxxxxxx] FTP response: Client  
"121.72.0.211", "227 Entering Passive Mode (22,33,44,55,68,65)."

So I now get the required PASV response - with the pasv_address I  
specified in the vsftpd.conf file.

Not sure what to do next - just about hit the current limits of my C  
ability.  RTFMing and understanding how to debug a beastie like this ...

I know there are options e.g. don't hack around with NAT/FTP/IP  
addresses and pasv_address or use proftpd, etc., etc., but I'd like  
to understand why this worked in 2.0.5/.6 and 2.1.0 and doesn't any  
more.  And a learning experience as well.

If no bright ideas forthcoming, I'll try the vsftpd author.

Thanks.