[OT] FTP client problems

[Greg Keogh]

Folks, I'm getting conflicting behaviour in FTP clients on our new server.
We installed an app in this new server and it died attempting to GET a file
from a remote FTP server.

So I ran ftp.exe from the command prompt to do the same thing as the app
does in code to see what happens (thinking that ftp.exe is a nice vanilla
test). It takes my user and password okay, but an 'ls' command says "501
Server cannot accept argument". I tried PASV mode and it does the same
thing.

Next test from Windows Explorer asks for my credentials and then lists the
FTP server's file okay.

So that's weird ... the app and ftp.exe fail, but Windows Explorer works.
Can anyone suggest why? Different authentication modes? This is a serious
problem that has stopped the rollout of the app.

Greg K

P.S. I know that FTP is ancient, but it's being used for historical
reasons. I've told the app's author to use HTTP instead and have supplied
some sample code.

RE: [OT] FTP client problems

[Jorke Odolphi]

Are you using ISA or some other firewall/proxy? That's generally what causes a 
501

Best bet is to wireshark the process and attach the cap - very hard to figure 
it out otherwise.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Thursday, 17 October 2013 9:28 AM
To: ozDotNet
Subject: [OT] FTP client problems

Folks, I'm getting conflicting behaviour in FTP clients on our new server. We 
installed an app in this new server and it died attempting to GET a file from a 
remote FTP server.

So I ran ftp.exe<ftp://ftp.exe> from the command prompt to do the same thing as 
the app does in code to see what happens (thinking that ftp.exe<ftp://ftp.exe> 
is a nice vanilla test). It takes my user and password okay, but an 'ls' 
command says "501 Server cannot accept argument". I tried PASV mode and it does 
the same thing.

Next test from Windows Explorer asks for my credentials and then lists the FTP 
server's file okay.

So that's weird ... the app and ftp.exe<ftp://ftp.exe> fail, but Windows 
Explorer works. Can anyone suggest why? Different authentication modes? This is 
a serious problem that has stopped the rollout of the app.

Greg K

P.S. I know that FTP is ancient, but it's being used for historical reasons. 
I've told the app's author to use HTTP instead and have supplied some sample 
code.

Re: [OT] FTP client problems

[Scott Barnes]

*blink blink* ... Jorke... says to wireshark the giglyhertz so the
megatwatts can access the mother fruggles... :)

:D

---
Regards,
Scott Barnes
http://www.riagenic.com


On Thu, Oct 17, 2013 at 8:44 AM, Jorke Odolphi  wrote:

>  Are you using ISA or some other firewall/proxy? That’s generally what
> causes a 501
>
> ** **
>
> Best bet is to wireshark the process and attach the cap – very hard to
> figure it out otherwise.
>
> ** **
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Greg Keogh
> *Sent:* Thursday, 17 October 2013 9:28 AM
> *To:* ozDotNet
> *Subject:* [OT] FTP client problems
>
> ** **
>
> Folks, I'm getting conflicting behaviour in FTP clients on our new server.
> We installed an app in this new server and it died attempting to GET a file
> from a remote FTP server.
>
>  
>
> So I ran ftp.exe from the command prompt to do the same thing as the app
> does in code to see what happens (thinking that ftp.exe is a nice vanilla
> test). It takes my user and password okay, but an 'ls' command says "501
> Server cannot accept argument". I tried PASV mode and it does the same
> thing.
>
>  
>
> Next test from Windows Explorer asks for my credentials and then lists the
> FTP server's file okay.
>
>  
>
> So that's weird ... the app and ftp.exe fail, but Windows Explorer works.
> Can anyone suggest why? Different authentication modes? This is a serious
> problem that has stopped the rollout of the app.
>
>  
>
> Greg K
>
>  
>
> P.S. I know that FTP is ancient, but it's being used for historical
> reasons. I've told the app's author to use HTTP instead and have supplied
> some sample code.
>

Re: [OT] FTP client problems

[David Connors]

Try again with FileZilla and set the FTP mode to Active and try again.

David.

David Connors
da...@connors.com | M +61 417 189 363
Download my v-card: https://www.codify.com/cards/davidconnors
Follow me on Twitter: https://www.twitter.com/davidconnors
Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors


On Thu, Oct 17, 2013 at 8:44 AM, Jorke Odolphi  wrote:

>  Are you using ISA or some other firewall/proxy? That’s generally what
> causes a 501
>
> ** **
>
> Best bet is to wireshark the process and attach the cap – very hard to
> figure it out otherwise.
>
> ** **
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Greg Keogh
> *Sent:* Thursday, 17 October 2013 9:28 AM
> *To:* ozDotNet
> *Subject:* [OT] FTP client problems
>
> ** **
>
> Folks, I'm getting conflicting behaviour in FTP clients on our new server.
> We installed an app in this new server and it died attempting to GET a file
> from a remote FTP server.
>
>  
>
> So I ran ftp.exe from the command prompt to do the same thing as the app
> does in code to see what happens (thinking that ftp.exe is a nice vanilla
> test). It takes my user and password okay, but an 'ls' command says "501
> Server cannot accept argument". I tried PASV mode and it does the same
> thing.
>
>  
>
> Next test from Windows Explorer asks for my credentials and then lists the
> FTP server's file okay.
>
>  
>
> So that's weird ... the app and ftp.exe fail, but Windows Explorer works.
> Can anyone suggest why? Different authentication modes? This is a serious
> problem that has stopped the rollout of the app.
>
>  
>
> Greg K
>
>  
>
> P.S. I know that FTP is ancient, but it's being used for historical
> reasons. I've told the app's author to use HTTP instead and have supplied
> some sample code.
>

Re: [OT] FTP client problems

[Greg Keogh]

Chaps, FileZilla or Wireshark! The former I haven't used and I won't learn
anything if works or nor, unless it has some tracing facility. The latter I
haven't used for more than a year and it's complicated and I'll have to
configure it and interpret the results. I guess it's Wireshark then.

Greg K

Scott, I'm sending a prescription repeat to help your condition.


On 17 October 2013 11:25, David Connors  wrote:

