DTLS with multiple clients

[Varun Kulkarni]

Hi,

I was able to get DTLS work with the latest version of openssl with a single client and server. However, I was unable to get it to work with multiple clients. The first client completes the handshake and works well. But however the function DTLSv1_listen returns 1 immediately even for an application data packet (after the first client completes the handshake), where it should ideally return 0 and wait for the next client hello. Since it hangs on SSL_accept, the next client hello packets won't be answered.  

The closest reference I have got is from: https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5. This doesn't seem to work for multiple clients.

Any suggestions/references would be helpful in this regard. If this is not the right mailing list, please point me to the right one.

--

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Matt Caswell-2]

Are you able to share a simple reproducer of your problem?

Matt

On 05/04/18 02:14, Varun Kulkarni wrote:

> Hi,
>
> I was able to get DTLS work with the latest version of openssl with a
> single client and server. However, I was unable to get it to work with
> multiple clients. The first client completes the handshake and works
> well. But however the function DTLSv1_listen returns 1 immediately even
> for an application data packet (after the first client completes the
> handshake), where it should ideally return 0 and wait for the next
> client hello. Since it hangs on SSL_accept, the next client hello
> packets won't be answered.  
>
>
> The closest reference I have got is from:
> https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5. This
> doesn't seem to work for multiple clients.
>
> Any suggestions/references would be helpful in this regard. If this is
> not the right mailing list, please point me to the right one.
>
>
> --
>
>
> Thanks and Regards,
> Varun K S
>
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Varun Kulkarni]

Hi Matt,

I was able to fix the issue with the following changes. The change was to create new fd (bound to server address) each time DTLSv1_listen() was called.  Previously, I used the same fd for every DTLSv1_listen call. The new dgram BIO was created with an old fd. On passing newly created fd to BIO_new_dgram, the problem seems to be resolved. However, this leads to another question. Why doesn't DTLS_listen queue up the connections similar to accept call? Does that mean DTLS can support only one handshake at a time? Is it recommended to create multiple fds bound to server address and then spawning a thread (per fd) to listen to DTLS requests.

     

while(1) {

int fd = socket(AF_INET6, SOCK_DGRAM, 0);
bind(fd, &server_addr, sizeof(struct sockaddr_in6));


  BIO *bio = BIO_new_dgram(fd, BIO_NOCLOSE);
  SSL *ssl = SSL_new(ctx);
  SSL_set_bio(ssl, bio, bio);

  /* Enable cookie exchange */
  SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE);

  /* Wait for incoming connections */
  while (!DTLSv1_listen(ssl, &client_addr));

  /* connect to client on different fd and complete the handshake and process data packets */

}

Thanks,

Varun

On Thu, Apr 5, 2018 at 1:03 AM, Matt Caswell <[hidden email]> wrote:

Are you able to share a simple reproducer of your problem?

Matt

On 05/04/18 02:14, Varun Kulkarni wrote:
> Hi,
>
> I was able to get DTLS work with the latest version of openssl with a
> single client and server. However, I was unable to get it to work with
> multiple clients. The first client completes the handshake and works
> well. But however the function DTLSv1_listen returns 1 immediately even
> for an application data packet (after the first client completes the
> handshake), where it should ideally return 0 and wait for the next
> client hello. Since it hangs on SSL_accept, the next client hello
> packets won't be answered.  
>
>
> The closest reference I have got is from:
> https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5. This
> doesn't seem to work for multiple clients.
>
> Any suggestions/references would be helpful in this regard. If this is
> not the right mailing list, please point me to the right one.
>
>
> --
>
>
> Thanks and Regards,
> Varun K S
>
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Matt Caswell-2]

On 05/04/18 18:53, Varun Kulkarni wrote:
> Hi Matt,
>
>
> I was able to fix the issue with the following changes. The change was
> to create new fd (bound to server address) each time DTLSv1_listen() was
> called.

There should be no need to do that. Instead, when DTLSv1_listen returns
successfully, you should create a new fd for the *client* (connected to
their address as returned from DTLSv1_listen()), and then update the SSL
object for the client to use that fd. You can reuse the old fd for the
next DTLSv1_listen call. You will need a new SSL object for the next
DTLSv1_listen() call though.

Matt

