Bug 358181

Summary:	"lftp" disconnects FTP data connection if remote dir is found empty
Product:	Red Hat Enterprise Linux 4	Reporter:	David Tonhofer <bughunt>
Component:	lftp	Assignee:	Jiri Skala <jskala>
Status:	CLOSED ERRATA	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	4.5	CC:	aglotov, jpayne, mbarabas, rvokal, sputhenp, tao
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-05-18 20:15:17 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Tonhofer 2007-10-30 13:56:40 UTC

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

Comment 1 David Tonhofer 2007-11-02 13:12:32 UTC

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...]

Comment 2 David Tonhofer 2007-12-05 20:58:45 UTC

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.

Comment 3 RHEL Program Management 2008-09-24 20:24:05 UTC

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.

Comment 21 errata-xmlrpc 2009-05-18 20:15:17 UTC

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