NetBSD Problem Report #10897

Received: (qmail 23622 invoked from network); 26 Aug 2000 14:18:18 -0000
Message-Id: <200008261402.e7QE2AF29827@zoo>
Date: Sat, 26 Aug 2000 08:02:10 -0600 (MDT)
From: jbernard@mines.edu
Reply-To: jbernard@mines.edu
To: gnats-bugs@gnats.netbsd.org
Subject: ftp doesn't play nice with some servers
X-Send-Pr-Version: 3.95

>Number:         10897
>Category:       bin
>Synopsis:       ftp doesn't play nice with some servers
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sat Aug 26 14:19:00 +0000 2000
>Closed-Date:    
>Last-Modified:  Sat Jun 16 07:19:24 +0000 2012
>Originator:     Jim Bernard
>Release:        Aug. 12, 2000
>Organization:
	Speaking for myself
>Environment:
System: NetBSD zoo 1.5E NetBSD 1.5E (ZOO-$Revision: 1.55 $) #0: Sat Aug 12 14:34:20 MDT 2000 jim@zoo:/home/tmp/compile/sys/arch/i386/compile/ZOO i386


>Description:
	If I connect to ftp.netscape.com with the default configuration
	(no startup flags except -i) and try to do a directory listing
	(dir or ls), the connection is dropped.  Initially, there's a
	message about EPSV not being understood (which seems to happen
	with most servers), but evidently the fallback to active mode
	is not working in this case.  If I force active mode on the
	command line (-A), then I can get a directory listing.  It seems
	like the default behavior should be less prone to failure, whatever
	it takes to accomplish that.

>How-To-Repeat:
	ftp -i ftp.netscape.com
	dir

>Fix:
	Unknown.
>Release-Note:
>Audit-Trail:

From: itojun@iijlab.net
To: jbernard@mines.edu
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Sat, 26 Aug 2000 23:54:30 +0900

 >>Synopsis:       ftp doesn't play nice with some servers

 	this seems to be problem on ftp.netscape.com.  I happened to be
 	connected to this guy,
 220 ftp-va52 SGI 1.5: FTP server (Version wu-2.4.2-academ[BETA-17](2) Wed Jul 19 13:06:02 PDT 2000) ready.

 	and this guy chokes with normal IPv4 passive connection (I mean, PASV).
 	there should be something really badly configured on the
 	ftp.netscape.com side.

 itojun

