From patchwork Thu Jan 4 01:07:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steffan Karger X-Patchwork-Id: 167 Return-Path: Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director4.mail.ord1d.rsapps.net ([172.30.191.6]) by backend31.mail.ord1d.rsapps.net (Dovecot) with LMTP id m7SwArI7TloTJQAAgoeIoA for ; Thu, 04 Jan 2018 09:35:30 -0500 Received: from proxy2.mail.ord1d.rsapps.net ([172.30.191.6]) by director4.mail.ord1d.rsapps.net (Dovecot) with LMTP id c9SQArI7TlrhRAAAHDmxtw ; Thu, 04 Jan 2018 09:35:30 -0500 Received: from smtp32.gate.ord1c ([172.30.191.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy2.mail.ord1d.rsapps.net (Dovecot) with LMTP id OH0qArI7TloJIgAAfawv4w ; Thu, 04 Jan 2018 09:35:30 -0500 X-Spam-Threshold: 95 X-Spam-Score: 0 X-Spam-Flag: NO Authentication-Results: smtp32.gate.ord1c.rsapps.net x-tls.subject="/OU=Domain Control Validated/CN=www.neomailbox.net"; auth=pass (cipher=DHE-RSA-AES256-GCM-SHA384) X-Virus-Scanned: OK X-Orig-To: patchwork@openvpn.net X-Originating-Ip: [5.148.176.60] Authentication-Results: smtp32.gate.ord1c.rsapps.net; iprev=pass policy.iprev="5.148.176.60"; spf=permerror smtp.mailfrom="a@unstable.cc" smtp.helo="s2.neomailbox.net"; dkim=fail (signature verification failed) header.d=sourceforge.net; dkim=fail (signature verification failed) header.d=sf.net; dmarc=none (p=nil; dis=none) header.from=fox-it.com X-Classification-ID: 820a4876-f15c-11e7-9c42-842b2b572c6a-1-1 Received: from [5.148.176.60] ([5.148.176.60:2351] helo=s2.neomailbox.net) by smtp32.gate.ord1c.rsapps.net (envelope-from ) (ecelerity 4.2.1.56364 r(Core:4.2.1.14)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384 subject="/OU=Domain Control Validated/CN=www.neomailbox.net") id 5C/3A-14149-1BB3E4A5; Thu, 04 Jan 2018 09:35:29 -0500 Resent-From: Antonio Quartulli Resent-To: patchwork@openvpn.net Resent-Date: Thu, 4 Jan 2018 22:34:24 +0800 Resent-Message-ID: <558e5e55-2c56-356b-dae4-d03c58436cd4@unstable.cc> Resent-User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:MIME-Version:Message-ID:Date:Subject: CC:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=tgRP2bxoX+5w02BJHqgmK6iOa28AhLriMYGIrNo5TIs=; b=FoGwD9tduA/ReZ9oMVXXCBBzEg yz6DjTt9TlKlf1rYFl95vZ7gzfzmfdhA6JTecPR6PMgfO8vGfKr+yr8zeys7e9x13NNJvPZqtFCFn 7CpN2q4gzcP7r0FwOYWbi7MHnh048d0i0X2xq1+mCH9NbQjqxXOi7K11DrY3JrN43f6A=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:MIME-Version:Message-ID:Date:Subject:CC:To:From:Sender: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=tgRP2bxoX+5w02BJHqgmK6iOa28AhLriMYGIrNo5TIs=; b=I mPGwsU0c84Oj2cHldxKXMaeyMAVW1sbbV4nByPIaMcfjXcOFcovK0Im8PKxdYNFLg/ms385PWTr/n hcl8C4XB9TjUGBRGZkX56NpYRIJyQrppkmvbLqxEapWbfPBb62dmyyh8QU3a49GlWWQd6pW7HQIe7 MPcsi5q+1td/HFpg=; From: Steffan Karger To: Date: Thu, 4 Jan 2018 13:07:50 +0100 Message-ID: <1515067670-13094-1-git-send-email-steffan.karger@fox-it.com> MIME-Version: 1.0 X-ClientProxiedBy: FOXDFT52.FOX.local (10.0.0.129) To FOXDFT52.FOX.local (10.0.0.129) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1eX4Jv-0004El-QI Subject: [Openvpn-devel] [PATCH] Check for more data in control channel X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-SA-Score: -4.8 X-getmail-retrieved-from-mailbox: Inbox 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 Acked-by: David Sommerseth --- src/openvpn/ssl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c index 7b42845..15a37a3 100644 --- a/src/openvpn/ssl.c +++ b/src/openvpn/ssl.c @@ -2935,6 +2935,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; } }