Re: [Openvpn-devel] [PATCH] windows: do not use X_OK as it is unsupported

No, The alternate way is for people to go into github and start comment inline. Did you ever tried to use github interface? You see nice formatted patches and can comment on each line. After we see we stabilize we send the lng patches to the mailing list. Trust me it won't be

Re: [Openvpn-devel] [PATCH] windows: do not use X_OK as it is unsupported

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/02/12 23:47, Alon Bar-Lev wrote: > Please start go over my patches in github[1] and mark your comments, > this way we know if it was a total waste of time. > > Alon. > > [1] https://github.com/alonbl/openvpn Alon, If you want to have the

Re: [Openvpn-devel] [PATCH] windows: do not use X_OK as it is unsupported

On Tue, Feb 21, 2012 at 12:39 AM, David Sommerseth wrote: > But remember that all your patches *will* go through review as for > everyone else in the community.  That means either *1)* patch reviews on > the mailing list, or *2)* reviewed through a sprint review in

Re: [Openvpn-devel] [PATCH] windows: do not use X_OK as it is unsupported

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/02/12 20:35, Alon Bar-Lev wrote: > David, > > Again, This has nothing to do with POSIX. mingw *DOES* define this > constant in *WINDOWS*. You seem to ignore the fact that mingw provides an access() function which *behaves* like the rest of the

Re: [Openvpn-devel] [PATCH] windows: do not use X_OK as it is unsupported

Hi, On Mon, Feb 20, 2012 at 10:44:31PM +0200, Alon Bar-Lev wrote: > It still touches the same places... > > The difference is the usage: > --- > R_OK|PLATFORM_X_OK > --- > or: > --- > PLATFORM_MODE_MASK(R_OK | X_OK) > --- Nah, that's not the way it should be. Given that we currently use X_OK

Re: [Openvpn-devel] [PATCH] windows: do not use X_OK as it is unsupported

Hi, On Mon, Feb 20, 2012 at 09:47:25PM +0200, Alon Bar-Lev wrote: > Another option is to use X_OK and declare a macro > PLATFORM_MASK_MODE(m)... whatever you think more readable. This is something I would like better, as it localizes the change to one place. gert -- USENET is *not* the

Re: [Openvpn-devel] [PATCH] windows: do not use X_OK as it is unsupported

Another option is to use X_OK and declare a macro PLATFORM_MASK_MODE(m)... whatever you think more readable. On Mon, Feb 20, 2012 at 9:35 PM, Alon Bar-Lev wrote: > David, > > Again, > This has nothing to do with POSIX. > mingw *DOES* define this constant in *WINDOWS*. > >

Re: [Openvpn-devel] [PATCH] windows: do not use X_OK as it is unsupported

David, Again, This has nothing to do with POSIX. mingw *DOES* define this constant in *WINDOWS*. We do not want to have a different constants (and different values) at the MSVC and mingw build. Build should be consistent when possible, but not override environment SDK. Anyway, If this will not

Re: [Openvpn-devel] Better use ip -batch on adding/removing server pushed routes on Linux

Hi, On Tue, Feb 21, 2012 at 12:00:37AM +0800, Yang Zhe wrote: > It's quite slow to add thousands of routes via execve thousands times. > It's better writing the parameters to a pipe to `ip -batch -` on > linux. Well, my VPNs have far less routes ("tens" instead of "thousands"), and exec()'ing

Re: [Openvpn-devel] Better use ip -batch on adding/removing server pushed routes on Linux

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/02/12 17:15, Heiko Hund wrote: > On Monday 20 February 2012 16:00:37 Yang Zhe wrote: >> It's quite slow to add thousands of routes via execve thousands >> times. It's better writing the parameters to a pipe to `ip -batch -` >> on linux. > > I

Re: [Openvpn-devel] Better use ip -batch on adding/removing server pushed routes on Linux

On Monday 20 February 2012 16:00:37 Yang Zhe wrote: > It's quite slow to add thousands of routes via execve thousands times. > It's better writing the parameters to a pipe to `ip -batch -` on > linux. I would even go as far as saying that it would make sense to get rid of the forking completely

[Openvpn-devel] Better use ip -batch on adding/removing server pushed routes on Linux

Hi, It's quite slow to add thousands of routes via execve thousands times. It's better writing the parameters to a pipe to `ip -batch -` on linux. -- Sincerely,     Yang Zhe

