08-21-2019, 09:13 PM
(08-18-2019, 04:08 PM)PeakTibor Wrote: I made that modification, using a SVN version 5515 of Indy.
It really makes the SSL shutdown now, I can see the 'close notify' TLS messages in the WireShark log.
Good.
(08-18-2019, 04:08 PM)PeakTibor Wrote: But it fails when I try to get a file from the server with "Access violation at address 00407E8E in module 'IdFtp_Tests_2.exe'. Read of address 00000020" message that appears after a while (destination local file is created, but empty).
An AV at a memory address near 0 usually indicates a nil pointer is being accessed. What does the call stack look like when the AV is raised? Which module inside your EXE does memory address $00407E8E reside in?
(08-18-2019, 04:08 PM)PeakTibor Wrote: I cannot really debug the program, before I cannot access the server from my developer pc, I can write only log messages to see at which step the program is executing.
Well, then you will likely have to install a 3rd party exception logger into your app, like MadExcept, EurekaLog, JclDebug, etc so that you can log those kind of details when the exception happens.
(08-18-2019, 04:08 PM)PeakTibor Wrote: It seems to me the problem is in "TIdFTP.InitDataChannel" where "PassThrough" is set to true for the newly cloned IOHandler of the datachannel, and it causes the SSL_shutdown to be called for that IOHandler.
Try changing the following line in SetPassThrough() from this:
Code:
if fSSLSocket <> nil then begin
To this:
Code:
if (fSSLSocket <> nil) and (fSSLSocket.fSSL <> nil) then begin
Something else I notice is that the fPassThrough member in IdSSL.pas is initialized to False by default. It probably should be initialized to True instead. Many places inside of Indy force PassThrough=True as soon as they create new instances of SSLIOHandler objects.