<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 05/04/18 23:37, Varun Kulkarni wrote:<br>
<br>
><br>
> Thanks for the reply Matt. Previosuly , I did the exact thing you<br>
> mentioned. But in that case , the DTLSV1_listen returns succesfully (><br>
> 0) immediately on reception of<br>
> app packet and hangs on SSL_accept.<br>
><br>
> Here is tshark trace of the same:<br>
><br>
> 1 0.000000000 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello<br>
> 2 0.000136330 127.0.0.1 → 127.0.0.1 DTLSv1.0 90 Hello Verify<br>
> Request<br>
> 3 0.000258998 127.0.0.1 → 127.0.0.1 DTLSv1.0 264 Client Hello<br>
> 4 0.999217798 127.0.0.1 → 127.0.0.1 DTLSv1.0 264 Client Hello<br>
> 5 1.001095034 127.0.0.1 → 127.0.0.1 DTLSv1.0 1482 Server<br>
> Hello, Certificate, Server Key Exchange, Certificate Request, Server<br>
> Hello Done<br>
> 6 1.003771485 127.0.0.1 → 127.0.0.1 DTLSv1.0 1457 Certificate,<br>
> Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted<br>
> Handshake Message<br>
> 7 1.004282757 127.0.0.1 → 127.0.0.1 DTLSv1.0 1252 New Session<br>
> Ticket, Change Cipher Spec, Encrypted Handshake Message<br>
> 8 4.313854533 127.0.0.1 → 127.0.0.1 DTLSv1.0 103 Application Data<br>
> 9 4.314110117 127.0.0.1 → 127.0.0.1 DTLSv1.0 295 Application<br>
> Data <br>
</span>> * 10 31.662557986 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello*<br>
<span class="">> 11 32.662344551 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello<br>
> 12 34.665481449 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello<br>
> 13 38.662321433 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello<br>
> 14 46.662998247 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello<br>
> 15 62.662816876 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello<br>
><br>
> The trace starting from 10 is from the second client and it hangs<br>
> because DTLSv1_listen has already returned and is struck on SSL_accept.<br>
><br>
> Can you clarify that at any moment of time, dtls can process only one<br>
> handshake at a time. <br>
<br>
</span>For any single thread that is true. It is self evident that in a single<br>
thread you can only do one thing at a time. But plenty of applications<br>
still manage to handle multiple simultaneous clients! There are two<br>
general ways that applications solve this problem.<br>
<br>
1) Have one thread for DTLSv1_listen. When a client connects offload the<br>
SSL_accept call to some other thread. In the first thread you can loop<br>
around and call DTLSv1_listen again while, at the same time, the second<br>
thread can process the handshake with the connected client.<br>
<br></blockquote><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> This is what I tried to do. But it appears that DTLSV1_listen() fails to send</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> the Hello verify request for the second client (Refer trace above). But If I recreate the fd</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> every time in the thread, it works as expected.</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
or<br>
<br>
2) Interleave processing of different clients and DTLSv1_listen within<br>
the same thread. Usually on some event driven process (e.g. select,<br>
poll, epoll, libevent etc). So in this case you set the underlying fd to<br>
be non-blocking and then handle the<br>
SSL_ERROR_WANT_READ/SSL_ERROR_<wbr>WANT_WRITE errors than you get back from<br>
OpenSSL (see man page for SSL_get_error).<br>
<span class="HOEnZb"><font color="#888888"><br>
Matt<br>
</font></span><div class="HOEnZb"><div class="h5">--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div><br></div><div><br></div><div>Regards,</div><div>Varun K S</div></div></div></div>
</div></div>