Re: [Openvpn-devel] +++ route.c 2011-05-18 09:15:17.000000000 +0200

David Sommerseth wrote: > Please do a git commit -s to your local git tree (you have all rights to do > so, its all on your own computer) then do 'git format-patch HEAD~1' and > send the 0001-whatever-comes-here.patch via git send-email. git send-email HEAD~1 # is shorthand for that //Peter

Re: [Openvpn-devel] [PATCH] Improve the mysprintf() issue in openvpnserv.c

David Sommerseth wrote: > Signed-off-by: David Sommerseth Acked-by: Peter Stuge

Re: [Openvpn-devel] [PATCH v2] Change the default --tmp-dir path to a more suitable path

David Sommerseth wrote: > In commit 4e1cc5f6dda22e9 the create_temp_filename() function was > reviewed and hardened, which in the end renamed this function to > create_temp_file() in commit 495e3cec5d156. > > With these changes it became more evident that OpenVPN needs a directory > where it can c

Re: [Openvpn-devel] [PATCH] Change the default --tmp-dir path to a more suitable path

Alon Bar-Lev wrote: > I really think you should remove this from compile time (autoconf). It > is useless, users can override it anyway in configuration, so there is > no need for this. And users can also set the environment variable to point to where they want. Agree, please remove from autoconf.

Re: [Openvpn-devel] [PATCH] Bind only to specified interface

Federico Heinz wrote: > * some other people agree that there is a use case, but propose > different ways of approaching the problem through various > mechanisms to resolve the interface name to an IP address before > passing it on to OpenVPN. The disagreement here seems to be in >

Re: [Openvpn-devel] [PATCH] Bind only to specified interface

Gert Doering wrote: > On Sun, Mar 13, 2011 at 05:04:21PM +0100, Peter Stuge wrote: > > Was this for PPP? Sorry then, I completely overlooked that! I'm > > fortunate to not have to deal with many PPP links now, but I have, > > and pppd of course /etc/ppp/ip-up and -down

Re: [Openvpn-devel] [PATCH] Bind only to specified interface

Gert Doering wrote: > > Changing startup scripts or wrapping openvpn is one way. But I would > > probably drive everything from the DHCP client instead. > > udhcp can notify components if the IP address of a PPP(!) interface > changes? > > "No DHCP involved on PPP links". Was this for PPP? Sorry

Re: [Openvpn-devel] [PATCH] Bind only to specified interface

Peter Stuge wrote: > Your /usr/share/udhcpc/default.script to accomplish this would be: > > #!/bin/sh > test "$1" = bound || exit 0 > sed -i "/^local /s/.*/local $ip/" /etc/openvpn/something/local.conf > /etc/init.d/openvpn.something restart > > >

Re: [Openvpn-devel] [PATCH] Bind only to specified interface

Peter Stuge wrote: > Changing startup scripts or wrapping openvpn is one way. But I > would probably drive everything from the DHCP client instead. > > As I wrote, udhcpc is very very easy to deal with. Your /usr/share/udhcpc/default.script to accomplish this would be: #!/bin

Re: [Openvpn-devel] [PATCH] Bind only to specified interface

Federico Heinz wrote: > > > Because I don't know it at configuration time. > > > > You said that you already have a solution in place for dealing > > with interface reconfiguration. > > I said I have a solution in place to restart OpenVPN when the > configuration changes. I understand. So there

Re: [Openvpn-devel] [PATCH] Bind only to specified interface

Federico Heinz wrote: > On 12/03/2011, Peter Stuge wrote: > > Federico Heinz wrote: > > > What I'm trying to solve here is a much simpler (and, in my case, > > > frequent) use case: I'm starting several instances of OpenVPN, > > > and I need each

Re: [Openvpn-devel] [PATCH] Bind only to specified interface

Federico Heinz wrote: > What I'm trying to solve here is a much simpler (and, in my case, > frequent) use case: I'm starting several instances of OpenVPN, and I > need each of them to listen on specific interfaces, but their dyndns > addresses may not be up-to date yet, so I can specify neither an

Re: [Openvpn-devel] [PATCH] Bind only to specified interface

