On Mon, 5 Jun 2000, Rich Gray wrote:

> I've been doing some FTP put (upload) testing to a site running Sequent
> Unix (hmm, guess I'm going to have to compile curl on Sequent too!)

I'm quite impressed by the number of different unix systems you seem to have
at your place! ;-)

> If I use -P - to go to PORT mode:
>
> curl -v -u UserName:SECRET -P - -T somefile.Z ftp://x.y.zz.y/somefile.Z
>
> * Connected to x.y.zz.y (x.y.zz.y)
> < 220 somehost FTP server (Version 8.4.4 Tue Nov 10 03:29:05 GMT 1998)
> ready.
> > USER UserName
> < 331 Password required for UserName.
> > PASS SECRET
> < 230 User UserName logged in.
> * We have successfully logged in
> * We connect from ourhost
> > PORT w,x,y,z,19,61
> < 500 Illegal PORT range rejected.
> curl: (30) Server does not grok PORT, try without it!

I'll tell you what I find weirdest with this: the ftp server itself tells us
this is an "Illegal PORT range". 19*256+61 = 4925 and it is certainly an
acceptable port "range" in most normal systems. Now, why does the server say
that is a bad port number?

Did the server actually try that port number and got a connection refused?
500-errors are supposed to be "Syntax error, command unrecognized. This may
include errors such as command line too long."

> If I try it with the native NCR MP-RAS ftp client:

> ---> USER UserName
> ---> PASS XXXX
> ---> SYST
> ---> TYPE I

> ---> PORT w,x,y,z,19,127
> 200 PORT command successful.
> ---> STOR somefile.Z
> 150 Opening BINARY mode data connection for 'somefile.Z'.
> 226 Transfer complete.

The only difference I can see is that curl would do 'TYPE I' after the PORT
command.

> I also tried this on AIX 4.3 & SCO Openserver 5 systems and got the same
> results, so it does not seem to be a function of OS.

You mean ftp upload to those fellows failed as well?

Does ftp download work as it should?

> There is a joker here, we are behind a firewall and Network Address
> Translation (NAT) is being performed. I can't really see what the Sequent
> box does. We did switch our development host to a static NAT mapping and
> it did not seem to matter. This _could_ somehow be our firewall, but
> that is hard to believe given that the regular ftp clients work on
> multiple other unixes with PASS.

If you login to the box and run curl locally (which would then require that
port you mentioned), does it fail in the same way then?

Curl upload has worked without reports for quite a long time, why I believe
there must be something special here that cause this.

> 1. What the heck could be going on with the curl -P - PORT mode? How can
> transfers be succeeding with the native clients but not curl??? Looks
> like curl and natives are doing the same thing, but curl fails. I don't
> see any difference. If I alternatively try the curl & native clients, I
> just see port#'s increasing, but curl fails and native works. Very
> Strange...

You could edit the curl source to do the FTP commands in the exact same order
as the native clients. Maybe something in the server or firewall messes up
otherwise. Doesn't seem very likely though. :-/

> 2. Out of curiosity, why does curl default to PASV?? RFC 959 section
> 5.1. Minimum Implementation includes PORT but not PASV and it seems that
> the classic ftp clients on our various Unix boxes use PORT, so it would
> _seem_ prudent for curl to default thusly too. Is there some operational
> experience at work here?

Well, you could say that my own judgement took over. Originally, I
implemented PASV first since it is so much easier to do client-wise and when
I added PORT I added that as an option. I was at the time based behind a
firewall that simply denied most incoming TCP requests which made PORT
impossible to use. Also, with the development of recent years with NATs, IP
masquerading, multiple network interfaces and more it just seemed like the
least error-prone method (client-wise). I know RFC959 allows a server not to
implement PASV, but in real life very few servers neglect that. And if they
do, we can switch on -P.

> (I tried the new curl site search option [neat!]

Yeah, on popular request I finally took an hour to download, install,
configure and run htdig.

> Richard B. Gray, Sr. Software Egr.| Tel: 513-746-8118 ext. 2405
> Plus Technologies, a division of | 877-899-PLUS (7587)
> Digital Controls Corporation | Fax: 513/743-8575

-- 
      Daniel Stenberg - http://daniel.haxx.nu - +46-705-44 31 77
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol