From a9052bed9e485a614dd44c6ae8f8c0e84c3205df Mon Sep 17 00:00:00 2001 From: Matt Caswell Date: Fri, 5 Feb 2016 20:17:10 +0000 Subject: [PATCH] Update DTLSv1_listen documentation Make it clear that if we are unable to get hold of the peer address then *peer is cleared and the family set to AF_UNSPEC. Reviewed-by: Viktor Dukhovni --- doc/ssl/DTLSv1_listen.pod | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/doc/ssl/DTLSv1_listen.pod b/doc/ssl/DTLSv1_listen.pod index 62913de56d..741669395d 100644 --- a/doc/ssl/DTLSv1_listen.pod +++ b/doc/ssl/DTLSv1_listen.pod @@ -44,9 +44,11 @@ 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 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 handshake in a -connected state. +details of the peer that sent the ClientHello. If the underlying BIO is unable +to obtain the B of the peer (for example because the BIO does not +support this), then B<*peer> will be cleared and the family set to AF_UNSPEC. +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 and verification callbacks have been set up using -- 2.34.1