[Openvpn-devel] [PATCH] windows: do not use X_OK as it is unsupported

Reported by Heiko Hund. Reference [1]. Replaces 4ebc587eab73e03ef64d344a5707d84e7f8d875a [1] http://msdn.microsoft.com/en-us/library/1w06ktdy%28v=vs.100%29.aspx Signed-off-by: Alon Bar-Lev --- options.c | 38 ++

Re: [Openvpn-devel] [PATCH] define access mode flag X_OK as 0 on Windows

On Mon, Feb 20, 2012 at 4:22 PM, Heiko Hund wrote: > Defining them makes code more readable, but without X_OK being 0 on Windows > openvpn crashes. See my commit message again and read the MSDN page about > _access at

Re: [Openvpn-devel] [PATCH] define access mode flag X_OK as 0 on Windows

On Monday 20 February 2012 13:44:54 Alon Bar-Lev wrote: > This X_OK is standard define. That's true for unixoid systems, but none of the [FWRX]_OK #defines exist in the MS C runtime headers. > It exists in mingw as 1. Yeah, but only for legacy glue code reasons. From io.h: 8<-

Re: [Openvpn-devel] [PATCH] define access mode flag X_OK as 0 on Windows

Big NAK. This X_OK is standard define. It exists in mingw as 1. OpenVPN should not check execute if unsupported by OS, not changing standard constants. Heiko, Where exactly is the problem? When directories are checked or script? Correct patch would be to have a macro for execute ok in option.c

[Openvpn-devel] [CRASH] on master /packet_id.c::packet_id_debug_print

Hi, Master with verb 255 I get the following after a few packets... Can someone else try out to see if it reproduced? tls-client tls-cipher DHE-RSA-AES256-SHA cipher AES-256-CBC Server DH 4096bit Server certificate 2048bit Client certificate 2048bit Mon Feb 20 14:53:58 2012 us=139424

Re: [Openvpn-devel] [DEVELOPER REQUESTED] Repackage TAP-Win32

2012/2/20 Samuli Seppänen > > Here are the tasks to perform: > > 1. Create a GIT repository of the master TAP-Win32 sources with all > > history, to ease our work, please use github. > Any thoughts of this anyone? Personally, I don't care where the source > code lives. It

Re: [Openvpn-devel] [PATCH] Revamp check_file_access() checks in stdin scenarios

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/02/12 10:37, David Sommerseth wrote: > It was discovered that --management also can take stdin as argument > instead of a file. Enabled this by revamping the check_file_access() > flags by adding CHKACC_ACPTSTDIN. Setting this flag will then

Re: [Openvpn-devel] [PATCH] define access mode flag X_OK as 0 on Windows

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/02/12 20:44, Heiko Hund wrote: > The _access and _waccess functions in Windows don't know about X_OK > (1). If you pass an uneven mode flag the C runtime's default invalid > parameter handler ends execution of openvpn. > > Signed-off-by: Heiko

Re: [Openvpn-devel] [PATCH] Revamp check_file_access() checks in stdin scenarios

Hi, On Mon, Feb 20, 2012 at 10:37:05AM +0100, David Sommerseth wrote: > It was discovered that --management also can take stdin as argument > instead of a file. Enabled this by revamping the check_file_access() > flags by adding CHKACC_ACPTSTDIN. Setting this flag will then consider > filenames

[Openvpn-devel] [PATCH] Revamp check_file_access() checks in stdin scenarios

It was discovered that --management also can take stdin as argument instead of a file. Enabled this by revamping the check_file_access() flags by adding CHKACC_ACPTSTDIN. Setting this flag will then consider filenames as 'stdin' as always present. The other place where 'stdin' was accepted is

Re: [Openvpn-devel] [DEVELOPER REQUESTED] Repackage TAP-Win32

Hi Alon, > Hello, > > We have a go to rewrite the OpenvPN build system. > I started to work at core product [1]. > > As part of the re-write we split out the TAP-Win32 out of OpenVPN code base. > > To make things go faster we may try to parallelize the effort. > > Here are the tasks to perform: >

Re: [Openvpn-devel] [DEVELOPER REQUESTED] Repackage TAP-Win32

>> > >> > But for now, I'd like to see more focus on the steps before the >> > packaging >> > method. We first need to have something to package. > Makes sense. > > Regardless... > > You might try my old patch that produces a tarball of MS binaries, > found here: > >