Check for more data in control channel

If control channel packets arrive quickly after each other, or out of
order, there might be more data available than we can read in one
tls_process() call.  If that happened, and no further control channel
packet arrived (e.g. because the last two packets arrived out-of-order),
we would wait for 16 second ("coarse timer") before we would read the
remaining data.  To avoid that, always schedule ourself again if there
was control channel data, to check whether more data is available.

For mbedtls, we could implement a slightly more elegant "is there more
data?" function, instead of blindly rescheduling.  But I can't find a way
to implement that for OpenSSL, and the current solution is very simple and
still has quite low overhead.

Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1515067670-13094-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16151.html
Signed-off-by: David Sommerseth <davids@openvpn.net>

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index d758c31a2c38cf9ee73757f446d1fa7b8fad4c41..669f941b37863549dc163c47c9567e27f2975ecf 100644 (file)
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -2942,6 +2942,9 @@ tls_process(struct tls_multi *multi,
             {
                 state_change = true;
                 dmsg(D_TLS_DEBUG, "TLS -> Incoming Plaintext");
+
+                /* More data may be available, wake up again asap to check. */
+                *wakeup = 0;
             }
         }