> Try again with FileZilla and set the FTP mode to Active and try again.
>
> David.
>
> David Connors
> da...@connors.com | M +61 417 189 363
> Download my v-card: https://www.codify.com/cards/davidconnors
> Follow me on Twitter: https://www.twitter.com/davidconnors
> Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors
>
>
> On Thu, Oct 17, 2013 at 8:44 AM, Jorke Odolphi  wrote:
>
>>  Are you using ISA or some other firewall/proxy? That’s generally what
>> causes a 501
>>
>> ** **
>>
>> Best bet is to wireshark the process and attach the cap – very hard to
>> figure it out otherwise.
>>
>> ** **
>>
>> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
>> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Greg Keogh
>> *Sent:* Thursday, 17 October 2013 9:28 AM
>> *To:* ozDotNet
>> *Subject:* [OT] FTP client problems
>>
>> ** **
>>
>> Folks, I'm getting conflicting behaviour in FTP clients on our new
>> server. We installed an app in this new server and it died attempting to
>> GET a file from a remote FTP server.
>>
>>  
>>
>> So I ran ftp.exe from the command prompt to do the same thing as the app
>> does in code to see what happens (thinking that ftp.exe is a nice
>> vanilla test). It takes my user and password okay, but an 'ls' command says
>> "501 Server cannot accept argument". I tried PASV mode and it does the same
>> thing.
>>
>>  
>>
>> Next test from Windows Explorer asks for my credentials and then lists
>> the FTP server's file okay.
>>
>>  
>>
>> So that's weird ... the app and ftp.exe fail, but Windows Explorer
>> works. Can anyone suggest why? Different authentication modes? This is a
>> serious problem that has stopped the rollout of the app.
>>
>>  
>>
>> Greg K
>>
>>  
>>
>> P.S. I know that FTP is ancient, but it's being used for historical
>> reasons. I've told the app's author to use HTTP instead and have supplied
>> some sample code.
>>
>
>

RE: [OT] FTP client problems

[Jorke Odolphi]

http://i.imgur.com/5sRt9Hh.gif


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Thursday, 17 October 2013 2:47 PM
To: ozDotNet
Subject: Re: [OT] FTP client problems

Chaps, FileZilla or Wireshark! The former I haven't used and I won't learn 
anything if works or nor, unless it has some tracing facility. The latter I 
haven't used for more than a year and it's complicated and I'll have to 
configure it and interpret the results. I guess it's Wireshark then.

Greg K

Scott, I'm sending a prescription repeat to help your condition.

On 17 October 2013 11:25, David Connors 
mailto:da...@connors.com>> wrote:
Try again with FileZilla and set the FTP mode to Active and try again.

David.


David Connors
da...@connors.com<mailto:da...@connors.com> | M +61 417 189 363
Download my v-card: https://www.codify.com/cards/davidconnors
Follow me on Twitter: https://www.twitter.com/davidconnors
Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors

On Thu, Oct 17, 2013 at 8:44 AM, Jorke Odolphi 
mailto:jo...@jorke.net>> wrote:
Are you using ISA or some other firewall/proxy? That's generally what causes a 
501

Best bet is to wireshark the process and attach the cap - very hard to figure 
it out otherwise.

From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Greg Keogh
Sent: Thursday, 17 October 2013 9:28 AM
To: ozDotNet
Subject: [OT] FTP client problems

Folks, I'm getting conflicting behaviour in FTP clients on our new server. We 
installed an app in this new server and it died attempting to GET a file from a 
remote FTP server.

So I ran ftp.exe<ftp://ftp.exe> from the command prompt to do the same thing as 
the app does in code to see what happens (thinking that ftp.exe<ftp://ftp.exe> 
is a nice vanilla test). It takes my user and password okay, but an 'ls' 
command says "501 Server cannot accept argument". I tried PASV mode and it does 
the same thing.

Next test from Windows Explorer asks for my credentials and then lists the FTP 
server's file okay.

So that's weird ... the app and ftp.exe<ftp://ftp.exe> fail, but Windows 
Explorer works. Can anyone suggest why? Different authentication modes? This is 
a serious problem that has stopped the rollout of the app.

Greg K

P.S. I know that FTP is ancient, but it's being used for historical reasons. 
I've told the app's author to use HTTP instead and have supplied some sample 
code.

Re: [OT] FTP client problems

[David Connors]

On Thu, Oct 17, 2013 at 1:47 PM, Greg Keogh  wrote:

> Chaps, FileZilla or Wireshark! The former I haven't used and I won't learn
> anything if works or nor, unless it has some tracing facility.
>

You will learn exactly what the problem is.

If it works with FileZilla using passive FTP then the problem is your
firewall. Windows command-line FTP is active by default.

With active FTP the server opens the data connection to you which is
blocked unless you have a firewall that does stateful inspection.

WIth passive FTP the client opens the data connection and that will work by
default in most NAT/firewalls even without stateful inspection.

David.

Re: [OT] FTP client problems

[Greg Keogh]

I haven't tried FileZilla yet, but in Wireshark I have a trace of FTP
failing from the command prompt and a trace working from Windows Explorer.
As I expected, the results are so different that I can't compare them. The
Windows Explorer trace is much longer and contains dozens of lines that are
gibberish to me as I'm not a networking guy.

So I now have traces of one working and one failing, but I'm unable to
interpret or compare the results and I've learned nothing.

Greg K


On 17 October 2013 15:01, David Connors  wrote:

> On Thu, Oct 17, 2013 at 1:47 PM, Greg Keogh  wrote:
>
>> Chaps, FileZilla or Wireshark! The former I haven't used and I won't
>> learn anything if works or nor, unless it has some tracing facility.
>>
>
> You will learn exactly what the problem is.
>
> If it works with FileZilla using passive FTP then the problem is your
> firewall. Windows command-line FTP is active by default.
>
> With active FTP the server opens the data connection to you which is
> blocked unless you have a firewall that does stateful inspection.
>
> WIth passive FTP the client opens the data connection and that will work
> by default in most NAT/firewalls even without stateful inspection.
>
> David.
>

Re: [OT] FTP client problems

[David Connors]

Windows explorer uses pasv, command line does not.
On 17/10/2013 3:10 PM, "Greg Keogh"  wrote:

