> -----Original Message-----
> From: Daniel Stenberg [mailto:Daniel.Stenberg_at_haxx.nu]
> Sent: Tuesday, June 06, 2000 2:50 AM
> To: Curl Mailinglist
> Subject: Re: FTP put PASS/PASV problems
>
>
> 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! ;-)

Sequent is one we don't have at our place, so we have to FTP our stuff to
this site, compile and bring back the objects. When it came time to do
this, I thought I'd use curl to automate things... :-o Unfortunately, I
ran into this snag. (Or fortunately, depending on how you regard testing...
;p )

> > 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?

The weirdest thing is that the native ftp, _appearing_ to do the same thing
WORKS! Port # increases by a few each attempt with either client. I'm
going to have to figure out what the difference is! There must be
something....

> Did the server actually try that port number and got a
> connection refused?

I think I'd need a sniffer beyond the NAT to know that....

> 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?
>

No, curl failed to upload and the native ftp's succeded in the same manner
as on MP-RAS.

I just tried curl to this site on an MP-RAS system with no firewall and PASV
hung as before, but PASS (-P -) *WORKED*, late TYPE I and all. (port# was
3700) This points the finger at our firewall. But of course the nagging
question is why native ftp works and curl fails doing PASS?

> Does ftp download work as it should?

curl download with PASV fails as with upload:
...
* We have successfully logged in
> PASV
< 227 Entering Passive Mode (xxxxxx,5,195)
* Connecting to yyyyyyyyyyyy.com (xxxxxx) port 1475
curl: (16) Can't connect to ftp server

I have to wonder if the problem with PASV is a firewall at this remote site.

How does one tell a classical ftp client to use PASV? I should try that.
(I tried toggling "sendport", but all that seems to have done was to try the
transfer without doing PORT or PASV!)

And download with PORT:

* We have successfully logged in
* We connect from [here]
> PORT [hereip],10,79
< 500 Illegal PORT range rejected.
curl: (30) Server does not grok PORT, try without it!

So, pretty much the same problem as with upload.

> 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?
>

In theory, I have access to two of these Sequent boxes, so I will port curl
and see how they talk to each other. They appear to be co-located, so this
should bypass firewall issues. Guess this is what I will do next. (And see
if I can get my hands on a sniffer to see what the difference is between the
native client and curl doing PASS.)

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

Agreed. I noticed the lack of conversation on PORT & PASV when I searched.

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

Seemed to work from the non-firewalled NCR without having to do this, so
I'll have to think it is all the more unlikely, unless the firewall is
messing it up.

Rich
Received on 2000-06-06