openvpn-devel Mailing List for OpenVPN

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, We need some help here to figure out why we get much more build errors when compiling the new 'master' branch (checkout of commit b70d99fb617350). The issues can be found here: <http://build.openvpn.net/buildlog.txt> What has happened since the v2.2.0 builds and master is basically merging in feat_ipv6_payload and feat_ipv6_transport branches, in addition to syncing up with the latest changes from James' SVN 2.1 branch. In total there are 137 commits differentiating the v2.2.0 and master branch. I've just sent a patch for review which fixes the openvpn-plugin.h warnings [1]. But there are plentiful of other things to fix as well. Samuli has tried to use git bisect to isolate the commit, and it can look like commit 49a945eafea2c [2] might cause some of these issues. But it's not enough to confirm if it solves everything. I'm Cc'ing JuanJo Ciarlante as he is the author of that commit. If anyone have some good ideas or insight, please share! :) kind regards, David Sommerseth [1] <http://thread.gmane.org/gmane.network.openvpn.devel/4629> [2] <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn.git;a=commitdiff;h=49a945eafea2c64dbaa5cb2ecdfd4ca9a82aa26e> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEUEARECAAYFAk26qWYACgkQDC186MBRfrpjHwCfcPc3EcinjQMUkQTWEBD8L+Ta Qm4Al1479RV2vwEpJO/FMQlA+x5XAyY= =Uzez -----END PGP SIGNATURE----- 

