I am getting SIGPIPE signals under Linux when calling
on SSL_shutdown and the remote is gone. Basically, the remote end terminates the connection abruptly, then the server finishes doing whatever is doing and issues a SSL_shutdown on the ssl structure that used to handle the connection. This generates a SIGPIPE on the server. Is there anything I should be checking for before calling SSL_shutdown to make sure the connection is still OK? Thanks, Alberto -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
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 <[hidden email]> wrote: > I am getting SIGPIPE signals under Linux when > calling > on SSL_shutdown and the remote is gone. > > Basically, the remote end terminates the connection > abruptly, > then the server finishes doing whatever is doing and > issues > a SSL_shutdown on the ssl structure that used to > handle the > connection. This generates a SIGPIPE on the server. > > Is there anything I should be checking for before > calling > SSL_shutdown to make sure the connection is still > OK? > > > Thanks, > > Alberto > -- > Alberto Alonso Global Gate > Systems LLC. > (512) 351-7233 > http://www.ggsys.net > Hardware, consulting, sysadmin, monitoring and > remote backups > > > OpenSSL Project > http://www.openssl.org > User Support Mailing List > [hidden email] > Automated List Manager > [hidden email] > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by Alberto Alonso
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.. Thanks --G3 -----Original Message----- From: [hidden email] [mailto:[hidden email]]On Behalf Of Alberto Alonso Sent: Sunday, February 12, 2006 2:08 PM To: [hidden email] Subject: SSL_shutdown and SIGPIPE I am getting SIGPIPE signals under Linux when calling on SSL_shutdown and the remote is gone. Basically, the remote end terminates the connection abruptly, then the server finishes doing whatever is doing and issues a SSL_shutdown on the ssl structure that used to handle the connection. This generates a SIGPIPE on the server. Is there anything I should be checking for before calling SSL_shutdown to make sure the connection is still OK? Thanks, Alberto -- Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
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 <[hidden email]> 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 > saves me from this.. > > Thanks > --G3 > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]]On Behalf Of Alberto Alonso > Sent: Sunday, February 12, 2006 2:08 PM > To: [hidden email] > Subject: SSL_shutdown and SIGPIPE > > > I am getting SIGPIPE signals under Linux when calling > on SSL_shutdown and the remote is gone. > > Basically, the remote end terminates the connection abruptly, > then the server finishes doing whatever is doing and issues > a SSL_shutdown on the ssl structure that used to handle the > connection. This generates a SIGPIPE on the server. > > Is there anything I should be checking for before calling > SSL_shutdown to make sure the connection is still OK? > > > Thanks, > > Alberto > -- > Alberto Alonso Global Gate Systems LLC. > (512) 351-7233 http://www.ggsys.net > Hardware, consulting, sysadmin, monitoring and remote backups > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [hidden email] > Automated List Manager [hidden email] > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [hidden email] > Automated List Manager [hidden email] > OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by Gayathri Sundar-2
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 alerts..and if a FIN was received meanwhile, > you will catch a SIGPIPE..this piece of code, actually > saves me from this.. > > Thanks > --G3 > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]]On Behalf Of Alberto Alonso > Sent: Sunday, February 12, 2006 2:08 PM > To: [hidden email] > Subject: SSL_shutdown and SIGPIPE > > > I am getting SIGPIPE signals under Linux when calling > on SSL_shutdown and the remote is gone. > > Basically, the remote end terminates the connection abruptly, > then the server finishes doing whatever is doing and issues > a SSL_shutdown on the ssl structure that used to handle the > connection. This generates a SIGPIPE on the server. > > Is there anything I should be checking for before calling > SSL_shutdown to make sure the connection is still OK? > > > Thanks, > > Alberto Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by Kyle Hamilton
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 interact with other utilities in the system, therefore opening pipes. I need to make sure I get the signals when a system tool exits unexpectedly. Alberto On Sun, 2006-02-12 at 22:45 -0700, Kyle Hamilton wrote: > 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 <[hidden email]> 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 > > saves me from this.. > > > > Thanks > > --G3 > > > > -----Original Message----- > > From: [hidden email] > > [mailto:[hidden email]]On Behalf Of Alberto Alonso > > Sent: Sunday, February 12, 2006 2:08 PM > > To: [hidden email] > > Subject: SSL_shutdown and SIGPIPE > > > > > > I am getting SIGPIPE signals under Linux when calling > > on SSL_shutdown and the remote is gone. > > > > Basically, the remote end terminates the connection abruptly, > > then the server finishes doing whatever is doing and issues > > a SSL_shutdown on the ssl structure that used to handle the > > connection. This generates a SIGPIPE on the server. > > > > Is there anything I should be checking for before calling > > SSL_shutdown to make sure the connection is still OK? > > > > > > Thanks, > > > > Alberto > > -- > > Alberto Alonso Global Gate Systems LLC. > > (512) 351-7233 http://www.ggsys.net > > Hardware, consulting, sysadmin, monitoring and remote backups > > > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List [hidden email] > > Automated List Manager [hidden email] > > > > ______________________________________________________________________ ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
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 MSG_NOSIGNAL, but that is not supported on every platform OpenSSL runs on... > 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 interact > with other utilities in the system, therefore opening pipes. I need > to make sure I get the signals when a system tool exits unexpectedly. SIGPIPE is something you normally can ignore: if the write fails, you get an error return value and can check errno for EPIPE. This has the advantage you handle the closed connection on the function that fails and not in an global signal handler... Bye Goetz -- DMCA: The greed of the few outweighs the freedom of the many |
In reply to this post by Kyle Hamilton
yeah, I have an unusual requirement dat, I cant ignore sigpipe..
meanwhile, SSL_get_shutdown will check the FD status, and if a FIN/RST was received, the return value will reflect dat..so I will not even attempt a write. Thanks --G3 -----Original Message----- From: [hidden email] [mailto:[hidden email]]On Behalf Of Kyle Hamilton Sent: Monday, February 13, 2006 11:15 AM To: [hidden email] 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 on (if you needed that). -Kyle H On 2/12/06, Gayathri Sundar <[hidden email]> 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 > saves me from this.. > > Thanks > --G3 > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]]On Behalf Of Alberto Alonso > Sent: Sunday, February 12, 2006 2:08 PM > To: [hidden email] > Subject: SSL_shutdown and SIGPIPE > > > I am getting SIGPIPE signals under Linux when calling > on SSL_shutdown and the remote is gone. > > Basically, the remote end terminates the connection abruptly, > then the server finishes doing whatever is doing and issues > a SSL_shutdown on the ssl structure that used to handle the > connection. This generates a SIGPIPE on the server. > > Is there anything I should be checking for before calling > SSL_shutdown to make sure the connection is still OK? > > > Thanks, > > Alberto > -- > Alberto Alonso Global Gate Systems LLC. > (512) 351-7233 http://www.ggsys.net > Hardware, consulting, sysadmin, monitoring and remote backups > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [hidden email] > Automated List Manager [hidden email] > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [hidden email] > Automated List Manager [hidden email] > OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by Alberto Alonso
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 to be listening isn't listening anymore, so you may need to update your internal state. However, since the other effect of writing to a socket that is remote-closed is the descriptor itself being closed, there's no reason to worry about it. I help maintain a MUD software (that uses OpenSSL); often players will disconnect by closing their clients instead of using the QUIT command, and this leads to attempts to send information to them. When the software receives the TCP RST ('connection reset by peer'), it also receives a SIGPIPE. However, we have no need to deal with it, since we check the return status of the write operation; if it fails, we close the socket and clean up the memory allocated to that connection. On 2/12/06, Alberto Alonso <[hidden email]> wrote: > 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 :-) It's there because the underlying operating system forces them to be there. It's certainly not at the behest of the OpenSSL team. > Ignoring SIGPIPE (or most signals for that matter) is not really > that good. They get generated for good reasons. ...explained above... > In my case, depending on what came down the wire, I have to interact > with other utilities in the system, therefore opening pipes. I need > to make sure I get the signals when a system tool exits unexpectedly. Alright, then just check to see what descriptor actually caused the SIGPIPE (instead of setting it to SIG_IGN, you always have the ability to write your own handler). If it's a descriptor that connects to another utility, handle that special case (preferably by setting a global variable and exiting the signal handler quickly, before handling the exceptional circumstance in your main program loop -- this is akin to a 'deferred procedure call' in Windows 2000+ device driver programming). If it's not, then it probably belongs to a TLS/SSL connection, and can be safely ignored (since you're supposed to be checking the return statuses of all of your OpenSSL calls anyway, and since you're trying to shut down the SSL socket, you might as well just call SSL_free() immediately after the SSL_shutdown [taking into account the possibility of an SSL_WANTS_WRITE return status]. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
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 standard practice. Best, Girish --- Kyle Hamilton <[hidden email]> 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 'good reason' for it is that what > you think is > supposed to be listening isn't listening anymore, so > you may need to > update your internal state. However, since the > other effect of > writing to a socket that is remote-closed is the > descriptor itself > being closed, there's no reason to worry about it. > > I help maintain a MUD software (that uses OpenSSL); > often players will > disconnect by closing their clients instead of using > the QUIT command, > and this leads to attempts to send information to > them. When the > software receives the TCP RST ('connection reset by > peer'), it also > receives a SIGPIPE. However, we have no need to > deal with it, since > we check the return status of the write operation; > if it fails, we > close the socket and clean up the memory allocated > to that connection. > > On 2/12/06, Alberto Alonso <[hidden email]> > wrote: > > 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 :-) > > It's there because the underlying operating system > forces them to be > there. It's certainly not at the behest of the > OpenSSL team. > > > Ignoring SIGPIPE (or most signals for that matter) > is not really > > that good. They get generated for good reasons. > > ...explained above... > > > In my case, depending on what came down the wire, > I have to interact > > with other utilities in the system, therefore > opening pipes. I need > > to make sure I get the signals when a system tool > exits unexpectedly. > > Alright, then just check to see what descriptor > actually caused the > SIGPIPE (instead of setting it to SIG_IGN, you > always have the ability > to write your own handler). If it's a descriptor > that connects to > another utility, handle that special case > (preferably by setting a > global variable and exiting the signal handler > quickly, before > handling the exceptional circumstance in your main > program loop -- > this is akin to a 'deferred procedure call' in > Windows 2000+ device > driver programming). If it's not, then it probably > belongs to a > TLS/SSL connection, and can be safely ignored (since > you're supposed > to be checking the return statuses of all of your > OpenSSL calls > anyway, and since you're trying to shut down the SSL > socket, you might > as well just call SSL_free() immediately after the > SSL_shutdown > [taking into account the possibility of an > SSL_WANTS_WRITE return > status]. > > -Kyle H > > OpenSSL Project > http://www.openssl.org > User Support Mailing List > [hidden email] > Automated List Manager > [hidden email] > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by Kyle Hamilton
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 standard practice. Best, Girish --- Kyle Hamilton <[hidden email]> 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 'good reason' for it is that what > you think is > supposed to be listening isn't listening anymore, so > you may need to > update your internal state. However, since the > other effect of > writing to a socket that is remote-closed is the > descriptor itself > being closed, there's no reason to worry about it. > > I help maintain a MUD software (that uses OpenSSL); > often players will > disconnect by closing their clients instead of using > the QUIT command, > and this leads to attempts to send information to > them. When the > software receives the TCP RST ('connection reset by > peer'), it also > receives a SIGPIPE. However, we have no need to > deal with it, since > we check the return status of the write operation; > if it fails, we > close the socket and clean up the memory allocated > to that connection. > > On 2/12/06, Alberto Alonso <[hidden email]> > wrote: > > 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 :-) > > It's there because the underlying operating system > forces them to be > there. It's certainly not at the behest of the > OpenSSL team. > > > Ignoring SIGPIPE (or most signals for that matter) > is not really > > that good. They get generated for good reasons. > > ...explained above... > > > In my case, depending on what came down the wire, > I have to interact > > with other utilities in the system, therefore > opening pipes. I need > > to make sure I get the signals when a system tool > exits unexpectedly. > > Alright, then just check to see what descriptor > actually caused the > SIGPIPE (instead of setting it to SIG_IGN, you > always have the ability > to write your own handler). If it's a descriptor > that connects to > another utility, handle that special case > (preferably by setting a > global variable and exiting the signal handler > quickly, before > handling the exceptional circumstance in your main > program loop -- > this is akin to a 'deferred procedure call' in > Windows 2000+ device > driver programming). If it's not, then it probably > belongs to a > TLS/SSL connection, and can be safely ignored (since > you're supposed > to be checking the return statuses of all of your > OpenSSL calls > anyway, and since you're trying to shut down the SSL > socket, you might > as well just call SSL_free() immediately after the > SSL_shutdown > [taking into account the possibility of an > SSL_WANTS_WRITE return > status]. > > -Kyle H > > OpenSSL Project > http://www.openssl.org > User Support Mailing List > [hidden email] > Automated List Manager > [hidden email] > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by Kyle Hamilton
--- Kyle Hamilton <[hidden email]> 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 'good reason' for it is that what > you think is > supposed to be listening isn't listening anymore, so > you may need to > update your internal state. However, since the > other effect of > writing to a socket that is remote-closed is the > descriptor itself > being closed, there's no reason to worry about it. > > I help maintain a MUD software (that uses OpenSSL); > often players will > disconnect by closing their clients instead of using > the QUIT command, > and this leads to attempts to send information to > them. When the > software receives the TCP RST ('connection reset by > peer'), it also > receives a SIGPIPE. However, we have no need to > deal with it, since > we check the return status of the write operation; > if it fails, we > close the socket and clean up the memory allocated > to that connection. > > On 2/12/06, Alberto Alonso <[hidden email]> > wrote: > > 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 :-) > > It's there because the underlying operating system > forces them to be > there. It's certainly not at the behest of the > OpenSSL team. > > > Ignoring SIGPIPE (or most signals for that matter) > is not really > > that good. They get generated for good reasons. > > ...explained above... > > > In my case, depending on what came down the wire, > I have to interact > > with other utilities in the system, therefore > opening pipes. I need > > to make sure I get the signals when a system tool > exits unexpectedly. > > Alright, then just check to see what descriptor > actually caused the > SIGPIPE (instead of setting it to SIG_IGN, you > always have the ability > to write your own handler). If it's a descriptor > that connects to > another utility, handle that special case > (preferably by setting a > global variable and exiting the signal handler > quickly, before > handling the exceptional circumstance in your main > program loop -- > this is akin to a 'deferred procedure call' in > Windows 2000+ device > driver programming). If it's not, then it probably > belongs to a > TLS/SSL connection, and can be safely ignored (since > you're supposed > to be checking the return statuses of all of your > OpenSSL calls > anyway, and since you're trying to shut down the SSL > socket, you might > as well just call SSL_free() immediately after the > SSL_shutdown > [taking into account the possibility of an > SSL_WANTS_WRITE return > status]. > > -Kyle H > > OpenSSL Project > http://www.openssl.org > User Support Mailing List > [hidden email] > Automated List Manager > [hidden email] > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by Kyle Hamilton
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. write() or read() will return a 0 or -1 on a closed socket, so you stand to lose nothing by ignoring SIGPIPE. regards, Girish --- Kyle Hamilton <[hidden email]> 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 'good reason' for it is that what > you think is > supposed to be listening isn't listening anymore, so > you may need to > update your internal state. However, since the > other effect of > writing to a socket that is remote-closed is the > descriptor itself > being closed, there's no reason to worry about it. > > I help maintain a MUD software (that uses OpenSSL); > often players will > disconnect by closing their clients instead of using > the QUIT command, > and this leads to attempts to send information to > them. When the > software receives the TCP RST ('connection reset by > peer'), it also > receives a SIGPIPE. However, we have no need to > deal with it, since > we check the return status of the write operation; > if it fails, we > close the socket and clean up the memory allocated > to that connection. > > On 2/12/06, Alberto Alonso <[hidden email]> > wrote: > > 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 :-) > > It's there because the underlying operating system > forces them to be > there. It's certainly not at the behest of the > OpenSSL team. > > > Ignoring SIGPIPE (or most signals for that matter) > is not really > > that good. They get generated for good reasons. > > ...explained above... > > > In my case, depending on what came down the wire, > I have to interact > > with other utilities in the system, therefore > opening pipes. I need > > to make sure I get the signals when a system tool > exits unexpectedly. > > Alright, then just check to see what descriptor > actually caused the > SIGPIPE (instead of setting it to SIG_IGN, you > always have the ability > to write your own handler). If it's a descriptor > that connects to > another utility, handle that special case > (preferably by setting a > global variable and exiting the signal handler > quickly, before > handling the exceptional circumstance in your main > program loop -- > this is akin to a 'deferred procedure call' in > Windows 2000+ device > driver programming). If it's not, then it probably > belongs to a > TLS/SSL connection, and can be safely ignored (since > you're supposed > to be checking the return statuses of all of your > OpenSSL calls > anyway, and since you're trying to shut down the SSL > socket, you might > as well just call SSL_free() immediately after the > SSL_shutdown > [taking into account the possibility of an > SSL_WANTS_WRITE return > status]. > > -Kyle H > > OpenSSL Project > http://www.openssl.org > User Support Mailing List > [hidden email] > Automated List Manager > [hidden email] > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by Gayathri Sundar-2
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 > saves me from this.. Strictly speaking, it isn't that a FIN was received. Receipt of the FIN in and of itself does not mean that the remote TCP endpoint is gone, nor that it is unwilling to accept more data. All a FIN means in and of itself is that the remote TCP and application will be sending no more data our way on the connection. For example, when the remote simply calls shutdown(SHUT_WR). Now, we also receive a FIN when the remote calls close(). In this sitation, while it was unable to communicate that via TCP, the remote is not willing to recieve any more data. The close() has implicitly stated such to the remote TCP, so when the remote TCP recieves our data, it becomes upset/worried/concernec/confused tosses its hands in the air and sends us a RST segment. Receipt of that RST segment puts our end of the TCP connection into an aborted state, and an attempt to write to the socket generates the SIGPIPE. Generally, this will not be seen by us until our _second_ access of the socket - first the write to trigger the RST from the remote, and then some other socket call - typically another write IIRC, but I think it could be a recv. SIGPIPE/EPIPE is our local TCP's way of telling us that we screwed-up in the application-level handshaking between the ends. A variation of the close() scenario is if the remote application is (bogusly IMO) using an "abortive close" a la SO_LINGER. In that case they emit a RST and go away. Either we receive that RST and go SIGPIPE/EPIPE on the next socket call, or we don't see that RST (it is lost) and we follow a path much like the FIN. The only way to be more or less sure we won't get an EPIPE/SIGPIPE is to preface all our socket calls with something like select() or poll(), and even then there is still a small window of a race condition, and of course the slight matter of the select/poll overhead... rick jones ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by Girish Venkatachalam
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 essentially a TCP > issue. Not to say that OpenSSL is or is not partially culpable, but things like SIGPIPE/EPIPE are not _solely_ the responsibility of TCP. Connection close handshaking is the joint responsibility of TCP and its user. rick jones ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
In reply to this post by Kyle Hamilton
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 that the windows pthreads implementation doesn't do per thread signals it becomes even more difficult to pinpoint the culprit. Proper checking of all the return codes helps (and that's what I've been doing anyway). I was trying to use a SIGPIPE as an indication of a problem with the system tools interaction, but it is clear now that it was a simplistic approach. Thanks, Alberto On Mon, 2006-02-13 at 06:42 -0700, Kyle Hamilton 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 'good reason' for it is that what you think is > supposed to be listening isn't listening anymore, so you may need to > update your internal state. However, since the other effect of > writing to a socket that is remote-closed is the descriptor itself > being closed, there's no reason to worry about it. > > I help maintain a MUD software (that uses OpenSSL); often players will > disconnect by closing their clients instead of using the QUIT command, > and this leads to attempts to send information to them. When the > software receives the TCP RST ('connection reset by peer'), it also > receives a SIGPIPE. However, we have no need to deal with it, since > we check the return status of the write operation; if it fails, we > close the socket and clean up the memory allocated to that connection. > > On 2/12/06, Alberto Alonso <[hidden email]> wrote: > > 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 :-) > > It's there because the underlying operating system forces them to be > there. It's certainly not at the behest of the OpenSSL team. > > > Ignoring SIGPIPE (or most signals for that matter) is not really > > that good. They get generated for good reasons. > > ...explained above... > > > In my case, depending on what came down the wire, I have to interact > > with other utilities in the system, therefore opening pipes. I need > > to make sure I get the signals when a system tool exits unexpectedly. > > Alright, then just check to see what descriptor actually caused the > SIGPIPE (instead of setting it to SIG_IGN, you always have the ability > to write your own handler). If it's a descriptor that connects to > another utility, handle that special case (preferably by setting a > global variable and exiting the signal handler quickly, before > handling the exceptional circumstance in your main program loop -- > this is akin to a 'deferred procedure call' in Windows 2000+ device > driver programming). If it's not, then it probably belongs to a > TLS/SSL connection, and can be safely ignored (since you're supposed > to be checking the return statuses of all of your OpenSSL calls > anyway, and since you're trying to shut down the SSL socket, you might > as well just call SSL_free() immediately after the SSL_shutdown > [taking into account the possibility of an SSL_WANTS_WRITE return > status]. > > -Kyle H > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [hidden email] > Automated List Manager [hidden email] Alberto Alonso Global Gate Systems LLC. (512) 351-7233 http://www.ggsys.net Hardware, consulting, sysadmin, monitoring and remote backups ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [hidden email] Automated List Manager [hidden email] |
Free forum by Nabble | Edit this page |