Joe Patterson wrote: > I'm actually kind of curious what reasons there would be that > listening to 0.0.0.0 would be undesireable. .. > if you want to have different configurations bound to different > interfaces, Exactly. > while I could possibly see having one configuration for Internet > user

Re: [Openvpn-devel] [PATCH] Bind only to specified interface

Federico Heinz wrote: > The reason I looked into this in the first place was that, unlike > those TCP-based protocols, I couldn't get OpenVPN to work on a > firewall with two external IP addresses without running two deamons, > each one bound to one interface only. It is then that I stumbled upon >

Re: [Openvpn-devel] sctp in openvpn

Olivier Van Acker wrote: > I might start with Linux first since, as you rightly point out, > more people can use/test it. I'd be happy to test it too. //Peter

Re: [Openvpn-devel] [PATCH 1/1] Fix warning: format not a string literal and no format arguments

Gilles Espinasse wrote: > Seen with gcc-4.4.5 and -Wformat -Wformat-security > > Signed-off-by: Gilles Espinasse Acked-by: Peter Stuge

Re: [Openvpn-devel] OpenVPN 2.2-rc Windows installer ready

Gert Doering wrote: > On Fri, Feb 11, 2011 at 10:41:55AM +0200, Samuli Seppänen wrote: > > The older TAP driver probably works fine for the 2.2 branch. However, it > > won't work properly in 2.3, which will contain IPv6 support. > > It will just not do IPv6, but the code in tun.c checks for this,

Re: [Openvpn-devel] [PATCH] Changed snprintf to _snprintf in service-win32/openvpnserv.c

Samuli Seppänen wrote: > +++ b/service-win32/openvpnserv.c > @@ -86,7 +86,7 @@ static HANDLE exit_event = NULL; > /* snprintf with guaranteed null termination */ > #define mysnprintf(out, ...) \ > { \ > - snprintf (out, sizeof(out), __VA_ARGS__); \ > + _snprintf (out,

Re: [Openvpn-devel] Can *plugin* kill specific ovpn tunnel?...

Vineet Kumar wrote: > You mean closing the telnet session after every use so that whoever > the next guy is gets served? No I mean creating an intermediary that will know about your use case and provide an interface that works. > say, an interactive telnet session Are they a requirement in your

Re: [Openvpn-devel] Can *plugin* kill specific ovpn tunnel?...

Vineet Kumar wrote: > Are there ways around that : making telnet accept multiple sessions? You could serialize your administrative requests somehow and only ever have one entity use the admin interface. //Peter

Re: [Openvpn-devel] [Patch] OpenVPN PolarSSL Support Preview [7/8]

Matthias Andree wrote: > > Having the branch in git allows iterating over the commits with > > great ease. > > let's not waste time discussing this over and over I'm sorry I wasted your time. //Peter

Re: [Openvpn-devel] [Patch] OpenVPN PolarSSL Support Preview [7/8]

Adriaan de Jong wrote: > > I'd use git for the patches right away anyway, > > I'm afraid that we started off development based on checked out > sources (quite a long time ago). I'll start rebasing to git as soon > as I've heard that the git tree is stable. By git I don't mean the very latest cont

Re: [Openvpn-devel] [Patch] OpenVPN PolarSSL Support Preview [7/8]

Adriaan de Jong wrote: > > > About the whitespace: it's a tad difficult to split the patches > > > now. Are you sure it wouldn't be acceptable this way? I may have misunderstood this. (I read "now" as "this late", but I guess maybe you meant "this early".) > > I'd suggest that we primarily do co

Re: [Openvpn-devel] [Patch] OpenVPN PolarSSL Support Preview [7/8]

Adriaan de Jong wrote: > Thanks, I'll change the configure options when I rebase the patches > to 2.2 . I'm a little more familiar with cmake, thanks for pointing > that out. Great. > About the whitespace: it's a tad difficult to split the patches now. Simple with git. Check out how to do an in

Re: [Openvpn-devel] [Patch] OpenVPN PolarSSL Support Preview [7/8]