Microsoft Visual Studio complains about const char const **ptr declarations and expects them to be be const char ** const ptr. The latter is what was the intention, that neither the pointer nor the value(s) it points at can be changed. Signed-off-by: David Sommerseth <da...@re...> --- openvpn-plugin.h | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/openvpn-plugin.h b/openvpn-plugin.h index 5c82daf..24aa36c 100644 --- a/openvpn-plugin.h +++ b/openvpn-plugin.h @@ -203,8 +203,8 @@ struct openvpn_plugin_string_list struct openvpn_plugin_args_open_in { const int type_mask; - const char const **argv; - const char const **envp; + const char ** const argv; + const char ** const envp; }; @@ -267,8 +267,8 @@ struct openvpn_plugin_args_open_return struct openvpn_plugin_args_func_in { const int type; - const char const **argv; - const char const **envp; + const char ** const argv; + const char ** const envp; openvpn_plugin_handle_t handle; void *per_client_context; int current_cert_depth; -- 1.7.4.4 

Hi, Here's the summary of the previous community meeting. --- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net Date: Thursday, 28th Apr 2011 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2011-04-28> Next meeting will be announced in advance, but will be on the same weekday and at the same time. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/world clock> or with $ date -u SUMMARY cron2, dazo, ecrist, jamesyonan, krzee and mattock were present in this meeting. -- Discussed "make check" (t_client.sh) test failures most buildslaves are experiencing. This is caused by buildslaves doing their tests in parallel with the same (sample) certificates and same configuration files. Mattock will fix this by making each buildslave unique, so that the server can handle all of them simultaneously. -- Discussed which build configurations should be tested with buildbot. Agreed that we can only choose a few or each commit will trigger a ridiculously large number of builds. Cron2 suggested trying to identify --enable/--disable combinations that touch completely unrelated bits of code which can still be combined. Jamesyonan suggested focusing on the major build features, such as - <no configure flags> --disable-crypto --disable-ssl --disable-lzo --disable-management Mattock will make buildbot configuration more automated, thus allowing adding of builders for each combination of these, as well as for other combinations deemed useful. -- Discussed the purpose of openvpn-testing.git and openvpn.git repos. Dazo outlined his current thoughts: - openvpn-testing.git - would contain feature branches - would be a "sandbox" for testing potentially unstable features - openvpn.git - would contain release/maintenance branches (e.g. 2.1, 2.2) - would contain pre-release branches (e.g. 2.3 alpha, beta and rc) The "master" branch on both would be kept in sync. Agreed that this setup makes sense. -- Discussed the future of "allmerged" branch. Found two useful purposes for it's existance: - can serve as a stabilisation branch for separate feature branches - allows a single binary snapshot release (Windows, deb, rpm) to cover many new features, instead of just one (e.g. IPv6, VLAN tagging) Decided to maintain this branch, but change it's name to "experimental" for clarity. -- Discussed providing snapshot builds for Windows. With current Git activity a monthly snapshots seem frequent enough: <ftp://ftp2.secure-computing.net/pub/openvpn/revision.log> Mattock will start providing monthly snapshot builds based on the Git "master" branch at the end of the month, starting today/tomorrow. -- Discussed the 2.2.1 release schedule. Currently there are two fixes that will certainly go into it: <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn.git;a=commit;h=60fdd9b01deab10f9a62ee9235ad9ec16873b5d5> <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn.git;a=commit;h=4d453a1792b04f01a8c313157402ce0501ae809c> Agreed to make the 2.2.1 release in 4-6 weeks. -- Discussed merge conflicts when pulling code from SVN to Git. Jamesyonan promised to use the openvpn.8 (=the biggest offender) from current Git "master" branch in his SVN repo to minimize future conflicts. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hi, I just would like to thank dazo, mattock and all the other developers and contributors who have put so much time into creating this release - great job guys! JJK David Sommerseth wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 27/04/11 20:48, Samuli Seppänen wrote: > | > | Note that we've recently switched to using a different Git repository: > | > | <git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git> > > Just to follow up this one a little bit with more details. > > For me personally, the 2.2 release is a remarkable release for the OpenVPN > community. This is probably the release with the most visible patches from > the community. If I've counted correctly, there are 23 different patch > authors in addition to the work of James Yonan. Over 100 patches have been > contributed and have been implemented. So I want to thank all of you who have > contributed with fixes, new features, documentation and other improvements. > > To mark that we now are officially using git as the official source > repository, all releases and the approved patches will now go into the new > openvpn.git tree, as announced. This tree will also have release branches, > one for each major release, like 2.1, 2.2 and the coming 2.3. All major and > minor releases (2.1.x, 2.2.x, etc) are in addition tagged. > > For more information about the code repositories, please have a look at our wiki: > <https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Coderepositories> > > > We have for about a year used the openvpn-testing.git tree. The future of > this tree will be discussed in the near future. Right now, this tree will be > available. The master branch in this tree and in the openvpn.git tree will be > kept in sync, and all approved feature branches will be merged into allmerged > together with the master branch when they are considered stable enough. Right > now, it is not much new things in the allmerged branch, as the last > outstanding and approved feature branches was the IPv6 branches. > > As you now understand, the OpenVPN 2.3 will have IPv6 as one of the more > important features. Both feat_ipv6_transport (connecting/listening to IPv6 > addresses between OpenVPN client and server) and feat_ipv6_payload > (transporting IPv6 traffic inside the tunnel) have been available in the > allmerged branch for about a year, so it is considered safe and stable enough > to be merged into the master branch. So everyone who wants to begin to look > at what OpenVPN 2.3 really will bring, grab the a master branch. > > > So to summarise it quickly: openvpn.git is the main git repository, where all > that has been released and will be released in the coming OpenVPN releases can > be found. The openvpn-testing.git repository contains now experimental code > which needs a lot of testing and possibly much more development. And the > master branch in both trees will stay in sync. What is in found the master > branch will make it into a coming release. > > Again thanks to all support and contributions. They are indeed very much > appreciated! > 

Hi, We're having an IRC meeting today, starting at 18:00 UTC on #ope...@ir.... Current topic list is here: <https://community.openvpn.net/openvpn/wiki/Topics-2011-04-28> If you have any other things you'd like to bring up, respond to this mail, send me mail privately or add them to the list yourself. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27/04/11 20:48, Samuli Seppänen wrote: | | Note that we've recently switched to using a different Git repository: | | <git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git> Just to follow up this one a little bit with more details. For me personally, the 2.2 release is a remarkable release for the OpenVPN community. This is probably the release with the most visible patches from the community. If I've counted correctly, there are 23 different patch authors in addition to the work of James Yonan. Over 100 patches have been contributed and have been implemented. So I want to thank all of you who have contributed with fixes, new features, documentation and other improvements. To mark that we now are officially using git as the official source repository, all releases and the approved patches will now go into the new openvpn.git tree, as announced. This tree will also have release branches, one for each major release, like 2.1, 2.2 and the coming 2.3. All major and minor releases (2.1.x, 2.2.x, etc) are in addition tagged. For more information about the code repositories, please have a look at our wiki: <https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation#Coderepositories> We have for about a year used the openvpn-testing.git tree. The future of this tree will be discussed in the near future. Right now, this tree will be available. The master branch in this tree and in the openvpn.git tree will be kept in sync, and all approved feature branches will be merged into allmerged together with the master branch when they are considered stable enough. Right now, it is not much new things in the allmerged branch, as the last outstanding and approved feature branches was the IPv6 branches. As you now understand, the OpenVPN 2.3 will have IPv6 as one of the more important features. Both feat_ipv6_transport (connecting/listening to IPv6 addresses between OpenVPN client and server) and feat_ipv6_payload (transporting IPv6 traffic inside the tunnel) have been available in the allmerged branch for about a year, so it is considered safe and stable enough to be merged into the master branch. So everyone who wants to begin to look at what OpenVPN 2.3 really will bring, grab the a master branch. So to summarise it quickly: openvpn.git is the main git repository, where all that has been released and will be released in the coming OpenVPN releases can be found. The openvpn-testing.git repository contains now experimental code which needs a lot of testing and possibly much more development. And the master branch in both trees will stay in sync. What is in found the master branch will make it into a coming release. Again thanks to all support and contributions. They are indeed very much appreciated! kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk24gocACgkQDC186MBRfrpyjQCeLPDjeQIUhj1S2QU68lbGtVrh k9AAn3lEsLkrPIfhyOwjyd189vu+QzFU =tA5S -----END PGP SIGNATURE----- 

The OpenVPN community project team is proud to release OpenVPN 2.2.0. It can be downloaded from here: <http://openvpn.net/index.php/open-source/downloads.html> Changes include: - Several man-page updates - Several buildsystem fixes - Fixed a bug with GUI icon deletion on upgrade from 2.2-RC or earlier - Change the default --tmp-dir path to a more suitable path - Improve the mysprintf() issue in openvpnserv.c - Fixed bug in port-share that could cause port share process to crash - Fix the --client-cert-not-required feature A more comprehensive list of changes is available here: <http://openvpn.net/index.php/open-source/documentation/change-log/425-changelog-for-openvpn-22.html> For generic help use these support channels: - Official documentation: <http://openvpn.net/index.php/open-source/documentation/howto.html> - Wiki: <https://community.openvpn.net> - Forums: <https://forums.openvpn.net> - User mailing list: <http://sourceforge.net/mail/?group_id=48978> - User IRC channel: #openvpn at irc.freenode.net Please report bugs and ask development questions here: - Bug tracker and Wiki: <https://community.openvpn.net> - Developer mailing list: <http://sourceforge.net/mail/?group_id=48978> - Developer IRC channel: #openvpn-devel at irc.freenode.net Note that we've recently switched to using a different Git repository: <git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git> -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/04/11 20:47, David Sommerseth wrote: > From: David Sommerseth <da...@us...> > > A quick and dirty compile fix was introduced in commit 77d244050964525417, > and was accepted under the condition that it would be a temporary fix. > > As the usage of _snprintf() is realy not ideal on Windows, this patch > uses the same well tested openvpn_snprintf() function from buffer.c. > It was a longer discussion of several possibilities to re-use that code, > but in the end it seemed easier to just copy-paste this function to > openvpnserv.c for now. > > The reason for this conclusion was that the function is really simple, > well defined and will most likely not be changed much in the future. > It is also added a comment in openvpnserv.c where this function > has its origins. > > Signed-off-by: David Sommerseth <da...@us...> > --- > service-win32/openvpnserv.c | 39 ++++++++++++++++++++++++++++----------- > 1 files changed, 28 insertions(+), 11 deletions(-) ACKed by James Yonan on IRC 2011-04-11 18:51 UTC: <dazo> jamesyonan: do you have time to have a look at this patch? and ACK it if you agree ... <http://thread.gmane.org/gmane.network.openvpn.devel/4621> <jamesyonan> looking at it now... <jamesyonan> dazo: sure, looks fine Applied to master and cherry-picked to beta2.2. commit 47dd9a4d7b2930f6e1b5d6f0ce0c154efc87ac29 (beta2.2) commit df5a4380c3931520d5fae2b18f0fc2e67a883aae (master) Author: David Sommerseth <da...@us...> Date: Thu Apr 21 20:32:26 2011 +0200 Improve the mysprintf() issue in openvpnserv.c Signed-off-by: David Sommerseth <da...@us...> Acked-by: James Yonan <ja...@op...> kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2wgLMACgkQDC186MBRfrpHowCgnEQbjP2foyBbNtHcxULaVd4B MzEAn02/K92yp6ujE3d39gLpngghV7YG =jMRx -----END PGP SIGNATURE----- 

David Sommerseth wrote: > Signed-off-by: David Sommerseth <da...@us...> Acked-by: Peter Stuge <pe...@st...> 

From: David Sommerseth <da...@us...> A quick and dirty compile fix was introduced in commit 77d244050964525417, and was accepted under the condition that it would be a temporary fix. As the usage of _snprintf() is realy not ideal on Windows, this patch uses the same well tested openvpn_snprintf() function from buffer.c. It was a longer discussion of several possibilities to re-use that code, but in the end it seemed easier to just copy-paste this function to openvpnserv.c for now. The reason for this conclusion was that the function is really simple, well defined and will most likely not be changed much in the future. It is also added a comment in openvpnserv.c where this function has its origins. Signed-off-by: David Sommerseth <da...@us...> --- service-win32/openvpnserv.c | 39 ++++++++++++++++++++++++++++----------- 1 files changed, 28 insertions(+), 11 deletions(-) diff --git a/service-win32/openvpnserv.c b/service-win32/openvpnserv.c index b5d8d37..5b0eb6e 100755 --- a/service-win32/openvpnserv.c +++ b/service-win32/openvpnserv.c @@ -37,6 +37,7 @@ #include <windows.h> #include <stdlib.h> #include <stdio.h> +#include <stdarg.h> #include <process.h> #include "service.h" @@ -79,13 +80,6 @@ static HANDLE exit_event = NULL; /* clear an object */ #define CLEAR(x) memset(&(x), 0, sizeof(x)) -/* snprintf with guaranteed null termination */ -#define mysnprintf(out, ...) \ - { \ - _snprintf (out, sizeof(out), __VA_ARGS__); \ - out [sizeof (out) - 1] = '\0'; \ - } - /* * Message handling */ @@ -97,7 +91,7 @@ static HANDLE exit_event = NULL; #define MSG(flags, ...) \ { \ char x_msg[256]; \ - mysnprintf (x_msg, __VA_ARGS__); \ + openvpn_snprintf (x_msg, sizeof(x_msg), __VA_ARGS__); \ AddToMessageLog ((flags), x_msg); \ } @@ -129,6 +123,28 @@ static HANDLE exit_event = NULL; } \ } +/* + * This is necessary due to certain buggy implementations of snprintf, + * that don't guarantee null termination for size > 0. + * (copied from ../buffer.c, line 217) + * (git: 100644 blob e2f8caab0a5b2a870092c6cd508a1a50c21c3ba3	buffer.c) + */ + +int openvpn_snprintf(char *str, size_t size, const char *format, ...) +{ + va_list arglist; + int ret = 0; + if (size > 0) + { + va_start (arglist, format); + ret = vsnprintf (str, size, format, arglist); + va_end (arglist); + str[size - 1] = 0; + } + return ret; +} + + bool init_security_attributes_allow_all (struct security_attributes *obj) { @@ -353,7 +369,7 @@ VOID ServiceStart (DWORD dwArgc, LPTSTR *lpszArgv) BOOL more_files; char find_string[MAX_PATH]; - mysnprintf (find_string, "%s\\*", config_dir); + openvpn_snprintf (find_string, MAX_PATH, "%s\\*", config_dir); find_handle = FindFirstFile (find_string, &find_obj); if (find_handle == INVALID_HANDLE_VALUE) @@ -395,10 +411,11 @@ VOID ServiceStart (DWORD dwArgc, LPTSTR *lpszArgv) FindClose (find_handle); goto finish; } - mysnprintf (log_path, "%s\\%s", log_dir, log_file); + openvpn_snprintf (log_path, sizeof(log_path), + "%s\\%s", log_dir, log_file); /* construct command line */ - mysnprintf (command_line, PACKAGE " --service %s 1 --config \"%s\"", + openvpn_snprintf (command_line, sizeof(command_line), PACKAGE " --service %s 1 --config \"%s\"", EXIT_EVENT_NAME, find_obj.cFileName); -- 1.7.4.4 

Hi David, David Sommerseth wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 20/04/11 17:25, Jan Just Keijser wrote: > >> Hi *, >> >> copying in the openvpn-devel list as they might be interested in this memory usage analysis as well.... >> >> Ralf Hildebrandt wrote: >> >>> * Ralf Hildebrandt <Ral...@ch...>: >>> >>>> * Fredrik Kers <fre...@gm...>: >>>> >>>>> I measure the memory usage by checking the VmRSS (Resident Set Size) in >>>>> /proc/[pid]/status before and after the clients connect (about 1000 of >>>>> them). >>>>> >>>> So it's the same method (because that's what top and htop do). >>>> >>>> >>>>> I'm using a 64 bit system, maybe that will cause OpenVPN to consume >>>>> more memory per client then your setup >>>>> >>>> Yes, that could be. It's 32Bit here. >>>> >>> pmap -d pid_of_openvpn >>> >>> is showing: >>> >>> # pmap -d 1607 >>> 1607: /usr/sbin/openvpn --writepid /var/run/openvpn.server.pid --syslog ovpn-server --cd /etc/openvpn --config /etc/openvpn/server.conf >>> Address Kbytes Mode Offset Device Mapping >>> 08048000 500 r-x-- 0000000000000000 068:00005 openvpn >>> 080c5000 4 rwx-- 000000000007d000 068:00005 openvpn >>> 080c6000 24 rwx-- 0000000000000000 000:00000 [ anon ] >>> * 08b51000 41396 rwx-- 0000000000000000 000:00000 [ anon ] >>> b7270000 132 rwx-- 0000000000000000 000:00000 [ anon ] >>> ... >>> bfef8000 132 rw--- 0000000000000000 000:00000 [ stack ] >>> mapped: 46240K writeable/private: 42304K shared: 0K >>> >>> The line starting with * shows the biggest chunk of memory in use. >>> >>> >> I'm running openvpn 2.1.4 on a 64bit system (CentSO 5.5 with openssl 0.9.8e). when the first client connects the openvpn server >> gets "hit" by ~ 600 Kb (as seen using pmap). The size of the 'hit' most likely depends on the encryption cipher used. >> >> I recompiled openvpn using >> ./configure --with-mem-check=valgrind >> and then ran the server again using >> valgrind --tool=massif .../openvpn >> >> this results in a nice memory report which you can view using >> ms_print massif.out.22218 >> >> turns out that most memory is allocated by the openssl libraries : CRYPTO_malloc >> the memory trace is too large to show here, but there's tons of stuff in that 'ms_print' output. >> Note that compression was NOT used in this example, apparently the openssl libs call deflateInit internally? >> >> Timestep 49 is when the client connects: you see the memory usage jump from 327,520 bytes to 934,688. >> >> -------------------------------------------------------------------------------- >> n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B) >> -------------------------------------------------------------------------------- >> 48 36,072,833 327,520 276,102 51,418 0 >> 49 36,341,762 934,688 883,126 51,562 0 >> 94.48% (883,126B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. >> > > Again, thanks a lot for wonderful reports. It is easy to shoot OpenSSL > here. But I'm not going to do that just yet. There are some work in > progress of modularising the SSL layer in OpenVPN (if patches are cleaned > up in time and get a decent review, we might have this in OpenVPN 2.3 > already). This work will also add support for PolarSSL. > > When we see those patches, it might be easier to see if there's something > which can be improved in OpenVPN or if it is something which is completely > into the hands of OpenSSL. So running this test with the PolarSSL module > instead will be very interesting. > > I generally think that the crypto context needs to stay in memory for some > time, especially in UDP mode, to avoid re-negotiating of the connections in > case of connectivity issues between client and server. But when the > session is defined as closed by the OpenVPN server, this memory pool should > be released. For TCP mode, the session is closed (afair) when the client > explicitly closes the connection. In UDP mode it's a timeout, unless > - --explicit-exit is used. This freeing of context memory needs to be > verified in the code. > for the record: I did not mean to "shoot OpenSSL" here; I use OpenSSL a lot for my regular work and I know how difficult it is to get it to behave correctly when it comes to memory usage. The reason I started digging was that I added a very dumb 'printf' statement every time gc_alloc or ALLOC_OBJ was called (in openvpn buffer.c) ; I then grabbed the output after a client connected and added up all the mallocs : this did not even add up to 75 KB (and I'm probably double counting too). So then I went on a hunt to find out what _IS_ causing the 600 KB hit, which led to the ms_print report. I'm not too worried about a 600 KB per client hit for an OpenVPN server - it means a 1,000 clients will eat up less than 1 GB of RAM . Unless you're running on tiny hardware (dd-wrt etc) this should not be an issue, but I would not recommend to connect a 1,000 clients to a single dd-wrt box anyway. It will be interesting to see if PolarSSL is actually better in terms of memory consumed. share and enjoy, JJK 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/04/11 17:25, Jan Just Keijser wrote: > Hi *, > > copying in the openvpn-devel list as they might be interested in this memory usage analysis as well.... > > Ralf Hildebrandt wrote: >> * Ralf Hildebrandt <Ral...@ch...>: >>> * Fredrik Kers <fre...@gm...>: >>>> I measure the memory usage by checking the VmRSS (Resident Set Size) in >>>> /proc/[pid]/status before and after the clients connect (about 1000 of >>>> them). >>> So it's the same method (because that's what top and htop do). >>> >>>> I'm using a 64 bit system, maybe that will cause OpenVPN to consume >>>> more memory per client then your setup >>> Yes, that could be. It's 32Bit here. >> >> pmap -d pid_of_openvpn >> >> is showing: >> >> # pmap -d 1607 >> 1607: /usr/sbin/openvpn --writepid /var/run/openvpn.server.pid --syslog ovpn-server --cd /etc/openvpn --config /etc/openvpn/server.conf >> Address Kbytes Mode Offset Device Mapping >> 08048000 500 r-x-- 0000000000000000 068:00005 openvpn >> 080c5000 4 rwx-- 000000000007d000 068:00005 openvpn >> 080c6000 24 rwx-- 0000000000000000 000:00000 [ anon ] >> * 08b51000 41396 rwx-- 0000000000000000 000:00000 [ anon ] >> b7270000 132 rwx-- 0000000000000000 000:00000 [ anon ] >> ... >> bfef8000 132 rw--- 0000000000000000 000:00000 [ stack ] >> mapped: 46240K writeable/private: 42304K shared: 0K >> >> The line starting with * shows the biggest chunk of memory in use. >> > > I'm running openvpn 2.1.4 on a 64bit system (CentSO 5.5 with openssl 0.9.8e). when the first client connects the openvpn server > gets "hit" by ~ 600 Kb (as seen using pmap). The size of the 'hit' most likely depends on the encryption cipher used. > > I recompiled openvpn using > ./configure --with-mem-check=valgrind > and then ran the server again using > valgrind --tool=massif .../openvpn > > this results in a nice memory report which you can view using > ms_print massif.out.22218 > > turns out that most memory is allocated by the openssl libraries : CRYPTO_malloc > the memory trace is too large to show here, but there's tons of stuff in that 'ms_print' output. > Note that compression was NOT used in this example, apparently the openssl libs call deflateInit internally? > > Timestep 49 is when the client connects: you see the memory usage jump from 327,520 bytes to 934,688. > > -------------------------------------------------------------------------------- > n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B) > -------------------------------------------------------------------------------- > 48 36,072,833 327,520 276,102 51,418 0 > 49 36,341,762 934,688 883,126 51,562 0 > 94.48% (883,126B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. Again, thanks a lot for wonderful reports. It is easy to shoot OpenSSL here. But I'm not going to do that just yet. There are some work in progress of modularising the SSL layer in OpenVPN (if patches are cleaned up in time and get a decent review, we might have this in OpenVPN 2.3 already). This work will also add support for PolarSSL. When we see those patches, it might be easier to see if there's something which can be improved in OpenVPN or if it is something which is completely into the hands of OpenSSL. So running this test with the PolarSSL module instead will be very interesting. I generally think that the crypto context needs to stay in memory for some time, especially in UDP mode, to avoid re-negotiating of the connections in case of connectivity issues between client and server. But when the session is defined as closed by the OpenVPN server, this memory pool should be released. For TCP mode, the session is closed (afair) when the client explicitly closes the connection. In UDP mode it's a timeout, unless - --explicit-exit is used. This freeing of context memory needs to be verified in the code. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2vFPIACgkQDC186MBRfrrjYACdFgsI9bBKA/Mp5OZ3uwvuwEH8 knwAn3TMjSl2nsiKVxJRNadLh+RAB8mY =9D/e -----END PGP SIGNATURE----- 

