On Thu, Apr 5, 2018 at 3:06 PM, Matt Caswell <m...@openssl.org> 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 <m...@openssl.org
> > <mailto:m...@openssl.org>> 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
>
--
Regards,
Varun K S
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
