RE: SSL_shutdown and SIGPIPE

2006-02-13 Thread Gayathri Sundar
:[EMAIL PROTECTED] Behalf Of Kyle Hamilton Sent: Monday, February 13, 2006 11:15 AM To: openssl-users@openssl.org Subject: Re: SSL_shutdown and SIGPIPE Why are you trying to avoid SIGPIPE, anyway? It's easy to ignore, and a global state would make it possible to determine what socket you were writing

Re: SSL_shutdown and SIGPIPE

2006-02-13 Thread Kyle Hamilton
SIGPIPE is a remnant of BSD attempting to overlay UNIX socket (named pipe) semantics onto TCP/IP connections. If the socket that you are writing to is a socket (or pipe), AND the pipe is closed, then you receive a SIGPIPE. In this case, the 'good reason' for it is that what you think is supposed

Re: SSL_shutdown and SIGPIPE

2006-02-13 Thread Girish Venkatachalam
None of the solutions suggested by others in the list will protect you against a SIGPIPE for the simple reason that it is a fatal signal if not handled or ignored and it can come at any time during the TCP session... Ignoring SIGPIPE is one of the steps in writing a server daemon and it is

Re: SSL_shutdown and SIGPIPE

2006-02-13 Thread Girish Venkatachalam
None of the solutions suggested by others in the list will protect you against a SIGPIPE for the simple reason that it is a fatal signal if not handled or ignored and it can come at any time during the TCP session... Ignoring SIGPIPE is one of the steps in writing a server daemon and it is

Re: SSL_shutdown and SIGPIPE

2006-02-13 Thread Girish Venkatachalam
--- Kyle Hamilton [EMAIL PROTECTED] wrote: SIGPIPE is a remnant of BSD attempting to overlay UNIX socket (named pipe) semantics onto TCP/IP connections. If the socket that you are writing to is a socket (or pipe), AND the pipe is closed, then you receive a SIGPIPE. In this case, the

Re: SSL_shutdown and SIGPIPE

2006-02-13 Thread Girish Venkatachalam
SIGPIPE is fatal if not handled or ignored and it can come at any time during the TCP session. Which means that none of the solutions suggested by others in the list will work. And it is wrong to rely on OpenSSL for solving a TCP closure at the remote end which is essentially a TCP issue.

Re: SSL_shutdown and SIGPIPE

2006-02-13 Thread Rick Jones
Girish Venkatachalam wrote: SIGPIPE is fatal if not handled or ignored and it can come at any time during the TCP session. Which means that none of the solutions suggested by others in the list will work. And it is wrong to rely on OpenSSL for solving a TCP closure at the remote end which is

Re: SSL_shutdown and SIGPIPE

2006-02-13 Thread Rick Jones
Gayathri Sundar wrote: Probably you can call the following iRet = SSL_get_shutdown(pSSL); if(iRet = 0) SSL_shutdown(pSSL); This is because, SSL_shutdown writes data on the wire, i.e the closure alerts..and if a FIN was received meanwhile, you will catch a SIGPIPE..this piece of code, actually

Re: SSL_shutdown and SIGPIPE

2006-02-13 Thread Alberto Alonso
Thanks for the detailed explanation, it clearly helped my understanding of the whole thing. I obviously already have a SIGPIPE handler, but the difficulty comes from trying to figure out which call generated the signal. As the code is meant to work on Linux and windows, and my understanding is

Re: SSL_shutdown and SIGPIPE

2006-02-12 Thread Girish Venkatachalam
The standard practice is that of ignoring SIGPIPE in all TCP servers. signal(SIGPIPE,SIG_IGN); OpenSSL cannot help you here because the problem occurs at a lower level(TCP). I remember seeing this line in the ssh server source code as well. regards, Girish --- Alberto Alonso [EMAIL

RE: SSL_shutdown and SIGPIPE

2006-02-12 Thread Gayathri Sundar
Probably you can call the following iRet = SSL_get_shutdown(pSSL); if(iRet = 0) SSL_shutdown(pSSL); This is because, SSL_shutdown writes data on the wire, i.e the closure alerts..and if a FIN was received meanwhile, you will catch a SIGPIPE..this piece of code, actually saves me from this..

Re: SSL_shutdown and SIGPIPE

2006-02-12 Thread Kyle Hamilton
Why are you trying to avoid SIGPIPE, anyway? It's easy to ignore, and a global state would make it possible to determine what socket you were writing on (if you needed that). -Kyle H On 2/12/06, Gayathri Sundar [EMAIL PROTECTED] wrote: Probably you can call the following iRet =

RE: SSL_shutdown and SIGPIPE

2006-02-12 Thread Alberto Alonso
Excellent, I'll give this a try. Thanks, Alberto On Mon, 2006-02-13 at 10:51 +0530, Gayathri Sundar wrote: Probably you can call the following iRet = SSL_get_shutdown(pSSL); if(iRet = 0) SSL_shutdown(pSSL); This is because, SSL_shutdown writes data on the wire, i.e the closure

Re: SSL_shutdown and SIGPIPE

2006-02-12 Thread Alberto Alonso
I personally don't know why pipes are even in use in the openssl internals (though I bet there is a good reason for it :-) Ignoring SIGPIPE (or most signals for that matter) is not really that good. They get generated for good reasons. In my case, depending on what came down the wire, I have to

Re: SSL_shutdown and SIGPIPE

2006-02-12 Thread Goetz Babin-Ebell
Hallo Alberto, Alberto Alonso schrieb: I personally don't know why pipes are even in use in the openssl internals (though I bet there is a good reason for it :-) OpenSSL doesn't use pipes. You get a SIGPIPE if you write to a socket for that the other end is closed. I prefer using send() with