Hi *, copying in the openvpn-devel list as they might be interested in this memory usage analysis as well.... Ralf Hildebrandt wrote: > * Ralf Hildebrandt <Ral...@ch...>: >> * Fredrik Kers <fre...@gm...>: >>> I measure the memory usage by checking the VmRSS (Resident Set Size) in >>> /proc/[pid]/status before and after the clients connect (about 1000 of >>> them). >> So it's the same method (because that's what top and htop do). >> >>> I'm using a 64 bit system, maybe that will cause OpenVPN to consume >>> more memory per client then your setup >> Yes, that could be. It's 32Bit here. > > pmap -d pid_of_openvpn > > is showing: > > # pmap -d 1607 > 1607: /usr/sbin/openvpn --writepid /var/run/openvpn.server.pid --syslog ovpn-server --cd /etc/openvpn --config /etc/openvpn/server.conf > Address Kbytes Mode Offset Device Mapping > 08048000 500 r-x-- 0000000000000000 068:00005 openvpn > 080c5000 4 rwx-- 000000000007d000 068:00005 openvpn > 080c6000 24 rwx-- 0000000000000000 000:00000 [ anon ] > * 08b51000 41396 rwx-- 0000000000000000 000:00000 [ anon ] > b7270000 132 rwx-- 0000000000000000 000:00000 [ anon ] > ... > bfef8000 132 rw--- 0000000000000000 000:00000 [ stack ] > mapped: 46240K writeable/private: 42304K shared: 0K > > The line starting with * shows the biggest chunk of memory in use. > I'm running openvpn 2.1.4 on a 64bit system (CentSO 5.5 with openssl 0.9.8e). when the first client connects the openvpn server gets "hit" by ~ 600 Kb (as seen using pmap). The size of the 'hit' most likely depends on the encryption cipher used. I recompiled openvpn using ./configure --with-mem-check=valgrind and then ran the server again using valgrind --tool=massif .../openvpn this results in a nice memory report which you can view using ms_print massif.out.22218 turns out that most memory is allocated by the openssl libraries : CRYPTO_malloc the memory trace is too large to show here, but there's tons of stuff in that 'ms_print' output. Note that compression was NOT used in this example, apparently the openssl libs call deflateInit internally? Timestep 49 is when the client connects: you see the memory usage jump from 327,520 bytes to 934,688. -------------------------------------------------------------------------------- n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B) -------------------------------------------------------------------------------- 48 36,072,833 327,520 276,102 51,418 0 49 36,341,762 934,688 883,126 51,562 0 94.48% (883,126B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. ->82.41% (770,295B) 0x3858CDAD90: CRYPTO_malloc (in /lib64/libcrypto.so.0.9.8e) | ->62.91% (588,016B) 0x3858CBFF34: ??? (in /lib64/libcrypto.so.0.9.8e) | | ->14.02% (131,072B) 0x38578064B3: deflateInit2_ (in /usr/lib64/libz.so.1.2.3) | | | ->14.02% (131,072B) 0x3857806622: deflateInit_ (in /usr/lib64/libz.so.1.2.3) | | | ->14.02% (131,072B) 0x3858CBFECA: ??? (in /lib64/libcrypto.so.0.9.8e) | | | ->14.02% (131,072B) 0x3858CBFA96: COMP_CTX_new (in /lib64/libcrypto.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E025CDF: tls1_change_cipher_state (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E020492: ssl3_do_change_cipher_spec (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E021952: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E0222AE: ssl3_get_message (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E022B1B: ssl3_get_finished (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E01A740: ssl3_accept (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E021883: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E01E55F: ??? (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E038F3F: ??? (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x3858C7678D: BIO_read (in /lib64/libcrypto.so.0.9.8e) | | | | ->07.01% (65,536B) 0x46F7A3: bio_read (ssl.c:2058) | | | | ->07.01% (65,536B) 0x46FA8F: key_state_read_plaintext (ssl.c:2148) | | | | ->07.01% (65,536B) 0x474859: tls_process (ssl.c:4075) | | | | ->07.01% (65,536B) 0x475420: tls_multi_process (ssl.c:4303) | | | | ->07.01% (65,536B) 0x411B4C: check_tls_dowork (forward.c:93) | | | | ->07.01% (65,536B) 0x41571F: check_tls (forward-inline.h:41) | | | | ->07.01% (65,536B) 0x415663: pre_select (forward.c:1304) | | | | ->07.01% (65,536B) 0x439130: multi_process_post (multi.c:1876) | | | | ->07.01% (65,536B) 0x439927: multi_process_incoming_link (multi.c:2110) | | | | ->07.01% (65,536B) 0x43413B: multi_process_io_udp (mudp.c:170) | | | | ->07.01% (65,536B) 0x4344AC: tunnel_server_udp_single_threaded (mudp.c:255) | | | | ->07.01% (65,536B) 0x434885: tunnel_server_udp (mudp.c:277) | | | | ->07.01% (65,536B) 0x43ACFB: tunnel_server (multi.c:2680) | | | | ->07.01% (65,536B) 0x43D7F3: main (openvpn.c:211) | | | | | | | ->07.01% (65,536B) 0x385E025D9F: tls1_change_cipher_state (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E01A9A5: ssl3_accept (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E021883: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E01E55F: ??? (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E038F3F: ??? (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x3858C7678D: BIO_read (in /lib64/libcrypto.so.0.9.8e) | | | ->07.01% (65,536B) 0x46F7A3: bio_read (ssl.c:2058) | | | ->07.01% (65,536B) 0x46FA8F: key_state_read_plaintext (ssl.c:2148) | | | ->07.01% (65,536B) 0x474859: tls_process (ssl.c:4075) | | | ->07.01% (65,536B) 0x475420: tls_multi_process (ssl.c:4303) | | | ->07.01% (65,536B) 0x411B4C: check_tls_dowork (forward.c:93) | | | ->07.01% (65,536B) 0x41571F: check_tls (forward-inline.h:41) | | | ->07.01% (65,536B) 0x415663: pre_select (forward.c:1304) | | | ->07.01% (65,536B) 0x439130: multi_process_post (multi.c:1876) | | | ->07.01% (65,536B) 0x439927: multi_process_incoming_link (multi.c:2110) | | | ->07.01% (65,536B) 0x43413B: multi_process_io_udp (mudp.c:170) | | | ->07.01% (65,536B) 0x4344AC: tunnel_server_udp_single_threaded (mudp.c:255) | | | ->07.01% (65,536B) 0x434885: tunnel_server_udp (mudp.c:277) | | | ->07.01% (65,536B) 0x43ACFB: tunnel_server (multi.c:2680) | | | ->07.01% (65,536B) 0x43D7F3: main (openvpn.c:211) | | | | | ->14.02% (131,072B) 0x38578064C7: deflateInit2_ (in /usr/lib64/libz.so.1.2.3) | | | ->14.02% (131,072B) 0x3857806622: deflateInit_ (in /usr/lib64/libz.so.1.2.3) | | | ->14.02% (131,072B) 0x3858CBFECA: ??? (in /lib64/libcrypto.so.0.9.8e) | | | ->14.02% (131,072B) 0x3858CBFA96: COMP_CTX_new (in /lib64/libcrypto.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E025CDF: tls1_change_cipher_state (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E020492: ssl3_do_change_cipher_spec (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E021952: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E0222AE: ssl3_get_message (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E022B1B: ssl3_get_finished (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E01A740: ssl3_accept (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E021883: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E01E55F: ??? (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E038F3F: ??? (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x3858C7678D: BIO_read (in /lib64/libcrypto.so.0.9.8e) | | | | ->07.01% (65,536B) 0x46F7A3: bio_read (ssl.c:2058) | | | | ->07.01% (65,536B) 0x46FA8F: key_state_read_plaintext (ssl.c:2148) | | | | ->07.01% (65,536B) 0x474859: tls_process (ssl.c:4075) | | | | ->07.01% (65,536B) 0x475420: tls_multi_process (ssl.c:4303) | | | | ->07.01% (65,536B) 0x411B4C: check_tls_dowork (forward.c:93) | | | | ->07.01% (65,536B) 0x41571F: check_tls (forward-inline.h:41) | | | | ->07.01% (65,536B) 0x415663: pre_select (forward.c:1304) | | | | ->07.01% (65,536B) 0x439130: multi_process_post (multi.c:1876) | | | | ->07.01% (65,536B) 0x439927: multi_process_incoming_link (multi.c:2110) | | | | ->07.01% (65,536B) 0x43413B: multi_process_io_udp (mudp.c:170) | | | | ->07.01% (65,536B) 0x4344AC: tunnel_server_udp_single_threaded (mudp.c:255) | | | | ->07.01% (65,536B) 0x434885: tunnel_server_udp (mudp.c:277) | | | | ->07.01% (65,536B) 0x43ACFB: tunnel_server (multi.c:2680) | | | | ->07.01% (65,536B) 0x43D7F3: main (openvpn.c:211) | | | | | | | ->07.01% (65,536B) 0x385E025D9F: tls1_change_cipher_state (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E01A9A5: ssl3_accept (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E021883: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E01E55F: ??? (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E038F3F: ??? (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x3858C7678D: BIO_read (in /lib64/libcrypto.so.0.9.8e) | | | ->07.01% (65,536B) 0x46F7A3: bio_read (ssl.c:2058) | | | ->07.01% (65,536B) 0x46FA8F: key_state_read_plaintext (ssl.c:2148) | | | ->07.01% (65,536B) 0x474859: tls_process (ssl.c:4075) | | | ->07.01% (65,536B) 0x475420: tls_multi_process (ssl.c:4303) | | | ->07.01% (65,536B) 0x411B4C: check_tls_dowork (forward.c:93) | | | ->07.01% (65,536B) 0x41571F: check_tls (forward-inline.h:41) | | | ->07.01% (65,536B) 0x415663: pre_select (forward.c:1304) | | | ->07.01% (65,536B) 0x439130: multi_process_post (multi.c:1876) | | | ->07.01% (65,536B) 0x439927: multi_process_incoming_link (multi.c:2110) | | | ->07.01% (65,536B) 0x43413B: multi_process_io_udp (mudp.c:170) | | | ->07.01% (65,536B) 0x4344AC: tunnel_server_udp_single_threaded (mudp.c:255) | | | ->07.01% (65,536B) 0x434885: tunnel_server_udp (mudp.c:277) | | | ->07.01% (65,536B) 0x43ACFB: tunnel_server (multi.c:2680) | | | ->07.01% (65,536B) 0x43D7F3: main (openvpn.c:211) | | | | | ->14.02% (131,072B) 0x38578064EA: deflateInit2_ (in /usr/lib64/libz.so.1.2.3) | | | ->14.02% (131,072B) 0x3857806622: deflateInit_ (in /usr/lib64/libz.so.1.2.3) | | | ->14.02% (131,072B) 0x3858CBFECA: ??? (in /lib64/libcrypto.so.0.9.8e) | | | ->14.02% (131,072B) 0x3858CBFA96: COMP_CTX_new (in /lib64/libcrypto.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E025CDF: tls1_change_cipher_state (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E020492: ssl3_do_change_cipher_spec (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E021952: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E0222AE: ssl3_get_message (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E022B1B: ssl3_get_finished (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E01A740: ssl3_accept (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E021883: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E01E55F: ??? (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E038F3F: ??? (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x3858C7678D: BIO_read (in /lib64/libcrypto.so.0.9.8e) | | | | ->07.01% (65,536B) 0x46F7A3: bio_read (ssl.c:2058) | | | | ->07.01% (65,536B) 0x46FA8F: key_state_read_plaintext (ssl.c:2148) | | | | ->07.01% (65,536B) 0x474859: tls_process (ssl.c:4075) | | | | ->07.01% (65,536B) 0x475420: tls_multi_process (ssl.c:4303) | | | | ->07.01% (65,536B) 0x411B4C: check_tls_dowork (forward.c:93) | | | | ->07.01% (65,536B) 0x41571F: check_tls (forward-inline.h:41) | | | | ->07.01% (65,536B) 0x415663: pre_select (forward.c:1304) | | | | ->07.01% (65,536B) 0x439130: multi_process_post (multi.c:1876) | | | | ->07.01% (65,536B) 0x439927: multi_process_incoming_link (multi.c:2110) | | | | ->07.01% (65,536B) 0x43413B: multi_process_io_udp (mudp.c:170) | | | | ->07.01% (65,536B) 0x4344AC: tunnel_server_udp_single_threaded (mudp.c:255) | | | | ->07.01% (65,536B) 0x434885: tunnel_server_udp (mudp.c:277) | | | | ->07.01% (65,536B) 0x43ACFB: tunnel_server (multi.c:2680) | | | | ->07.01% (65,536B) 0x43D7F3: main (openvpn.c:211) | | | | | | | ->07.01% (65,536B) 0x385E025D9F: tls1_change_cipher_state (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E01A9A5: ssl3_accept (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E021883: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E01E55F: ??? (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E038F3F: ??? (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x3858C7678D: BIO_read (in /lib64/libcrypto.so.0.9.8e) | | | ->07.01% (65,536B) 0x46F7A3: bio_read (ssl.c:2058) | | | ->07.01% (65,536B) 0x46FA8F: key_state_read_plaintext (ssl.c:2148) | | | ->07.01% (65,536B) 0x474859: tls_process (ssl.c:4075) | | | ->07.01% (65,536B) 0x475420: tls_multi_process (ssl.c:4303) | | | ->07.01% (65,536B) 0x411B4C: check_tls_dowork (forward.c:93) | | | ->07.01% (65,536B) 0x41571F: check_tls (forward-inline.h:41) | | | ->07.01% (65,536B) 0x415663: pre_select (forward.c:1304) | | | ->07.01% (65,536B) 0x439130: multi_process_post (multi.c:1876) | | | ->07.01% (65,536B) 0x439927: multi_process_incoming_link (multi.c:2110) | | | ->07.01% (65,536B) 0x43413B: multi_process_io_udp (mudp.c:170) | | | ->07.01% (65,536B) 0x4344AC: tunnel_server_udp_single_threaded (mudp.c:255) | | | ->07.01% (65,536B) 0x434885: tunnel_server_udp (mudp.c:277) | | | ->07.01% (65,536B) 0x43ACFB: tunnel_server (multi.c:2680) | | | ->07.01% (65,536B) 0x43D7F3: main (openvpn.c:211) | | | | | ->14.02% (131,072B) 0x385780649F: deflateInit2_ (in /usr/lib64/libz.so.1.2.3) | | | ->14.02% (131,072B) 0x3857806622: deflateInit_ (in /usr/lib64/libz.so.1.2.3) | | | ->14.02% (131,072B) 0x3858CBFECA: ??? (in /lib64/libcrypto.so.0.9.8e) | | | ->14.02% (131,072B) 0x3858CBFA96: COMP_CTX_new (in /lib64/libcrypto.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E025CDF: tls1_change_cipher_state (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E020492: ssl3_do_change_cipher_spec (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E021952: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E0222AE: ssl3_get_message (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E022B1B: ssl3_get_finished (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E01A740: ssl3_accept (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E021883: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E01E55F: ??? (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x385E038F3F: ??? (in /lib64/libssl.so.0.9.8e) | | | | ->07.01% (65,536B) 0x3858C7678D: BIO_read (in /lib64/libcrypto.so.0.9.8e) | | | | ->07.01% (65,536B) 0x46F7A3: bio_read (ssl.c:2058) | | | | ->07.01% (65,536B) 0x46FA8F: key_state_read_plaintext (ssl.c:2148) | | | | ->07.01% (65,536B) 0x474859: tls_process (ssl.c:4075) | | | | ->07.01% (65,536B) 0x475420: tls_multi_process (ssl.c:4303) | | | | ->07.01% (65,536B) 0x411B4C: check_tls_dowork (forward.c:93) | | | | ->07.01% (65,536B) 0x41571F: check_tls (forward-inline.h:41) | | | | ->07.01% (65,536B) 0x415663: pre_select (forward.c:1304) | | | | ->07.01% (65,536B) 0x439130: multi_process_post (multi.c:1876) | | | | ->07.01% (65,536B) 0x439927: multi_process_incoming_link (multi.c:2110) | | | | ->07.01% (65,536B) 0x43413B: multi_process_io_udp (mudp.c:170) | | | | ->07.01% (65,536B) 0x4344AC: tunnel_server_udp_single_threaded (mudp.c:255) | | | | ->07.01% (65,536B) 0x434885: tunnel_server_udp (mudp.c:277) | | | | ->07.01% (65,536B) 0x43ACFB: tunnel_server (multi.c:2680) | | | | ->07.01% (65,536B) 0x43D7F3: main (openvpn.c:211) | | | | | | | ->07.01% (65,536B) 0x385E025D9F: tls1_change_cipher_state (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E01A9A5: ssl3_accept (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E021883: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E01E55F: ??? (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x385E038F3F: ??? (in /lib64/libssl.so.0.9.8e) | | | ->07.01% (65,536B) 0x3858C7678D: BIO_read (in /lib64/libcrypto.so.0.9.8e) | | | ->07.01% (65,536B) 0x46F7A3: bio_read (ssl.c:2058) | | | ->07.01% (65,536B) 0x46FA8F: key_state_read_plaintext (ssl.c:2148) | | | ->07.01% (65,536B) 0x474859: tls_process (ssl.c:4075) | | | ->07.01% (65,536B) 0x475420: tls_multi_process (ssl.c:4303) | | | ->07.01% (65,536B) 0x411B4C: check_tls_dowork (forward.c:93) | | | ->07.01% (65,536B) 0x41571F: check_tls (forward-inline.h:41) | | | ->07.01% (65,536B) 0x415663: pre_select (forward.c:1304) | | | ->07.01% (65,536B) 0x439130: multi_process_post (multi.c:1876) | | | ->07.01% (65,536B) 0x439927: multi_process_incoming_link (multi.c:2110) | | | ->07.01% (65,536B) 0x43413B: multi_process_io_udp (mudp.c:170) | | | ->07.01% (65,536B) 0x4344AC: tunnel_server_udp_single_threaded (mudp.c:255) | | | ->07.01% (65,536B) 0x434885: tunnel_server_udp (mudp.c:277) | | | ->07.01% (65,536B) 0x43ACFB: tunnel_server (multi.c:2680) | | | ->07.01% (65,536B) 0x43D7F3: main (openvpn.c:211) | 

