[openssl-users] Information to detach a BIO from fd
Grace Priscilla Jero
grace.priscilla at gmail.com
Fri Jan 12 07:49:16 UTC 2018
Hi Michael,
Below is our scenario on DTLS.
We have multiple connections to the same server. We have mapped one fd to
the ssl in the server to receive all connections.
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
- creating bio/ssl each time on the same fd
- fetching the peer using BIO_dgram_get_peer after ssl_accept
- Comparing it to the internally maintained list of peer
- If it is a new peer we continue with handshake but if it is old peer
we do the ssl_read.
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.
Hence we are checking for a way to detach and remove the ssl/bio that gets
created in already connected case.
Thanks,
Grace
On Thu, Jan 11, 2018 at 6:30 PM, Michael Richardson <mcr at sandelman.ca>
wrote:
>
> Grace Priscilla Jero <grace.priscilla at gmail.com> wrote:
> > We are having a scenario wherein we are having 2 BIOs for DTLS
> > attached to the same fd. Each BIO has a different SSL associated with
> > it. The messages are getting written to different BIO each time and
> we
> > are trying to resolve it.
>
> > Is there a API or any way to detach one of the BIO/SSL from the fd
> for
> > DTLS?
>
> No. How did you get into that situation in the first place?
> My belief is that the DTLS API is suitable for (Secure)RTP only, and not
> for
> CoAP-type usage. (or other DTLS server end-point usage)
>
> According to some source code comments, you should have called connect() on
> the socket after the first connection was received, and then (or
> previously... there are race conditions either way), opened a new
> socket.
>
> I ran into this, and I wound up creating a new API, which is in a pull
> request:
> https://github.com/openssl/openssl/pull/5024
> https://github.com/mcr/openssl/tree/dtls-listen-refactor
>
> Sadly, the new test case I wrote is not running consistently, which I'm
> still
> debugging.
>
> --
> ] Never tell me the odds! | ipv6 mesh
> networks [
> ] Michael Richardson, Sandelman Software Works | network
> architect [
> ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on
> rails [
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180112/0fda78e8/attachment.html>
More information about the openssl-users
mailing list