On Thu Nov 27 16:23:04 2014, prav...@viptela.com wrote: > *My approach* > > global_ssl = SSL_new(ctx); > > In Server call back function > > ret = DTLSv1_listen(global_ssl, client_addr); > if ret <= 0 return; > else socket, > bind, > connect (more specific) and > migrate the global_ssl to this peer (peer->ssl) and > continue > SSL_do_handshake (NON blocking) > > Create new global_ssl = SSL_new(ctx) > Go back to Server call back function
Ahhh, ok. I understand your approach now. Yes. This should be ok. > > I don't quite understand what you are saying here: "we do use the > > DTLS_listen in the same way". Are you saying you handle the initial > > "listen" part of the handshake with DTLSv1_listen and then call > > SSL_accept on the connected socket? Because this suggests you are > > calling DTLSv1_listen a second time (i.e. on a handshake that has > > already completed the initial ClientHello/HelloVerify/ClientHello > > exchange): > > > > [praveen] > > This should *never* be the case. I will put an assert and make sure > *THIS* > situation never happens. Before we further discuss the original > problem, do > you agree with me so far ? Yes, please do that - and I think we are in agreement. What concerns me is that the valgrind logs show a message being sent from DTLSv1_listen which should never be sent whilst listening. That means either: 1) There's a bug in your code that means you are re-entering DTLSv1_listen when you shouldn't be or 2) There's a bug in our code that means we are not correctly handling the listening state I'd like to figure out which of 1 or 2 is correct! Matt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