I don't understand the "more secure" argument. But you can write less secured suid iproute2 ip utility replacement which can do whatever you like if the sudo is your problem. On Sat, Apr 16, 2011 at 1:57 AM, Mr Dash Four <mr....@go...> wrote: > > Is there a plugin allowing me to run "route-up" and "iproute" > (replacement) scripts taking advantage of the split privilege execution? > > I know there is down-root which allows a "down" script to be executed in > this fashion, but I am not sure I could find a similar one for the above > two scripts. > > The reason I am asking this is two-fold: currently I have to install the > sudo package, configure it and include sudo commands in the above 2 > scripts in order to avoid route/ip commands being executed in > unprivileged environment. While this works well, I'd much rather have > everything better organised (and more secure) within OpenVPN. > > I've had a (very) quick look at down-root.c and openvpn-plugin.h files > and it seems possible to use those as a template to write 2 additional > plugins dealing with those two scripts, though I do not wish to reinvent > the wheel if there are already in existence or if there is an easier way > of doing this (if at all possible). > > Many thanks in advance! > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

Is there a plugin allowing me to run "route-up" and "iproute" (replacement) scripts taking advantage of the split privilege execution? I know there is down-root which allows a "down" script to be executed in this fashion, but I am not sure I could find a similar one for the above two scripts. The reason I am asking this is two-fold: currently I have to install the sudo package, configure it and include sudo commands in the above 2 scripts in order to avoid route/ip commands being executed in unprivileged environment. While this works well, I'd much rather have everything better organised (and more secure) within OpenVPN. I've had a (very) quick look at down-root.c and openvpn-plugin.h files and it seems possible to use those as a template to write 2 additional plugins dealing with those two scripts, though I do not wish to reinvent the wheel if there are already in existence or if there is an easier way of doing this (if at all possible). Many thanks in advance! 

