<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 5, 2018 at 3:06 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
On 05/04/18 18:53, Varun Kulkarni wrote:<br>
> Hi Matt,<br>
><br>
><br>
> I was able to fix the issue with the following changes. The change was<br>
> to create new fd (bound to server address) each time DTLSv1_listen() was<br>
> called.<br>
<br>
</span>There should be no need to do that. Instead, when DTLSv1_listen returns<br>
successfully, you should create a new fd for the *client* (connected to<br>
their address as returned from DTLSv1_listen()), and then update the SSL<br>
object for the client to use that fd. You can reuse the old fd for the<br>
next DTLSv1_listen call. You will need a new SSL object for the next<br>
DTLSv1_listen() call though.<br>
<br>
Matt<br></blockquote><div><br></div><div><br></div><div>Thanks for the reply Matt. Previosuly , I did the exact thing you mentioned. But in that case , the DTLSV1_listen returns succesfully (> 0) immediately on reception of</div><div>app packet and hangs on SSL_accept.</div><div><br></div><div>Here is tshark trace of the same:</div><div><br></div><div><div> 1 0.000000000 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello</div><div> 2 0.000136330 127.0.0.1 → 127.0.0.1 DTLSv1.0 90 Hello Verify Request</div><div> 3 0.000258998 127.0.0.1 → 127.0.0.1 DTLSv1.0 264 Client Hello</div><div> 4 0.999217798 127.0.0.1 → 127.0.0.1 DTLSv1.0 264 Client Hello</div><div> 5 1.001095034 127.0.0.1 → 127.0.0.1 DTLSv1.0 1482 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done</div><div> 6 1.003771485 127.0.0.1 → 127.0.0.1 DTLSv1.0 1457 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message</div><div> 7 1.004282757 127.0.0.1 → 127.0.0.1 DTLSv1.0 1252 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message</div><div> 8 4.313854533 127.0.0.1 → 127.0.0.1 DTLSv1.0 103 Application Data</div><div> 9 4.314110117 127.0.0.1 → 127.0.0.1 DTLSv1.0 295 Application Data </div><div> <b> 10 31.662557986 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello</b></div><div> 11 32.662344551 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello</div><div> 12 34.665481449 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello</div><div> 13 38.662321433 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello</div><div> 14 46.662998247 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello</div><div> 15 62.662816876 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello</div></div><div><br></div><div>The trace starting from 10 is from the second client and it hangs because DTLSv1_listen has already returned and is struck on SSL_accept.</div><div><br></div><div>Can you clarify that at any moment of time, dtls can process only one handshake at a time. </div><div><br></div><div>-Varun</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> Previously, I used the same fd for every DTLSv1_listen call.<br>
> The new dgram BIO was created with an old fd. On passing newly created<br>
> fd to BIO_new_dgram, the problem seems to be resolved. However, this<br>
> leads to another question. Why doesn't DTLS_listen queue up the<br>
> connections similar to accept call? Does that mean DTLS can support only<br>
> one handshake at a time? Is it recommended to create multiple fds bound<br>
> to server address and then spawning a thread (per fd) to listen to DTLS<br>
> requests.<br>
><br>
> <br>
><br>
> while(1) {<br>
><br>
> int fd = socket(AF_INET6, SOCK_DGRAM, 0);<br>
> bind(fd, &server_addr, sizeof(struct sockaddr_in6));<br>
><br>
><br>
><br>
> BIO *bio = BIO_new_dgram(fd, BIO_NOCLOSE);<br>
> SSL *ssl = SSL_new(ctx);<br>
> SSL_set_bio(ssl, bio, bio);<br>
><br>
> /* Enable cookie exchange */<br>
> SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE);<br>
><br>
> /* Wait for incoming connections */<br>
> while (!DTLSv1_listen(ssl, &client_addr));<br>
><br>
> /* connect to client on different fd and complete the handshake and<br>
> process data packets */<br>
><br>
> }<br>
><br>
><br>
><br>
><br>
> Thanks,<br>
> Varun<br>
><br>
><br>
><br>
> On Thu, Apr 5, 2018 at 1:03 AM, Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a><br>
</span><span class="gmail-">> <mailto:<a href="mailto:matt@openssl.org">matt@openssl.org</a>>> wrote:<br>
><br>
> Are you able to share a simple reproducer of your problem?<br>
><br>
> Matt<br>
><br>
> On 05/04/18 02:14, Varun Kulkarni wrote:<br>
> > Hi,<br>
> ><br>
> > I was able to get DTLS work with the latest version of openssl with a<br>
> > single client and server. However, I was unable to get it to work with<br>
> > multiple clients. The first client completes the handshake and works<br>
> > well. But however the function DTLSv1_listen returns 1 immediately<br>
> even<br>
> > for an application data packet (after the first client completes the<br>
> > handshake), where it should ideally return 0 and wait for the next<br>
> > client hello. Since it hangs on SSL_accept, the next client hello<br>
> > packets won't be answered. <br>
> ><br>
> ><br>
> > The closest reference I have got is from:<br>
> > <a href="https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5" rel="noreferrer" target="_blank">https://gist.github.com/Jxck/<wbr>b211a12423622fe304d2370b1f1d30<wbr>d5</a><br>
</span>> <<a href="https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5" rel="noreferrer" target="_blank">https://gist.github.com/Jxck/<wbr>b211a12423622fe304d2370b1f1d30<wbr>d5</a>>. This<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">> > doesn't seem to work for multiple clients.<br>
> ><br>
> > Any suggestions/references would be helpful in this regard. If this is<br>
> > not the right mailing list, please point me to the right one.<br>
> ><br>
> ><br>
> > --<br>
> ><br>
> ><br>
> > Thanks and Regards,<br>
> > Varun K S<br>
> ><br>
> ><br>
> --<br>
> openssl-users mailing list<br>
> To unsubscribe:<br>
> <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>
> <<a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><wbr>><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
><br>
> Regards,<br>
> Varun K S<br>
><br>
><br>
--<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"><div dir="ltr"><div><div><br></div><div><br></div><div>Regards,</div><div>Varun K S</div></div></div></div>
</div></div>