Adriaan de Jong wrote: Content-Description: 07_polarssl_addition.patch.gz > Add PolarSSL support to OpenVPN > +++ b/configure.acWed Dec 08 12:35:42 2010 +0100 > @@ -273,14 +273,16 @@ > ) > > AC_ARG_WITH([ssl-type], > - [ --with-ssl-type=TYPE Build with the given SSL library, TYPE = ope

Re: [Openvpn-devel] [Patch] OpenVPN OpenSSL Crypto Separation Preview [2/8]

Adriaan de Jong wrote: Content-Description: 02_openssl_crypto_separation.patch.gz > Separate OpenSSL specific code > > diff -r 228dee8676bf Makefile.am > --- a/Makefile.am Wed Aug 11 14:37:00 2010 +0200 > +++ b/Makefile.am Wed Dec 08 11:49:46 2010 +0100 > @@ -74,18 +74,18 @@ > INSTAL

Re: [Openvpn-devel] how to limite the bandwidth of every client ?

hmy wrote: > I use openvpn in server mode. more than 100 clients to connect it > . I want limit every client's bandwidth ? how to do it ? Suggest on networking layer in the operating system. //Peter

Re: [Openvpn-devel] script-security 1

David Sommerseth wrote: > a so called NETLINK API .. > isn't too easy to work with Maybe libnl can help. //Peter

Re: [Openvpn-devel] [PATCH] Removed hardcoded signtool dependency from win/build_all.py

> SignTool module is installed. If not, the build is interrupted. > --- > win/build_all.py | 45 +++-- > 1 files changed, 43 insertions(+), 2 deletions(-) Acked-by: Peter Stuge

Re: [Openvpn-devel] [PATCH] Removed hardcoded signtool dependency from win/build_all.py

Samuli Seppänen wrote: > here's the next version of the patch; Functionally fine! > def main(config): > + > +# Do a signed build by default > +unsignedBuild=False Maybe name the option signedBuild instead? :) > +# Check if the SignTool module is present. This avoids ImportErrors

Re: [Openvpn-devel] [PATCH 1/6] Use stricter snprintf() formatting in socks_username_password_auth()

Gert Doering wrote: > > - snprintf (to_send, sizeof (to_send), "\x01%c%s%c%s", > > strlen(creds.username), > > -creds.username, strlen(creds.password), creds.password); > > + snprintf (to_send, sizeof (to_send), "\x01%c%s%c%s", (int) > > strlen(creds.username) & 0xff, > > +

Re: [Openvpn-devel] [PATCH 0/6] GNU C compiler warning clean-up

ded > Removed functions not being used anywhere > Merged add_bypass_address() and add_host_route_if_nonlocal() Acked-by: Peter Stuge

Re: [Openvpn-devel] [PATCH] Removed hardcoded signtool dependency from win/build_all.py

OL variable could then > be used to just locate signtool.exe and nothing else. This would make it > behave the same way as most other variables in "settings.in" and allow > making signed and unsigned builds using the same configuration file. Acked-by: Peter Stuge

Re: [Openvpn-devel] [PATCH] Removed hardcoded signtool dependency from win/build_all.py

Samuli Seppänen wrote: > What if build_all.py did this: > > - Check if SIGNTOOL is enabled in settings.in: > - Yes: fail if can't import "sign" module > - No: don't fail if can't import "sign" module This also sounds good. (Who typically creates settings.in? Is one in git?) //Peter

Re: [Openvpn-devel] [PATCH] Removed hardcoded signtool dependency from win/build_all.py

David Sommerseth wrote: > >> So if you don't have a signing key/tool available, it is still > >> possible to build the rest of OpenVPN. > > > > Fine, but this is not really acceptable when James&co builds OpenVPN, > > so I am requesting a solution that allows them to specify to the > > build proce

Re: [Openvpn-devel] [PATCH] Removed hardcoded signtool dependency from win/build_all.py

David Sommerseth wrote: > >> Modified win/build_all.py so that build does not fail even if > >> the optional signtool python class is not available. > > > > What is it needed for? Is it really *always* optional? > > If I've understood it correctly, this is related to signing the Windows > TUN/TAP

Re: [Openvpn-devel] [PATCH] Removed hardcoded signtool dependency from win/build_all.py

Samuli Seppänen wrote: > From 57b983dc2a1f4a31d3b7c0e2f6de7f778d234b2e Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Samuli=20Sepp=C3=A4nen?= > Date: Fri, 12 Nov 2010 17:32:19 +0200 > Subject: [PATCH] Removed hardcoded signtool dependency from win/build_all.py > > Modified win/build_all.py so that b

Re: [Openvpn-devel] [PATCH] Added check for variable CONFIGURE_DEFINES into options.c

; The file containing CONFIGURE_DEFINES variable, configure.h, is not present if > openvpn is built using the Python + Visual C -based buildsystem. This causes > the > build to fail. This patch adds a check to see if variable exists before trying > to use it. Acked-by: Peter Stuge

Re: [Openvpn-devel] Architecture diagram & Theory of Operation documents

Jan Just Keijser wrote: > PS I am not directly involved in the development of openvpn :) Actually I think you are! Because you have at the very least contributed information about bugs that you have encountered, which might not have been discovered otherwise. Writing code is not the only way to p

Re: [Openvpn-devel] Architecture diagram & Theory of Operation documents

john s wolter wrote: > When it comes to debugging problems inside OpenVPN and other FOSS > software there is a lack of design information. I disagree that this is relevant for debugging. > Architecture diagram & Theory of Operation documents are a minimum > starting point for those not directly

Re: [Openvpn-devel] HTTP Host header

Lars Hupel wrote: > When thinking about it, the Host header doesn't make any sense to me. It was added to support virtual hosting in a time (20? years ago) when the domain name wasn't included anywhere in the request, but used only for client-side IP-adress lookup. Back then it was a reasonable as

Re: [Openvpn-devel] HTTP Host header

h is acceptable for you. I'm just another community member, but I think the patch is correct. Thanks! Acked-by: Peter Stuge pgpqMNObQRJv_.pgp Description: PGP signature

Re: [Openvpn-devel] HTTP/1.1 Host header

Lars Hupel wrote: > I would suggest to always send the Host header (even when HTTP/1.0 > is selected). I strongly support this. Please watch out for HTTP/1.1, if a client claims to support 1.1 then servers can respond e.g. with chunked transfer coding, which certainly isn't supported by 1.0 client

Re: [Openvpn-devel] [PATCH] Fixed compiler warnings reported on Ubuntu 10.04

t; Signed-off-by: David Sommerseth Acked-by: Peter Stuge

Re: [Openvpn-devel] Windows build was messed up!

Toby Thain wrote: > > So we have stuff for VC6, VS2005, VS2008, DDK/WDK, MinGW and Cygwin. :) > > I consider diversity of working build environments a net benefit to > the project. It's another useful axis of portability and helps rub > off non-portable burrs. I see your point and I agree in part

Re: [Openvpn-devel] Windows build was messed up!

Alon Bar-Lev wrote: > The whole build environment of openvpn is malformed, using two > separate build systems for windows and posix, Only two? Oh that's nothing. We're having lots of fun with build systems in libusb-1.0, where each contributing Windows developer actually requires a separate build

Re: [Openvpn-devel] Compiling OpenVPN for Windows

Allan Swanepoel wrote: > I have a small customization that I make to the openvpn sourcecode to > call external software on initialization, and would like to build a > Windows build with this in. Maybe your Linux distribution offers a simple way to install a cross-compiler. Find out which host tupl

Re: [Openvpn-devel] Summary of the IRC meeting (26th Aug 2010)

Gert Doering wrote: > > > Did some testing to see if creating a static binary would be > > > trivial. As it was not, > > > > Why wasn't it? Please share details from the testing. > > Naively just calling "gcc -static" led to linker failures due to > OpenSSL not being found. > > This was a "can w

Re: [Openvpn-devel] Summary of the IRC meeting (26th Aug 2010)

Alon Bar-Lev wrote: > I am not sure ELF is capable of mixing static/dynamic in same module. > I had this problem in several cases, at the end, dynamic glibc was > used. I'm not sure what the problem would be. I think a static binary should be able to dlopen a .so fine at least if it the .so doesn

Re: [Openvpn-devel] Summary of the IRC meeting (26th Aug 2010)

Alon Bar-Lev wrote: > > > Did some testing to see if creating a static binary would be > > > trivial. As it was not, > > > > Why wasn't it? Please share details from the testing. > > I guess the modules, pkcs11 and other components that uses dlopen > should be disabled in openvpn. Well, as a firs

Re: [Openvpn-devel] Summary of the IRC meeting (26th Aug 2010)

Samuli Seppänen wrote: > Discussed the "Some way of supporting static compilation" issue: > > > > Did some testing to see if creating a static binary would be > trivial. As it was not, Why wasn't it? Please share details from the testing. > dec

Re: [Openvpn-devel] Summary of the IRC meeting (19th Aug 2010)

Gert Doering wrote: > The app is cross-compileable today - but to make that work requires that > all relevant Windows APIs are exported in mingw headers *and libraries*. Sure. You emphasize libraries, but MinGW is not so much a library as it is a wrapper for the standard runtime from MS. > Wind

Re: [Openvpn-devel] Summary of the IRC meeting (19th Aug 2010)

Samuli Seppänen wrote: > converting the OpenVPN build system (on Windows) to depend only on > python, Visual Studio Professional and DDK. The original build > system required bash and various other UNIX tools. James' mentioned argument for prefering Visual Studio, namely that MinGW may not have al

Re: [Openvpn-devel] features

Alex T wrote: > - some kind of route / firewall manipulation for the Windows client. Try: push "ip-win32 dynamic" push "redirect-gateway def1" //Peter

Re: [Openvpn-devel] [RFC] - (ticket #29) - Fix for --push-reset resetting --topology and --route-gateway

David Sommerseth wrote: > 1) Adding a new configure option which "unpush" chosen elements > 2) Add a new immutable option list for PUSH_REPLY > 3) Add a flag to the PUSH_REPLY list indicating if it is immutable .. > Does anyone see another solution which is better? Or which > suggestion do you con

