From 468f043ece0e7e262ee6166ae6ec1f7683d82220 Mon Sep 17 00:00:00 2001 From: Matt Caswell Date: Wed, 23 Sep 2015 12:40:09 +0100 Subject: [PATCH] Clarify DTLSv1_listen documentation Clarify that user code is required to allocate sufficient space for the addressing scheme in use in the call to DTLSv1_listen. Reviewed-by: Andy Polyakov --- doc/ssl/DTLSv1_listen.pod | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/doc/ssl/DTLSv1_listen.pod b/doc/ssl/DTLSv1_listen.pod index 7a8f080625..d5f5a525ca 100644 --- a/doc/ssl/DTLSv1_listen.pod +++ b/doc/ssl/DTLSv1_listen.pod @@ -44,8 +44,12 @@ When a ClientHello is received that contains a cookie that has been verified, then DTLSv1_listen() will return with the B parameter updated into a state where the handshake can be continued by a call to (for example) SSL_accept(). Additionally the B location pointed to by B will be -filled in with details of the peer that sent the ClientHello. Typically user -code is expected to "connect" the underlying socket to the peer and continue the +filled in with details of the peer that sent the ClientHello. It is the calling +code's responsibility to ensure that the B location is sufficiently large +to accommodate the addressing scheme in use. For example this might be done by +allocating space for a struct sockaddr_storage and casting the pointer to it to +a struct sockaddr * for the call to DTLSv1_listen(). Typically user code is +expected to "connect" the underlying socket to the peer and continue the handshake in a connected state. Prior to calling DTLSv1_listen() user code must ensure that cookie generation -- 2.40.0