>  Previously, I used the same fd for every DTLSv1_listen call.
> The new dgram BIO was created with an old fd. On passing newly created
> fd to BIO_new_dgram, the problem seems to be resolved. However, this
> leads to another question. Why doesn't DTLS_listen queue up the
> connections similar to accept call? Does that mean DTLS can support only
> one handshake at a time? Is it recommended to create multiple fds bound
> to server address and then spawning a thread (per fd) to listen to DTLS
> requests.
>
>      
>
> while(1) {
>
> int fd = socket(AF_INET6, SOCK_DGRAM, 0);
> bind(fd, &server_addr, sizeof(struct sockaddr_in6));
>
>
>
>   BIO *bio = BIO_new_dgram(fd, BIO_NOCLOSE);
>   SSL *ssl = SSL_new(ctx);
>   SSL_set_bio(ssl, bio, bio);
>
>   /* Enable cookie exchange */
>   SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE);
>
>   /* Wait for incoming connections */
>   while (!DTLSv1_listen(ssl, &client_addr));
>
>   /* connect to client on different fd and complete the handshake and
> process data packets */
>
> }
>
>
>
>
> Thanks,
> Varun
>
>
>
> On Thu, Apr 5, 2018 at 1:03 AM, Matt Caswell <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Are you able to share a simple reproducer of your problem?
>
>     Matt
>
>     On 05/04/18 02:14, Varun Kulkarni wrote:
>     > Hi,
>     >
>     > I was able to get DTLS work with the latest version of openssl with a
>     > single client and server. However, I was unable to get it to work with
>     > multiple clients. The first client completes the handshake and works
>     > well. But however the function DTLSv1_listen returns 1 immediately
>     even
>     > for an application data packet (after the first client completes the
>     > handshake), where it should ideally return 0 and wait for the next
>     > client hello. Since it hangs on SSL_accept, the next client hello
>     > packets won't be answered.  
>     >
>     >
>     > The closest reference I have got is from:
>     > https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5
>     <https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5>. This
>     > doesn't seem to work for multiple clients.
>     >
>     > Any suggestions/references would be helpful in this regard. If this is
>     > not the right mailing list, please point me to the right one.
>     >
>     >
>     > --
>     >
>     >
>     > Thanks and Regards,
>     > Varun K S
>     >
>     >
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
>
>
> --
>
>
> Regards,
> Varun K S
>
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Varun Kulkarni]

On Thu, Apr 5, 2018 at 3:06 PM, Matt Caswell <[hidden email]> wrote:

On 05/04/18 18:53, Varun Kulkarni wrote:
> Hi Matt,
>
>
> I was able to fix the issue with the following changes. The change was
> to create new fd (bound to server address) each time DTLSv1_listen() was
> called.

There should be no need to do that. Instead, when DTLSv1_listen returns
successfully, you should create a new fd for the *client* (connected to
their address as returned from DTLSv1_listen()), and then update the SSL
object for the client to use that fd. You can reuse the old fd for the
next DTLSv1_listen call. You will need a new SSL object for the next
DTLSv1_listen() call though.

Matt

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

app packet and hangs on SSL_accept.

Here is tshark trace of the same:

    1 0.000000000    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello

    2 0.000136330    127.0.0.1 → 127.0.0.1    DTLSv1.0 90 Hello Verify Request

    3 0.000258998    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello

    4 0.999217798    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello

    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

    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

    7 1.004282757    127.0.0.1 → 127.0.0.1    DTLSv1.0 1252 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message

    8 4.313854533    127.0.0.1 → 127.0.0.1    DTLSv1.0 103 Application Data

    9 4.314110117    127.0.0.1 → 127.0.0.1    DTLSv1.0 295 Application Data   

   10 31.662557986    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello

   11 32.662344551    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello

   12 34.665481449    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello

   13 38.662321433    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello

   14 46.662998247    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello

   15 62.662816876    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello

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.

Can you clarify that at any moment of time, dtls can process only one handshake at a time. 

-Varun

  

>  Previously, I used the same fd for every DTLSv1_listen call.
> The new dgram BIO was created with an old fd. On passing newly created
> fd to BIO_new_dgram, the problem seems to be resolved. However, this
> leads to another question. Why doesn't DTLS_listen queue up the
> connections similar to accept call? Does that mean DTLS can support only
> one handshake at a time? Is it recommended to create multiple fds bound
> to server address and then spawning a thread (per fd) to listen to DTLS
> requests.
>
>      
>
> while(1) {
>
> int fd = socket(AF_INET6, SOCK_DGRAM, 0);
> bind(fd, &server_addr, sizeof(struct sockaddr_in6));
>
>
>
>   BIO *bio = BIO_new_dgram(fd, BIO_NOCLOSE);
>   SSL *ssl = SSL_new(ctx);
>   SSL_set_bio(ssl, bio, bio);
>
>   /* Enable cookie exchange */
>   SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE);
>
>   /* Wait for incoming connections */
>   while (!DTLSv1_listen(ssl, &client_addr));
>
>   /* connect to client on different fd and complete the handshake and
> process data packets */
>
> }
>
>
>
>
> Thanks,
> Varun
>
>
>
> On Thu, Apr 5, 2018 at 1:03 AM, Matt Caswell <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Are you able to share a simple reproducer of your problem?
>
>     Matt
>
>     On 05/04/18 02:14, Varun Kulkarni wrote:
>     > Hi,
>     >
>     > I was able to get DTLS work with the latest version of openssl with a
>     > single client and server. However, I was unable to get it to work with
>     > multiple clients. The first client completes the handshake and works
>     > well. But however the function DTLSv1_listen returns 1 immediately
>     even
>     > for an application data packet (after the first client completes the
>     > handshake), where it should ideally return 0 and wait for the next
>     > client hello. Since it hangs on SSL_accept, the next client hello
>     > packets won't be answered.  
>     >
>     >
>     > The closest reference I have got is from:
>     > https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5
>     <https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5>. This

