Am 07.06.2016 um 15:47 schrieb Илья Шипицин:
> Hello,
>
> I played with valgrind a bit
>
> https://travis-ci.org/chipitsine/openvpn/jobs/135869065
>
> Looks like there are leaks in openssl code, should we suppress it?
Not that I've found the "leaks" you're reporting; however:
I seem to recall
Take upstream release from https://github.com/Cyan4973/lz4/releases,
copy lz4-r131/lib/lz4.c to src/compat/compat-lz4.c
copy lz4-r131/lib/lz4.h to src/compat/compat-lz4.h
change #include line in compat-lz4.c to use "compat-lz4.h" not "lz4.h"
No other changes to upstream code.
This commit is quite
Pushes AES-256-GCM when a connection client advertises IV_NCP=2, and
supports serving connections to clients with different data channel
cipher configuration simultaneously.
v2:
* Update manpage
* Add Changes.rst entry
Signed-off-by: Steffan Karger
---
Changes.rst | 11 ++
Add --ncp-disable to completely disable cipher negotiation, and
--ncp-ciphers to specify which ciphers to accept from the server.
v2:
* fix --disable-crypto builds
* use register_signal() instead of operating directly on c->sig
* add man-page entry for new options
Signed-off-by: Steffan Karger
ACK. Easy to review :-) - Arne just beat me to it.
Your patch has been applied to the master branch.
commit d92718141287a0f9adcffec5c2fa7d76213162cc
Author: Steffan Karger
List-Post: openvpn-devel@lists.sourceforge.net
Date: Wed Jun 8 14:20:40 2016 +0200
cleanup: remove alloc_buffers arg
Another ACK from me.
I'm not sure I understand all the intricacies of our buffer/frame handling
and *why* there is always enough "capacity" present, but since we're never
reading more bytes than we have capacity, this is definitely *safe*.
Obviously the old code never requested more bytes tha
Based on the 'IV_NCP=2' mechanism described in
http://permalink.gmane.org/gmane.network.openvpn.devel/9385.
This is the first patch of a set that adds support for cipher negotiation.
Follow-up patches will add ways to restrict or disable the mechanism, and
add server-side support.
v2:
* Account
On Wed, Jun 8, 2016 at 6:47 PM, Selva Nair wrote:
> But, in general, its better to use register signal for setting signals
> inside the context struct. That is, when all that one has is a pointer to a
> context which could be in a multi_instance, or the top context of the server
> or a the context
Hi,
> I see daily builds like
>
>
>
> http://build.openvpn.net/downloads/snapshots/openvpn-install-master-20160607214911-63b3e000c9-x86_64.exe
>
>
> I used to think they are built with "build-snapshot":
> https://github.com/OpenVPN/openvpn-build/blob/master/windows-nsis/build-snapshot
>
> however
On Wed, Jun 8, 2016 at 12:11 PM, Steffan Karger wrote:
> Sure, please tell me what to use. I never had to deal with our
> signals before, so I simply copied this from a few lines below, where
> (as far as I could see) the did what I wanted it to do.
>
> I had already replaced this with
>
>th
On 08/06/16 17:19, Steffan Karger wrote:
On Wed, Jun 8, 2016 at 6:13 PM, debbie10t wrote:
First downloaded the wrong repo .. Not sure what I did wrong .. nvm
Second: This is where my git foo falls down .. tried:
$ git clone https://github.com/syzzer/openvpn/tree/nego-squashed
Cloning into 'n
On Wed, Jun 8, 2016 at 6:13 PM, debbie10t wrote:
> First downloaded the wrong repo .. Not sure what I did wrong .. nvm
>
> Second: This is where my git foo falls down .. tried:
> $ git clone https://github.com/syzzer/openvpn/tree/nego-squashed
> Cloning into 'nego-squashed'...
> fatal: repository
On 08/06/16 16:45, Arne Schwabe wrote:
On 08.06.2016 17:09, debbie10t wrote:
Hi
On 08/06/16 13:32, Steffan Karger wrote:
On Wed, Jun 8, 2016 at 2:20 PM, Steffan Karger wrote:
Please test and provide comments. I ran the 'make check' test suite, including
t_client tests, and performed manua
On Wed, Jun 8, 2016 at 5:53 PM, Selva Nair wrote:
> On Wed, Jun 8, 2016 at 8:20 AM, Steffan Karger wrote:
>>
>> --- a/src/openvpn/push.c
>> +++ b/src/openvpn/push.c
>> @@ -239,11 +239,21 @@ incoming_push_message (struct context *c, const
>> struct buffer *buffer)
>> {
>>c->options.pu
On Wed, Jun 8, 2016 at 8:20 AM, Steffan Karger wrote:
> --- a/src/openvpn/push.c
> +++ b/src/openvpn/push.c
> @@ -239,11 +239,21 @@ incoming_push_message (struct context *c, const
> struct buffer *buffer)
> {
>c->options.push_option_types_found |= option_types_found;
>
> + /* de
On 08.06.2016 17:09, debbie10t wrote:
> Hi
>
> On 08/06/16 13:32, Steffan Karger wrote:
>> On Wed, Jun 8, 2016 at 2:20 PM, Steffan Karger wrote:
>>> Please test and provide comments. I ran the 'make check' test suite,
>>> including
>>> t_client tests, and performed manual testing. But, as Gert
Hi
On 08/06/16 13:32, Steffan Karger wrote:
On Wed, Jun 8, 2016 at 2:20 PM, Steffan Karger wrote:
Please test and provide comments. I ran the 'make check' test suite, including
t_client tests, and performed manual testing. But, as Gert eloquently puts it,
this is likely to 'break stuff in in
On Wed, Jun 8, 2016 at 4:23 PM, Arne Schwabe wrote:
>
>> +#ifdef ENABLE_CRYPTO
>> + if (c->options.pull)
>> +{
>> + /* If we use --pull, we don't know the crypto overhead yet. */
>> + msg (M_WARN, "*** Account for max crypto overhead ***");
>
> That message will surely confuse users
> +#ifdef ENABLE_CRYPTO
> + if (c->options.pull)
> +{
> + /* If we use --pull, we don't know the crypto overhead yet. */
> + msg (M_WARN, "*** Account for max crypto overhead ***");
That message will surely confuse users.
Arne
Am 08.06.16 um 14:20 schrieb Steffan Karger:
> multi_top_init() is always called with alloc_buffers=true, so just remove
> the argument and alloc unconditionally.
>
> Si
ACK. This is one is easy!
Arne
Am 08.06.16 um 14:20 schrieb Steffan Karger:
> "Be conservative in what you send, be liberal in what you accept"
>
> When receiving packets, the real limitation of how much data we can accept
> is the size of our internal buffers, not the maximum size we expect
> incoming packets to have.
>
> I r
Hello,
I see daily builds like
http://build.openvpn.net/downloads/snapshots/openvpn-install-master-20160607214911-63b3e000c9-x86_64.exe
I used to think they are built with "build-snapshot":
https://github.com/OpenVPN/openvpn-build/blob/master/windows-nsis/build-snapshot
however, when I run it
On Wed, Jun 8, 2016 at 2:20 PM, Steffan Karger wrote:
> Please test and provide comments. I ran the 'make check' test suite,
> including
> t_client tests, and performed manual testing. But, as Gert eloquently puts
> it,
> this is likely to 'break stuff in interesting ways', so more testing (an
Pushes AES-256-GCM when a connection client advertises IV_NCP=2, and
supports serving connections to clients with different data channel
cipher configuration simultaneously.
Signed-off-by: Steffan Karger
---
src/openvpn/init.c | 5 +++--
src/openvpn/push.c | 27 +
Add --ncp-disable to completely disable cipher negotiation, and
--ncp-ciphers to specify which ciphers to accept from the server.
Signed-off-by: Steffan Karger
---
src/openvpn/init.c | 34 --
src/openvpn/init.h | 4 ++--
src/openvpn/openvpn.h| 3
Based on the 'IV_NCP=2' mechanism described in
http://permalink.gmane.org/gmane.network.openvpn.devel/9385.
This is the first patch of a set that adds support for cipher negatiation.
Follow-up patches will add ways to restrict or disable the mechanism, and
add server-side support.
Signed-off-by:
multi_top_init() is always called with alloc_buffers=true, so just remove
the argument and alloc unconditionally.
Signed-off-by: Steffan Karger
---
src/openvpn/mtcp.c | 2 +-
src/openvpn/mudp.c | 2 +-
src/openvpn/multi.c | 6 ++
src/openvpn/multi.h | 2 +-
4 files changed, 5 insertions(+)
"Be conservative in what you send, be liberal in what you accept"
When receiving packets, the real limitation of how much data we can accept
is the size of our internal buffers, not the maximum size we expect
incoming packets to have.
I ran into this while working on cipher negotiation, which wil
Hi,
The following five patches add support for cipher negotiation, according to
the 'IV_NCP=2' mechanism as described in
http://permalink.gmane.org/gmane.network.openvpn.devel/9385.
Please test and provide comments. I ran the 'make check' test suite, including
t_client tests, and performed manua
29 matches
Mail list logo
