Yes, if you never call FIPS_mode_set(), the POST will never run. I'll
defer to the experts on your other questions.
On 05/01/2015 05:10 PM, Bryan Call wrote:
> So can I assume the FIPS POST has completed if I never call FIPS_mode_set() in the code? I was confused about that.
>
> When we call SSL_read() and get a 0 byte return we call SSL_get_error() to see if there was an error not not. Maybe there is a more efficient handle this, like looking at the shutdown flag?
>
> 0 The read operation was not successful. The reason may either be a
> clean shutdown due to a "close notify" alert sent by the peer (in
> which case the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown state
> is set (see SSL_shutdown(3), SSL_set_shutdown(3)). It is also
> possible, that the peer simply shut down the underlying transport
> and the shutdown is incomplete. Call SSL_get_error() with the
> return value ret to find out, whether an error occurred or the
> connection was shut down cleanly (SSL_ERROR_ZERO_RETURN).
>
> When we call SSL_accept we also call SSL_get_error() to see we need to read or write. Is there a more efficient way to tell if we need to read or write?
>
> If the underlying BIO is non-blocking, SSL_accept() will also return
> when the underlying BIO could not satisfy the needs of SSL_accept() to
> continue the handshake, indicating the problem by the return value -1.
> In this case a call to SSL_get_error() with the return value of
> SSL_accept() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
> The calling process then must repeat the call after taking appropriate
> action to satisfy the needs of SSL_accept(). The action depends on the
> underlying BIO. When using a non-blocking socket, nothing is to be
> done, but select() can be used to check for the required condition.
> When using a buffering BIO, like a BIO pair, data must be written into
> or retrieved out of the BIO before being able to continue.
>
>
> Thank you...
>
> -Bryan
>
>
>
>
>> On May 1, 2015, at 5:34 AM, John Foley <foleyj at cisco.com> wrote:
>>
>> Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors. It appears your application is generating a lot of errors for some reason. Never tried it myself, but you probably can't disable this lock with multiple threads running. You should take a look at the error log to identify the cause of the errors. Then resolve the issue, whatever it may be.
>>
>>
>>
>> On 04/30/2015 06:52 PM, Bryan Call wrote:
>>> This is for Apache Traffic Server and we have no knobs for turning on/off FIPS. I am thinking about always disabling FIPS right now and that would happen before we create the threads.
>>>
>>> I was able to get rid of all the FIPS lock connection with the changes you recommend (Big Thanks!). The big one now is type 1. I am printing out the log every time the contention total is mod 1M. Are there any tricks I can do for type 1 locks?
>>>
>>> [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock - total contention: 4000000 waiting: 1 file: pmeth_lib.c line: 185 type: 10
>>> [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock - total contention: 11000000 waiting: 2 file: err.c line: 469 type: 1
>>> [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock - total contention: 4000000 waiting: 0 file: ex_data.c line: 304 type: 2
>>> [Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock - total contention: 12000000 waiting: 5 file: err.c line: 446 type: 1
>>> [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock - total contention: 1000000 waiting: 0 file: rand_lib.c line: 212 type: 19
>>>
>>> -Bryan
>>>
>>>
>> _______________________________________________
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> .
>
