Description of problem: lftp connects to remote server to retrieve files in passive mode. If the remote directory is found emtpy on "ls", then the data connection is broken by lftp. This may or may not depend on the implementation of the remote server. The debug log by lftp: "<---" comes from the remote server "--->" comes from the local client <--- 211 End ---> USER foo <--- 331 Password required for foo. ---> PASS bar <--- 230 User foo logged in. ---> PASV <--- 227 Entering Passive Mode (XXX,XXX,XXX,XXX,209,47) ---- Connecting data socket to (XXX.XXX.XXX.XXX) port 53551 ---> NLST **** data-socket: Connection reset by peer This seems to be the problem described here: http://www.mail-archive.com/lftp-devel@uniyar.ac.ru/msg01502.html There we read: "In the source code you have a workaround for the case where [FTP server] would return a 450 error when you NLST a empty directory. In the case above though, it seems that lftp decides to call DisconnectNow() when the data socket is reset (which happens because [FTP server] writes nothing to the data socket and just returns 450)." I tried the patch described in http://www.mail-archive.com/lftp-devel@uniyar.ac.ru/msg01503.html on the Red Hat source package, but no joy. As a workaround, I will upgrade to the latest lftp 3.6.0 of 2007-10-19 Version-Release number of selected component (if applicable): lftp-3.0.6-3 How reproducible: Always
Further information: - The problem cannot be reproduced with FTP servers available on Red Hat. - The problem occurs with the "nlist" command on an empty directory, not "ls" or "dir" on an empty directory. Behaviour observed with the offending FTP server: Logging in manually using "ftp" (ftp-0.17-23.EL4) and issuing an "NLIST" works: ftp> nlist 227 Entering Passive Mode 226 Transfer complete. ftp> Logging in manually using the RH4 "lftp", then issuing an "NLIST" fails: lftp XXXXXXX@XXXXXXXX:~> nlist ---- Connecting to XXXXXXXXXXX port 21 <--- 220 XXXXXXXXXXXXXXXXXXX ---> FEAT <--- 211-Features: <--- MDTM <--- REST STREAM <--- SIZE <--- 211 End ---> USER XXXXXXXX <--- 331 Password required for XXXXXXXXX. ---> PASS YYYYYYYY <--- 230 User XXXXXXX logged in. ---> PWD <--- 257 "/XXXXXXX" is current directory. ---> PASV <--- 227 Entering Passive Mode XXXXXXXXXXXXX ---- Connecting data socket to XXXXXXXXXXXXXX ---> NLST **** data-socket: Connection reset by peer ---- Closing data socket ---- Closing control socket `' at 0 [Delaying before reconnect: 27] Logging in manually using the latest available lftp (3.6.0) from the command line yields a "waiting for response" which does not seem to end. lftp XXXXXXXX@XXXXXXXXXXXX:~> nlist ---- Connecting to XXXXXXXXXXXXXXXXXXXXXX <--- 220 XXXXXXXXXXXXXXXXXX ---> FEAT <--- 211-Features: MDTM REST STREAM SIZE <--- 211 End ---> USER XXXXXXX <--- 331 Password required for XXXXXXXXX. ---> PASS YYYYYYYY <--- 230 User XXXXXXXX logged in. ---> PWD <--- 257 "/XXXXXXX" is current directory. ---> PASV <--- 227 Entering Passive Mode XXXXXXXXXXXXX ---- Connecting data socket to XXXXXXXXXXXXXX ---- Data connection established ---> NLST <--- 226 Transfer complete. `' at 0 [Waiting for response...]
The problem occurs if the the remote server is: ProFTPD Version 1.3.0a A short look at their bug database brings this: http://bugs.proftpd.org/show_bug.cgi?id=1931 Red Hat Support says: --------------------- I have been trying to reproduce this issue with proftpd. I am using the proftpd rpm from ftp://rpmfind.net/linux/dag/redhat/el4/en/i386/dag/RPMS/. I can only reproduce this issue with proftpd-1.3.0a-4 as the server, but can't reproduce this with proftpd-1.3.1-1. So it seems that the latest version of proftpd itself has a fix for this. Can you please inquire your server admin about the possibility of getting proftpd upgraded from 1.3.0 to 1.3.1. I think, once your proftpd server gets upgraded to 1.3.1, you would get this issue fixed automatically. I agree that this may be a bug with lftp, but I am not aware of any other lftp + ftp server combination which causes this bug to force engineering for a fix in lftp. --------------------- OR agrees with bug being too obscure to warrant fixing.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0976.html