Re: [Openvpn-devel] OpenVPN-mbedTLS depends on mbedTLS debug module - safe to remove?

Hi, On Sun, Jun 12, 2016 at 08:57:49PM +0200, Steffan Karger wrote: > Right, of course. Sorry - too tired today. That would be #ifdef > MBEDTLS_DEBUG_C, and totally makes sense. I'll send a patch. commit b63f98633dbe2ca92cd43fc6f8597ab283a600bf Author: Steffan Karger List-Post: openvpn-devel@l

[Openvpn-devel] [PATCH applied] Re: mbedtls: don't set debug threshold if compiled without MBEDTLS_DEBUG_C

ACK. An easy one for a change :-) Your patch has been applied to the master branch. commit b63f98633dbe2ca92cd43fc6f8597ab283a600bf Author: Steffan Karger List-Post: openvpn-devel@lists.sourceforge.net Date: Tue Jun 14 22:00:03 2016 +0200 mbedtls: don't set debug threshold if compiled wi

[Openvpn-devel] [PATCH] mbedtls: don't set debug threshold if compiled without MBEDTLS_DEBUG_C

For targets with space constraints, one might want to compile mbed TLS without MBEDTLS_DEBUG_C defined, to save some tens of kilobytes. Make sure OpenVPN still compiles if that is the case. Signed-off-by: Steffan Karger --- src/openvpn/ssl_mbedtls.c | 2 ++ 1 file changed, 2 insertions(+) diff

Re: [Openvpn-devel] [PATCH] Promptly close the netcmd_semaphore handle after use

Hi, On Mon, Jun 13, 2016 at 10:34:49PM -0400, Selva Nair wrote: > @@ -759,6 +762,8 @@ void > netcmd_semaphore_release (void) > { >semaphore_release (&netcmd_semaphore); > + /* netcmd_semaphore has max count of 1 - safe to close after release */ > + semaphore_close (&netcmd_semaphore); > }

[Openvpn-devel] Summary of the IRC meeting on 13th June 2016

Hi, Here's the summary of today's IRC meeting. --- COMMUNITY MEETING Place: #openvpn-meeting on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Monday 13th June 2016 Time: 20:00 CEST (18:00 UTC) Planned meeting topics for this meeting were here:

[Openvpn-devel] [PATCH] Promptly close the netcmd_semaphore handle after use

If more than one openvpn processes are running and one aborts without releasing the semaphore, subsequent processes fail to get a lock for the semaphore. This may be avoided by not keeping open handles to the semaphore so that Windows can destroy it when no open handles remain. See also: http://ar