- Original Message -
> From: "Wiebe Cazemier"
> To: openssl-users@openssl.org
> Sent: Thursday, 23 May, 2024 12:22:31
> Subject: Blocking on a non-blocking socket?
>
> Hi List,
>
> I have a very obscure problem with an application using O_NONBLOCK
On 24/05/2024 02:30, Wiebe Cazemier wrote:
Can you show me in the code where that is?
It's here:
https://github.com/openssl/openssl/blob/b9e084f139c53ce133e66aba2f523c680141c0e6/ssl/record/rec_layer_s3.c#L1038-L1054
The "retry" codepath occurs where we hit the "goto start".
My main
Hi Detlef,
- Original Message -
> From: "Detlef Vollmann"
> To: openssl-users@openssl.org
> Sent: Friday, 24 May, 2024 12:02:37
> Subject: Re: Blocking on a non-blocking socket?
>
> That's correct, but if I understand Matt correctly, thi
On 5/24/24 03:30, Wiebe Cazemier via openssl-users wrote:
Hi Matt,
- Original Message -
From: "Matt Caswell"
To: openssl-users@openssl.org
Sent: Friday, 24 May, 2024 00:26:28
Subject: Re: Blocking on a non-blocking socket?
Not quite.
When you call SSL_read() it is b
Hi Matt,
- Original Message -
> From: "Matt Caswell"
> To: openssl-users@openssl.org
> Sent: Friday, 24 May, 2024 00:26:28
> Subject: Re: Blocking on a non-blocking socket?
> Not quite.
>
> When you call SSL_read() it is because you are hoping to read
&
WANT_READ/WANT_WRITE until such time as the re-negotiation has
>>>> completed. I need to confirm thats the case in the code, but it
>>>> seems to be. If the underlying socket is in non-blocking mode, there
>>>> should be no way for calls to block in SSL_read/SSL_write on
_mode.html ]
SSL_MODE_AUTO_RETRY in non-blocking mode should cause
SSL_reaa/SSL_write to return -1 with an error code of
WANT_READ/WANT_WRITE until such time as the re-negotiation has
completed. I need to confirm thats the case in the code, but it seems
to be. If the underlying socket is in non-blocking mode, th
UTO_RETRY in non-blocking mode should cause
>> SSL_reaa/SSL_write to return -1 with an error code of
>> WANT_READ/WANT_WRITE until such time as the re-negotiation has
>> completed. I need to confirm thats the case in the code, but it seems
>> to be. If the underlying socket is
Hi Neil,
- Original Message -
> From: "Neil Horman"
> To: "Wiebe Cazemier"
> Cc: "udhayakumar" , openssl-users@openssl.org
> Sent: Thursday, 23 May, 2024 23:42:18
> Subject: Re: Blocking on a non-blocking socket?
> from
in the
code, but it seems to be. If the underlying socket is in non-blocking
mode, there should be no way for calls to block in SSL_read/SSL_write on
the socket read/write system call.
On Thu, May 23, 2024 at 8:15 AM Wiebe Cazemier wrote:
> - Original Message -
> > From: &qu
- Original Message -
> From: "Neil Horman"
> To: "udhayakumar"
> Cc: "Wiebe Cazemier" , openssl-users@openssl.org
> Sent: Thursday, 23 May, 2024 22:05:22
> Subject: Re: Blocking on a non-blocking socket?
> do you have a stack trace of t
do you have a stack trace of the thread hung in this state? That would
confirm whats going on here
Neil
On Wed, May 22, 2024 at 11:12 PM udhayakumar
wrote:
> hi Wiebe Cazemier,
>
> The flag SSL_MODE_AUTO_RETRY will cause read/write operations to only
> return after the handshake and
hi Wiebe Cazemier,
The flag SSL_MODE_AUTO_RETRY will cause read/write operations to only return
after the handshake and successful completion. if cable is unplugged connection
got broken until re-authentication it's holding read/write operations i think.
/ udhay!.
On 5/23/24 7:52 AM, Wiebe
not a deadlock or spinning event
loop or something, primarily because the application recovers after about 20
minutes with a client errorring out with ETIMEDOUT. Coincidentally, that 20
minutes matches the timeout description of the tcp man page [1].
It really looks like a non-blocking socket is still
14 matches
Mail list logo