Re: [Openvpn-devel] [PATCH] Choose a different field in X509 to be username

Emilien Mantel wrote: > See attached a very small patch (based on allmerged tree) to fix "sizeof". Acked-by: Peter Stuge

Re: [Openvpn-devel] [Openvpn-users] Is it possible to access Windows XP shares over port 445?

Jan Just Keijser wrote: > > So XP is refusing port 445 connections from OpenVPN adapter. > > Maybe someone on the -devel list (CC'ed) knows more about the > interaction between the tap-win32 adapter and the rest of the > windows os? This reminds me of my experience with pushing a DNS server addre

Re: [Openvpn-devel] [PATCH] Choose a different field in X509 to be username

David Sommerseth wrote: > > 3) "sizeof(common_name)" is useless... Line 745: char > > common_name[TLS_USERNAME_LEN]; we can use directly TLS_USERNAME_LEN. > > Thanks a lot for the patch and all rework done. (Also: thank you to all > reviewers!) > > The third and last patch looks very good! I've

Re: [Openvpn-devel] [Openvpn-users] FW: Patch submission - git crash course ?

Samuli Seppänen wrote: > git clone > # do your changes > # then git to create and mail a patch to -devel chantra wrote: > # do changes > $ git diff > my_patch Please make sure to always create commits in your repo before sending a patch. Once you have made a commit it is easy to generate a pat