From: itojun@iijlab.net
To: jbernard@mines.edu, gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Sat, 26 Aug 2000 23:58:16 +0900

 ------- =_aaaaaaaaaa0
 Content-Type: text/plain; charset="us-ascii"
 Content-ID: <27301.967301889.1@coconut.itojun.org>
 Content-Transfer-Encoding: 7bit

 >	this seems to be problem on ftp.netscape.com.  I happened to be
 >	connected to this guy,
 >220 ftp-va52 SGI 1.5: FTP server (Version wu-2.4.2-academ[BETA-17](2) Wed Jul 19 13:06:02 PDT 2000) ready.
 >	and this guy chokes with normal IPv4 passive connection (I mean, PASV).
 >	there should be something really badly configured on the
 >	ftp.netscape.com side.

 	here is transcript.  noticed the following:
 	- 205.188.247.193 dies with PASV.
 	- 207.220.85.30 works just fine with PASV.

 itojun



 ------- =_aaaaaaaaaa0
 Content-Type: text/plain; charset="us-ascii"
 Content-ID: <27301.967301889.2@coconut.itojun.org>
 Content-Transfer-Encoding: 7bit

 ftp> open 205.188.247.193
 Connected to 205.188.247.193.
 220 ftp-va54 SGI 1.5: FTP server (Version wu-2.4.2-academ[BETA-17](2) Wed Jul 19 13:06:02 PDT 2000) ready.
 ftp_login: user `<null>' pass `<null>' host `205.188.247.193'
 Name (205.188.247.193:itojun): ftp
 ---> USER ftp
 331 Guest login ok, send your complete e-mail address as password.
 Password:
 ---> PASS XXXX
 230-Welcome to the Netscape Communications Corporation FTP server.
 230-
 230-If you have any odd problems, try logging in with a minus sign (-)
 230-as the first character of your password.  This will turn off a feature 
 230-that may be confusing your ftp client program.
 230-
 230-Please send any questions, comments, or problem reports about 
 230-this server to ftp@netscape.com.
 230-
 230-***********  October 13, 1995  **********
 230-Private ftp is now only on ftp1.netscape.com.  Anonymous is supported on
 230-ftp 2 through 8.  If you are accessing a named account please use ftp1.
 230-
 230 Guest login ok, access restrictions apply.
 ---> SYST
 215 UNIX Type: L8
 Remote system type is UNIX.
 Using binary mode to transfer files.
 ---> PWD
 di257 "/" is current directory.
 got remotepwd as `/'
 ftp> dir
 ---> PASV
 ^C
 421 Service not available, user interrupt. Connection closed.



 ------- =_aaaaaaaaaa0
 Content-Type: text/plain; charset="us-ascii"
 Content-ID: <27301.967301889.3@coconut.itojun.org>
 Content-Transfer-Encoding: 7bit

 ftp> ftp ftp.netscape.com
 Trying 207.200.85.30...
 Connected to hvftp-mv.netscape.com.
 220 ftp106 SGI 1.5: FTP server (Version wu-2.4.2-academ[BETA-17](2) Wed Jul 19 13:06:02 PDT 2000) ready.
 ftp_login: user `<null>' pass `<null>' host `ftp.netscape.com'
 Name (ftp.netscape.com:itojun): ftp
 ---> USER ftp
 331 Guest login ok, send your complete e-mail address as password.
 Password:
 ---> PASS XXXX
 230-Welcome to the Netscape Communications Corporation FTP server.
 230-
 230-If you have any odd problems, try logging in with a minus sign (-)
 230-as the first character of your password.  This will turn off a feature 
 230-that may be confusing your ftp client program.
 230-
 230-Please send any questions, comments, or problem reports about 
 230-this server to ftp@netscape.com.
 230-
 230-***********  October 13, 1995  **********
 230-Private ftp is now only on ftp1.netscape.com.  Anonymous is supported on
 230-ftp 2 through 8.  If you are accessing a named account please use ftp1.
 230-
 230 Guest login ok, access restrictions apply.
 ---> SYST
 215 UNIX Type: L8
 Remote system type is UNIX.
 Using binary mode to transfer files.
 ---> PWD
 257 "/" is current directory.
 got remotepwd as `/'
 ftp> dir
 ---> PASV
 227 Entering Passive Mode (207,200,85,30,27,177)
 ---> LIST
 150 Opening ASCII mode data connection for /bin/ls.
 total 8
 drwxr-xr-x    7 root     sys           71 Aug  8 01:58 .
 drwxr-xr-x    7 root     sys           71 Aug  8 01:58 ..
 d--x--x--x    2 root     other         20 Mar 18  1999 bin
 dr-xr-xr-x    2 root     other         22 Oct 19  1998 dev
 d--x--x--x    2 root     other         78 Feb  3  1999 etc
 dr-xr-xr-x    2 root     other         98 Nov  5  1998 lib32
 drwxr-xr-x   26 888      sys         4096 Jun 13 09:42 pub
 226 Transfer complete.
 ftp> close
 ---> QUIT
 221 Goodbye.

 ------- =_aaaaaaaaaa0--

From: Jim Bernard <jbernard@mines.edu>
To: itojun@iijlab.net
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Sat, 26 Aug 2000 19:59:08 -0600

 On Sat, Aug 26, 2000 at 11:58:16PM +0900, itojun@iijlab.net wrote:
 > >	this seems to be problem on ftp.netscape.com.  I happened to be
 > >	connected to this guy,

   I tried using ftp to ftp.netscape.com from a Linux system with no problems.
 (I didn't pay attention to exactly which server I got, but every time I tried
 using the NetBSD ftp client in the default configuration, I couldn't get a
 directory listing.)

   Here's another server where the default behavior of the ftp client prevents
 listing a directory:

   ftp.igd.fhg.de