> I haven't tried FileZilla yet, but in Wireshark I have a trace of FTP
> failing from the command prompt and a trace working from Windows Explorer.
> As I expected, the results are so different that I can't compare them. The
> Windows Explorer trace is much longer and contains dozens of lines that are
> gibberish to me as I'm not a networking guy.
>
> So I now have traces of one working and one failing, but I'm unable to
> interpret or compare the results and I've learned nothing.
>
> Greg K
>
>
> On 17 October 2013 15:01, David Connors  wrote:
>
>> On Thu, Oct 17, 2013 at 1:47 PM, Greg Keogh  wrote:
>>
>>> Chaps, FileZilla or Wireshark! The former I haven't used and I won't
>>> learn anything if works or nor, unless it has some tracing facility.
>>>
>>
>> You will learn exactly what the problem is.
>>
>> If it works with FileZilla using passive FTP then the problem is your
>> firewall. Windows command-line FTP is active by default.
>>
>> With active FTP the server opens the data connection to you which is
>> blocked unless you have a firewall that does stateful inspection.
>>
>> WIth passive FTP the client opens the data connection and that will work
>> by default in most NAT/firewalls even without stateful inspection.
>>
>> David.
>>
>
>

RE: [OT] FTP client problems

[Ken Schaefer]

Did you miss this step from Jorke's post?

...and attach the cap

Cheers
Ken

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Thursday, 17 October 2013 4:11 PM
To: ozDotNet
Subject: Re: [OT] FTP client problems

I haven't tried FileZilla yet, but in Wireshark I have a trace of FTP failing 
from the command prompt and a trace working from Windows Explorer. As I 
expected, the results are so different that I can't compare them. The Windows 
Explorer trace is much longer and contains dozens of lines that are gibberish 
to me as I'm not a networking guy.

So I now have traces of one working and one failing, but I'm unable to 
interpret or compare the results and I've learned nothing.

Greg K

On 17 October 2013 15:01, David Connors 
mailto:da...@connors.com>> wrote:
On Thu, Oct 17, 2013 at 1:47 PM, Greg Keogh 
mailto:g...@mira.net>> wrote:
Chaps, FileZilla or Wireshark! The former I haven't used and I won't learn 
anything if works or nor, unless it has some tracing facility.

You will learn exactly what the problem is.

If it works with FileZilla using passive FTP then the problem is your firewall. 
Windows command-line FTP is active by default.

With active FTP the server opens the data connection to you which is blocked 
unless you have a firewall that does stateful inspection.

WIth passive FTP the client opens the data connection and that will work by 
default in most NAT/firewalls even without stateful inspection.

David.

Re: [OT] FTP client problems

[Greg Keogh]

>
> Did you miss this step from Jorke’s post?
>

Yeah, look, it's not Friday and I'm up shit creek -- Greg

Re: [OT] FTP client problems

[Joseph Cooney]

Re: prescription - it isn't polite to make fun of people with mental
illnesses.

http://www.riagenic.com/archives/934

Joseph
On 17 Oct 2013 13:47, "Greg Keogh"  wrote:

> Chaps, FileZilla or Wireshark! The former I haven't used and I won't learn
> anything if works or nor, unless it has some tracing facility. The latter I
> haven't used for more than a year and it's complicated and I'll have to
> configure it and interpret the results. I guess it's Wireshark then.
>
> Greg K
>
> Scott, I'm sending a prescription repeat to help your condition.
>
>
> On 17 October 2013 11:25, David Connors  wrote:
>
>> Try again with FileZilla and set the FTP mode to Active and try again.
>>
>> David.
>>
>> David Connors
>> da...@connors.com | M +61 417 189 363
>> Download my v-card: https://www.codify.com/cards/davidconnors
>> Follow me on Twitter: https://www.twitter.com/davidconnors
>> Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors
>>
>>
>> On Thu, Oct 17, 2013 at 8:44 AM, Jorke Odolphi  wrote:
>>
>>>  Are you using ISA or some other firewall/proxy? That’s generally what
>>> causes a 501
>>>
>>> ** **
>>>
>>> Best bet is to wireshark the process and attach the cap – very hard to
>>> figure it out otherwise.****
>>>
>>> ** **
>>>
>>> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
>>> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Greg Keogh
>>> *Sent:* Thursday, 17 October 2013 9:28 AM
>>> *To:* ozDotNet
>>> *Subject:* [OT] FTP client problems
>>>
>>> ** **
>>>
>>> Folks, I'm getting conflicting behaviour in FTP clients on our new
>>> server. We installed an app in this new server and it died attempting to
>>> GET a file from a remote FTP server.
>>>
>>>  
>>>
>>> So I ran ftp.exe from the command prompt to do the same thing as the
>>> app does in code to see what happens (thinking that ftp.exe is a nice
>>> vanilla test). It takes my user and password okay, but an 'ls' command says
>>> "501 Server cannot accept argument". I tried PASV mode and it does the same
>>> thing.
>>>
>>>  
>>>
>>> Next test from Windows Explorer asks for my credentials and then lists
>>> the FTP server's file okay.
>>>
>>>  
>>>
>>> So that's weird ... the app and ftp.exe fail, but Windows Explorer
>>> works. Can anyone suggest why? Different authentication modes? This is a
>>> serious problem that has stopped the rollout of the app.
>>>
>>>  
>>>
>>> Greg K
>>>
>>>  
>>>
>>> P.S. I know that FTP is ancient, but it's being used for historical
>>> reasons. I've told the app's author to use HTTP instead and have supplied
>>> some sample code.
>>>
>>
>>
>

Re: [OT] FTP client problems

[Greg Keogh]

David, FileZilla works perfectly by default and lists the files and I can
see the following in the trace (pasted below). What it's doing seems to
make sense, but if I try similar requests from the command prompt
(including the PASV) I still get "501 Server cannot accept argument" when I
attempt to list or get files.

So although I can now see Windows Explorer and FileZilla all listing files
on the FTP server, I can't do the same from the command prompt. The point
of all this simulation from the command prompt is that if I get it working
I can then tell the C++ programmer exactly what steps I performed in the
hope he can do the same from his code and overcome our problem.

Greg K