Re: [Openvpn-devel] PATCH: remove bashisms from easy-rsa

Matthias Andree wrote: > I'm not sure currently if Solaris /bin/sh likes $(...) notation or > insists on `...` `` is the only portable way. //Peter pgpbnpSJnBkbG.pgp Description: PGP signature

Re: [Openvpn-devel] PATCH: remove bashisms from easy-rsa

David Sommerseth wrote: > I'd rather keep the current bashism which works on all platforms > where bash is available than to apply a patch which will break > the script from working on one of the supported platforms. Agree. //Peter

Re: [Openvpn-devel] bug: can't get dhcp using --up option

niv...@gmail.com wrote: > I want to report this bug: Can you help debug it? Add instrumentation to that script, or maybe to a new script, and see what is different about the interface when script is being run outside openvpn. //Peter

Re: [Openvpn-devel] Summary of the IRC meeting (20th May 2010)

David Sommerseth wrote: > You can argue that it's a company specific change and that the software > is not distributed - but the employees in that company do get this > software somehow - most often as verbatim copy, and these employees can > then internally request the source code according to the

Re: [Openvpn-devel] Summary of the IRC meeting (13th May 2010)

Samuli Seppänen wrote: > Here's the summary of the previous community meeting. Thanks for sending it out! > user-space network stack > packet bus Look into vde > right -- if you had an openvpn core with only producer/consumer > modules That would be vdeswitch > crazy kinds of transport p

