YUN GAO wrote:
Hi there:
SSL_shutdown used to have a problem that in some instances it always
returns 0 no matter how many time it is called before 0.9.8l.
To solve the issue, I have to call SSL_shutdown() twice and check the
error number and return code at the second time: if the return code
is
Which code you want, my application is very big?
Just the code to call, SSL_shutdown from client side is pasted in this.
http://pastebin.com/7P70aNWU
On Tue, May 3, 2011 at 12:35 PM, derleader mail wrote:
> Hi,
>I am using Blocking sockets for my applicaiton. The server i have accept
>
Hi,
I am using Blocking sockets for my applicaiton. The server i have accept SSL
and non SSL connections, from the client side when i connect with SSL then on
closesocket i dont get a notification of client closed, while for non SSL i get
notification. Is this some desired behavior or i am
t;leak".
> -Original Message-
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Kyle Hamilton
> Sent: 19 May 2009 12:49
> To: openssl-users@openssl.org
> Subject: Re: SSL_shutdown never returns 1
>
> When you get an
; Thanks for any help you can give.
>
> Andy
>
>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
>> us...@openssl.org] On Behalf Of Kyle Hamilton
>> Sent: 14 May 2009 18:10
>> To: openssl-users@openssl.org
>
ny help you can give.
Andy
> -Original Message-
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Kyle Hamilton
> Sent: 14 May 2009 18:10
> To: openssl-users@openssl.org
> Subject: Re: SSL_shutdown never returns 1
>
> I
If you expect no more data from the client, you can simply destroy the
SSL context at the point you first call it (even if it returns 0). It
will only return 1 if it has received the peer's close_notify, and
it's possible that those peers failed to send it. (Do you get an
SSL_ERROR_SYSCALL with E
-- Original Message --
To: (openssl-users@openssl.org)
From: Saju ([EMAIL PROTECTED])
Subject: RE: SSL_shutdown
Date: 10/2/2008 3:52:05p
> Connection shutdown is just:
> Library->BIO_ssl_shutdown(Bio);
> Library->BIO_set_close(Bio,BIO_CLOSE);
Connection shutdown is just:
Library->BIO_ssl_shutdown(Bio);
Library->BIO_set_close(Bio,BIO_CLOSE);
Library->BIO_free_all(Bio);
//if (Library->SSL_shutdown(Ssl) == 0)
// Library->SSL_shutdown(Ssl);
// Library->SSL_free(Ssl); // Do I need this or
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 t
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
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 e
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
--- 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
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 standar
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 standar
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
:[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 wr
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
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 i
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 a
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 = SSL_get_s
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..
Tha
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 PROTECT
On 2005-03-29, at 21:15, [EMAIL PROTECTED] wrote:
On Solaris, truss shows this:
18416: poll(0xFEE219D0, 2, 4320) = 1
18416: write(13, "150301\018 3F1DBCCCBCAE3".., 29) Err#32 EPIPE
What is your configuration?
The stunnel source implies that it will retry the shutdown whe
On Thu, Jul 03, 2003 at 10:47:27PM -0400, Thomas J. Hruska wrote:
> For non-blocking BIOs (in this case, non-blocking sockets), the
> documentation is unclear as to whether or not a second call to
> SSL_shutdown() will block:
>
> "The second call will make SSL_shutdown() wait for the peer's "close
On Thu, Aug 23, 2001 at 01:17:17PM -0400, George Lind wrote:
> I am running openssl on an NT machine. I am trying to transfer a file to an
> IBM mainframe which is using IBM's implementation of SSL. When I issue an
> SSL_shutdown the mainframe does not have the ability to send back the
> shutdow
On Mon, Jul 23, 2001 at 02:18:37PM +0200, Martin Sjögren wrote:
> This is the mail I sent last Friday that didn't seem to reach the list.
>
> Since then I've made progress. Apparently the SSL_shutdown() function
> cannot return -1! From reading the source I'd say it can only return 1 or
> 0. 1 if
On Sun, Feb 04, 2001 at 07:30:27PM +0100, Gil Peeters wrote:
> > On Sun, Feb 04, 2001 at 06:12:39PM +0100, Gil Peeters wrote:
> > > After calling SSL_shutdown() is it still nesc to close the underlying
> > > socket associated with the SSL Connection?
> >
> > SSL_shutdown() will only send the close
Lutz Jaenicke wrote:
> On Sun, Feb 04, 2001 at 06:12:39PM +0100, Gil Peeters wrote:
> > After calling SSL_shutdown() is it still nesc to close the underlying
> > socket associated with the SSL Connection?
>
> SSL_shutdown() will only send the close-alert to the peer and switch the
> setting of th
On Sun, Feb 04, 2001 at 06:12:39PM +0100, Gil Peeters wrote:
> After calling SSL_shutdown() is it still nesc to close the underlying
> socket associated with the SSL Connection?
SSL_shutdown() will only send the close-alert to the peer and switch the
setting of the SSL to "shutdown mode".
It does
31 matches
Mail list logo