=
Status: Resolving address of ftp.###.com
Status: Connecting to ###.50.142.77:21...
Status: Connection established, waiting for welcome message...
Response: 220 Microsoft FTP Service
Command: USER ##
Response: 331 Password required for ##.
Command: PASS 
Response: 230-Welcome to the ###.com FTP service on the dedicated #
server.
Response: 230 User logged in.
Command: SYST
Response: 215 Windows_NT
Command: FEAT
Response: 211-Extended features supported:
Response:  LANG EN*
Response:  UTF8
Response:  AUTH TLS;TLS-C;SSL;TLS-P;
Response:  PBSZ
Response:  PROT C;P;
Response:  CCC
Response:  HOST
Response:  SIZE
Response:  MDTM
Response:  REST STREAM
Response: 211 END
Command: OPTS UTF8 ON
Response: 200 OPTS UTF8 command successful - UTF8 encoding now ON.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is current directory.
Command: TYPE I
Response: 200 Type set to I.
Command: PASV
Response: 227 Entering Passive Mode (###,50,142,77,203,156).
Command: LIST
Response: 150 Opening BINARY mode data connection.
Response: 226 Transfer complete.
Status: Calculating timezone offset of server...
Command: MDTM 23456781.rlf
Response: 213 20111220002502
Status: Timezone offsets: Server: -25200 seconds. Local: 0 seconds.
Difference: 25200 seconds.
Status: Directory listing successful


On 17 October 2013 15:01, David Connors  wrote:

> On Thu, Oct 17, 2013 at 1:47 PM, Greg Keogh  wrote:
>
>> Chaps, FileZilla or Wireshark! The former I haven't used and I won't
>> learn anything if works or nor, unless it has some tracing facility.
>>
>
> You will learn exactly what the problem is.
>
> If it works with FileZilla using passive FTP then the problem is your
> firewall. Windows command-line FTP is active by default.
>
> With active FTP the server opens the data connection to you which is
> blocked unless you have a firewall that does stateful inspection.
>
> WIth passive FTP the client opens the data connection and that will work
> by default in most NAT/firewalls even without stateful inspection.
>
> David.
>

Re: [OT] FTP client problems

[David Richards]

David,

I know this might be a bit vague but I seem to recall discovering the ftp
client you use at the command prompt doesn't do something it should.  eg
perhaps it doesn't support PASV or something like that.  I know we can't
connect to our ftp server from it and have to use windows explorer or
pretty much any other client.  I think the problem is you're trying to use
an inferior client that doesn't work properly.

Most of the problems I've had have been around the active ports.  Are you
using an unusual active port range? Maybe ftp.exe isn't negotiating the
active port correctly?

David

"If we can hit that bullseye, the rest of the dominoes
 will fall like a house of cards... checkmate!"
 -Zapp Brannigan, Futurama


On 17 October 2013 16:51, Greg Keogh  wrote:

> David, FileZilla works perfectly by default and lists the files and I can
> see the following in the trace (pasted below). What it's doing seems to
> make sense, but if I try similar requests from the command prompt
> (including the PASV) I still get "501 Server cannot accept argument" when I
> attempt to list or get files.
>
> So although I can now see Windows Explorer and FileZilla all listing files
> on the FTP server, I can't do the same from the command prompt. The point
> of all this simulation from the command prompt is that if I get it working
> I can then tell the C++ programmer exactly what steps I performed in the
> hope he can do the same from his code and overcome our problem.
>
> Greg K
>
> =
> Status: Resolving address of ftp.###.com
> Status: Connecting to ###.50.142.77:21...
> Status: Connection established, waiting for welcome message...
> Response: 220 Microsoft FTP Service
> Command: USER ##
> Response: 331 Password required for ##.
> Command: PASS 
> Response: 230-Welcome to the ###.com FTP service on the dedicated
> # server.
> Response: 230 User logged in.
> Command: SYST
> Response: 215 Windows_NT
> Command: FEAT
> Response: 211-Extended features supported:
> Response:  LANG EN*
> Response:  UTF8
> Response:  AUTH TLS;TLS-C;SSL;TLS-P;
> Response:  PBSZ
> Response:  PROT C;P;
> Response:  CCC
> Response:  HOST
> Response:  SIZE
> Response:  MDTM
> Response:  REST STREAM
> Response: 211 END
> Command: OPTS UTF8 ON
> Response: 200 OPTS UTF8 command successful - UTF8 encoding now ON.
> Status: Connected
> Status: Retrieving directory listing...
> Command: PWD
> Response: 257 "/" is current directory.
> Command: TYPE I
> Response: 200 Type set to I.
> Command: PASV
> Response: 227 Entering Passive Mode (###,50,142,77,203,156).
> Command: LIST
> Response: 150 Opening BINARY mode data connection.
> Response: 226 Transfer complete.
> Status: Calculating timezone offset of server...
> Command: MDTM 23456781.rlf
> Response: 213 20111220002502
> Status: Timezone offsets: Server: -25200 seconds. Local: 0 seconds.
> Difference: 25200 seconds.
> Status: Directory listing successful
>
>
> On 17 October 2013 15:01, David Connors  wrote:
>
>> On Thu, Oct 17, 2013 at 1:47 PM, Greg Keogh  wrote:
>>
>>> Chaps, FileZilla or Wireshark! The former I haven't used and I won't
>>> learn anything if works or nor, unless it has some tracing facility.
>>>
>>
>> You will learn exactly what the problem is.
>>
>> If it works with FileZilla using passive FTP then the problem is your
>> firewall. Windows command-line FTP is active by default.
>>
>> With active FTP the server opens the data connection to you which is
>> blocked unless you have a firewall that does stateful inspection.
>>
>> WIth passive FTP the client opens the data connection and that will work
>> by default in most NAT/firewalls even without stateful inspection.
>>
>> David.
>>
>
>

RE: [OT] FTP client problems

[Jorke Odolphi]

Bottom line, as David said - you're out of luck if you want a passive transfer 
from ftp.exe<ftp://ftp.exe>

you can type 'pasv', 'quote pasv' as much as you want but 
ftp.exe<ftp://ftp.exe> will just set it back to active - I think it's a port 
command or similar - if you want to verify this just type 'debug' and you'll 
see what is sent to the server.

IE works because it uses passive - but you can turn that off and verify active 
is broken under the "advanced options"




From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Thursday, 17 October 2013 4:52 PM
To: ozDotNet
Subject: Re: [OT] FTP client problems

David, FileZilla works perfectly by default and lists the files and I can see 
the following in the trace (pasted below). What it's doing seems to make sense, 
but if I try similar requests from the command prompt (including the PASV) I 
still get "501 Server cannot accept argument" when I attempt to list or get 
files.

So although I can now see Windows Explorer and FileZilla all listing files on 
the FTP server, I can't do the same from the command prompt. The point of all 
this simulation from the command prompt is that if I get it working I can then 
tell the C++ programmer exactly what steps I performed in the hope he can do 
the same from his code and overcome our problem.

Greg K

=
Status: Resolving address of ftp.###.com<ftp://ftp.###.com>
Status: Connecting to ###.50.142.77:21...
Status: Connection established, waiting for welcome message...
Response: 220 Microsoft FTP Service
Command: USER ##
Response: 331 Password required for ##.
Command: PASS 
Response: 230-Welcome to the ###.com FTP service on the dedicated # 
server.
Response: 230 User logged in.
Command: SYST
Response: 215 Windows_NT
Command: FEAT
Response: 211-Extended features supported:
Response:  LANG EN*
Response:  UTF8
Response:  AUTH TLS;TLS-C;SSL;TLS-P;
Response:  PBSZ
Response:  PROT C;P;
Response:  CCC
Response:  HOST
Response:  SIZE
Response:  MDTM
Response:  REST STREAM
Response: 211 END
Command: OPTS UTF8 ON
Response: 200 OPTS UTF8 command successful - UTF8 encoding now ON.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is current directory.
Command: TYPE I
Response: 200 Type set to I.
Command: PASV
Response: 227 Entering Passive Mode (###,50,142,77,203,156).
Command: LIST
Response: 150 Opening BINARY mode data connection.
Response: 226 Transfer complete.
Status: Calculating timezone offset of server...
Command: MDTM 23456781.rlf
Response: 213 20111220002502
Status: Timezone offsets: Server: -25200 seconds. Local: 0 seconds. Difference: 
25200 seconds.
Status: Directory listing successful

On 17 October 2013 15:01, David Connors 
mailto:da...@connors.com>> wrote:
On Thu, Oct 17, 2013 at 1:47 PM, Greg Keogh 
mailto:g...@mira.net>> wrote:
Chaps, FileZilla or Wireshark! The former I haven't used and I won't learn 
anything if works or nor, unless it has some tracing facility.

You will learn exactly what the problem is.

If it works with FileZilla using passive FTP then the problem is your firewall. 
Windows command-line FTP is active by default.

With active FTP the server opens the data connection to you which is blocked 
unless you have a firewall that does stateful inspection.

WIth passive FTP the client opens the data connection and that will work by 
default in most NAT/firewalls even without stateful inspection.

David.

Re: [OT] FTP client problems

[Greg Keogh]

>
> Re: prescription - it isn't polite to make fun of people with mental
> illnesses. http://www.riagenic.com/archives/934
>
Good lord, what little chance would I ever have of seeing that post or
knowing such a thing?! It was a surprising coincidence (apologies to Scott
just in case) -- Greg

Re: [OT] FTP client problems

[David Connors]

Command prompt ftp doesn't do pasv. You need to use client that does or get
a stateful firewall or use a proxy
On 17/10/2013 3:51 PM, "Greg Keogh"  wrote:

> David, FileZilla works perfectly by default and lists the files and I can
> see the following in the trace (pasted below). What it's doing seems to
> make sense, but if I try similar requests from the command prompt
> (including the PASV) I still get "501 Server cannot accept argument" when I
> attempt to list or get files.
>
> So although I can now see Windows Explorer and FileZilla all listing files
> on the FTP server, I can't do the same from the command prompt. The point
> of all this simulation from the command prompt is that if I get it working
> I can then tell the C++ programmer exactly what steps I performed in the
> hope he can do the same from his code and overcome our problem.
>
> Greg K
>
> =
> Status: Resolving address of ftp.###.com
> Status: Connecting to ###.50.142.77:21...
> Status: Connection established, waiting for welcome message...
> Response: 220 Microsoft FTP Service
> Command: USER ##
> Response: 331 Password required for ##.
> Command: PASS 
> Response: 230-Welcome to the ###.com FTP service on the dedicated
> # server.
> Response: 230 User logged in.
> Command: SYST
> Response: 215 Windows_NT
> Command: FEAT
> Response: 211-Extended features supported:
> Response:  LANG EN*
> Response:  UTF8
> Response:  AUTH TLS;TLS-C;SSL;TLS-P;
> Response:  PBSZ
> Response:  PROT C;P;
> Response:  CCC
> Response:  HOST
> Response:  SIZE
> Response:  MDTM
> Response:  REST STREAM
> Response: 211 END
> Command: OPTS UTF8 ON
> Response: 200 OPTS UTF8 command successful - UTF8 encoding now ON.
> Status: Connected
> Status: Retrieving directory listing...
> Command: PWD
> Response: 257 "/" is current directory.
> Command: TYPE I
> Response: 200 Type set to I.
> Command: PASV
> Response: 227 Entering Passive Mode (###,50,142,77,203,156).
> Command: LIST
> Response: 150 Opening BINARY mode data connection.
> Response: 226 Transfer complete.
> Status: Calculating timezone offset of server...
> Command: MDTM 23456781.rlf
> Response: 213 20111220002502
> Status: Timezone offsets: Server: -25200 seconds. Local: 0 seconds.
> Difference: 25200 seconds.
> Status: Directory listing successful
>
>
> On 17 October 2013 15:01, David Connors  wrote:
>
>> On Thu, Oct 17, 2013 at 1:47 PM, Greg Keogh  wrote:
>>
>>> Chaps, FileZilla or Wireshark! The former I haven't used and I won't
>>> learn anything if works or nor, unless it has some tracing facility.
>>>
>>
>> You will learn exactly what the problem is.
>>
>> If it works with FileZilla using passive FTP then the problem is your
>> firewall. Windows command-line FTP is active by default.
>>
>> With active FTP the server opens the data connection to you which is
>> blocked unless you have a firewall that does stateful inspection.
>>
>> WIth passive FTP the client opens the data connection and that will work
>> by default in most NAT/firewalls even without stateful inspection.
>>
>> David.
>>
>
>

Re: [OT] FTP client problems

[Greg Keogh]

OK chaps, your combined comments are great clues. If vanilla old ftp.exe is
an inferior client that misbehaves and doesn't do PASV correctly, then it
would explain my frustration and lack of progress. I was betting on the
wrong horse all along.

I'm going to knock-up a little C# client that uses WebClient and PASV mode
and see if I can get files. If this works then I can curse ftp.exe to Hades
and pass my code to the C++ guy to follow the same pattern.

I'll let you know fi I learn anything useful.

Greg K


On 17 October 2013 17:12, David Connors  wrote:

> Command prompt ftp doesn't do pasv. You need to use client that does or
> get a stateful firewall or use a proxy
> On 17/10/2013 3:51 PM, "Greg Keogh"  wrote:
>
>> David, FileZilla works perfectly by default and lists the files and I can
>> see the following in the trace (pasted below). What it's doing seems to
>> make sense, but if I try similar requests from the command prompt
>> (including the PASV) I still get "501 Server cannot accept argument" when I
>> attempt to list or get files.
>>
>> So although I can now see Windows Explorer and FileZilla all listing
>> files on the FTP server, I can't do the same from the command prompt. The
>> point of all this simulation from the command prompt is that if I get it
>> working I can then tell the C++ programmer exactly what steps I performed
>> in the hope he can do the same from his code and overcome our problem.
>>
>> Greg K
>>
>> =
>> Status: Resolving address of ftp.###.com
>> Status: Connecting to ###.50.142.77:21...
>> Status: Connection established, waiting for welcome message...
>> Response: 220 Microsoft FTP Service
>> Command: USER ##
>> Response: 331 Password required for ##.
>> Command: PASS 
>> Response: 230-Welcome to the ###.com FTP service on the dedicated
>> # server.
>> Response: 230 User logged in.
>> Command: SYST
>> Response: 215 Windows_NT
>> Command: FEAT
>> Response: 211-Extended features supported:
>> Response:  LANG EN*
>> Response:  UTF8
>> Response:  AUTH TLS;TLS-C;SSL;TLS-P;
>> Response:  PBSZ
>> Response:  PROT C;P;
>> Response:  CCC
>> Response:  HOST
>> Response:  SIZE
>> Response:  MDTM
>> Response:  REST STREAM
>> Response: 211 END
>> Command: OPTS UTF8 ON
>> Response: 200 OPTS UTF8 command successful - UTF8 encoding now ON.
>> Status: Connected
>> Status: Retrieving directory listing...
>> Command: PWD
>> Response: 257 "/" is current directory.
>> Command: TYPE I
>> Response: 200 Type set to I.
>> Command: PASV
>> Response: 227 Entering Passive Mode (###,50,142,77,203,156).
>> Command: LIST
>> Response: 150 Opening BINARY mode data connection.
>> Response: 226 Transfer complete.
>> Status: Calculating timezone offset of server...
>> Command: MDTM 23456781.rlf
>> Response: 213 20111220002502
>> Status: Timezone offsets: Server: -25200 seconds. Local: 0 seconds.
>> Difference: 25200 seconds.
>> Status: Directory listing successful
>>
>>
>> On 17 October 2013 15:01, David Connors  wrote:
>>
>>> On Thu, Oct 17, 2013 at 1:47 PM, Greg Keogh  wrote:
>>>
 Chaps, FileZilla or Wireshark! The former I haven't used and I won't
 learn anything if works or nor, unless it has some tracing facility.

>>>
>>> You will learn exactly what the problem is.
>>>
>>> If it works with FileZilla using passive FTP then the problem is your
>>> firewall. Windows command-line FTP is active by default.
>>>
>>> With active FTP the server opens the data connection to you which is
>>> blocked unless you have a firewall that does stateful inspection.
>>>
>>> WIth passive FTP the client opens the data connection and that will work
>>> by default in most NAT/firewalls even without stateful inspection.
>>>
>>> David.
>>>
>>
>>

Re: [OT] FTP client problems

[David Connors]

ftp.exe doesn't do PASV incorrectly. It doesn't do it at all.

What sort of firewall is the app behind? e.g. if you can ask your network
people to turn on stateful inspection and the firewall supports active ftp
then you don't need to change the app.

David Connors
da...@connors.com | M +61 417 189 363
Download my v-card: https://www.codify.com/cards/davidconnors
Follow me on Twitter: https://www.twitter.com/davidconnors
Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors


On Thu, Oct 17, 2013 at 4:28 PM, Greg Keogh  wrote:

> OK chaps, your combined comments are great clues. If vanilla old ftp.exe
> is an inferior client that misbehaves and doesn't do PASV correctly, then
> it would explain my frustration and lack of progress. I was betting on the
> wrong horse all along.
>
> I'm going to knock-up a little C# client that uses WebClient and PASV mode
> and see if I can get files. If this works then I can curse ftp.exe to Hades
> and pass my code to the C++ guy to follow the same pattern.
>
> I'll let you know fi I learn anything useful.
>
> Greg K
>
>
> On 17 October 2013 17:12, David Connors  wrote:
>
>> Command prompt ftp doesn't do pasv. You need to use client that does or
>> get a stateful firewall or use a proxy
>> On 17/10/2013 3:51 PM, "Greg Keogh"  wrote:
>>
>>> David, FileZilla works perfectly by default and lists the files and I
>>> can see the following in the trace (pasted below). What it's doing seems to
>>> make sense, but if I try similar requests from the command prompt
>>> (including the PASV) I still get "501 Server cannot accept argument" when I
>>> attempt to list or get files.
>>>
>>> So although I can now see Windows Explorer and FileZilla all listing
>>> files on the FTP server, I can't do the same from the command prompt. The
>>> point of all this simulation from the command prompt is that if I get it
>>> working I can then tell the C++ programmer exactly what steps I performed
>>> in the hope he can do the same from his code and overcome our problem.
>>>
>>> Greg K
>>>
>>> =
>>> Status: Resolving address of ftp.###.com
>>> Status: Connecting to ###.50.142.77:21...
>>> Status: Connection established, waiting for welcome message...
>>> Response: 220 Microsoft FTP Service
>>> Command: USER ##
>>> Response: 331 Password required for ##.
>>> Command: PASS 
>>> Response: 230-Welcome to the ###.com FTP service on the dedicated
>>> # server.
>>> Response: 230 User logged in.
>>> Command: SYST
>>> Response: 215 Windows_NT
>>> Command: FEAT
>>> Response: 211-Extended features supported:
>>> Response:  LANG EN*
>>> Response:  UTF8
>>> Response:  AUTH TLS;TLS-C;SSL;TLS-P;
>>> Response:  PBSZ
>>> Response:  PROT C;P;
>>> Response:  CCC
>>> Response:  HOST
>>> Response:  SIZE
>>> Response:  MDTM
>>> Response:  REST STREAM
>>> Response: 211 END
>>> Command: OPTS UTF8 ON
>>> Response: 200 OPTS UTF8 command successful - UTF8 encoding now ON.
>>> Status: Connected
>>> Status: Retrieving directory listing...
>>> Command: PWD
>>> Response: 257 "/" is current directory.
>>> Command: TYPE I
>>> Response: 200 Type set to I.
>>> Command: PASV
>>> Response: 227 Entering Passive Mode (###,50,142,77,203,156).
>>> Command: LIST
>>> Response: 150 Opening BINARY mode data connection.
>>> Response: 226 Transfer complete.
>>> Status: Calculating timezone offset of server...
>>> Command: MDTM 23456781.rlf
>>> Response: 213 20111220002502
>>> Status: Timezone offsets: Server: -25200 seconds. Local: 0 seconds.
>>> Difference: 25200 seconds.
>>> Status: Directory listing successful
>>>
>>>
>>> On 17 October 2013 15:01, David Connors  wrote:
>>>
 On Thu, Oct 17, 2013 at 1:47 PM, Greg Keogh  wrote:

> Chaps, FileZilla or Wireshark! The former I haven't used and I won't
> learn anything if works or nor, unless it has some tracing facility.
>

 You will learn exactly what the problem is.

 If it works with FileZilla using passive FTP then the problem is your
 firewall. Windows command-line FTP is active by default.

 With active FTP the server opens the data connection to you which is
 blocked unless you have a firewall that does stateful inspection.

 WIth passive FTP the client opens the data connection and that will
 work by default in most NAT/firewalls even without stateful inspection.

 David.

>>>
>>>
>

Re: [OT] FTP client problems

[Greg Keogh]

David, we suspected a firewall at first, but it was ruled out a few days
ago. If ftp.exe doesn't do PASV at then I was accidentally wasting my time.
Web searches on this matter now hint that you're right, but I would never
have guessed such a stupid thing could be true. My little C# client is
correctly getting files on the FTP server and all I'm doing is this:
var client = new
WebClient
();
client.Credentials = new NetworkCredentials("user", "password");
client.BaseAddress = "ftp://ftp.myserver.com";;
byte[] buffer = client.DownloadData("getme.txt");

I didn't expect this to work at first, thinking I'd have to change modes or
properties or some other trickery, but it works! I didn't even have to use
the 
FtpWebRequestclass.

Now I think the ball is to be passed over to the C++ programmer to see what
he's doing that is different. His code is still crashing trying to get a
file.

Greg

Re: [OT] FTP client problems

[David Connors]

The firewall is technically at fault rather than your C++ programmer. There
is nothing inherently wrong with not supporting passive FTP - but using
active FTP will not work from behind NAT as a side effect of how NAT works.
Getting the firewall to handle the return path is another way to fix the
problem (which will also cause active FTP to work for the rest of the users
on your network).

You do need a higher end firewall though.

David Connors
da...@connors.com | M +61 417 189 363
Download my v-card: https://www.codify.com/cards/davidconnors
Follow me on Twitter: https://www.twitter.com/davidconnors
Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors


On Thu, Oct 17, 2013 at 5:06 PM, Greg Keogh  wrote:

> David, we suspected a firewall at first, but it was ruled out a few days
> ago. If ftp.exe doesn't do PASV at then I was accidentally wasting my time.
> Web searches on this matter now hint that you're right, but I would never
> have guessed such a stupid thing could be true. My little C# client is
> correctly getting files on the FTP server and all I'm doing is this:
> var client = new 
> WebClient
> ();
> client.Credentials = new NetworkCredentials("user", "password");
> client.BaseAddress = "ftp://ftp.myserver.com";;
> byte[] buffer = client.DownloadData("getme.txt");
>
> I didn't expect this to work at first, thinking I'd have to change modes
> or properties or some other trickery, but it works! I didn't even have to
> use the 
> FtpWebRequestclass.
>
> Now I think the ball is to be passed over to the C++ programmer to see
> what he's doing that is different. His code is still crashing trying to get
> a file.
>
> Greg
>

Re: [OT] FTP client problems

[Greg Keogh]

>
> >You do need a higher end firewall though.
>

I didn't want to confuse matters previously, but now things have calmed
down I can add that the offending server is actually inside an Amazon AWS
server instance. I turned off the Windows firewall ages ago, but Amazon
have their own "Security Group" feature where you say which
inbound/outbound ports are open. I'm not sure why they have such a "meta
firewall" as it just confuses things for customers. It turns out that this
feature was irrelevant to our problem anyway.

The other good news is that the chap writing the Borland C++ code found a
passive switch which lets his ftp operations work perfectly. I'm still
going to urge him over to http instead.

Greg K

Re: [OT] FTP client problems

[Grant Maw]

Just a side-comment - maybe we're luddites here, but we use FTP all the
time to get things from A to B. Every single day. I know it's old, but it's
still useful.


On 18 October 2013 09:46, Greg Keogh  wrote:

> >You do need a higher end firewall though.
>>
>
> I didn't want to confuse matters previously, but now things have calmed
> down I can add that the offending server is actually inside an Amazon AWS
> server instance. I turned off the Windows firewall ages ago, but Amazon
> have their own "Security Group" feature where you say which
> inbound/outbound ports are open. I'm not sure why they have such a "meta
> firewall" as it just confuses things for customers. It turns out that this
> feature was irrelevant to our problem anyway.
>
> The other good news is that the chap writing the Borland C++ code found a
> passive switch which lets his ftp operations work perfectly. I'm still
> going to urge him over to http instead.
>
> Greg K
>

Re: [OT] FTP client problems

[David Connors]

FTP is arguably a lot better for uploads as well as network devices don't
make the same assumptions about length of connections etc with FTP that
they do with HTTP.

David Connors
da...@connors.com | M +61 417 189 363
Download my v-card: https://www.codify.com/cards/davidconnors
Follow me on Twitter: https://www.twitter.com/davidconnors
Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors


On Fri, Oct 18, 2013 at 1:22 PM, Grant Maw  wrote:

> Just a side-comment - maybe we're luddites here, but we use FTP all the
> time to get things from A to B. Every single day. I know it's old, but it's
> still useful.
>
>
> On 18 October 2013 09:46, Greg Keogh  wrote:
>
>>  >You do need a higher end firewall though.
>>>
>>
>> I didn't want to confuse matters previously, but now things have calmed
>> down I can add that the offending server is actually inside an Amazon AWS
>> server instance. I turned off the Windows firewall ages ago, but Amazon
>> have their own "Security Group" feature where you say which
>> inbound/outbound ports are open. I'm not sure why they have such a "meta
>> firewall" as it just confuses things for customers. It turns out that this
>> feature was irrelevant to our problem anyway.
>>
>> The other good news is that the chap writing the Borland C++ code found a
>> passive switch which lets his ftp operations work perfectly. I'm still
>> going to urge him over to http instead.
>>
>> Greg K
>>
>
>

Re: [OT] FTP client problems

[Richard Carde]

Or SFTP (not to be confused with FTPS) which works flawlessly through 
firewalls, is easy to reverse publish and is secure.

I don't understand why Server 2012 still doesn't do it.

--
Richard Carde
Ph: +44 7956 356 226

> On 18 Oct 2013, at 04:22, Grant Maw  wrote:
> 
> Just a side-comment - maybe we're luddites here, but we use FTP all the time 
> to get things from A to B. Every single day. I know it's old, but it's still 
> useful.
> 
> 
>> On 18 October 2013 09:46, Greg Keogh  wrote:
>>> >You do need a higher end firewall though. 
>>  
>> I didn't want to confuse matters previously, but now things have calmed down 
>> I can add that the offending server is actually inside an Amazon AWS server 
>> instance. I turned off the Windows firewall ages ago, but Amazon have their 
>> own "Security Group" feature where you say which inbound/outbound ports are 
>> open. I'm not sure why they have such a "meta firewall" as it just confuses 
>> things for customers. It turns out that this feature was irrelevant to our 
>> problem anyway. 
>>  
>> The other good news is that the chap writing the Borland C++ code found a 
>> passive switch which lets his ftp operations work perfectly. I'm still going 
>> to urge him over to http instead.
>>  
>> Greg K
> 

RE: [OT] FTP client problems

[Ken Schaefer]

Probably because Server 2012 supports FTPS – I remember speaking to the PM on 
the IIS team about this at the time, and Microsoft invested a fair amount of 
time and effort into developing FTPS (including contributing the RFC for the 
equivalent of Host header support for FTPS)

Cheers
Ken

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Richard Carde
Sent: Friday, 18 October 2013 8:25 PM
To: ozDotNet
Subject: Re: [OT] FTP client problems

Or SFTP (not to be confused with FTPS) which works flawlessly through 
firewalls, is easy to reverse publish and is secure.

I don't understand why Server 2012 still doesn't do it.

--
Richard Carde
Ph: +44 7956 356 226

On 18 Oct 2013, at 04:22, Grant Maw 
mailto:grant@gmail.com>> wrote:
Just a side-comment - maybe we're luddites here, but we use FTP all the time to 
get things from A to B. Every single day. I know it's old, but it's still 
useful.

On 18 October 2013 09:46, Greg Keogh mailto:g...@mira.net>> 
wrote:
>You do need a higher end firewall though.

I didn't want to confuse matters previously, but now things have calmed down I 
can add that the offending server is actually inside an Amazon AWS server 
instance. I turned off the Windows firewall ages ago, but Amazon have their own 
"Security Group" feature where you say which inbound/outbound ports are open. 
I'm not sure why they have such a "meta firewall" as it just confuses things 
for customers. It turns out that this feature was irrelevant to our problem 
anyway.

The other good news is that the chap writing the Borland C++ code found a 
passive switch which lets his ftp operations work perfectly. I'm still going to 
urge him over to http instead.

Greg K

Re: [OT] FTP client problems

[Jorke Odolphi]

So AWS assigns their ip's based on an internal private ip and an external (kind 
of nat'd) ip - both dhcp. While you said this wasn't your problem - a very 
quick fix is to add an Elastic IP to the instance and force the FTP server to 
use that IP - usually works by default.

Or you can use the dynamic external ip muck about for ages to get the passive 
settings working on the AWS side via the software - which when you reboot the 
instance it'll change - rinse/repeat.


From: "g...@mira.net<mailto:g...@mira.net>" 
mailto:g...@mira.net>>
Reply-To: ozDotNet mailto:ozdotnet@ozdotnet.com>>
Date: Friday, 18 October 2013 10:46 AM
To: ozDotNet mailto:ozdotnet@ozdotnet.com>>
Subject: Re: [OT] FTP client problems

>You do need a higher end firewall though.

I didn't want to confuse matters previously, but now things have calmed down I 
can add that the offending server is actually inside an Amazon AWS server 
instance. I turned off the Windows firewall ages ago, but Amazon have their own 
"Security Group" feature where you say which inbound/outbound ports are open. 
I'm not sure why they have such a "meta firewall" as it just confuses things 
for customers. It turns out that this feature was irrelevant to our problem 
anyway.

The other good news is that the chap writing the Borland C++ code found a 
passive switch which lets his ftp operations work perfectly. I'm still going to 
urge him over to http instead.

Greg K