Re: [Openvpn-devel] Building the TAP drivers from source and then signing them (possible?)

Jon Onstott wrote: > I would like to go ahead and compile and sign the TAP drivers > myself. Does anyone know which certificate would be best to > purchase? There was some discussion about this on the libusb mailinglist just the other day. It seems there may be a good deal to be had with VeriSign

Re: [Openvpn-devel] [PULL-REQUEST v3] VLAN-Tagging

Fabian Knittel wrote: > I've attached a diff containing all changes introduced by the > current patch-set. Thanks for doing this. It makes review so much easier. > +++ b/configure.ac > @@ -212,6 +212,12 @@ AC_ARG_ENABLE(selinux, > [SELINUX="yes"] > ) > > +AC_ARG_ENABLE(vlan-tagging, > +

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

Karl O. Pinc wrote: > IMO OpenVPN is encouraging bad practices by supplying packages for > distros that include OpenVPN. Ideally the package for that distro as made by OpenVPN is always equivalent to the one made by the distributor. What do I mean? I mean that I'm happy with .spec files and the l

Re: [Openvpn-devel] [PATCH] Serial number export, fixed

Davide Brini wrote: > The users are supposed to adapt it to their needs and make it more > robust. Hah! Users will not. //Peter

Re: [Openvpn-devel] Unpackaged Windows binaries (Was: Re: [Openvpn-users] [ANN] OS X packages - OpenVPN 2.1.1)

Karl O. Pinc wrote: > the project is already releasing unpackaged Linux > binaries Really? > and it now talking about doing the same for OS/X binaries. Recently discussed work for contrib/ produces a .dmg, very much a package in my view. > There's clear utility. I guess it depends. I'm not s

Re: [Openvpn-devel] [PATCH] revocation

Davide Brini wrote: > the serial number is just an (almost) arbitrarily large number. Why > would a CA choose such a serial number? In order to avoid a chosen-prefix collision that works among other things by predicting the serial number of certificates generated by the CA. http://www.win.tue.nl/

Re: [Openvpn-devel] Finnish translation of OpenVPN-GUI for review

Samuli Seppänen wrote: > Btw. this translation file format is by far the most difficult one > I've ever worked with. Probably because it isn't a translation file format at all. :) This is the file format used by the Windows Resource Compiler to turn "resources" such as dialogs or files into objec

Re: [Openvpn-devel] [PATCH 4/9] vlan: Prepend and remove VLAN identifiers on outgoing and incoming frames

Jan Just Keijser wrote: > FYI: 802.1Q defines VLAN 1 as the 'native' LAN: all packets on VLAN 1 > are *by definition* not encapsulated (according to my CCNA guide ;-)) 802.1Q != CCNA.. Look at the spec, Table 9-2 on page 86. (100 in PDF) VID Use 0 "no VLAN identifier is present in the frame"

Re: [Openvpn-devel] [PATCH 3/9] vlan: Add per-client --vlan-tag option

Hi Fabian, Fabian Knittel wrote: > >> +#define OPENVPN_8021Q_MAX_VID 0xFFFE > > > > The max VID in 802.1q is 4095 = 0xfff. > > You are absolutely correct. Thanks for catching that. I intended > it to say 0xFFE, because the standard talks about VID values being > valid within the range 0 throug

Re: [Openvpn-devel] [RFC][PATCH 0/9] VLAN tagging on TAP devices in OpenVPN server mode

