> In response to the FEAT request, some servers just return "PROT"
> and the current test for PROT P will always fail.
> This is the minor change I have made to the FTP Client. It would
> be nice if this could be added so I don't have to modify the
> source after each update:
I'll put it on my
In response to the FEAT request, some servers just return "PROT" and the
current test for PROT P will always fail.
This is the minor change I have made to the FTP Client. It would be nice
if this could be added so I don't have to modify the source after each
update:
Change this:
Yes please, an account might be useful to have, thank you.
Graham
On 12/02/2018 12:01, Angus Robertson - Magenta Systems Ltd wrote:
The only reason I mentioned it was, as you may remember, my
mission is to connect to a Linux FTP server using AUTH TLS.
Everything is fine except if I select
> The only reason I mentioned it was, as you may remember, my
> mission is to connect to a Linux FTP server using AUTH TLS.
> Everything is fine except if I select "Passive" mode and
> PROT=Private, I cannot login. I get SSL handshake errors. They
> suggested that I should use BLOCK mode in
The only reason I mentioned it was, as you may remember, my mission is
to connect to a Linux FTP server using AUTH TLS. Everything is fine
except if I select "Passive" mode and PROT=Private, I cannot login. I
get SSL handshake errors. They suggested that I should use BLOCK mode in
this
> I see that the component supports MODE S and MODE Z. Is there any
> way it can, or will in the future, support MODE B (Block)?
Block mode goes back to the RFC959 written over 40 years ago, before
the internet really existed and FTP was used by mainframe computers.
I've never really come
Hopefully the last question on this FTP client.
I see that the component supports MODE S and MODE Z. Is there any way it
can, or will in the future, support MODE B (Block)?
Regards
Graham
On 11/02/2018 21:16, Graham Powell wrote:
Thank you once again for your help. You are indeed correct. A
Thank you once again for your help. You are indeed correct. A search on
the Internet suggests the timeout could be between 30 and 120 seconds.
When I have finished all my testing, I show you what I have modified in
the SslFtpClient. Just a simple change to the processing of the FEAT
response
> I have set Active Mode and the Data Port Range to 1..10010
> I connect to the Demo Server and click on the "Get" button.
> I have a breakpoint where the Data Port number is allocated so I
> can see it increment through the above range.
> When it gets to 10010 it loops back to 1.
> The
Sorry, more questions on this topic.
I am testing with the SslFtpClient demo and the SslFtpServer demo
programs and am currently interested in setting the Data Port range.
I have set Active Mode and the Data Port Range to 1..10010
I connect to the Demo Server and click on the "Get"
> It would appear that this is a Windows Firewall issue after all.
> I am using Windows 10 and if I turn off the Private AND Public
> Firewalls, the problem of "peer reset" after a certain number of
> transfers does not occur.
Is Windows Firewall aware of your application?
You can add it to
First a reply to Nicholas Machand as a reply to your e-mail bounces:
The "KeepAliveSecs" makes no difference.
I have turned off the Windows Firewall - No difference.
I have disconnected the Internet router, just left with a simple switch
connecting the computers - No difference.
Graham
On
Hi,
Am 23.01.2018 um 15:54 schrieb Graham Powell:
> I don't think that's the problem as the ICS FTP demo setup I am
> currently using for test only has one connection.
> Somehow my network or Windows has a data limit for each session.
>
Send details please.. ;-)
Note that this rings a bell here:
I don't think that's the problem as the ICS FTP demo setup I am
currently using for test only has one connection.
Somehow my network or Windows has a data limit for each session.
Graham
On 23/01/2018 14:23, Angus Robertson - Magenta Systems Ltd wrote:
Any clues as to whether or not there is
> Any clues as to whether or not there is something wrong with the
> ICS components or is it my setup?
Sorry no, I download hundreds of files a day from my servers using
secure FTP, totalling hundreds of megs, and problems are very rare.
I suggest you try and use FTP with a single component,
Hello again,
I have been doing more tests to try and find out which end is causing
the problem.
My latest setup is to use the IcsSslFtpTst1 demo program and connect it
to the IcsSslFtpServ1 demo program.
The client demo has been modified to display the number of times I press
the "Get"
> I have 2 ftp components and both are logged into the server. The
> first just does a LIST command every 3 seconds. The second does
> the GET commands.
> After 198 GETs I receive and error 10054. I re-connect both ftp
> clients and after a further 198 GETs the same thing happens again.
So you
1: The PROT issue is indeed irrelevent, but a simple fix at least lets
you know if PROT is supported.
Something like this maybe, so long as ftpFeatProt is added to the set:
if Pos('PROT', Feat) = 1 then begin
if Feat = 'PROT' then
> Hold fire on what I said before. I am still in learning mode as
> this is all new to me.
I would suggest you at least try the compiled version of my high level
TMagFtp component from:
https://www.magsys.co.uk/delphi/magxfer.asp
which handles all this stuff automatically. If TMagFtp works,
Hold fire on what I said before. I am still in learning mode as this is
all new to me.
I had made a basic assumption that if I set "C" or "P" in the
ftpClient.ProtLevel then that would be enough to be incorporated into
the FTP connect mechanism. However not so is it. I have to manually
execute
I'll contact the server folks as well to see what they are expecting.
Thanks again.
Graham
On 20/12/2017 12:09, Angus Robertson - Magenta Systems Ltd wrote:
Also if I set the PROT to C, both the listAsync and getAsync
responses are encrypted. If PROT is set to P, only the getAsync
response is
Thank you for that. It does appear that the cert and key files are not
required to log in.
Also if I set the PROT to C, both the listAsync and getAsync responses
are encrypted. If PROT is set to P, only the getAsync response is encrypted.
P and C are the only two PROT commands supported by
> I use the 01cert.pem etc. as example files
SSL client applications don't need certificate or private key files,
unless the server is high security and requires secure identification
of remote users, like access to corporate LANs, money transfer services.
You only need a root CA file bundle, and
23 matches
Mail list logo
