SSL_shutdown and SIGPIPE

[Alberto Alonso]

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

[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

Post by Alberto Alonso
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.
[phone]
http://www.ggsys.net
Hardware, consulting, sysadmin, monitoring and
remote backups

______________________________________________________________________

Post by Alberto Alonso
OpenSSL Project
http://www.openssl.org
User Support Mailing List
Automated List Manager

__________________________________________________
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 openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[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..

Thanks
--G3

-----Original Message-----
From: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org]On Behalf Of Alberto Alonso
Sent: Sunday, February 12, 2006 2:08 PM
To: openssl-users-MCmKBN63+***@public.gmane.org
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.
[phone] http://www.ggsys.net
Hardware, consulting, sysadmin, monitoring and remote backups

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[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

Post by 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..
Thanks
--G3
-----Original Message-----
Sent: Sunday, February 12, 2006 2:08 PM
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.
[phone] http://www.ggsys.net
Hardware, consulting, sysadmin, monitoring and remote backups
______________________________________________________________________
OpenSSL Project http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[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 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

Post by 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

Post by 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..
Thanks
--G3
-----Original Message-----
Sent: Sunday, February 12, 2006 2:08 PM
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.
[phone] http://www.ggsys.net
Hardware, consulting, sysadmin, monitoring and remote backups
______________________________________________________________________
OpenSSL Project http://www.openssl.org
______________________________________________________________________

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Goetz Babin-Ebell]

Hallo Alberto,

Post by 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 :-)

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...

Post by Alberto Alonso
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

[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 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.

Post by 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 :-)

It's there because the underlying operating system forces them to be
there. It's certainly not at the behest of the OpenSSL team.

Post by Alberto Alonso
Ignoring SIGPIPE (or most signals for that matter) is not really
that good. They get generated for good reasons.

...explained above...

Post by Alberto Alonso
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 openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[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 standard practice.

Best,
Girish

Post by 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 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.

Post by Alberto Alonso
I personally don't know why pipes are even in use

in the openssl

Post by Alberto Alonso
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.

Post by Alberto Alonso
Ignoring SIGPIPE (or most signals for that matter)

is not really

Post by Alberto Alonso
that good. They get generated for good reasons.

...explained above...

Post by Alberto Alonso
In my case, depending on what came down the wire,

I have to interact

Post by Alberto Alonso
with other utilities in the system, therefore

opening pipes. I need

Post by Alberto Alonso
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

______________________________________________________________________

Post by Kyle Hamilton
OpenSSL Project
http://www.openssl.org
User Support Mailing List
Automated List Manager

__________________________________________________
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 openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[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 standard practice.

Best,
Girish

Post by 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 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.

Post by Alberto Alonso
I personally don't know why pipes are even in use

in the openssl

Post by Alberto Alonso
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.

Post by Alberto Alonso
Ignoring SIGPIPE (or most signals for that matter)

is not really

Post by Alberto Alonso
that good. They get generated for good reasons.

...explained above...

Post by Alberto Alonso
In my case, depending on what came down the wire,

I have to interact

Post by Alberto Alonso
with other utilities in the system, therefore

opening pipes. I need

Post by Alberto Alonso
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

______________________________________________________________________

Post by Kyle Hamilton
OpenSSL Project
http://www.openssl.org
User Support Mailing List
Automated List Manager

__________________________________________________
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 openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Girish Venkatachalam]

Post by 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 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.

Post by Alberto Alonso
I personally don't know why pipes are even in use

in the openssl

Post by Alberto Alonso
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.

Post by Alberto Alonso
Ignoring SIGPIPE (or most signals for that matter)

is not really

Post by Alberto Alonso
that good. They get generated for good reasons.

...explained above...

Post by Alberto Alonso
In my case, depending on what came down the wire,

I have to interact

Post by Alberto Alonso
with other utilities in the system, therefore

opening pipes. I need

Post by Alberto Alonso
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

______________________________________________________________________

Post by Kyle Hamilton
OpenSSL Project
http://www.openssl.org
User Support Mailing List
Automated List Manager

__________________________________________________
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 openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[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.

write() or read() will return a 0 or -1 on a closed
socket, so you stand to lose nothing by ignoring
SIGPIPE.

regards,
Girish

Post by 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 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.

Post by Alberto Alonso
I personally don't know why pipes are even in use

in the openssl

Post by Alberto Alonso
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.

Post by Alberto Alonso
Ignoring SIGPIPE (or most signals for that matter)

is not really

Post by Alberto Alonso
that good. They get generated for good reasons.

...explained above...

Post by Alberto Alonso
In my case, depending on what came down the wire,

I have to interact

Post by Alberto Alonso
with other utilities in the system, therefore

opening pipes. I need

Post by Alberto Alonso
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

______________________________________________________________________

Post by Kyle Hamilton
OpenSSL Project
http://www.openssl.org
User Support Mailing List
Automated List Manager

__________________________________________________
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 openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Rick Jones]

Post by 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.

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 openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[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 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

Post by 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 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.

Post by 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 :-)

It's there because the underlying operating system forces them to be
there. It's certainly not at the behest of the OpenSSL team.

Post by Alberto Alonso
Ignoring SIGPIPE (or most signals for that matter) is not really
that good. They get generated for good reasons.

...explained above...

Post by Alberto Alonso
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

[Gayathri Sundar]

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: owner-openssl-users-MCmKBN63+***@public.gmane.org
[mailto:owner-openssl-users-MCmKBN63+***@public.gmane.org]On Behalf Of Kyle Hamilton
Sent: Monday, February 13, 2006 11:15 AM
To: openssl-users-MCmKBN63+***@public.gmane.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 on (if you needed that).

-Kyle H

Post by 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..
Thanks
--G3
-----Original Message-----
Sent: Sunday, February 12, 2006 2:08 PM
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.
[phone] http://www.ggsys.net
Hardware, consulting, sysadmin, monitoring and remote backups
______________________________________________________________________
OpenSSL Project http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Alberto Alonso]

Excellent, I'll give this a try.

Thanks,

Alberto

Post by 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..
Thanks
--G3
-----Original Message-----
Sent: Sunday, February 12, 2006 2:08 PM
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

[Rick Jones]

Post by 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..

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 openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org