From: itojun@iijlab.net
To: Jim Bernard <jbernard@mines.edu>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Sun, 27 Aug 2000 11:28:01 +0900

 ------- =_aaaaaaaaaa0
 Content-Type: text/plain; charset="us-ascii"
 Content-ID: <2748.967343260.1@coconut.itojun.org>
 Content-Transfer-Encoding: 7bit

 >> >	this seems to be problem on ftp.netscape.com.  I happened to be
 >> >	connected to this guy,
 >  I tried using ftp to ftp.netscape.com from a Linux system with no problems.
 >(I didn't pay attention to exactly which server I got, but every time I tried
 >using the NetBSD ftp client in the default configuration, I couldn't get a
 >directory listing.)

 	could you please do the following:
 	- use the one I contacted and choked (with IPv4 numeric address),
 	  as there are several instances of ftp.netscape.com.  to get
 	  repeatable behavior, we need to use the exact one.
 	- please try to enable "debug" and/or "verbose" option, and send me
 	  the exact transaction.  "linux system with no problem" gives no
 	  information about what kind of transaction was used.

 >  Here's another server where the default behavior of the ftp client prevents
 >listing a directory:
 >  ftp.igd.fhg.de

 	the server (192.44.32.10) chokes with PASV, just like one of
 	ftp.netscape.com.  the issue is unrelated to the use of EPSV.
 	I have tested with the following:
 	- NetBSD 1.4.2 ftp client (never issues EPSV)
 		PASV chokes, PORT is okay
 	- NetBSD 1.5_ALPHA2 ftp client (issues EPSV)
 		EPSV unsupported, PASV chokes, PORT is okay
 	- FreeBSD 2.2.8 ftp client (never issues EPSV)
 		PASV chokes, PORT is okay
 	NetBSD 1.4.2/1.5 client works better than FreeBSD 2.2.8, as
 	it implements fallback case from PASV to PORT.

 itojun


 ------- =_aaaaaaaaaa0
 Content-Type: text/plain; charset="us-ascii"
 Content-ID: <2748.967343260.2@coconut.itojun.org>
 Content-Transfer-Encoding: 7bit

 (NetBSD 1.4.2)

 itojun[lychee:~/work/isakmpd/isakmpd] /usr/bin/ftp 192.44.32.10
 Connected to 192.44.32.10.
 220 ProFTPD 1.2.0pre10 Server (ProFTPD Anonymous Server) [nikolausharnoncourt]
 Name (192.44.32.10:itojun): ftp
 331 Anonymous login ok, send your complete e-mail address as password.
 Password:
 230 Anonymous access granted, restrictions apply.
 Remote system type is UNIX.
 Using binary mode to transfer files.
 ftp> passive
 Passive mode off.
 ftp> debug
 Debugging on (debug=1).
 ftp> dir
 ---> PORT 210,160,95,106,254,53
 200 PORT command successful.
 ---> LIST
 150 Opening ASCII mode data connection for file list.
 lrwxrwxrwx   1 root     sys             7 Dec  2  1997 bin -> usr/bin
 dr-xr-xr-x   2 root     sys           512 Dec  2  1997 dev
 dr-xr-xr-x   3 root     sys           512 Dec  8  1997 etc
 drwxrwxrwx  19 root     sys          1024 Aug 27 03:15 incoming
 -rw-r--r--   1 root     sys         91517 Aug 27 03:30 ls-lR.gz
 drwxrwxrwx 113 root     sys          3584 Aug 24 16:00 outgoing
 drwxrwxr-x  10 root     290           512 Jan 18  1999 pub
 dr-xr-xr-x   5 root     sys           512 Dec  2  1997 usr
 226 Transfer complete.
 ftp> passive
 Passive mode on.
 ftp> dir
 ---> PASV
 227 Entering Passive Mode (192,44,32,10,234,43).
 ---> PORT 210,160,95,106,254,51				<--- fallback to PORT
 200 PORT command successful.
 ---> LIST
 150 Opening ASCII mode data connection for file list.
 lrwxrwxrwx   1 root     sys             7 Dec  2  1997 bin -> usr/bin
 dr-xr-xr-x   2 root     sys           512 Dec  2  1997 dev
 dr-xr-xr-x   3 root     sys           512 Dec  8  1997 etc
 drwxrwxrwx  19 root     sys          1024 Aug 27 03:15 incoming
 -rw-r--r--   1 root     sys         91517 Aug 27 03:30 ls-lR.gz
 drwxrwxrwx 113 root     sys          3584 Aug 24 16:00 outgoing
 drwxrwxr-x  10 root     290           512 Jan 18  1999 pub
 dr-xr-xr-x   5 root     sys           512 Dec  2  1997 usr
 226 Transfer complete.

 ------- =_aaaaaaaaaa0
 Content-Type: text/plain; charset="us-ascii"
 Content-ID: <2748.967343260.3@coconut.itojun.org>
 Content-Transfer-Encoding: 7bit

 (NetBSD 1.5_ALPHA2)

 itojun[mango:/home/itojun] itojun[mango:~] ftp 192.44.32.10
 Connected to 192.44.32.10.
 220 ProFTPD 1.2.0pre10 Server (ProFTPD Anonymous Server) [nikolausharnoncourt]
 Name (192.44.32.10:itojun): ftp
 331 Anonymous login ok, send your complete e-mail address as password.
 Password:
 230 Anonymous access granted, restrictions apply.
 Remote system type is UNIX.
 Using binary mode to transfer files.
 ftp> debug
 Debugging on (debug=1).
 ftp> dir
 ---> EPSV
 500 EPSV not understood.
 disabling epsv4 for this connection
 ---> PASV
 227 Entering Passive Mode (192,44,32,10,234,47).
 ---> PORT 210,160,95,104,255,252			<--- fallback to PORT
 200 PORT command successful.
 ---> LIST
 150 Opening ASCII mode data connection for file list.
 lrwxrwxrwx   1 root     sys             7 Dec  2  1997 bin -> usr/bin
 dr-xr-xr-x   2 root     sys           512 Dec  2  1997 dev
 dr-xr-xr-x   3 root     sys           512 Dec  8  1997 etc
 drwxrwxrwx  19 root     sys          1024 Aug 27 03:15 incoming
 -rw-r--r--   1 root     sys         91517 Aug 27 03:30 ls-lR.gz
 drwxrwxrwx 113 root     sys          3584 Aug 24 16:00 outgoing
 drwxrwxr-x  10 root     290           512 Jan 18  1999 pub
 dr-xr-xr-x   5 root     sys           512 Dec  2  1997 usr
 226 Transfer complete.


 ------- =_aaaaaaaaaa0--

