[PATCH 5/8] secur32: Add support for setting DTLS timeouts.

[Hans Leidekker]

On Tue, 2022-01-25 at 19:24 -0500, Connor McAdams wrote:
> On Tue, Jan 25, 2022 at 10:32:11AM -0500, Connor McAdams wrote:
> > Add support for setting the DTLS timeout values, and set the
> > retransmission timeout value to 0 to allow for retransmission on each
> > call to schan_InitializeSecurityContext.
> 
> All patches prior to this one are good, but this one and beyond will
> break things. Maybe this is the universe's way of telling me to send
> smaller patch sets. ;)
> 
> Essentially, the issue seems to be that we need to go back to
> non-blocking mode with gnutls on DTLS contexts. We behave in a
> non-blocking manner to begin with, seeing as we return immediately from
> the pull_timeout callback. If we don't do this, it takes all sorts of
> effort to work around it, and make it not get into a weird state when no
> data is received. If it isn't in non-blocking mode, it doesn't seem to
> complete a handshake if retransmission is involved.
> 
> Is there any good reason we switched away from GNUTLS_NONBLOCK in the
> first place? If so, I can try to work around it. But from my testing,
> having it enabled doesn't seem to cause issues. But maybe I'm missing
> something.

GnuTLS blocking mode corresponds to the blocking behavior of the underlying
transport (sockets, usually). We don't own the socket, so we can't pull data or
know what mode is used by the client. In that sense the GnuTLS blocking mode is
irrelevant; we always need to return to the caller immediately. If GnuTLS needs
to be in non-blocking mode to handle retransmission correctly then we could
switch back I guess.