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:
(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.