From: Jim Bernard <jbernard@mines.edu>
To: itojun@iijlab.net
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Sat, 26 Aug 2000 21:32:20 -0600

 On Sun, Aug 27, 2000 at 11:28:01AM +0900, itojun@iijlab.net wrote:
 > 	could you please do the following:
 > 	- use the one I contacted and choked (with IPv4 numeric address),
 > 	  as there are several instances of ftp.netscape.com.  to get
 > 	  repeatable behavior, we need to use the exact one.

   Yes.  NetBSD's ftp client chokes (without -A).  Linux's doesn't.  Nor AIX's.

 > 	- please try to enable "debug" and/or "verbose" option, and send me
 > 	  the exact transaction.  "linux system with no problem" gives no
 > 	  information about what kind of transaction was used.

   OK, on Linux (Red Hat 6.2):

     ftp -i 205.188.247.193
     ...
     ftp> debug
     Debugging on (debug=1).
     ftp> dir
     ftp: setsockopt (ignored): Permission denied
     ---> PORT xx,xx,xx,xx,9,145
     200 PORT command successful.
     ---> LIST
     150 Opening ASCII mode data connection for /bin/ls.
     ...
     226 Transfer complete.

   AIX behaves similarly (just goes right to PORT, and works fine).

   NetBSD (1.5E) looks like:

     ftp -i 205.188.247.193
     ...
     ftp> debug
     Debugging on (debug=1).
     ftp> dir
     ---> EPSV
     500 'EPSV': command not understood.
     disabling epsv4 for this connection
     ---> PASV
     at which point it just hangs until timing out.

 > 	the server (192.44.32.10) chokes with PASV, just like one of
 > 	ftp.netscape.com.  the issue is unrelated to the use of EPSV.

   Evidently that is correct, though with debugging off (the default),
 the only message given refers to EPSV.

 > 	I have tested with the following:
 > 	- NetBSD 1.4.2 ftp client (never issues EPSV)
 > 		PASV chokes, PORT is okay
 > 	- NetBSD 1.5_ALPHA2 ftp client (issues EPSV)
 > 		EPSV unsupported, PASV chokes, PORT is okay
 > 	- FreeBSD 2.2.8 ftp client (never issues EPSV)
 > 		PASV chokes, PORT is okay
 > 	NetBSD 1.4.2/1.5 client works better than FreeBSD 2.2.8, as
 > 	it implements fallback case from PASV to PORT.

   The NetBSD (1.5E as of Aug. 12) client does _not_ fall back from PASV to PORT
 with either 205.188.247.193 (ftp.netscape.com) or 192.44.32.10 (ftp.igd.fhg.de).

 --Jim