Hi, Here's the next version of the installer: <http://build.openvpn.net/openvpn-2.2-preview-2-install.exe> This version fixes this issue: <https://community.openvpn.net/openvpn/ticket/120> -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock > Hi everyone, > > The first test build of OpenVPN 2.2 for Windows is available here: > > <http://build.openvpn.net/openvpn-2.2-preview-1-install.exe> > > Any help in testing it prior to the final release - hopefully 22nd April > - is much appreciated! Changes to 2.2-RC2 include: > > --- > > 2011.04.xx -- Version 2.2 > David Sommerseth (2): > Fix the --client-cert-not-required feature > Change the default --tmp-dir path to a more suitable path > > Gert Doering (1): > Add more detailed explanation regarding the function of "--rdns-internal" > > Gisle Vanem (1): > Avoid re-defining uint32_t when using mingw compiler > > James Yonan (1): > Fixed bug in port-share that could cause port share process to crash > > Samuli Seppänen (5): > Add man page entry for --redirect-private > Change all CRLF linefeeds to LF linefeeds > Fix a bug in devcon source code handling > Removed Win2k from supported platforms list in INSTALL and win/openvpn.nsi > Fixed copying of tapinstall.exe to dist/bin when using prebuilt TAP-drivers > > chantra (1): > Clarify --tmp-dir option > > rf (2): > Update man page with info about --remote-random-hostname > Added man page entry for --management-client > > --- > > The final 2.2 installer may include a few minor additional changes. > > 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/04/11 15:25, Samuli Seppänen wrote: > This bug was introduced in commit 110e42d199e735ab1a31388c5678f59d0fa9510c. > > Trac-ticket: 120 > Signed-off-by: Samuli Seppänen <sa...@op...> ACK. Applied to master and beta2.2 commit 1cc2b62d97d651ce9b05466928faba3b463838b7 Author: Samuli Seppänen <sa...@op...> Date: Fri Apr 15 16:25:17 2011 +0300 Fixed a bug with GUI icon deletion on upgrade from 2.2-RC or earlier This bug was introduced in commit 110e42d199e735ab1a31388c5678f59d0fa9 Trac-ticket: 120 Signed-off-by: Samuli Seppänen <sa...@op...> Acked-by: David Sommerseth <da...@re...> Signed-off-by: David Sommerseth <da...@re...> (cherry picked from commit 6d1d08f6792109a4a4cdd9cd0936fd4338c76fa1) kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2oUj4ACgkQDC186MBRfrpNtACfVtuKzYJ36/gx/irIYtFfruPb kVgAn2v3v3N/aJJDOj2crbwH3+mbF5UN =/qmi -----END PGP SIGNATURE----- 

