Date: Sat, 22 Aug 2009 22:31:58 +1200 From: Richard Toohey <richardtoohey@paradise.net.nz> To: ports@FreeBSD.org Subject: Re: vsftpd 2.2.0 - FTP clients (PASV) not working after upgrade from 2.1.0 Message-ID: <D0F07E7C-D5CE-4CAF-9AD6-5AE271772B81@paradise.net.nz> In-Reply-To: <E89977DA-1885-4C04-AE01-0036DAD57311@paradise.net.nz> References: <E89977DA-1885-4C04-AE01-0036DAD57311@paradise.net.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0F07E7C-D5CE-4CAF-9AD6-5AE271772B81>