vsftpd 2.2.0 - FTP clients (PASV) not working after upgrade from 2.1.0
Richard Toohey
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-
di...@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.
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Richard Toohey
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.
Richard Toohey
> On 20/08/2009, at 9:41 PM, Richard Toohey wrote:
[cut]
>>
>> 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.
[cut]
>> Firefox 3.5 on Mac gives me 500 OOPS: priv_sock_get_cmd
>>
>> Google gave me this: http://www.mail-archive.com/debian-bugs-
>> di...@lists.debian.org/msg673507.html
[cut]
>
> If no bright ideas forthcoming, I'll try the vsftpd author.
For the archives:
I emailed the author (Chris Evans) and there is a fix in the latest
version (2.2.1 - Oct 2009)
- Fix crash regression with the pasv_address option enabled.