From: itojun@iijlab.net
To: Jim Bernard <jbernard@mines.edu>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Sun, 27 Aug 2000 13:00:09 +0900

 >> 	I have tested with the following:
 >> 	- NetBSD 1.4.2 ftp client (never issues EPSV)
 >> 		PASV chokes, PORT is okay
 >> 	- NetBSD 1.5_ALPHA2 ftp client (issues EPSV)
 >> 		EPSV unsupported, PASV chokes, PORT is okay
 >> 	- FreeBSD 2.2.8 ftp client (never issues EPSV)
 >> 		PASV chokes, PORT is okay
 >> 	NetBSD 1.4.2/1.5 client works better than FreeBSD 2.2.8, as
 >> 	it implements fallback case from PASV to PORT.
 >  The NetBSD (1.5E as of Aug. 12) client does _not_ fall back from PASV to PORT
 >with either 205.188.247.193 (ftp.netscape.com) or 192.44.32.10 (ftp.igd.fhg.de).

 	try waiting a little bit longer.

 itojun

From: itojun@iijlab.net
To: Jim Bernard <jbernard@mines.edu>, gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Sun, 27 Aug 2000 17:49:42 +0900

 >>  The NetBSD (1.5E as of Aug. 12) client does _not_ fall back from PASV to PORT
 >>with either 205.188.247.193 (ftp.netscape.com) or 192.44.32.10 (ftp.igd.fhg.de).
 >	try waiting a little bit longer.

 	"little bit longer" means 1 minute or more.  for me it successfully
 	fall back to PORT.  I admit this is rather slow, but as the peer has
 	broken PASV support, it is the best client can do (if we switch to
 	PORT too early, we will see wrong behavior).

 itojun


 itojun[turmeric:~/NetBSD.clean/pkgsrc/net/zebra] ftp 192.44.32.10
 Connected to 192.44.32.10.
 220 ProFTPD 1.2.0pre10 Server (ProFTPD Anonymous Server) [nikolausharnoncourt]
 Name (192.44.32.10:itojun): ftp
 331 Anonymous login ok, send your complete e-mail address as password.
 Password:
 230 Anonymous access granted, restrictions apply.
 Remote system type is UNIX.
 Using binary mode to transfer files.
 debugftp> debug
 Debugging on (debug=1).
 ftp> dir
 ---> EPSV
 500 EPSV not understood.
 disabling epsv4 for this connection
 ---> PASV
 227 Entering Passive Mode (192,44,32,10,234,127).
 ---> PORT 210,160,95,98,255,227			<--- wait 1 minute or more
 200 PORT command successful.
 ---> LIST
 150 Opening ASCII mode data connection for file list.
 lrwxrwxrwx   1 root     sys             7 Dec  2  1997 bin -> usr/bin
 dr-xr-xr-x   2 root     sys           512 Dec  2  1997 dev
 dr-xr-xr-x   3 root     sys           512 Dec  8  1997 etc
 drwxrwxrwx  19 root     sys          1024 Aug 27 03:15 incoming
 -rw-r--r--   1 root     sys         91517 Aug 27 03:30 ls-lR.gz
 drwxrwxrwx 113 root     sys          3584 Aug 24 16:00 outgoing
 drwxrwxr-x  10 root     290           512 Jan 18  1999 pub
 dr-xr-xr-x   5 root     sys           512 Dec  2  1997 usr
 226 Transfer complete.
 ftp> status
 Connected and logged into 192.44.32.10.
 No proxy connection.
 Gate ftp: off, server (none), port ftpgate.
 Passive mode: off; fallback to active mode: on.
 Mode: stream; Type: binary; Form: non-print; Structure: file.
 Verbose: on; Bell: off; Prompting: on; Globbing: on.
 Store unique: off; Receive unique: off.
 Preserve modification times: on.
 Case: off; CR stripping: on.
 Ntrans: off.
 Nmap: off.
 Hash mark printing: off; Mark count: 1024; Progress bar: on.
 Get transfer rate throttle: off; maximum: 0; increment 1024.
 Put transfer rate throttle: off; maximum: 0; increment 1024.
 Socket buffer sizes: send 16384, receive 16384.
 Use of PORT cmds: on.
 Use of EPSV/EPRT cmds for IPv4: on (disabled for this connection).
 Command line editing: on.
 Version: NetBSD-ftp 20000806
 ftp> ^D
 ---> QUIT
 un221 Goodbye.
 itojun[turmeric:~/NetBSD.clean/pkgsrc/net/zebra] uname -a
 NetBSD turmeric.itojun.org 1.5E NetBSD 1.5E (TURMERIC.v6) #5: Mon Aug 21 17:51:07 PDT 2000     itojun@turmeric.itojun.org:/usr/home/itojun/NetBSD/src/sys/arch/i386/compile/TURMERIC.v6 i386


