<div dir="ltr">Hi Michael,<div><br></div><div>Below is our scenario on DTLS.</div><div><br></div><div>We have multiple connections to the same server. We have mapped one fd to the ssl in the server to receive all connections.</div><div><br></div><div>Whenever a connect is initiated from any client we need to know if it is already connected client or a new client. We are doing this by </div><div><ul><li>creating bio/ssl each time on the same fd<br></li><li>fetching the peer using BIO_dgram_get_peer after ssl_accept <br></li><li>Comparing it to the internally maintained list of peer<br></li><li>If it is a new peer we continue with handshake but if it is old peer we do the ssl_read.</li></ul><div>The problem is that there are 2 bio/ssl that gets created for the same fd and the peer end up writing to one of them and we don't get the message on the intended ssl.</div></div><div>Hence we are checking for a way to detach and remove the ssl/bio that gets created in already connected case.</div><div><br></div><div>Thanks,</div><div>Grace</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 11, 2018 at 6:30 PM, Michael Richardson <span dir="ltr"><<a href="mailto:mcr@sandelman.ca" target="_blank">mcr@sandelman.ca</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>
Grace Priscilla Jero <<a href="mailto:grace.priscilla@gmail.com">grace.priscilla@gmail.com</a>> wrote:<br>
    > We are having a scenario wherein we are having 2 BIOs for DTLS<br>
    > attached to the same fd. Each BIO has a different SSL associated with<br>
    > it. The messages are getting written to different BIO each time and we<br>
    > are trying to resolve it.<br>
<br>
    > Is there a API or any way to detach one of the BIO/SSL from the fd for<br>
    > DTLS?<br>
<br>
</span>No.  How did you get into that situation in the first place?<br>
My belief is that the DTLS API is suitable for (Secure)RTP only, and not for<br>
CoAP-type usage. (or other DTLS server end-point usage)<br>
<br>
According to some source code comments, you should have called connect() on<br>
the socket after the first connection was received, and then (or<br>
previously... there are race conditions either way), opened a new<br>
socket.<br>
<br>
I ran into this, and I wound up creating a new API, which is in a pull<br>
request:<br>
  <a href="https://github.com/openssl/openssl/pull/5024" rel="noreferrer" target="_blank">https://github.com/openssl/<wbr>openssl/pull/5024</a><br>
  <a href="https://github.com/mcr/openssl/tree/dtls-listen-refactor" rel="noreferrer" target="_blank">https://github.com/mcr/<wbr>openssl/tree/dtls-listen-<wbr>refactor</a><br>
<br>
Sadly, the new test case I wrote is not running consistently, which I'm still<br>
debugging.<br>
<br>
--<br>
]               Never tell me the odds!                 | ipv6 mesh networks [<br>
]   Michael Richardson, Sandelman Software Works        | network architect  [<br>
]     <a href="mailto:mcr@sandelman.ca">mcr@sandelman.ca</a>  <a href="http://www.sandelman.ca/" rel="noreferrer" target="_blank">http://www.sandelman.ca/</a>        |   ruby on rails    [<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>
<br></blockquote></div><br></div></div></div>