David Sommerseth wrote: > I'll admit I don't understand too much how the VLAN's really work in > core network code. There's a prefix, and a wrapper to create virtual interfaces. And there's the vconfig tool to do configuration. NIC drivers need to support oversize frames. vconfig add eth0 4 # VL

Re: [Openvpn-devel] [PATCH 4/9] vlan: Prepend and remove VLAN identifiers on outgoing and incoming frames

Fabian Knittel wrote: > + if (ntohs (vlanhdr.tpid) != OPENVPN_ETH_P_8021Q) > +{ > + /* Drop untagged frames */ > + goto err; > +} It would be nice to be able to use VID 0 to mean untagged packets. //Peter

Re: [Openvpn-devel] [PATCH 3/9] vlan: Add per-client --vlan-tag option

Fabian Knittel wrote: > + if (options->vlan_tag < OPENVPN_8021Q_MIN_VID || options->vlan_tag > > OPENVPN_8021Q_MAX_VID) .. > +#define OPENVPN_8021Q_MIN_VID 1 This looks like --vlan-tag 0 will not work. > +#define OPENVPN_8021Q_MAX_VID 0xFFFE The max VID in 802.1q is 4095 = 0xfff. //Pet

Re: [Openvpn-devel] Linux tun/tap performance issues

David Sommerseth wrote: > if you have a "test script" Then git bisect could be used to find the one kernel commit that changed the behavior. //Peter

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

David Sommerseth wrote: > > Nothing should patch the autotools generated files, just the > > autotools source files. Right? > > Correct, that was my mistake. I initially meant autotools source > files. As Alon pointed out it would be less intrusive to patch the files that were generated by auto

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

Karl O. Pinc wrote: > And, to reiterate, applying patches within an rpm > spec file is normal, expected, and part of the > rpm design so a certain level of "development" is supported. Should also not be a problem, since those patches are likely to start from a known release tarball, so autoconf st

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

Peter Stuge wrote: > RHEL4.6 can easily build a release that was prepared using the most > recent autoconf. In fact, I would suggest that using the newest autotools when creating the package makes it *more* likely to build effortlessly on older systems. //Peter

Re: [Openvpn-devel] [PATCH] On TARGET_LINUX define _GNU_SOURCE if not defined

David Sommerseth wrote: > it's a requirement to be able to build OpenVPN on RHEL4.6. As Alon explained, building is not the problem. autotools are used when preparing git source for build. This is done for every release, so that there is a ready-made configure script included in the tarball. When

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

Karl O. Pinc wrote: > I'm not at all sure it solves the core issues, which is that > an already running dhcp client won't have auto-detected > the tap interface that OpenVPN creates -- iff OpenVPN is > started after the dhcp client. Note that several DHCP clients only handle one interface per DHC

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

Karl O. Pinc wrote: > The boot order that makes sense to me is: > > bring the interfaces up > start dhcp client (if not triggered directly from the interfaces) > start openvpn > > The problem is that if the dhcp client is started before openvpn > and openvpn is creating the tap interface then it'

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

Karl O. Pinc wrote: > > I know of at least four DHCP clients and I avoid dhclient as much as > > possible. It would be a tremendous mistake to tie OpenVPN to any one > > DHCP client IMO. > > Only D is tied to dhclient. A, B, and C, work fine with any dhcp > client daemon. (Or A does anyway, B an

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

Karl O. Pinc wrote: > > I'm hoping that we can make "route-gateway dhcp" work on Unix > > platforms as well. I'm thinking there are two possible ways we > > could do this: Network interface configuration is highly distribution specific. > A) dhclient > > B) dhclient.conf > > C) dhclient > >

Re: [Openvpn-devel] Linux tun/tap performance issues

James Yonan wrote: > all of the CPU-intensive cryptographic operations are being done in > user space. Could some kind of crypto acceleration of OpenSSL be in play? //Peter

Re: [Openvpn-devel] [PATCH] IPv6 support for TUN/TAP driver on windows

Gert Doering wrote: > -!define PRODUCT_TAP_RELDATE "06/22/2009" > +!define PRODUCT_TAP_RELDATE "07/03/2010" Seems month/date are swapped. //Peter

Re: [Openvpn-devel] Openvpn 2.1.1 bad tcp performance but good pingwhen -l 1472 (with packet size = MTU)