This bug was introduced in commit 110e42d199e735ab1a31388c5678f59d0fa9510c. Trac-ticket: 120 Signed-off-by: Samuli Seppänen <sa...@op...> --- win/openvpn.nsi | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/win/openvpn.nsi b/win/openvpn.nsi index bad1ef4..d3f80d0 100755 --- a/win/openvpn.nsi +++ b/win/openvpn.nsi @@ -237,6 +237,12 @@ Section -pre Sleep 3000 + # Fix for Trac ticket 120. Remove after 2.3 has been released. + !ifdef USE_GUI + SetShellVarContext current + Delete "$DESKTOP\${PRODUCT_NAME} GUI.lnk" + !endif + SectionEnd Section "${PRODUCT_NAME} User-Space Components" SecOpenVPNUserSpace -- 1.6.3.3 

Hi all, Most of OpenVPN 2.2's build and packaging dependencies for Windows are now available in one convenient package: <http://build.openvpn.net/downloads/build-dependencies> See the included README.TXT file for details. Build instructions are available here: <https://community.openvpn.net/openvpn/wiki/BuildingOnWindows> -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

This bug was introduced in commit 110e42d199e735ab1a31388c5678f59d0fa9510c. Trac-ticket: 120 Signed-off-by: Samuli Seppänen <sa...@op...> --- win/openvpn.nsi | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/win/openvpn.nsi b/win/openvpn.nsi index bad1ef4..148dafc 100755 --- a/win/openvpn.nsi +++ b/win/openvpn.nsi @@ -237,6 +237,13 @@ Section -pre Sleep 3000 + # Fix for Trac ticket 120. Remove after 2.3 has been released. + !ifdef USE_GUI + SetShellVarContext current + Delete "$INSTDIR\bin\${OPENVPN_GUI}" + Delete "$DESKTOP\${PRODUCT_NAME} GUI.lnk" + !endif + SectionEnd Section "${PRODUCT_NAME} User-Space Components" SecOpenVPNUserSpace -- 1.6.3.3 

