Compilation Problem on Sun Solaris Optron 10
Hi All,
I have compiled openssl on many unix flavours and it worked fine.
When I try on Solaris Optron 10 machine. It gets compiled, however i see
Segmentation Fault /core-dump messages.
(I am compiling openssl for Cfengine as it is one of its pre-reqs)
I recompiled openssl forcefully in solaris-x86-gcc architecture to make
it compatible with cfengine in -i386
While running openssl make, was flashing core dumped messages (thus the
openssl binaries also core-dump).
---
make[2]: Entering directory
`/export/home/soetest1/trunk/openssl-0.9.8d/apps'
( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto -lsocket -lnsl -ldl}";
LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall
-DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS
-DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM}";
LIBPATH=`for x in $LIBDEPS; do if echo $x | grep '^ *-L' > /dev/null 2>&1;
then echo $x | sed -e 's/^ *-L//'; fi; done | uniq`; LIBPATH=`echo
$LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH
${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o verify.o asn1pars.o
req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o
crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o
genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o
s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o
pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o prime.o ${LIBDEPS} )
make[2]: Leaving directory
`/export/home/soetest1/trunk/openssl-0.9.8d/apps'
(cd ..; \
OPENSSL="`pwd`/util/opensslwrap.sh"; export OPENSSL; \
/usr/bin/perl tools/c_rehash certs)
Doing certs
Segmentation Fault - core dumped
argena.pem => .0
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate argeng.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate eng1.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate eng2.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate eng3.pem
Segmentation Fault - core dumped
WARNING: Skipping duplicate certificate eng4.pem
Any help will be appreciated
Regards
Neetee
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
RE: Really confusing with SSL_write
> I see, so if I disable PARTIAL_WRITES, will that mean that it will return > values as I wrote up there? PARTIAL_WRITES has no effect on the meaning of the return value. It just controls whether or not the internal write logic tries to continue writing if the underlying write partially completes. With or without PARTIAL_WRITES enabled, if the socket buffer and internal SSL buffers get full after some of the data has been accepted, you will get a partial write if the socket is non-blocking. > Otherwise I fail to see the difference between allowin partial > writes and not. The difference for a non-blocking socket, is that with PARTIAL_WRITES disabled, the underlying internal write operation will be retried until it is unable to accept any bytes at all. With PARTIAL_WRITES enabled, only one call to the underlying internal write operation will be made. > Furthermore, that would mean that I should actually call > SSL_write with new > arguments on the same packet. I don't know what you mean by "the same packet". Packets are below the TCP level and have no meaning at or above the TCP level. > SSL_write(ssl, buffer + written, len - written); > > or am I being retarded here ? If a previous SSL_write has successfully queued some bytes for sending, you don't want to send those same bytes again. In any non-blocking socket application, you have to handle partial writes (a form of *success*) by saving the rest of the data for when your next write attempt. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Really confusing with SSL_write
On Friday 30 March 2007 22:41, David Schwartz wrote: > > > Call SSL_write with the same parameters until it succeeds. You need > > > to handle WANT_READ and WANT_WRITE return values. > > > > I guess that is clear enough. > > but does that imply if I call > > SSL_write(ssl, buffer, len), > > it will ONLY return len > > or <0 ? > > I mean if it returns len/2 (sent only half the buffer) > > will I have to keep track of that myself or will it only return > > > > call #1: 0 - want write > > call #2: 0 - want write > > call #3: 0 - want write > > call #4: len - everything done > > > > I find the docs a bit unclear on that. > > I'm as I already stated, on non blocking sockets. > > A partial write is a form of success. Once the operation succeeds, there is > no need to repeat it. You may, of course, want to write the rest of the > data that didn't get sent, but that would be an entirely new operation as > far as OpenSSL is concerned. I see, so if I disable PARTIAL_WRITES, will that mean that it will return values as I wrote up there? Otherwise I fail to see the difference between allowin partial writes and not. Furthermore, that would mean that I should actually call SSL_write with new arguments on the same packet. SSL_write(ssl, buffer + written, len - written); or am I being retarded here ? Thanks /Tommy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Really confusing with SSL_write
> > Call SSL_write with the same parameters until it succeeds. You need > > to handle WANT_READ and WANT_WRITE return values. > I guess that is clear enough. > but does that imply if I call > SSL_write(ssl, buffer, len), > it will ONLY return len > or <0 ? > I mean if it returns len/2 (sent only half the buffer) > will I have to keep track of that myself or will it only return > > call #1: 0 - want write > call #2: 0 - want write > call #3: 0 - want write > call #4: len - everything done > > I find the docs a bit unclear on that. > I'm as I already stated, on non blocking sockets. A partial write is a form of success. Once the operation succeeds, there is no need to repeat it. You may, of course, want to write the rest of the data that didn't get sent, but that would be an entirely new operation as far as OpenSSL is concerned. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Really confusing with SSL_write
>Hi, > > > I've been trying to figure out (plus testing) how to actually > > use SSL_write. > > Call SSL_write with the same parameters until it succeeds. You need > to handle WANT_READ and WANT_WRITE return values. I guess that is clear enough. but does that imply if I call SSL_write(ssl, buffer, len), it will ONLY return len or <0 ? I mean if it returns len/2 (sent only half the buffer) will I have to keep track of that myself or will it only return call #1: 0 - want write call #2: 0 - want write call #3: 0 - want write call #4: len - everything done I find the docs a bit unclear on that. I'm as I already stated, on non blocking sockets. Thanks /Tommy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL_connect and SSL_accept
> So what you are saying is the scenario we have been discussing so far is > possible ONLY in case of memory allocation issues NOT OTHERWISE. > I guess I will have a look at the SSL_connect code before I just > trust this > :-) I would still recommend coding to handle this case. Perhaps the next version of OpenSSL will include a check in SSL_connect that this version does not have. It's not a good idea to build undocumented insider information about a library into code that calls into that library. You should do that only when there is a very good reason. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Really confusing with SSL_write
Hi, > I've been trying to figure out (plus testing) how to actually > use SSL_write. Call SSL_write with the same parameters until it succeeds. You need to handle WANT_READ and WANT_WRITE return values. Mark __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Trouble compiling and openssl 0.9.8 d or e on solari10
Laurent Blume <[EMAIL PROTECTED]> > Date: Fri, 30 Mar 2007 17:12:12 +0200 > Subject: Re: Trouble compiling and openssl 0.9.8 d or e on solari10 >[EMAIL PROTECTED] a écrit : >> I don't know. Which patch ? > >Those are the latest for Studio 11 on Solaris x86: > >120759-10 Sun Studio 11_x86: Sun Compiler Common patch for x86 backend >120762-03 Sun Studio 11_x86: Patch for Performance Analyzer Tools >121016-05 Sun Studio 11_x86: Patch for Sun C_x86 5.8 Compiler >121018-10 Sun Studio 11_x86: Patch for Sun C++ 5.8 compiler >121020-05 Sun Studio 11_x86: Patch for x86 Fortran 95 8.2 Compiler >121022-03 Sun Studio 11_x86: Patch for Fortran 95 Dynamic Libraries >121616-04 Sun Studio 11_x86: Patch for Sun dbx 7.5_x86 Debugger >122136-02 Sun Studio 11_x86: Performance Library Patch > >It's probably 121016-05 that fixes that, but better to install them all, >I suppose. I'm trying to find the corresponding sparc ones.. I believe I'll get the answer monday. 120760-12 121015-04 And it still does not work. >I have no idea. GCC generates much slower code, and brings in libgcc_s >dependencies that I don't want to bother with. I've been using only >Studio for OpenSSL in years, and the only issue was that optimization >bug some months ago. I'm so used to gcc... f.g. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Trouble compiling and openssl 0.9.8 d or e on solari10
[EMAIL PROTECTED] a écrit : > I don't know. Which patch ? Those are the latest for Studio 11 on Solaris x86: 120759-10 Sun Studio 11_x86: Sun Compiler Common patch for x86 backend 120762-03 Sun Studio 11_x86: Patch for Performance Analyzer Tools 121016-05 Sun Studio 11_x86: Patch for Sun C_x86 5.8 Compiler 121018-10 Sun Studio 11_x86: Patch for Sun C++ 5.8 compiler 121020-05 Sun Studio 11_x86: Patch for x86 Fortran 95 8.2 Compiler 121022-03 Sun Studio 11_x86: Patch for Fortran 95 Dynamic Libraries 121616-04 Sun Studio 11_x86: Patch for Sun dbx 7.5_x86 Debugger 122136-02 Sun Studio 11_x86: Performance Library Patch It's probably 121016-05 that fixes that, but better to install them all, I suppose. > Well it seems I'm not alone in this case I have seen several case on the web. > > Btw it's a cipher problem. I have tried with -cipher RC4-SHA and it worked. > > Is there any gcc version that is supposed to work ? I have tried without -O3 > and it did not work. I have no idea. GCC generates much slower code, and brings in libgcc_s dependencies that I don't want to bother with. I've been using only Studio for OpenSSL in years, and the only issue was that optimization bug some months ago. Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Trouble compiling and openssl 0.9.8 d or e on solari10
Laurent Blume <[EMAIL PROTECTED]> > Date: Fri, 30 Mar 2007 16:39:02 +0200 > Subject: Re: Trouble compiling and openssl 0.9.8 d or e on solari10 >Frederic Goudal a écrit : >> I'm in trouble with openlls 0.9.8 on solaris10 : I compile it either >> witch gcc or sun cc (studio11), and when I try an s_client command on >> our web server I got the following error : > >Did you patch Studio 11? the original version had issues with OpenSSL >when built with -fast (as OpenSSL does by default). I don't know. Which patch ? >It built, but then «make test» failed. It was one of the flags added by >-fast (I can't remember which) that was the cause. >With the most recent patches, there's no such problem, and at least, it >works for me (Solaris 10 U3 x64 / Studio 11 w/ patches / OpenSSL 0.9.8e). > >$ ./openssl s_client -host www.enseirb.fr -port 443 >CONNECTED(0004) >depth=1 /C=FR/O=CRU/CN=ac-serveur/[EMAIL PROTECTED] >verify error:num=20:unable to get local issuer certificate >verify return:0 >--- >Certificate chain >0 s:/C=FR/O=0330196J/CN=www.enseirb.fr/[EMAIL PROTECTED] >i:/C=FR/O=CRU/CN=ac-serveur/[EMAIL PROTECTED] >1 s:/C=FR/O=CRU/CN=ac-serveur/[EMAIL PROTECTED] >i:/C=FR/O=CRU/CN=ac-racine/[EMAIL PROTECTED] Well it seems I'm not alone in this case I have seen several case on the web. Btw it's a cipher problem. I have tried with -cipher RC4-SHA and it worked. Is there any gcc version that is supposed to work ? I have tried without -O3 and it did not work. f.g. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Trouble compiling and openssl 0.9.8 d or e on solari10
Frederic Goudal a écrit : > I'm in trouble with openlls 0.9.8 on solaris10 : I compile it either > witch gcc or sun cc (studio11), and when I try an s_client command on > our web server I got the following error : Did you patch Studio 11? the original version had issues with OpenSSL when built with -fast (as OpenSSL does by default). It built, but then «make test» failed. It was one of the flags added by -fast (I can't remember which) that was the cause. With the most recent patches, there's no such problem, and at least, it works for me (Solaris 10 U3 x64 / Studio 11 w/ patches / OpenSSL 0.9.8e). $ ./openssl s_client -host www.enseirb.fr -port 443 CONNECTED(0004) depth=1 /C=FR/O=CRU/CN=ac-serveur/[EMAIL PROTECTED] verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=FR/O=0330196J/CN=www.enseirb.fr/[EMAIL PROTECTED] i:/C=FR/O=CRU/CN=ac-serveur/[EMAIL PROTECTED] 1 s:/C=FR/O=CRU/CN=ac-serveur/[EMAIL PROTECTED] i:/C=FR/O=CRU/CN=ac-racine/[EMAIL PROTECTED] --- Server certificate -BEGIN CERTIFICATE- Laurent __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Trouble compiling and openssl 0.9.8 d or e on solari10
Hello, I'm in trouble with openlls 0.9.8 on solaris10 : I compile it either witch gcc or sun cc (studio11), and when I try an s_client command on our web server I got the following error : /opt/openssl-0.9.8e/bin/openssl s_client -host www -port 443 CONNECTED(0004) depth=1 /C=FR/O=CRU/CN=ac-serveur/[EMAIL PROTECTED] verify error:num=20:unable to get local issuer certificate verify return:0 18800:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:1053:SSL alert number 20 18800:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: Using openssl 0.9.7 compiled by SUN works well and this web server has been in prod for several monthes now so the ssl on the server is ok. I did a make test on one of my attempt and it worked well... f.g. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect and SSL_accept
I have spent quite some time with SSL_connect, and apart from tcp level socket failures (transient/fatal) and SSL Handshake failures it cannot return error, so ur case is NOT POSSIBLE unless the HOST has run out of memory wherein Openssl_malloc itself fails. So I dont suppose you need to worry about that. So what you are saying is the scenario we have been discussing so far is possible ONLY in case of memory allocation issues NOT OTHERWISE. I guess I will have a look at the SSL_connect code before I just trust this :-) >> Tell me if the client fails, why and how long will you wait for feedback? Also isnt that TCP's job? Why should the session layer worry about this? The response from the server is guarenteed unless the underlying tcp channel is in trouble. If SSL_connect fails, the client will block in tcp recv(). If SSL_connect succeeds, the client will block in SSL_read() The client is guarenteed to return, either when it gets The client either gets a response from the server or gets a tcp error and then decides what to do next. The session layer should be concerned about this, as long as it does not get any tcp errors. >>If the client failes with a malloc and memory corruption issues, you might >>as well restart your application..there is no point waiting on any >>feedback. Agreed. >>You cannot fix the symptom, u need to fix the cause and that is why this >>HYPOTHETICAL error occured in the 1st place. First thing is that I am more worried about my server blocking in a SSL_accept() forever. I might be able to get rid of this with timeout. Secondly, I want the communication to continue even if SSL session establishment fails. Now it is obvious that I can not do much in case the error due to which SSL_connect returnd failure is unrecoverable (memory issue is one of them). But if the error is recoverable (which as per your openion an IMPOSSIBLE thing) I would like to attempt further communication on plain tcp socket, for which I want my server to be ready to accept next tcp data packet. I guess I will have a look at the SSL code to see if there are possibilities, other than memory allocation issues, when SSL_connect returns error, unless of course someone who knows the code makes any authoritive statement here :-) Thank you very much for your help. ~ Urjit DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect and SSL_accept
Thanks for replying. I guess we are on the same page now. The only thing is that you are asking the same question that I am asking everyone on this list "What scenario may cause the SSL_connect to return error to the caller, without writing a single byte on the underlying tcp connection (which is healthy) ?" Can someone think of such a scenario? Has anyone ever experienced this before? I have spent quite some time with SSL_connect, and apart from tcp level socket failures (transient/fatal) and SSL Handshake failures it cannot return error, so ur case is NOT POSSIBLE unless the HOST has run out of memory wherein Openssl_malloc itself fails. So I dont suppose you need to worry about that. I guess you have already mentioned one such scenario ... memory allocation issues, which could cause SSL_connect to return before it could write something on the socket. Are there other such possibilities? SSL_init failures is not a candidate here, as I am already doing what you have suggested "dont attempt SSL at all if SSL_init fails". What I am considering is *some* error, that occurs *just as I enter SSL_connect*. Looking at the SSL_connect code may provide an answer, and I will surely consider this option. But I was looking for a response from folks who already know this code, and have better idea of what SSL_connect does before it writes its first byte on the socket. May be they can say if they foresee a case when SSL_connect can error out without writing a byte on the socket. As far as the synchronization between the server and the client goes, may be I can consider reading a feed back from the server. So the execution sequence will be like Client calls SSL_connect() Client waits for servers response (No matter if SSL_connect fails or succeeds) >> Tell me if the client fails, why and how long will you wait for feedback? Also isnt that TCP's job? Why should the session layer worry about this? >>If the client failes with a malloc and memory corruption issues, you might >>as well restart your application..there is no point waiting on any >>feedback. >>You cannot fix the symptom, u need to fix the cause and that is why this >>HYPOTHETICAL error occured in the 1st place. The server has a non blocking socket it calls SSL_accept() if succeeds, it would report success to the client if failure (timeout), it would report failure to the client ~ Urjit - Original Message - From: "Gayathri Sundar" <[EMAIL PROTECTED]> To: Sent: Friday, March 30, 2007 9:25 AM Subject: Re: SSL_connect and SSL_accept I am quite clear with your problem and am not confused. The only point I have been stressing from beginning is that SSL_connect due to WHATEVER error it returns a failure to the calling application, the peer WILL know for the simple fact that a "socket send " cannot fail unless the FD itself is not created/the host is not in the network/ or the interface is down or simply if the HOST runs out of MEMORY, I am not able to think of an error case wherein the SSL_connect fails to send a message out when the underlying TCP connection is ALIVE and KICKING. WHY? WHAT SORT OF ERROR ARE YOU ANTICIPATING that SSL_connect will return FAILURE to its application without even sending 1 byte on the wire? UNLESS SSL_INIT itself fails on the client or SSL OBJECT creation fails? If that is the FAILURE ur worried about then you might as well initiate a TCP teardown from the client and not attempt SSL anymore.. I hope I am able to explain better..see only in severe application programming errors/memory leak or whatever the SSL init itself will fail..so if the SSL init fails on the client side DONT initiate SSL at all so that the server will not go into SSL_accept. Why will SSL OBJ creation fail? CAN you explain to me WHAT ERROR UR TALKING ABOUT that SSL_CONNECT will return FAILURE TO CALLING APPLICATION without sending 1BYTE on the wire when the TCP CONNECTION IS A-OK? I can think of "BUGGY CODING"..and I dont think Non blocking will solve ur problem as its never going to detect this FAILURE THAT UR TALKING ABOUT..unless you implement POLL TIMEOUT i.e the FD will never SELECT as it never receives any DATA, so ur POLL TIMER should cleanup that FD if say it doesnt select within 5mins or so.. This is my solution: 1. Make ur FDs non blocking 2. Start a timer per FD basis before ur add it into ur POLL table 3. Everytime the FD selects on a POLLIN/POLLOUT restart ur timer 4. On TimerExpiration clean up that FD coz it never received any DATA for the timeout period, due to n/w or client failures. Decide on a good timeout value.. Thanks --Gayathri Hmm... I am surprised to see how I have managed to confuse you. I thought my previous post was pretty clear. Anyway, I will try to explain again. The client and server have and existing tcp connection, which is healthy. There is no problem with the tcp connection throughout the scenario. The client, for some reason decides to have a secured session, and so with its own protocol, tells th
Re: SSL_connect and SSL_accept
Thanks for replying. I guess we are on the same page now. The only thing is that you are asking the same question that I am asking everyone on this list "What scenario may cause the SSL_connect to return error to the caller, without writing a single byte on the underlying tcp connection (which is healthy) ?" Can someone think of such a scenario? Has anyone ever experienced this before? I guess you have already mentioned one such scenario ... memory allocation issues, which could cause SSL_connect to return before it could write something on the socket. Are there other such possibilities? SSL_init failures is not a candidate here, as I am already doing what you have suggested "dont attempt SSL at all if SSL_init fails". What I am considering is *some* error, that occurs *just as I enter SSL_connect*. Looking at the SSL_connect code may provide an answer, and I will surely consider this option. But I was looking for a response from folks who already know this code, and have better idea of what SSL_connect does before it writes its first byte on the socket. May be they can say if they foresee a case when SSL_connect can error out without writing a byte on the socket. As far as the synchronization between the server and the client goes, may be I can consider reading a feed back from the server. So the execution sequence will be like Client calls SSL_connect() Client waits for servers response (No matter if SSL_connect fails or succeeds) The server has a non blocking socket it calls SSL_accept() if succeeds, it would report success to the client if failure (timeout), it would report failure to the client ~ Urjit - Original Message - From: "Gayathri Sundar" <[EMAIL PROTECTED]> To: Sent: Friday, March 30, 2007 9:25 AM Subject: Re: SSL_connect and SSL_accept I am quite clear with your problem and am not confused. The only point I have been stressing from beginning is that SSL_connect due to WHATEVER error it returns a failure to the calling application, the peer WILL know for the simple fact that a "socket send " cannot fail unless the FD itself is not created/the host is not in the network/ or the interface is down or simply if the HOST runs out of MEMORY, I am not able to think of an error case wherein the SSL_connect fails to send a message out when the underlying TCP connection is ALIVE and KICKING. WHY? WHAT SORT OF ERROR ARE YOU ANTICIPATING that SSL_connect will return FAILURE to its application without even sending 1 byte on the wire? UNLESS SSL_INIT itself fails on the client or SSL OBJECT creation fails? If that is the FAILURE ur worried about then you might as well initiate a TCP teardown from the client and not attempt SSL anymore.. I hope I am able to explain better..see only in severe application programming errors/memory leak or whatever the SSL init itself will fail..so if the SSL init fails on the client side DONT initiate SSL at all so that the server will not go into SSL_accept. Why will SSL OBJ creation fail? CAN you explain to me WHAT ERROR UR TALKING ABOUT that SSL_CONNECT will return FAILURE TO CALLING APPLICATION without sending 1BYTE on the wire when the TCP CONNECTION IS A-OK? I can think of "BUGGY CODING"..and I dont think Non blocking will solve ur problem as its never going to detect this FAILURE THAT UR TALKING ABOUT..unless you implement POLL TIMEOUT i.e the FD will never SELECT as it never receives any DATA, so ur POLL TIMER should cleanup that FD if say it doesnt select within 5mins or so.. This is my solution: 1. Make ur FDs non blocking 2. Start a timer per FD basis before ur add it into ur POLL table 3. Everytime the FD selects on a POLLIN/POLLOUT restart ur timer 4. On TimerExpiration clean up that FD coz it never received any DATA for the timeout period, due to n/w or client failures. Decide on a good timeout value.. Thanks --Gayathri Hmm... I am surprised to see how I have managed to confuse you. I thought my previous post was pretty clear. Anyway, I will try to explain again. The client and server have and existing tcp connection, which is healthy. There is no problem with the tcp connection throughout the scenario. The client, for some reason decides to have a secured session, and so with its own protocol, tells the server to allow a secured session. After seeing such request from client (This is still a tcp communication, SSL is still not in picture), the server creates a SSL object, calls SSL_set_fd(sock_serv) and then calls SSL_accept The Client creates its SSL object, calls SSL_set_fd(sock_cli) and calls SSL_connect() Now *before* SSL_connect can actually write something on the tcp channel, using tcp send() or write(), something goes wrong and it returns an error to its caller. So there is nothing placed on the tcp channel. The server is waiting for the SSL handshake packet which it never get because SSL_connect() could never send it. Hope the scenario I am talking about is clear now. The reason why I am interested in knowing if somet
