On 9 Dec 12, at 14:05, Ludo Brands wrote:
.
.
> SSL_set_fd returning 1 means success (0 is failure).
> For SSL_ctrl the return value depends on the command parameter but 0 is
> in general an error. Is that the call with SSL_CTRL_SET_TLSEXT_HOSTNAME?
Yes, it is.
> Add a sslcheck after it to see what the error is.
SSLCheck doesn't help because ErrGetError again returns 0. :-(
> > SSLMethod* are all initialized. What's the right way for forcing
> > another SSLType? I can obviously add some hack to TSSLOpenSSL.Init
> > for this purpose, but I assume that there is some standard way for
> > selecting it. ;-)
> Before calling THTTPSend.HTTPMethod do a
> THTTPSend.Sock.SSL.SSLType:=LT_SSLv2;
> or any other TSSLType except for LT_SSHv2 which is not supported by openssl.
OK, thanks. LT_TLSv1_1 doesn't seem to be supported either because it
is not handled in TSSL_OpenSSL.Init. The other values (LT_SSLv2,
LT_SSLv3 and LT_TLSv1) don't make any difference.
.
.
> I'm a little out of ideas also. There is not a problem with calling
> convention?
That also came to my mind, but cdecl is the standard calling
convention used for all 32-bit libraries coming from the "C world"
(this makes it a bit easier compared to Win32 with its stdcall versus
cdecl). I have noticed that the OpenSSL imports are all declared as
cdecl (even under Win32), i.e. this should be OK.
> Another interesting test would be to run the following test program. It
> will call TSSLOpenSSL.CreateSelfSignedCert which makes a lot of openssl
> calls. Put a break point in the function and step through it to see if
> and when it breaks. If something is wrong with openssl, you'll probably
> won't get very far into the function without a sigsegv.
> CreateSelfSignedCert doesn't do a lot of error checking though.
>
> program openssltest;
>
> {$mode objfpc}{$H+}
>
> uses
> blcksock,ssl_openssl;
>
> var sock:TTCPBlockSocket;
>
> begin
> sock:=TTCPBlockSocket.Create;
> sock.bind('0.0.0.0','12345');
> sock.ssl.Accept;
> end.
>
> The program doesn't do anything useful :)
Most of the calls seem to succeed as far as I can see (they return
either 1, or some pointer, or non-zero length of generated
certificate string). The trouble comes with SSLAccept returning -1
(again :-( ) without providing any other information (the same
symptoms as with SSLConnect). The socket is clearly created and
listening on the defined port before that. That probably suggests
that we are as far as we were before.
Thanks for all your thoughts so far (and obviously also those
possibly coming in the future). I'm afraid that the next step would
be skipping the easy path and rewriting the OS/2 support to use the
native BSD sockets (possibly in platform specific way rather than
trying to re-use and just slightly modify the include file for Unix
due to the additional dependencies involved), but that will probably
require a lot of time / effort. :-(
Tomas
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
synalist-public mailing list
synalist-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synalist-public