>     > doesn't seem to work for multiple clients.
>     >
>     > Any suggestions/references would be helpful in this regard. If this is
>     > not the right mailing list, please point me to the right one.
>     >
>     >
>     > --
>     >
>     >
>     > Thanks and Regards,
>     > Varun K S
>     >
>     >
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
>
>
> --
>
>
> Regards,
> Varun K S
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Matt Caswell-2]

On 05/04/18 23:37, Varun Kulkarni wrote:

>
> 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
> app packet and hangs on SSL_accept.
>
> Here is tshark trace of the same:
>
>     1 0.000000000    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     2 0.000136330    127.0.0.1 → 127.0.0.1    DTLSv1.0 90 Hello Verify
> Request
>     3 0.000258998    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello
>     4 0.999217798    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello
>     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
>     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
>     7 1.004282757    127.0.0.1 → 127.0.0.1    DTLSv1.0 1252 New Session
> Ticket, Change Cipher Spec, Encrypted Handshake Message
>     8 4.313854533    127.0.0.1 → 127.0.0.1    DTLSv1.0 103 Application Data
>     9 4.314110117    127.0.0.1 → 127.0.0.1    DTLSv1.0 295 Application
> Data   
>  * 10 31.662557986    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello*
>    11 32.662344551    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    12 34.665481449    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    13 38.662321433    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    14 46.662998247    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    15 62.662816876    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>
> 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.
>
> Can you clarify that at any moment of time, dtls can process only one
> handshake at a time. 

For any single thread that is true. It is self evident that in a single
thread you can only do one thing at a time. But plenty of applications
still manage to handle multiple simultaneous clients! There are two
general ways that applications solve this problem.

1) Have one thread for DTLSv1_listen. When a client connects offload the
SSL_accept call to some other thread. In the first thread you can loop
around and call DTLSv1_listen again while, at the same time, the second
thread can process the handshake with the connected client.

or

2) Interleave processing of different clients and DTLSv1_listen within
the same thread. Usually on some event driven process (e.g. select,
poll, epoll, libevent etc). So in this case you set the underlying fd to
be non-blocking and then handle the
SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE errors than you get back from
OpenSSL (see man page for SSL_get_error).

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Varun Kulkarni]

On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <[hidden email]> wrote:

On 05/04/18 23:37, Varun Kulkarni wrote:

>
> 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
> app packet and hangs on SSL_accept.
>
> Here is tshark trace of the same:
>
>     1 0.000000000    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     2 0.000136330    127.0.0.1 → 127.0.0.1    DTLSv1.0 90 Hello Verify
> Request
>     3 0.000258998    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello
>     4 0.999217798    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello
>     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
>     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
>     7 1.004282757    127.0.0.1 → 127.0.0.1    DTLSv1.0 1252 New Session
> Ticket, Change Cipher Spec, Encrypted Handshake Message
>     8 4.313854533    127.0.0.1 → 127.0.0.1    DTLSv1.0 103 Application Data
>     9 4.314110117    127.0.0.1 → 127.0.0.1    DTLSv1.0 295 Application
> Data   
>  * 10 31.662557986    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello*
>    11 32.662344551    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    12 34.665481449    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    13 38.662321433    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    14 46.662998247    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    15 62.662816876    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>
> 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.
>
> Can you clarify that at any moment of time, dtls can process only one
> handshake at a time. 

For any single thread that is true. It is self evident that in a single
thread you can only do one thing at a time. But plenty of applications
still manage to handle multiple simultaneous clients! There are two
general ways that applications solve this problem.

1) Have one thread for DTLSv1_listen. When a client connects offload the
SSL_accept call to some other thread. In the first thread you can loop
around and call DTLSv1_listen again while, at the same time, the second
thread can process the handshake with the connected client.

>> This is what I tried to do. But it appears that DTLSV1_listen() fails to send the Hello verify request for the second client.

or

2) Interleave processing of different clients and DTLSv1_listen within
the same thread. Usually on some event driven process (e.g. select,
poll, epoll, libevent etc). So in this case you set the underlying fd to
be non-blocking and then handle the
SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE errors than you get back from
OpenSSL (see man page for SSL_get_error).

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Varun Kulkarni]