From: Jim Bernard <jbernard@mines.edu>
To: itojun@iijlab.net
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Sun, 27 Aug 2000 06:52:16 -0600

 On Sun, Aug 27, 2000 at 01:00:09PM +0900, itojun@iijlab.net wrote:
 > 
 > >> 	I have tested with the following:
 > >> 	- NetBSD 1.4.2 ftp client (never issues EPSV)
 > >> 		PASV chokes, PORT is okay
 > >> 	- NetBSD 1.5_ALPHA2 ftp client (issues EPSV)
 > >> 		EPSV unsupported, PASV chokes, PORT is okay
 > >> 	- FreeBSD 2.2.8 ftp client (never issues EPSV)
 > >> 		PASV chokes, PORT is okay
 > >> 	NetBSD 1.4.2/1.5 client works better than FreeBSD 2.2.8, as
 > >> 	it implements fallback case from PASV to PORT.
 > >  The NetBSD (1.5E as of Aug. 12) client does _not_ fall back from PASV to PORT
 > >with either 205.188.247.193 (ftp.netscape.com) or 192.44.32.10 (ftp.igd.fhg.de).
 > 
 > 	try waiting a little bit longer.

   It always times out and disconnects on me if I wait long enough on the
 netscape site; I haven't waited that long at ftp.igd.fhg.de.