booyakasha wrote: > We are using Windows XP / Vista. Could you try using the same configuration also on other systems? Linux, BSD, etc. I would be interested in knowing if this problem is only seen on Windows. //Peter

Re: [Openvpn-devel] [PATCH] enhance tls-verify possibility

Karl O. Pinc wrote: > > > + "--tls-export-cert [directory] : Get peer cert in PEM format and > > There is no man page. It's in sample-scripts/. It's a new option, right? //Peter

Re: [Openvpn-devel] [PATCH] enhance tls-verify possibility

David Sommerseth wrote: > +++ b/options.c > @@ -529,6 +529,9 @@ static const char usage_message[] = >" tests of certification. cmd should return 0 to allow\n" >" TLS handshake to proceed, or 1 to fail. (cmd is\n" >" executed as 'cmd c

Re: [Openvpn-devel] Gentoo Git-Live-Ebuild

David Sommerseth wrote: > And thank you for getting this into Gentoo! I agree! And I want to plug Gentoo's overlay system as well, it's really a fantastic way to allow system customization. Write ebuilds, commit to any public repo, write a simple .xml file and then layman can be used on any Gento

Re: [Openvpn-devel] segfault issue

mark wrote: > -sys.log: issue-- > .. error 6 in libc-2.10.1.so[b7ef5000+16a000] > .. error 6 in bash[8048000+d4000] David Sommerseth wrote: > Would you mind installing the openvpn-debug package and then run > openvpn via gdb? Since the crash is in libc and bash I don't know if openvpn-deb

Re: [Openvpn-devel] [PATCH v2] Do not randomize resolving of IP addresses in getaddr()

Karl O. Pinc wrote: > Someone may be relying on the behavior but, at the moment > or depending on present dns circumstances, does not have > multiple A records returned. In this case no warning will > be generated. The flip side of that coin is also valid I think. Consider independent configurat

Re: [Openvpn-devel] [PATCH] make ipv6_payload compile under windowze ( feat_ipv6_payload branch )

Gert Doering wrote: > I'll try to figure out how to setup a cross-compile environment > during next week, Some Linux distributions have premade mingw packages. In Gentoo building a toolchain for mingw is as simple as: emerge crossdev && crossdev -t i686-mingw32 On other distributions you might

Re: [Openvpn-devel] -devel version numbering

David Sommerseth wrote: > I believe there are som better ways to catch the last commit ID, git rev-list HEAD -1 //Peter

Re: [Openvpn-devel] New development process ready

David Sommerseth wrote: > I need a place where to put this openvpn-testing tree. If you send me a public SSH key and prefered username I'll set up a repo on git.stuge.se, currently hosting libusb and libssh2 development besides some of my own projects. //Peter

Re: [Openvpn-devel] Summary of the IRC meeting (4th Feb 2010)

Samuli Seppänen wrote: > http://www.secure-computing.net/wiki/index.php/OpenVPN/IRC_meetings I really appreciated getting the major points via email from the first meeting! The forced-attachment download from SF archive is not so nice for me. //Peter

Re: [Openvpn-devel] Summary of the IRC meeting (28th Jan 2010)

Samuli Seppänen wrote: > > OpenID > > I'm somewhat familiar with OpenID but I need to take another look > at it. SF.net supports it, so the same OpenID could be used for the > SF.net "openvpn" project (should we make use of it) as well as the > community site Trac instance. SF can be an OpenID pr

Re: [Openvpn-devel] Summary of the IRC meeting (28th Jan 2010)

Karl O. Pinc wrote: > > I do not feel the forums and mailing list need to be synchronized. > > They are two different mediums, and should be treated as such. > > I disagree. I would also like to unify forums and mailing lists, for purely egotistical reasons - I really dislike the web. My idea fo

Re: [Openvpn-devel] Summary of the IRC meeting (28th Jan 2010)

Samuli Seppänen wrote: > Decided to start with a single Trac-based site for the whole > community rather than have separate user/developer sites. I think this is a good way to get some content going, even if it turns out that the solution is inadequate sometime in the future. > Discussed communi

  1   2   >