On 16/01/18 15:32, Michael Richardson wrote:
> a) when the existing FD is connect(2) any future traffic to the bound port
>    will get rejected with no port.  So the application really has to open a
>    new socket first.
>    The application can do this two ways: it can open a new socket on which to 
> receive
>    new connections, or it can open a new socket on which to communicate with
>    the new client.    The second method is better for reason (b) below.
>    Either way, it socket to communicate with the client needs to be bind(2)
>    to the address that the client used to communicate with the server, and
>    DTLSv1_listen() didn't collect or return that information.

The second way is what is intended. Maybe I misunderstand your point -
but the client address *is* returned? Admittedly its wrapped in a
BIO_ADDR, but its easy to get the underlying "raw" address using


i.e. call BIO_ADDR_rawaddress() on the BIO_ADDR returned by
DTLSv1_listen() and then do something like this:

 /* Handle client connection */
 int client_fd = socket(AF_INET6, SOCK_DGRAM, 0);
 bind(client_fd, &server_addr, sizeof(struct sockaddr_in6));
 connect(client_fd, &client_addr, sizeof(struct sockaddr_in6));
 /* Set new fd and set BIO to connected */
 BIO *cbio = SSL_get_rbio(ssl);
 BIO_set_fd(cbio, client_fd, BIO_NOCLOSE);
 BIO_ctrl(cbio, BIO_CTRL_DGRAM_SET_CONNECTED, 0, &client_addr);
 /* Finish handshake */

> b) the existing FD might have additional packets from other clients. This
>    argues for opening a new socket for the new client, and leaving the queue
>    on the existing FD.

Which is what I recommend.

> I absolutely need to have recvmsg()/sendmsg() in the bss_dgram.c in order to
> get the destination address used.   This IPv6 code is portable, since the RFC
> API says how to do it.

Why isn't recvfrom() suitable (which is what the code currently uses to
get the address)?

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

Reply via email to