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 <d...@users.sourceforge.net> Acked-by: Peter Stuge <pe...@stuge.se>

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

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 wher

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?

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 of t

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

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] [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 <g@free.fr> Acked-by: Peter Stuge <pe...@stuge.se>

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

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

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

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

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 =

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] [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] Removed hardcoded signtool dependency from win/build_all.py

IGNTOOL 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 <pe...@stuge.se>

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: > >> 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 >

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

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

tions.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 <pe...@stuge.se>

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

Re: [Openvpn-devel] HTTP Host header

st another community member, but I think the patch is correct. Thanks! Acked-by: Peter Stuge <pe...@stuge.se> 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

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

> > Signed-off-by: David Sommerseth <d...@users.sourceforge.net> Acked-by: Peter Stuge <pe...@stuge.se>

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

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] 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

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

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. >

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. >

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

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] [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!

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] 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 (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

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

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

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

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

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

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 #

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] 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

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] 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

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

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

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] [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 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

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

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

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

Re: [Openvpn-devel] Summary of the "OpenVPN development model" meeting

David Sommerseth wrote: > For those of us not being heavily involved in development processes > from day-to-day, we can probably survive with whatever VCS is being > used. Fair enough. But I think two git features in particular matter also in the casual patcher case. It's very nice that git keeps

Re: [Openvpn-devel] OpenVPN core development processes?

Gert Doering wrote: > The nice thing about git is that people can very easily do > "experimental branches" in their own repository, giving access to > testers, without having to have write access to SVN. Agree, but the hosting issue aside this is possible also from an SVN repo thanks to the git

Re: [Openvpn-devel] Crosscompile OpenVPN 2.1.1

Eike Lohmann wrote: > checking for lzo1x_1_15_compress in -llzo... no > configure: error: LZO headers were found but LZO library was not found .. > What exactly is missing and how to build it? Look in config.log for the exact error from the configure test. It would help to also post it here.

Re: [Openvpn-devel] RFE: allow 'lport 0' setup for random port binding

Let's try some more. Karl O. Pinc wrote: > > no; it is because the OpenVPN client creates the same src + dst pair > > for every connection. > > Enrico is right. It's in the IP RFC, the 2MSL (twice the maximum > segment lifetime) rule. (STD 5 is the right rfc?) I agree that the statement about

Re: [Openvpn-devel] Summary of the "OpenVPN development model" meeting

Samuli Seppänen wrote: > Most other tasks are dependent on the setup of the community site. > A somewhat realistic estimate for finishing them is 1-2 months. Let me know (maybe off-list) if you want some hints on setting up Trac with git support. Trac is nice because it offers both tickets and a