reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate-users] openSSL error store clearing

Do we detect the error in the correct connection object first?  If so, it might make more sense to clear the error buffer at the time the error was detected, instead of waiting for the next Read.  Perhaps there is a place we are not calling ERR_get_error() after an error occurs which would remove the error from the buffer.

>I called ERR_clear_error() right before the call to SSL_read, and that fixed my issue.  Should it be more specific?  That is, should I check to see if we are in the middle of reading a packet (SSL packet state is read_body 0xF1)?  Or is there some other issue this will cause?

I'm not enough of an SSL expert to answer those questions.  : )

Scott

On Fri, Jan 4, 2013 at 10:50 AM, Haugen Keith-CKH040 <Keith.Haugen@xxxxxxxxxxxxxxxxxxxxx> wrote:

I am having an issue where with a low speed/bandwidth link to 2 SIP servers that have the same TLS certificates, if one of them goes off the network, my client begins failing reading packets from the other one.  After some debugging in both the openSSL source and the reciprocate source, the problem is that when the first server fails, an error indicating SSL internal error is written to the SSL error store and stays there to become stale.  Then when I try to read packets from the second server, if the entire packet is not there yet, TlsConnection::read() believes that an internal SSL error has just occurred, so even though the SSL packet state indicates 0xF1 (reading packet body), the stale SSL internal error causes TlsConnection::read() to return -1 rather than 0, and so the packet never gets read as the socket/connection gets closed.

 

I called ERR_clear_error() right before the call to SSL_read, and that fixed my issue.  Should it be more specific?  That is, should I check to see if we are in the middle of reading a packet (SSL packet state is read_body 0xF1)?  Or is there some other issue this will cause?

 

I am not using the latest resiprocate – my version of resiprocate is 1.7 which uses version 0.9.8g of openSSL, but the TlsConnection::read() code does not appear to have changed.


_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/