Hi,
On Thu, Nov 07, 2019 at 02:42:17PM +0200, Lev Stipakov wrote:
> > I'm a bit unhappy with that one, as it changes behaviour for all
> > non-windows
> > builds (including all the openssl build output even if it succeeds).
>
> The only place it changes behavior is this
>
> install:
>- if
We could introduce a master.c file which would include:
#include "argv.c"
#include "auth_token.c"
#include "base64.c"
#include "block_dns.c"
#include "buffer.c"
.
.
.
#include "status.c"
#include "tls_crypt.c"
#include "tun.c"
#include "win32.c"
And then have Makefile.ac and MSVC
From: Lev Stipakov
Wintun requires ring buffers registration to be
performed by privileged process. In order to use
openvpn with wintun by non-Administrator, we
need to use interactive service and shared memory
to register buffers.
Openvpn process creates memory mapping object and event
for
From: Lev Stipakov
Signed-off-by: Lev Stipakov
---
src/compat/compat.vcxproj | 12 ++--
src/openvpn/openvpn.vcxproj | 12 ++--
src/openvpnmsica/openvpnmsica.vcxproj | 14 +++---
src/openvpnserv/openvpnserv.vcxproj | 12 ++--
From: Lev Stipakov
With tap-windows6 we clear adapter settings with DHCP,
but since wintun doesn't do DHCP we do it with netsh.
Signed-off-by: Lev Stipakov
---
src/openvpn/tun.c | 79 +++
1 file changed, 50 insertions(+), 29 deletions(-)
From: Lev Stipakov
To open wintun device, we cannot use "\\.\Global\Wintun"
path as before. To get device path which we supply to CreateFile,
we have to use SetupAPI to:
- enumerate network adapters with "wintun" as component id
- for each adapter save its guid
- open device information set
From: Lev Stipakov
Implemented according to Wintun documentation
and reference client code.
Wintun uses ring buffers to communicate between
kernel driver and user process. Client allocates
send and receive ring buffers, creates events
and passes it to kernel driver under LocalSystem
privileges.
From: Lev Stipakov
This allows to specify which tun driver openvpn should use,
tap-windows6 (default) or wintun.
Note than wintun support will be added in follow-up patches.
Signed-off-by: Lev Stipakov
---
src/openvpn/init.c| 7 +++
src/openvpn/options.c | 37
This set of patches adds support of wintun kernel driver
(https://www.wintun.net) to OpenVPN Windows client and server.
While wintun is in beta (currently used version is 0.7), it performs
significantly faster comparison to tap-windows6.
Below are download bandwidth stats reported by iperf3
From: Lev Stipakov
Since Wintun doesn't do DHCP, use interactive service
calls to set up adapter properties.
This also fixes bug in previously unused IPv4 code of
do_address_service():
- ipv4 address must be in network byte order
- prefix length cannot be hardcoded /32 but
must be
Hi,
On Thu, Nov 07, 2019 at 07:28:36PM +0100, Lev Stipakov wrote:
> With VS2019 you cannot build for XP, you would need to install build tools
> from VS2017 for that.
>
> On the other hand, we do not build releases with VS, so it should not be an
> issue.
Not sure right now about 2.4, but for
With VS2019 you cannot build for XP, you would need to install build tools
from VS2017 for that.
On the other hand, we do not build releases with VS, so it should not be an
issue.
to 7. marrask. 2019 klo 18.52 Илья Шипицин kirjoitti:
>
>
> чт, 7 нояб. 2019 г. в 22:49, Lev Stipakov :
>
>>
чт, 7 нояб. 2019 г. в 22:49, Lev Stipakov :
> From: Lev Stipakov
>
> Signed-off-by: Lev Stipakov
> ---
> src/compat/compat.vcxproj | 12 ++--
> src/openvpn/openvpn.vcxproj | 12 ++--
> src/openvpnmsica/openvpnmsica.vcxproj | 14 +++---
>
Last version of openvpn for xp/Vista is 2.3, so dropping support for it in the
build system is a no brainer to me.
JM2CW,
JJK
Gert Doering wrote:
>Hi,
>
>On Thu, Nov 07, 2019 at 07:28:36PM +0100, Lev Stipakov wrote:
>> With VS2019 you cannot build for XP, you would need to install build
hello,
https://docs.travis-ci.com/user/multi-cpu-architectures
we can switch some builds to arm64. any suggestions ?
Cheers,
Ilya Shipitsin
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
Hi,
> I'm a bit unhappy with that one, as it changes behaviour for all
> non-windows
> builds (including all the openssl build output even if it succeeds).
>
The only place it changes behavior is this
install:
- if [ ! -z "${CHOST}" ]; then unset CC; fi
- - .travis/build-deps.sh >
Hi,
On 07/11/2019 12:42, Lev Stipakov wrote:
Hi,
I'm a bit unhappy with that one, as it changes behaviour for all
non-windows
builds (including all the openssl build output even if it succeeds).
The only place it changes behavior is this
install:
- if [ ! -z "${CHOST}" ]; then
Acked-by: Lev Stipakov
to 7. marrask. 2019 klo 15.30 Simon Rozman (si...@rozman.si) kirjoitti:
> This upgrades 99f28081477ca325a14b13c38abec2c9b619eb01 to support MSVC
> building.
>
> Signed-off-by: Simon Rozman
> ---
> src/openvpn/openvpn.vcxproj | 2 ++
>
This broke (again) Visual Studio build:
> error LNK2019: unresolved external symbol vlan_process_outgoing_tun
referenced in function multi_process_outgoing_tun
Can we please ack and merge this patch
https://patchwork.openvpn.net/patch/868/ to catch these things earlier?
ke 6. marrask. 2019 klo
Thanks!
Your patch has been applied to the master branch.
commit 2b11e57c02b2d21e384a2fc860fea1209f55
Author: Simon Rozman
Date: Thu Nov 7 14:29:01 2019 +0100
msvc: Add vlan.c/h
Signed-off-by: Simon Rozman
Acked-by: Lev Stipakov
Message-Id:
Hi
On Thu, Nov 7, 2019 at 7:43 AM Lev Stipakov wrote:
> Hi,
>
>
>> I'm a bit unhappy with that one, as it changes behaviour for all
>> non-windows
>> builds (including all the openssl build output even if it succeeds).
>>
>
> The only place it changes behavior is this
>
> install:
>- if [
Hi,
On Thu, Nov 07, 2019 at 02:18:25PM +0200, Lev Stipakov wrote:
> This broke (again) Visual Studio build:
>
> > error LNK2019: unresolved external symbol vlan_process_outgoing_tun
> referenced in function multi_process_outgoing_tun
Can you please send a patch that adds vlan.c to the list of
Hi,
On 07/11/2019 14:36, Simon Rozman wrote:
> I revoke this “master.c” idea. It makes incremental compiling ridiculously
> slow. It might work for production builds, but definitely not for development.
It also breaks scoping of variables/function. So, I am glad you found
your own reason to
I revoke this “master.c” idea. It makes incremental compiling ridiculously
slow. It might work for production builds, but definitely not for development.
Best regards,
Simon
From: Simon Rozman [mailto:si...@rozman.si]
Sent: Thursday, November 7, 2019 2:06 PM
To: 'Lev Stipakov' ; 'Gert
This upgrades 99f28081477ca325a14b13c38abec2c9b619eb01 to support MSVC
building.
Signed-off-by: Simon Rozman
---
src/openvpn/openvpn.vcxproj | 2 ++
src/openvpn/openvpn.vcxproj.filters | 6 ++
2 files changed, 8 insertions(+)
diff --git a/src/openvpn/openvpn.vcxproj
Acked-by: Gert Doering
Your patch has been applied to the master branch.
Stared at the code, did quite a bit of testing, found interesting effects.
What this patch does is "client-to-client isolation according to pvid"
(so if you have clients with "vlan-pvid 200" in their ccd/ file, and
other
Acked-by: Gert Doering
Stared at code, and ran the full t_client/t_server test suite, but
mostly for completeness. Since we do not have tagged packets yet
(with the appropriate ether type), this code does not change anything.
Again, only TAP code paths are touched.
Your patch has been applied
From: Lev Stipakov
Signed-off-by: Lev Stipakov
---
v2; do not unconditionally print dependencies build output for non-Windows
builds
.travis.yml | 9 -
.travis/build-check.sh| 5 +
.travis/build-deps.sh | 9 +
.travis/run-build-deps.sh | 10
Hi,
It's lots of text that is totally uninteresting if it succeeds, but that
> you need to scroll over when looking for the reason why a build fails -
> which is the reason why it is the way it is today.
>
I have sent v2 which doesn't change the behavior for non-Windows builds.
If you volunteer
29 matches
Mail list logo
