If SSL_read or SSL_write return SSL_WANT_READ or SSL_WANT_WRITE, just at some point call them again. It means either that insufficient data has actually come in to decrypt the next SSL packet, or that there's a request for a renegotiation, or whathaveyou. The SSL_read and SSL_write functions will do the appropriate underlying reading and writing, but they return because it might take a while for the negotiation to take place and it doesn't make sense to prevent any other connections that the same thread is managing. (In the case of DTLS, if your application data block is larger than about 3/4 of the MTU, it's going to need to be split across multiple IP datagrams. I haven't looked at the DTLS code itself to figure out if it's only reading one datagram at a time and thus possibly returning SSL_WANT_* when it's been split in those circumstances.)
They aren't really 'errors', they're more like errno being set to EAGAIN -- the desired semantic of the call cannot be completed at this time, but there's no particular reason why it won't work the next time you call it. What happens when you call SSL_read or SSL_write after getting SSL_WANT_*? -Kyle H On Fri, Aug 29, 2008 at 1:08 PM, Pau Rodriguez Estivill <[EMAIL PROTECTED]> wrote: > Hi, > > I'm using OpenSSL to create a VPN software based on the DTLS > implementation of it. > The source is available here: http://vpmn.googlecode.com/svn/trunk/src/ > > My application is currently using pthreads and I use a mutex for every > SSL object, locking it before every SSL_* function call. > > There are a collection of threads for sending (tunsrv.c) and another > collection of threads for receiving (udpsrv.c). And all openssl > related code is in file udpsrvdtls.c > I send an IP packet in a single SSL_write, trying to optimize the > protocol, and assuming that it will arrive as I write, and always > starting with an IP header. > I use a BIO_dgram for openssl writes, and a BIO_pair for openssl > reads, since the server share the same UDP port for different clients. > > The VPN application has no problems when low traffic, I tried by using pings. > > When trying to start TCP connection or high traffic, > and at random time, > the OpenSSL function SSL_read returns -1 with SSL_WANT_READ, > and after this error there are no way to receive the data blocs as > suppose to be. > > I suppose when I SSL_write a bloc of data the SSL_read should return > the same bloc. > So if a paquet is lost, there are only the offset applied in the flow > of the lost packets from SSL_write. > > Reading the code of openssl I found that in the case of DTLS, that is > datagram oriented, > it should be like I said before. So doesn't seam to be a problem. > > I suppose that SSL_WANT_READ could be for a TLS renegotiation, but > event in that case why I start to receive strange data. > I can't find if there are an strange offset in data blocs or is really > random data, but it seams that the length of the received data is the > correct form the original blocs. > So the SSL_write doesn't write entirely into a single record? It is at > maximum 1500 bytes (MTU) and I disabled DF bit from UDP channel, so > UDP packets are fragmented when are big enough. > > Thanks for your opinion. > > And supposing that there no solution: How can I know which offset is > applied in the internal buffers when a strange phenom like that > appears? > > Thanks for the replies. > > Pau > > PD: the software still beta, if there are some license issue related > with OpenSSL license I have no problems in change it. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