On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <[hidden email]> wrote:

On 05/04/18 23:37, Varun Kulkarni wrote:

>
> 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
> app packet and hangs on SSL_accept.
>
> Here is tshark trace of the same:
>
>     1 0.000000000    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     2 0.000136330    127.0.0.1 → 127.0.0.1    DTLSv1.0 90 Hello Verify
> Request
>     3 0.000258998    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello
>     4 0.999217798    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello
>     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
>     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
>     7 1.004282757    127.0.0.1 → 127.0.0.1    DTLSv1.0 1252 New Session
> Ticket, Change Cipher Spec, Encrypted Handshake Message
>     8 4.313854533    127.0.0.1 → 127.0.0.1    DTLSv1.0 103 Application Data
>     9 4.314110117    127.0.0.1 → 127.0.0.1    DTLSv1.0 295 Application
> Data   
>  * 10 31.662557986    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello*
>    11 32.662344551    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    12 34.665481449    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    13 38.662321433    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    14 46.662998247    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>    15 62.662816876    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>
> 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.
>
> Can you clarify that at any moment of time, dtls can process only one
> handshake at a time. 

For any single thread that is true. It is self evident that in a single
thread you can only do one thing at a time. But plenty of applications
still manage to handle multiple simultaneous clients! There are two
general ways that applications solve this problem.

1) Have one thread for DTLSv1_listen. When a client connects offload the
SSL_accept call to some other thread. In the first thread you can loop
around and call DTLSv1_listen again while, at the same time, the second
thread can process the handshake with the connected client.

 This is what I tried to do. But it appears that DTLSV1_listen() fails to send

 the Hello verify request for the second client (Refer trace above). But If I recreate the fd

 every time in the thread, it works as expected.

or

2) Interleave processing of different clients and DTLSv1_listen within
the same thread. Usually on some event driven process (e.g. select,
poll, epoll, libevent etc). So in this case you set the underlying fd to
be non-blocking and then handle the
SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE errors than you get back from
OpenSSL (see man page for SSL_get_error).

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Matt Caswell-2]

On 06/04/18 00:19, Varun Kulkarni wrote:

>
>
> On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     On 05/04/18 23:37, Varun Kulkarni wrote:
>
>     >
>     > 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
>     > app packet and hangs on SSL_accept.
>     >
>     > Here is tshark trace of the same:
>     >
>     >     1 0.000000000    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >     2 0.000136330    127.0.0.1 → 127.0.0.1    DTLSv1.0 90 Hello Verify
>     > Request
>     >     3 0.000258998    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello
>     >     4 0.999217798    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello
>     >     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
>     >     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
>     >     7 1.004282757    127.0.0.1 → 127.0.0.1    DTLSv1.0 1252 New Session
>     > Ticket, Change Cipher Spec, Encrypted Handshake Message
>     >     8 4.313854533    127.0.0.1 → 127.0.0.1    DTLSv1.0 103 Application Data
>     >     9 4.314110117    127.0.0.1 → 127.0.0.1    DTLSv1.0 295 Application
>     > Data   
>     >  * 10 31.662557986    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello*
>     >    11 32.662344551    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >    12 34.665481449    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >    13 38.662321433    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >    14 46.662998247    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >    15 62.662816876    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >
>     > 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.
>     >
>     > Can you clarify that at any moment of time, dtls can process only one
>     > handshake at a time. 
>
>     For any single thread that is true. It is self evident that in a single
>     thread you can only do one thing at a time. But plenty of applications
>     still manage to handle multiple simultaneous clients! There are two
>     general ways that applications solve this problem.
>
>     1) Have one thread for DTLSv1_listen. When a client connects offload the
>     SSL_accept call to some other thread. In the first thread you can loop
>     around and call DTLSv1_listen again while, at the same time, the second
>     thread can process the handshake with the connected client.
>
>
>  This is what I tried to do. But it appears that DTLSV1_listen() fails
> to send
>  the Hello verify request for the second client (Refer trace above). But
> If I recreate the fd
>  every time in the thread, it works as expected.

This code is quite old now and some things have moved on a bit in terms
of the OpenSSL API, but take a look at the sample code here:

https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c

This might give you some hints about how to tackle the problem.

Matt

>
>     or
>
>     2) Interleave processing of different clients and DTLSv1_listen within
>     the same thread. Usually on some event driven process (e.g. select,
>     poll, epoll, libevent etc). So in this case you set the underlying fd to
>     be non-blocking and then handle the
>     SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE errors than you get back from
>     OpenSSL (see man page for SSL_get_error).
>
>     Matt
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
>
>
> --
>
>
> Regards,
> Varun K S
>
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users