Hello Samuli, > release: this avoids having to sign the TAP-drivers again due to such a > trivial change. Release signing is trivial, too. No need to circumvent it, it's easy to automate. How to Release-Sign File System Drivers http://msdn.microsoft.com/en-us/windows/hardware/gg487543.aspx greetings Carsten 

Hi, Here's the summary of the previous community meeting. --- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net Date: Thursday, 14th Apr 2011 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2011-04-14> Next meeting will be announced in advance, but will be on the same weekday and at the same time. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/world clock> or with $ date -u SUMMARY cron2, dazo, krzee and mattock were present in this meeting. -- Discussed the status of VLAN tagging patchset (in the feat_vlan_tagging branch). Lack of test reports has prevented it from being merged into the main development branches. -- Discussed value of PRODUCT_TAP_RELDATE in win/settings.in. Agreed that when it's changed, it's should be set to 24th March 2011, when PRODUCT_TAP_WIN32_MIN_MINOR (in version.m4) was fixed. Also agreed that it's probably best not to update PRODUCT_TAP_RELDATE until after 2.2 release: this avoids having to sign the TAP-drivers again due to such a trivial change. -- Discussed lack of anchors in the FAQ: <http://openvpn.net/index.php/open-source/faq.html> For example, this is broken: <http://openvpn.net/faq.html#dhcpclientserv> Mattock will take a look at these. -- Discussed the "Removed Win2k from supported platforms list in INSTALL and win/openvpn.nsi" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/4596> Dazo gave this patch an ACK with a minor change. Decided to list supported Windows versions for every release on the downloads page and to add last Win2k-compliant version (2.1.3) to the download listing. -- Discussed the "Fixed copying of tapinstall.exe to dist/bin when using prebuilt TAP-drivers" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/4597> Dazo gave this patch an ACK. -- Discussed the "Fix a bug in devcon source code handling" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/4595> Dazo gave this patch an ACK. -- Discussed the "Change the default --tmp-dir path to a more suitable path" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/4593> Cron2 gave this patch an ACK after minor modifications. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hi everyone, The first test build of OpenVPN 2.2 for Windows is available here: <http://build.openvpn.net/openvpn-2.2-preview-1-install.exe> Any help in testing it prior to the final release - hopefully 22nd April - is much appreciated! Changes to 2.2-RC2 include: --- 2011.04.xx -- Version 2.2 David Sommerseth (2): Fix the --client-cert-not-required feature Change the default --tmp-dir path to a more suitable path Gert Doering (1): Add more detailed explanation regarding the function of "--rdns-internal" Gisle Vanem (1): Avoid re-defining uint32_t when using mingw compiler James Yonan (1): Fixed bug in port-share that could cause port share process to crash Samuli Seppänen (5): Add man page entry for --redirect-private Change all CRLF linefeeds to LF linefeeds Fix a bug in devcon source code handling Removed Win2k from supported platforms list in INSTALL and win/openvpn.nsi Fixed copying of tapinstall.exe to dist/bin when using prebuilt TAP-drivers chantra (1): Clarify --tmp-dir option rf (2): Update man page with info about --remote-random-hostname Added man page entry for --management-client --- The final 2.2 installer may include a few minor additional changes. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/11 16:29, David Sommerseth wrote: > After all the discussions regarding the --tmp-dir patch [1], I have now > condenced everything into one single patch. The main change is that > the new win_get_tempdir() function is simplified by using GetTempPath() > instead. > > On Windows the fallback solution, if GetTempPath() returns NULL, is now to > behave as before - write temporary files in the directory where OpenVPN was > started. > > > [1] <http://thread.gmane.org/gmane.network.openvpn.devel/4561> > > > David Sommerseth (1): > Change the default --tmp-dir path to a more suitable path > > options.c | 18 ++++++++++++++---- > win32.c | 19 +++++++++++++++++++ > win32.h | 3 +++ > 3 files changed, 36 insertions(+), 4 deletions(-) Applied to master and beta2.2. commit eb4b1bb6adc7fb1828839967a7807b6317305145 (beta2.2) commit eb4b1bb6adc7fb1828839967a7807b6317305145 (master) Author: David Sommerseth <da...@re...> Date: Thu Apr 14 16:21:16 2011 +0200 Signed-off-by: David Sommerseth <da...@re...> Tested-by: Jan Just Keijser <ja...@ni...> Acked-by: Gert Doering <ge...@gr...> Kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2oAyUACgkQDC186MBRfroWKgCdFp47roG5t8GlwBUtbqSWl36I N1AAn2uPVZgh8itgrQlLUi/hZcfrUEOz =t8A0 -----END PGP SIGNATURE----- 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/11 16:40, Samuli Seppänen wrote: > The win/config_ti.py build script assumes to find ../tapinstall/7600/sources.in > which does not exists in devcon.exe source code directory. This makes > config_ti.py look for ../tapinstall/7600/sources instead. > --- > win/config_ti.py | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > ACK. Applied to master and beta2.2. commit 6f0ded58250d4b4fef9cfdd314165d88d8f8f80e (beta2.2) commit a18752d4febdaa91f87efcc487ac865d6587c527 (master) Author: Samuli Seppänen <sa...@op...> Date: Thu Apr 14 17:40:33 2011 +0300 Fix a bug in devcon source code handling The win/config_ti.py build script assumes to find ../tapinstall /7600/sources.in which does not exists in devcon.exe source code directory. This makes config_ti.py look for ../tapinstall/7600/sources instead. Signed-off-by: Samuli Seppänen <sa...@op...> Acked-by: David Sommerseth <da...@us...> Signed-off-by: David Sommerseth <da...@us...> kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2oApUACgkQDC186MBRfrpBwQCfegsKnY91cdlJsXU05r6Y8Ynl ZJ8An1bGQENjDv06d4pdF81XPE9BOyj8 =sMaT -----END PGP SIGNATURE-----