On Thu, Jul 14, 2011 at 08:18:56AM +0200, Adriaan de Jong wrote:
> > -Original Message-
> > From: Samuli Seppänen [mailto:sam...@openvpn.net]
> >
> > There's some support for challenge-response authentication in OpenVPN:
> >
> >
Am 20.01.13 19:50, schrieb Gert Doering:
> Hi,
>
> On Sun, Jan 20, 2013 at 04:49:51PM +0100, Marcel Pennewiß wrote:
>>> in time for 2.3, one of the remaining open itches for the IPv6 code
>>> is now fixed :-) (and the changes needed turned out to be fairly
>>> trivial).
>> Using
Hi,
On Tue, Mar 12, 2013 at 11:08:29AM +, Peter Caprioli wrote:
> I'll ACK the bool -> int patch, it resolves the issue in ticket 263.
Thanks for bisecting this, and for verifying that the patch indeed fixes
the original problem (besides being "obviously correct" :) ).
Committed and pushed
Hi,
On Mon, Mar 11, 2013 at 09:10:49PM +0100, Arne Schwabe wrote:
> Clang in c mode warns about these. In C++ mode these are forbidden.
I'm not so sure about this chunk of changes. I can see why you want this,
but OTOH, this is all perfectly correct C (freely converting pointers to
and from
ACK.
Your patch has been applied to the master and release/2.3 branch.
commit dc63e06b2c366f74752c8baa61b0f173d62511ad (master)
commit a8cd06ea5acc6881edd10f3e5dabdc3354decb96 (master)
Author: Arne Schwabe
List-Post: openvpn-devel@lists.sourceforge.net
Date: Mon Mar 11 21:10:51 2013 +0100
ACK.
Your patch has been applied to the master and release/2.3 branch.
commit 46d402f6513a6745daeaf08e9b260258e912f184 (master)
commit 08c3b839bf796293e938170d004392c7f1d5bf16 (release/2.3)
Author: Arne Schwabe
List-Post: openvpn-devel@lists.sourceforge.net
Date: Mon Mar 11 21:10:50 2013
ACK.
Your patch has been applied to the master and release/2.3 branch.
commit 462b6d5228660d664c3158902ee50687edf3475d (master)
commit 589ef656c8718c38bfd82717d183ee0206dabc9b (release/2.3)
Author: Arne Schwabe
List-Post: openvpn-devel@lists.sourceforge.net
Date: Mon Mar 11 21:10:48 2013
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.03.13 11:07, schrieb Gert Doering:
> Hi,
>
> On Tue, Mar 12, 2013 at 09:32:36AM +0100, Steffan Karger wrote:
>> Shouldn't the return type be size_t or at least unsigned int, as
mbuf->len is also of type unsigned int?
>
> Well, unsigned int, as
Hi,
On Tue, Mar 12, 2013 at 09:32:36AM +0100, Steffan Karger wrote:
> Shouldn't the return type be size_t or at least unsigned int, as mbuf->len is
> also of type unsigned int?
Well, unsigned int, as ->len is not a size_t.
Not that it makes any real difference as we're talking about a range
Hi,
I did some quick HMAC benchmarking on my linux box with one core of my Intel i7:
+ 300k HMAC ops/s using 1200 byte packets
+ 700k HMAC ops/s using 100 byte packets
+ 840k HMAC ops/s using 10 byte packets
This is clearly fast enough for use cases like ours where a few tens of
customer sites
Hi,
Shouldn't the return type be size_t or at least unsigned int, as mbuf->len is
also of type unsigned int?
-Steffan
-Original Message-
From: Arne Schwabe [mailto:a...@rfc2549.org]
Sent: maandag 11 maart 2013 22:35
To: g...@greenie.muc.de; openvpn-devel@lists.sourceforge.net
Subject:
11 matches
Mail list logo