From: Jim Bernard <jbernard@mines.edu>
To: itojun@iijlab.net
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Sun, 27 Aug 2000 07:31:05 -0600

 On Sun, Aug 27, 2000 at 05:49:42PM +0900, itojun@iijlab.net wrote:
 > 
 > >>  The NetBSD (1.5E as of Aug. 12) client does _not_ fall back from PASV to PORT
 > >>with either 205.188.247.193 (ftp.netscape.com) or 192.44.32.10 (ftp.igd.fhg.de).
 > >	try waiting a little bit longer.
 > 
 > 	"little bit longer" means 1 minute or more.  for me it successfully
 > 	fall back to PORT.  I admit this is rather slow, but as the peer has
 > 	broken PASV support, it is the best client can do (if we switch to
 > 	PORT too early, we will see wrong behavior).
 > 
 > itojun

   Try it at the netscape site.  It always times out and disconnects on me.

   BTW: What do you mean by "if we switch to PORT too early, we will see
 wrong behavior".  Clearly, other clients (and NetBSD's with -A) just do
 PORT right away without any problem.  Or are you just saying that if the
 server really is going to respond to PASV and the client switches before
 the response, the connection will be messed up?

 > itojun[turmeric:~/NetBSD.clean/pkgsrc/net/zebra] ftp 192.44.32.10
 ...
 > ftp> dir
 > ---> EPSV
 > 500 EPSV not understood.
 > disabling epsv4 for this connection
 > ---> PASV
 > 227 Entering Passive Mode (192,44,32,10,234,127).
 > ---> PORT 210,160,95,98,255,227			<--- wait 1 minute or more

   It it NOT OK to have to wait this long for every data-returning command!

   In any case, a very important point is that users presented with an ftp client
 they have to wait on for a full minute or more to execute each data-returning
 command (_if_ it doesn't just disconnect), when the clients on other systems
 "just work", and do so promptly, are not going to conclude that the fault
 lies with the remote server.  The conclusion will inevitably be that NetBSD's
 ftp client is broken.  The fact that it may be more featureful and powerful
 in dealing with certain "problem" network setups won't matter one bit to the
 user faced with such difficulties in the simplest situations.

   It looks to me like it is just too soon to be _defaulting_ to the
 EPSV->PASV->PORT fallback scheme (unless there is a way to make it work
 better), given that there clearly are plenty of servers out there that don't
 work properly with it.  The fact that I came across two in a single day is
 sufficient to demonstrate that this is a serious problem.

 --Jim

From: itojun@iijlab.net
To: Jim Bernard <jbernard@mines.edu>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Mon, 28 Aug 2000 01:22:49 +0900

 >  Try it at the netscape site.  It always times out and disconnects on me.
 >
 >  BTW: What do you mean by "if we switch to PORT too early, we will see
 >wrong behavior".  Clearly, other clients (and NetBSD's with -A) just do
 >PORT right away without any problem.  Or are you just saying that if the
 >server really is going to respond to PASV and the client switches before
 >the response, the connection will be messed up?

 	the latter.

 >  It it NOT OK to have to wait this long for every data-returning command!
 >
 >  In any case, a very important point is that users presented with an ftp client
 >they have to wait on for a full minute or more to execute each data-returning
 >command (_if_ it doesn't just disconnect), when the clients on other systems
 >"just work", and do so promptly, are not going to conclude that the fault
 >lies with the remote server.  The conclusion will inevitably be that NetBSD's
 >ftp client is broken.  The fact that it may be more featureful and powerful
 >in dealing with certain "problem" network setups won't matter one bit to the
 >user faced with such difficulties in the simplest situations.
 >
 >  It looks to me like it is just too soon to be _defaulting_ to the
 >EPSV->PASV->PORT fallback scheme (unless there is a way to make it work
 >better), given that there clearly are plenty of servers out there that don't
 >work properly with it.  The fact that I came across two in a single day is
 >sufficient to demonstrate that this is a serious problem.

 	the behavior change (PORT -> PASV to PASV -> PORT) was made because,
 	it is increasingly becoming common to have NAT/firewall devices
 	that does not work with PORT, and work with PASV only.  it is
 	increasingly becoming common to try PASV first.  try ftp client on
 	OpenBSD and recent FreeBSD.  they both start with PASV and has the
 	same problem.

 	with broken (i'd say so) firewall device PORT does not work.
 	with broken server like ftp.netscape.com PASV does not work.  it is
 	the question of which one we should try first.  regardless from which
 	one we pick, we get problem report from the other party!

 	BTW, i am not the guy who made the change.  i just wanted to clarify
 	which part of ftp behavior was the source of your problem, since
 	the original report was not clear enough (and i think it was clarified
 	enough for me).  i should stop here.

 itojun

From: Jim Bernard <jbernard@mines.edu>
To: itojun@iijlab.net
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Sun, 27 Aug 2000 11:15:12 -0600

 On Mon, Aug 28, 2000 at 01:22:49AM +0900, itojun@iijlab.net wrote:
 > >  It looks to me like it is just too soon to be _defaulting_ to the
 > >EPSV->PASV->PORT fallback scheme (unless there is a way to make it work
 > >better), given that there clearly are plenty of servers out there that don't
 > >work properly with it.  The fact that I came across two in a single day is
 > >sufficient to demonstrate that this is a serious problem.
 > 
 > 	the behavior change (PORT -> PASV to PASV -> PORT) was made because,
 > 	it is increasingly becoming common to have NAT/firewall devices
 > 	that does not work with PORT, and work with PASV only.  it is
 > 	increasingly becoming common to try PASV first.  try ftp client on
 > 	OpenBSD and recent FreeBSD.  they both start with PASV and has the
 > 	same problem.
 > 
 > 	with broken (i'd say so) firewall device PORT does not work.
 > 	with broken server like ftp.netscape.com PASV does not work.  it is
 > 	the question of which one we should try first.  regardless from which
 > 	one we pick, we get problem report from the other party!

   Yes, I understand.  The important things to think about are:

     (1) Is there a way to improve robustness with _some_ chosen fallback
 	sequence so that nobody has to tolerate this kind of breakage?

     (2) If the answer to (1) is "no", is the current sequence the best
 	choice given the current mix of broken servers and firewall
 	configurations.  I'm guessing that it is not; certainly it's not
 	best for me, nor for the people around me.  It is perhaps worth
 	keeping in mind that users might have some influence over the local
 	firewall configuration (even if they don't have direct control over
 	it), but they have little influence over the behavior of remote
 	ftp servers.

     (3) If there is not a "good enough" solution, perhaps there should be some
 	simple way to tailor the default behavior for the local installation
 	(other than telling every user to always use -A or -p).  Perhaps
 	a system-wide configuration file would be appropriate.

 > 	BTW, i am not the guy who made the change.

   Yes, I know.  But I thought, from your interest, that maybe you were going
 to tackle the problem (or, I feared, dismiss it) anyway.

 > 	i just wanted to clarify
 > 	which part of ftp behavior was the source of your problem, since
 > 	the original report was not clear enough (and i think it was clarified
 > 	enough for me).  i should stop here.

   OK.  Thanks for the discussion and for pointing out that PASV was the
 real problem.  (I guess the PR has gotten rather long by now!)

 --Jim

From: itojun@iijlab.net
To: Jim Bernard <jbernard@mines.edu>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Mon, 28 Aug 2000 02:38:28 +0900

 >    (3) If there is not a "good enough" solution, perhaps there should be some
 >	simple way to tailor the default behavior for the local installation
 >	(other than telling every user to always use -A or -p).  Perhaps
 >	a system-wide configuration file would be appropriate.

 	how about $FTPMODE?

 itojun

From: Jim Bernard <jbernard@mines.edu>
To: itojun@iijlab.net
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10897: ftp doesn't play nice with some servers
Date: Sun, 27 Aug 2000 12:11:20 -0600

 On Mon, Aug 28, 2000 at 02:38:28AM +0900, itojun@iijlab.net wrote:
 > >    (3) If there is not a "good enough" solution, perhaps there should be some
 > >	simple way to tailor the default behavior for the local installation
 > >	(other than telling every user to always use -A or -p).  Perhaps
 > >	a system-wide configuration file would be appropriate.
 > 
 > 	how about $FTPMODE?

   Sure, that's better than -A/-p, but it still requires action on the part
 of every user (or a system administrator to impose environment variables on
 users, which is something I tend to dislike generally, since I often disagree
 with the choices made by other folks).  Since, every user on a particular
 machine sees the same local network environment, it seems to me that a
 configuration file is reasonable, though it does add a small startup penalty
 and adds to the noise in /etc.

   A configuration file also has the advantage that, if a default version is
 provided in the distribution, it will alert the system administrator to the
 issue, whereas depending on users to read the man page instead of giving up
 in frustration (or switching to Linux) will result in the feature not being
 discovered in many cases.  It also makes it easy to change the behavior in
 the event that a change in the local firewall configuration warrants it.
 It would also make it possible (in principle) to configure different defaults
 on different interfaces.

 --Jim
Responsible-Changed-From-To: bin-bug-people->lukem 
Responsible-Changed-By: lukem 
Responsible-Changed-When: Mon Aug 28 04:53:47 PDT 2000 
Responsible-Changed-Why:  
i'm mr ftp 
Responsible-Changed-From-To: lukem->bin-bug-people
Responsible-Changed-By: lukem@NetBSD.org
Responsible-Changed-When: Sat, 16 Jun 2012 07:19:24 +0000
Responsible-Changed-Why:
12 years later, I'm not going to change the behaviour


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.