openvpn-devel Mailing List for OpenVPN

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/02/11 16:47, Stefan Hellermann wrote: >> >> Thanks a lot for this fix. Good catch! >> >> Applied to bugfix2.1 and merged into allmerged. >> >> commit 4c4b8cedfa98e8892a53eadd154836f8fa8cea7a >> Author: Stefan Hellermann <st...@th...> >> Date: Sun Feb 27 22:15:44 2011 +0100 >> >> Signed-off-by: Stefan Hellermann <st...@th...> >> Acked-by: David Sommerseth <da...@re...> >> Signed-off-by: David Sommerseth <da...@re...> >> >> >> You asked earlier if this patch was good, and I see you managed to add the >> "Signed-off-by:" line (git commit -s). So this basically looks good to me! > > Sorry, the E-Mail with the Signed-off-by: was a patch v2, the last > changed line has a ";" too much. > The incremental diff: > > --- a/plugin.h > +++ b/plugin.h > @@ -176,7 +176,7 @@ plugin_call (const struct plugin_list *pl, > struct plugin_return *pr, > struct env_set *es, > int current_cert_depth, > - X509 *current_cert); > + X509 *current_cert) Gah! I managed to somehow mix stuff up. Sorry about that. I've applied a new commit with this patch with you as the author and Signed-off-by. I'm sorry about that mess. Even though I did a 'make distcheck' without failures. But I might have missed a warning. For patches which replaces earlier ones, please emphasize what the difference is, then it easier to see that I work with the proper patches. commit 2b7e41f39f54b68b515c9aa9053ca07bf54974a8 Author: Stefan Hellermann <st...@th...> Date: Mon Feb 28 16:53:26 2011 +0100 Fixed typo in plugin.h A additional ';' had sneaked in commit 4c4b8cedfa98e8892a53. Lets kick it out again. Signed-off-by: Stefan Hellermann <st...@th...> Acked-by: David Sommerseth <da...@re...> Signed-off-by: David Sommerseth <da...@re...> Kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1rxsIACgkQDC186MBRfro6RACfcuzzJ5b/kVXqMqLDJ6CPKQhF /cwAnigYwfBBG1O1thR2kOqiVUoy21sr =zN1n -----END PGP SIGNATURE----- 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/02/11 15:40, Stefan Hellermann wrote: > Am 28.02.2011 15:23, schrieb Stefan Hellermann: >> Am 28.02.2011 09:08, schrieb Samuli Seppänen: >>> Hi Stefan, >>> >>> I think you should rebase your patch against the "beta2.2" branch. No >>> development is done in the "allmerged" branch, it only used to aggregate >>> code from other branches. >>> >> The commit which introduces this build-failure is in the bugfix2.1 >> branch. Could you apply it there and merge the patch to allmerged? >> >> Otherwise the weekly snapshots linked on >> https://community.openvpn.net/openvpn/wiki/TesterDocumentation >> do not build in the !ENABLE_PLUGIN case. >> >> The router distribution Openwrt is using these. >> > > plugin.h: update prototype of plugin_call dummy in !ENABLE_PLUGIN case [v2] > > Commit 2db5a0ac3e053857d97e468de53e70a605f54561 adds two arguments to > plugin_call(...), but missed the !ENABLE_PLUGIN case. With > !ENABLE_PLUGIN, plugin_call(...) is only a dummy, so add these two > parameters there too. > > --- > plugin.h | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > > There is a small copy-paste failure in the patch, the correct one below. > This one is now really run-time tested. > > Signed-off-by: Stefan Hellermann <st...@th...> ACK! Thanks a lot for this fix. Good catch! Applied to bugfix2.1 and merged into allmerged. commit 4c4b8cedfa98e8892a53eadd154836f8fa8cea7a Author: Stefan Hellermann <st...@th...> Date: Sun Feb 27 22:15:44 2011 +0100 Signed-off-by: Stefan Hellermann <st...@th...> Acked-by: David Sommerseth <da...@re...> Signed-off-by: David Sommerseth <da...@re...> You asked earlier if this patch was good, and I see you managed to add the "Signed-off-by:" line (git commit -s). So this basically looks good to me! kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1rwdEACgkQDC186MBRfrq+9gCdGgk78cFkcXo+Oc1yEFi7Y5l0 SDkAni0Oa4lDyvK/9OrIwOAIeaEWFpVT =RoHL -----END PGP SIGNATURE----- 

Am 28.02.2011 15:23, schrieb Stefan Hellermann: > Am 28.02.2011 09:08, schrieb Samuli Seppänen: >> Hi Stefan, >> >> I think you should rebase your patch against the "beta2.2" branch. No >> development is done in the "allmerged" branch, it only used to aggregate >> code from other branches. >> > The commit which introduces this build-failure is in the bugfix2.1 > branch. Could you apply it there and merge the patch to allmerged? > > Otherwise the weekly snapshots linked on > https://community.openvpn.net/openvpn/wiki/TesterDocumentation > do not build in the !ENABLE_PLUGIN case. > > The router distribution Openwrt is using these. > plugin.h: update prototype of plugin_call dummy in !ENABLE_PLUGIN case [v2] Commit 2db5a0ac3e053857d97e468de53e70a605f54561 adds two arguments to plugin_call(...), but missed the !ENABLE_PLUGIN case. With !ENABLE_PLUGIN, plugin_call(...) is only a dummy, so add these two parameters there too. --- plugin.h | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) There is a small copy-paste failure in the patch, the correct one below. This one is now really run-time tested. Signed-off-by: Stefan Hellermann <st...@th...> diff --git a/plugin.h b/plugin.h index 846973f..9d48651 100644 --- a/plugin.h +++ b/plugin.h @@ -174,7 +174,9 @@ plugin_call (const struct plugin_list *pl, const int type, const struct argv *av, struct plugin_return *pr, - struct env_set *es) + struct env_set *es, + int current_cert_depth, + X509 *current_cert) { return 0; } -- 1.7.4 

Am 28.02.2011 09:08, schrieb Samuli Seppänen: > >> plugin.h: update prototype of plugin_call dummy in !ENABLE_PLUGIN case >> >> Commit 2db5a0ac3e053857d97e468de53e70a605f54561 adds two arguments to >> plugin_call(...), but missed the !ENABLE_PLUGIN case. With >> !ENABLE_PLUGIN, plugin_call(...) is only a dummy, so add these two >> parameters there too. >> >> --- >> plugin.h | 4 +++- >> 1 files changed, 3 insertions(+), 1 deletions(-) >> >> This is my first patch with git, is everything correct? This patch is >> against the allmerged branch. >> >> > Hi Stefan, > > I think you should rebase your patch against the "beta2.2" branch. No > development is done in the "allmerged" branch, it only used to aggregate > code from other branches. > The commit which introduces this build-failure is in the bugfix2.1 branch. Could you apply it there and merge the patch to allmerged? Otherwise the weekly snapshots linked on https://community.openvpn.net/openvpn/wiki/TesterDocumentation do not build in the !ENABLE_PLUGIN case. The router distribution Openwrt is using these. Regards, Stefan 

David Sommerseth wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 26/02/11 12:25, Gert Doering wrote: > | Hi, > | > | On Sat, Feb 26, 2011 at 11:19:19AM +0000, Olivier Van Acker wrote: > |>> The code parts in question inside OpenVPN (socket.c) are somewhat > |>> complicated due to lots of existing options and lots of existing > |>> operating systems being supported, so this will not be a trivial > |>> task. > |> > |> Would it be a good idea to limit the scope of this project by concentrating > |> on one OS first? I was thinking FreeBSD first since that contains the > |> reference implementation of SCTP. > | > | Well, you'd certainly start with one OS, but in the long run, you'd want > | the mainstream OSes (Linux and Windows) as well... > > I second this. SCTP is really interesting for OpenVPN in my perspective, but > we should rather quickly after having "something which works" support other > OSes as well. When we reach that point, merging SCTP support into 'allmerged' > for broader testing gets interesting. If Linux gets support quickly, I'm able > to test this out pretty soonish in a limited prod environment. > > Some practical details. General info about the development process can be > found here: > <https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation>, including > git repositories. > > For the git branch to look at, JJO's IPv6 transport patches is called > feat_ipv6_transport. *But* as soon as we manage to get the OpenVPN 2.2 > release out the door (I'm hope I'll be able to finalise the beta2.2 branch > today for the RC release), we're going to merge stuff, including JJO's branch > and Gert's feat_ipv6_payload branches officially and get started with the > OpenVPN 2.3 cycle. So what I'm saying, please base your stuff on JJO's branch > now, but be sure your changes can be merged against the feat_ipv6_payload > branch too. As I'm the one going to do the merges, I'm going to be noisy if > it doesn't go smooth ;-) > > And just let me state that, if someone got time to do a real overhaul of > socket.c, that would really be beneficial. That source file is confusing at > best to read. However, we do have some source documentation patches is the > wild somewhere, waiting to go in soonish too - which I'd like to see go into > the 2.3 cycle. So - there's a little coordination needed to be done here with > such an overhaul too. > > there seems to be a freely available SCTP implementation for Windows XP/Vista/7: http://www.bluestop.org/SctpDrv/ Sources for an older version of this driver are available, but I am not sure under what conditions/license is released. As for adding SCTP support: if I read the 'socat' sources it should be dead-easy: just open the socket using the protocol IPP_SCTP4 and that's about it. The real question is whether we'd want to support some of the niftier features that SCTP has to offer (e.g. opening multiple channels via a single connections). cheers, JJK 

 > plugin.h: update prototype of plugin_call dummy in !ENABLE_PLUGIN case > > Commit 2db5a0ac3e053857d97e468de53e70a605f54561 adds two arguments to > plugin_call(...), but missed the !ENABLE_PLUGIN case. With > !ENABLE_PLUGIN, plugin_call(...) is only a dummy, so add these two > parameters there too. > > --- > plugin.h | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > This is my first patch with git, is everything correct? This patch is > against the allmerged branch. > > Hi Stefan, I think you should rebase your patch against the "beta2.2" branch. No development is done in the "allmerged" branch, it only used to aggregate code from other branches. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

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 

> > > for broader testing gets interesting. If Linux gets support quickly, I'm > able > to test this out pretty soonish in a limited prod environment. > > I might start with Linux first since, as you rightly point out, more people can use/test it. Worth mentioning: you need third party implementation of SCTP on Windows and Mac OS X so this might be a significant hurdle for adoption on these platforms :-( > Some practical details. General info about the development process can be > found here: > <https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation>, > including > git repositories. > > Thanks, will read it. > So what I'm saying, please base your stuff on JJO's branch > now, but be sure your changes can be merged against the feat_ipv6_payload > branch too. As I'm the one going to do the merges, I'm going to be noisy > if > it doesn't go smooth ;-) > > Yes, I'll try JJO's branch first, see if I can make it work on FreeBSD and Linux Cheers, Olivier > And just let me state that, if someone got time to do a real overhaul of > socket.c, that would really be beneficial. That source file is confusing > at > best to read. However, we do have some source documentation patches is the > wild somewhere, waiting to go in soonish too - which I'd like to see go > into > the 2.3 cycle. So - there's a little coordination needed to be done here > with > such an overhaul too. > > > kind regards, > > David Sommerseth > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk1o6G0ACgkQDC186MBRfrrnPACgg5MNumXBR0McuTEip6/c76lY > BacAoIANCG/ZGas/yhiGEbw4U7xqDYeI > =PMoQ > -----END PGP SIGNATURE----- > -- “If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help”. ~ Padlipsky 

plugin.h: update prototype of plugin_call dummy in !ENABLE_PLUGIN case Commit 2db5a0ac3e053857d97e468de53e70a605f54561 adds two arguments to plugin_call(...), but missed the !ENABLE_PLUGIN case. With !ENABLE_PLUGIN, plugin_call(...) is only a dummy, so add these two parameters there too. --- plugin.h | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) This is my first patch with git, is everything correct? This patch is against the allmerged branch. Regards, Stefan diff --git a/plugin.h b/plugin.h index 846973f..9d48651 100644 --- a/plugin.h +++ b/plugin.h @@ -174,7 +174,9 @@ plugin_call (const struct plugin_list *pl, const int type, const struct argv *av, struct plugin_return *pr, - struct env_set *es) + struct env_set *es, + int current_cert_depth, + X509 *current_cert); { return 0; } -- 1.7.4 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/02/11 16:09, Samuli Seppänen wrote: | This change adds ENABLE_PASSWORD_SAVE to config-win32.h. This option is also | defined in win/settings.in, but it does not have any effect there. | --- | config-win32.h | 3 +++ | 1 files changed, 3 insertions(+), 0 deletions(-) | All patches (01-13 + the extra additional patch) have been applied to the beta2.2 branch and is pushed out to the git tree. [PATCH 01/13] Added ENABLE_PASSWORD_SAVE to config-win32.h	commit 980d44047f4ab1541f80df1c9c2cfe6a2c572af8 [PATCH 02/13] Added a nmake makefile for openvpnserv.exe building	commit da51a175ed364ae8d41950858d8ebb2a25b742ee [PATCH 03/13] Moved TAP-driver version info to version.m4. Cleaned up ~ win/settings.in.	commit 9e178ebe41233c228a3f76c1adb623a633057249 [PATCH 04/13] Added helper functionality to win/wb.py	commit a8220492b30f2780c55c57d110253f310c170b73 [PATCH 05/13] Added support for viewing config-win32.h paramters to ~ win/show.py	commit 3b44aa49400647b785721e77da9c5e38eeb9fd83 [PATCH 06/13] Added comments and made small modifications to win/msvc.mak.in	commit 292cf21a64b4afb3b22a6ba19967f965b486600a [PATCH 07/13] Added command-line switch to win/build_all.py to skip TAP ~ driver building	commit 8c1c666e65db37fe680f7760c6ef52c2dd031932 [PATCH 08/13] Added configure.h and version.m4 variable parsing to ~ win/config.py	commit a7f0fc316caf3fbbe7c75866b4d8d21e2e931fc1 [PATCH 09/13] Added openvpnserv.exe building to win/build.py	commit 5e0b636ba6cb26a69ce5e863526e44d0fbd33ffc [PATCH 10/13] Added comments to win/build_ddk.py	commit 26e127cd59e07825a0785db2247fdac76ff01693 [PATCH 11/13] Several modifications to win/make_dist.py to allow building the ~ NSI installer	commit 4e4aa65e9df1bfe4b9726eacea2c75cad32c0927 [PATCH 12/13] Copied install-win32/setpath.nsi to win/setpath.nsi	commit 21c60e9f11d8d53c11611ea66698afea9c0350ef [PATCH 13/13] Added first version of NSI installer script to win/openvpn.nsi	commit 3b315a57d579d9ba8e259216f722094f1c1dbcde [PATCH] Changes to buildsystem patchset	commit c75a8976f070ef86cfced71b3df5cbce0e32e01a kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1pl5UACgkQDC186MBRfrp8qACfcyglwAMWVKgeKtWzQyLZbgfI uJYAnRTzTkgzLFbnx9+Vn98MnDCS4Mgk =iUJx -----END PGP SIGNATURE----- 

Hi, On Sat, Feb 26, 2011 at 11:31:20AM +0000, Olivier Van Acker wrote: > > This doesn't help me a single bit if I'm sitting behind a firewall that > > Ah, sorry, I re-read what you were saying, I cherry picked the word > paralelI without reading the rest :-P No, SCTP won't help with this ... and I agree that it's not directly SCTP related - it's just that "these bits of the code would need to be changed anyway, so maybe this can be done in a nicely extensible way". gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/02/11 12:25, Gert Doering wrote: | Hi, | | On Sat, Feb 26, 2011 at 11:19:19AM +0000, Olivier Van Acker wrote: |>> The code parts in question inside OpenVPN (socket.c) are somewhat |>> complicated due to lots of existing options and lots of existing |>> operating systems being supported, so this will not be a trivial |>> task. |> |> Would it be a good idea to limit the scope of this project by concentrating |> on one OS first? I was thinking FreeBSD first since that contains the |> reference implementation of SCTP. | | Well, you'd certainly start with one OS, but in the long run, you'd want | the mainstream OSes (Linux and Windows) as well... I second this. SCTP is really interesting for OpenVPN in my perspective, but we should rather quickly after having "something which works" support other OSes as well. When we reach that point, merging SCTP support into 'allmerged' for broader testing gets interesting. If Linux gets support quickly, I'm able to test this out pretty soonish in a limited prod environment. Some practical details. General info about the development process can be found here: <https://community.openvpn.net/openvpn/wiki/DeveloperDocumentation>, including git repositories. For the git branch to look at, JJO's IPv6 transport patches is called feat_ipv6_transport. *But* as soon as we manage to get the OpenVPN 2.2 release out the door (I'm hope I'll be able to finalise the beta2.2 branch today for the RC release), we're going to merge stuff, including JJO's branch and Gert's feat_ipv6_payload branches officially and get started with the OpenVPN 2.3 cycle. So what I'm saying, please base your stuff on JJO's branch now, but be sure your changes can be merged against the feat_ipv6_payload branch too. As I'm the one going to do the merges, I'm going to be noisy if it doesn't go smooth ;-) And just let me state that, if someone got time to do a real overhaul of socket.c, that would really be beneficial. That source file is confusing at best to read. However, we do have some source documentation patches is the wild somewhere, waiting to go in soonish too - which I'd like to see go into the 2.3 cycle. So - there's a little coordination needed to be done here with such an overhaul too. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1o6G0ACgkQDC186MBRfrrnPACgg5MNumXBR0McuTEip6/c76lY BacAoIANCG/ZGas/yhiGEbw4U7xqDYeI =PMoQ -----END PGP SIGNATURE----- 

> > > This doesn't help me a single bit if I'm sitting behind a firewall that > Ah, sorry, I re-read what you were saying, I cherry picked the word paralelI without reading the rest :-P No, SCTP won't help with this Olivier > gert > -- > USENET is *not* the non-clickable part of WWW! > // > www.muc.de/~gert/ > Gert Doering - Munich, Germany > ge...@gr... > fax: +49-89-35655025 > ge...@ne... > -- “If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help”. ~ Padlipsky 

Hi, On Sat, Feb 26, 2011 at 11:19:19AM +0000, Olivier Van Acker wrote: > > The code parts in question inside OpenVPN (socket.c) are somewhat > > complicated due to lots of existing options and lots of existing > > operating systems being supported, so this will not be a trivial > > task. > > Would it be a good idea to limit the scope of this project by concentrating > on one OS first? I was thinking FreeBSD first since that contains the > reference implementation of SCTP. Well, you'd certainly start with one OS, but in the long run, you'd want the mainstream OSes (Linux and Windows) as well... [..] > > functionality to listen on multiple sockets in parallel, > > This is somethings SCTP has build in. > One SCTP association (connection over one or more nodes) can contain > multiple independent data streams. This doesn't help me a single bit if I'm sitting behind a firewall that doesn't even let UDP/1194 pass - listening on SCTP *and* UDP/TCP in parallel will be necesary, because too many clients won't be able to use SCTP, at least when starting this. Or are you implying that by listening on a SCTP socket, the kernel machinery will also handle incoming "plain UDP" and "plain TCP" connects via that SCTP socket? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Hi, Thanks for the quick reply, > > I would find that a useful thing, but admit that I have only theoretical > knowledge about SCTP (and have no time to work on it). > > I've been reading up on SCTP and making test apps with it, I'm also in contact with Randy Stewart who is the main person behind the spec and Michael Tuexen who's done a lot of research on it, both are very helpful. I won't say I'm an expert but I think I know my way around and I'll be happy to give it a serious try. > The code parts in question inside OpenVPN (socket.c) are somewhat > complicated due to lots of existing options and lots of existing > operating systems being supported, so this will not be a trivial > task. > > Would it be a good idea to limit the scope of this project by concentrating on one OS first? I was thinking FreeBSD first since that contains the reference implementation of SCTP. > What I'd definitely recommend to do is base your work on JJO's IPv6 > transport patches, because he already changed large parts of socket.c > - so if you base your work on "plain 2.2", there will be endless conflicts. > > Yes, I'll have a closer look at the IPv6 work. > functionality to listen on multiple sockets in parallel, This is somethings SCTP has build in. One SCTP association (connection over one or more nodes) can contain multiple independent data streams. Regards, Olivier > > gert > > -- > USENET is *not* the non-clickable part of WWW! > // > www.muc.de/~gert/ > Gert Doering - Munich, Germany > ge...@gr... > fax: +49-89-35655025 > ge...@ne... > -- “If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help”. ~ Padlipsky 

Hi, On Sat, Feb 26, 2011 at 10:05:58AM +0000, Olivier Van Acker wrote: > Are there any plans to support the sctp protocol in openvpn? I would find that a useful thing, but admit that I have only theoretical knowledge about SCTP (and have no time to work on it). The code parts in question inside OpenVPN (socket.c) are somewhat complicated due to lots of existing options and lots of existing operating systems being supported, so this will not be a trivial task. What I'd definitely recommend to do is base your work on JJO's IPv6 transport patches, because he already changed large parts of socket.c - so if you base your work on "plain 2.2", there will be endless conflicts. (Personally, I hope that such an overhaul of socket.c would bring in functionality to listen on multiple sockets in parallel, like "listen on udp/1194 for normal connections, plus tcp/443 for those behind too-strict firewalls"). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Hi, Are there any plans to support the sctp protocol in openvpn? I'm especially interested in the multihoming functionality of sctp, this would enable openvpn to keep a single (sctp) socket open over multiple network interfaces. If there are no plans to implement this I wouldn't mind having a go at it myself. Regards, Olivier PS I'm already hanging out in #openvpn-devel (cyberroadie) but am not sure when is a good time to ask this question -- “If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help”. ~ Padlipsky 

Implemented changes to the buildsystem patchset suggested by jamesyonan in IRC meeting on 17th Feb 2010: 1) Remove variables added to version.m4 and use win/settings.in instead 2) Add ENABLE_<FEATURE> configuration to win/settings.in instead of parsing config-win32.h for them This patch applies on top of the previous 13 patches. --- version.m4 | 3 --- win/settings.in | 15 +++++++++++++++ win/show.py | 3 +-- win/wb.py | 39 ++++++++++++++++++--------------------- 4 files changed, 34 insertions(+), 26 deletions(-) diff --git a/version.m4 b/version.m4 index 475a82f..d914fc1 100644 --- a/version.m4 +++ b/version.m4 @@ -4,6 +4,3 @@ dnl define the TAP version define(PRODUCT_TAP_ID,[tap0901]) define(PRODUCT_TAP_WIN32_MIN_MAJOR,[9]) define(PRODUCT_TAP_WIN32_MIN_MINOR,[1]) -define(PRODUCT_TAP_RELDATE,[04/19/2010]) -define(PRODUCT_TAP_DEVICE_DESCRIPTION,[TAP-Win32 Adapter V9]) -define(PRODUCT_TAP_PROVIDER,[TAP-Win32 Provider V9]) diff --git a/win/settings.in b/win/settings.in index c349752..25109e2 100644 --- a/win/settings.in +++ b/win/settings.in @@ -5,6 +5,16 @@ # stored in this file. This is done to allow using the old and new Windows build # systems side-by-side +# Features to include +!define ENABLE_PASSWORD_SAVE 1 +!define ENABLE_CLIENT_SERVER 1 +!define ENABLE_CLIENT_ONLY +!define ENABLE_MANAGEMENT 1 +!define ENABLE_HTTP_PROXY 1 +!define ENABLE_SOCKS 1 +!define ENABLE_FRAGMENT 1 +!define ENABLE_DEBUG 1 + # Branding !define PRODUCT_NAME "OpenVPN" !define PRODUCT_UNIX_NAME "openvpn" @@ -30,6 +40,11 @@ # TAP adapter icon -- visible=0x81 or hidden=0x89 !define PRODUCT_TAP_CHARACTERISTICS 0x81 +# TAP adapter metadata. Version information in ../version.m4. +!define PRODUCT_TAP_RELDATE "04/19/2010" +!define PRODUCT_TAP_DEVICE_DESCRIPTION "TAP-Win32 Adapter V9" +!define PRODUCT_TAP_PROVIDER "TAP-Win32 Provider V9" + # Build debugging version of TAP driver ;!define PRODUCT_TAP_DEBUG diff --git a/win/show.py b/win/show.py index 6b1140a..6cfebf2 100644 --- a/win/show.py +++ b/win/show.py @@ -1,9 +1,8 @@ -from wb import get_config, get_build_params +from wb import get_config from js import JSON def main(): print JSON().encode(get_config()) - print JSON().encode(get_build_params()) # if we are run directly, and not loaded as a module if __name__ == "__main__": diff --git a/win/wb.py b/win/wb.py index 2d7bd61..d4f8203 100644 --- a/win/wb.py +++ b/win/wb.py @@ -21,7 +21,7 @@ def get_config(): def get_build_params(): kv = {} - parse_config_win32_h(kv,home_fn('config-win32.h')) + parse_build_params(kv,mod_fn('settings.in')) return kv @@ -80,34 +80,18 @@ def parse_settings_in(kv, settings_in): kv[g[0]] = g[1] or '' f.close() -def parse_config_win32_h(kv, config_win32_h): - r = re.compile(r'^#define\s+(ENABLE_\w+)\s+(\w+)') - s = re.compile(r'^#ifdef|^#ifndef') - e = re.compile(r'^#endif') +def parse_build_params(kv, settings_in): + r = re.compile(r'^!define\s+(ENABLE_\w+)\s+(\w+)') - # How "deep" in nested conditional statements are we? - depth=0 - - f = open(config_win32_h) + f = open(settings_in) for line in f: line = line.rstrip() - # Check if this is a #define line starting with ENABLE_ + # Check if this is a #define line starts with ENABLE_ m = re.match(r, line) - # Calculate how deep we're in (nested) conditional statements. A simple - # #ifdef/#endif state switcher would get confused by an #endif followed - # by a #define. - if re.match(s, line): - depth=depth+1 - if re.match(e, line): - depth=depth-1 - if m: - # Only add this #define if it's not inside a conditional statement - # block - if depth == 0: g = m.groups() kv[g[0]] = g[1] or '' f.close() @@ -129,20 +113,33 @@ def build_autodefs(kv, autodefs_in, autodefs_out): def build_configure_h(kv, configure_h_out, head_comment): """Generate a configure.h dynamically""" fout = open(configure_h_out, 'w') + + # These two variables are required to view build parameters during runtime configure_defines='#define CONFIGURE_DEFINES \"' configure_call='#define CONFIGURE_CALL \" config_all.py \"' + # Initialize the list of enabled features + features = '' + + # Write the header fout.write(head_comment) dict = get_build_params() for key, value in dict.iteritems(): + # Add enabled features +	features = features + "#define " + key + " " + value + "\n" + +	# Add each enabled feature to CONFIGURE_DEFINES list configure_defines = configure_defines + " " + key + "=" + value + "," configure_defines = configure_defines + "\"" + "\n" + fout.write(features) fout.write(configure_defines) fout.write(configure_call) + + fout.close() def build_version_m4_vars(version_m4_vars_out, head_comment): -- 1.6.3.3 

Hi, Here's the summary of the previous community meeting. --- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net Date: Thursday, 17th Feb 2011 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2011-02-17> 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, ecrist, jamesyonan, mattock and psha were present in this meeting. -- Discussed mattock's buildsystem patchset: <http://thread.gmane.org/gmane.network.openvpn.devel/4406> Jamesyonan gave the patchset his ACK if it's modified slightly: 1) Remove variables added to version.m4 and use win/settings.in instead 2) Add ENABLE_<FEATURE> configuration to win/settings.in instead of parsing config-win32.h for them Mattock will provide modified patches after which the patchset can be merged to beta2.2 branch. -- Discussed "Coverity Scan" project briefly. Mattock contacted Coverity yesterday asking them to grant a few new developers access to the OpenVPN "Scan" results. He also asked them to update the codebase they're tracking, which is obsolete. There has not been any reply from Coverity yet. -- Discussed t_client.rc + buildbot integration. Today mattock configured buildbot to run "make check" after "make". This means that automated connection test script, "t_client.sh", is run after each build. However, currently all IPv6 tests on all buildslaves fail, causing buildbot to (incorrectly) mark every build as FAILED. Decided to turn off IPv6 tests until buildslaves are configured to properly handle IPv6 payload over IPv4 transport. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

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-02-17> 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 

Am 16.02.2011 22:55, schrieb Gilles Espinasse: > Seen with gcc-4.4.5 and -Wformat -Wformat-security > > Signed-off-by: Gilles Espinasse <g....@fr...> > --- > options.c | 6 +++--- > push.c | 4 ++-- > 2 files changed, 5 insertions(+), 5 deletions(-) Good catch, patch approved. -- Matthias Andree 

Hi all, Lately I've been thinking of ways to improve our ACK/NACK system so that patches could get merged _or_ rejected faster. There have some cases where no clear resolution has been reached, one example being the floating-tls patch[1]. The way I see it, whether a patch should be merged into OpenVPN depends on two factors: a) Does it make sense (feature-vise) to include the patch in OpenVPN? b) Is the patch of good quality / does it follow our coding conventions? Of these a) should be the primary consideration, after which b) can be looked into. In some cases determining a) is trivial, e.g. if the patch fixes a bug. Similarly, determining b) should be easy most of the time. Only patches which add, modify or remove features may require in-depth discussion on b). Although all of this is obvious, I've noted that very few non-developers have participated in the ACK/NACK system, even they would be perfectly capable of handling a). A good example is the DHCP filtering patch[2]. Therefore, I propose the following formal modification to the ACK/NACK system: - anybody can give a "Feature ACK/NACK" (a) for any given patch; or, in other words saying "this patch is worth/not worth including" - once (a) is given, a developer can give "Code ACK/NACK" (b), which will result in merging the patch or in request to modify the patch To avoid adding extra layer of bureaucracy both ACKs (a+b) could be given by the same person. I believe this approach would give us several benefits: - allow more people to participate in the ACK/NACK work - reduce workload of the developers (due to ^^^) - help focus on a) before b) - allow quicker rejection of "this does not make sense" type patches - allow sharing responsibility in giving an ACK (e.g. if developer can't give a "Feature ACK", but can still give a "Code ACK") Any thoughts? -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock [1] <http://thread.gmane.org/gmane.network.openvpn.devel/4213> <http://thread.gmane.org/gmane.network.openvpn.devel/4378> <http://article.gmane.org/gmane.network.openvpn.devel/4221> [2] <https://forums.openvpn.net/topic7479.html> 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/02/11 22:55, Gilles Espinasse wrote: | Seen with gcc-4.4.5 and -Wformat -Wformat-security | | Signed-off-by: Gilles Espinasse<g....@fr...> | --- | options.c | 6 +++--- | push.c | 4 ++-- | 2 files changed, 5 insertions(+), 5 deletions(-) Thank you very much, but I'm sorry to be a party killer ... this is already implemented in the beta2.2, bugfix2.1 and allmerged branches. commit d6b783a8ec505c8e158bd0304c5e195cff5bb8c3 Author: David Sommerseth <da...@us...> Date: Fri Sep 17 17:10:25 2010 +0200 ~ Fixed compiler warnings reported on Ubuntu 10.04 ~ The warnings reported where: ~ -------------------------------------------------------- ~ misc.c:158: warning: ignoring return value of ?nice?, declared with ~ attribute warn_unused_result ~ options.c:4033: warning: format not a string literal and no format ~ arguments ~ options.c:4043: warning: format not a string literal and no format ~ arguments ~ options.c:4053: warning: format not a string literal and no format ~ arguments ~ push.c:182: warning: format not a string literal and no format arguments ~ push.c:199: warning: format not a string literal and no format arguments ~ push.c:235: warning: format not a string literal and no format arguments ~ status.c:171: warning: ignoring return value of ?ftruncate?, declared ~ with attribute warn_unused_result ~ -------------------------------------------------------- ~ Signed-off-by: David Sommerseth <da...@us...> ~ Acked-by: Gert Doering <ge...@gr...> ~ Acked-by: Peter Stuge <pe...@st...> But good catch! Please be sure you check against at least the allmerged branch in the future, and you might avoid dumping into this issue again. And kudos for using the git tree and git send-email! We're also in the last stages of finalising the 2.2-RC release, so in the near future beta2.2 will become our master branch. The git tree will go through some minor changes, and we will simplify where to grab the correct code. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1cZc4ACgkQDC186MBRfrocIwCfUqNQIH/0D+OGZrNoW4QeauDg AqIAoJ29S4PtV3NCiPQxnq4GldOS+sAK =SNZs -----END PGP SIGNATURE----- 

Gilles Espinasse wrote: > Seen with gcc-4.4.5 and -Wformat -Wformat-security > > Signed-off-by: Gilles Espinasse <g....@fr...> Acked-by: Peter Stuge <pe...@st...> 

Seen with gcc-4.4.5 and -Wformat -Wformat-security Signed-off-by: Gilles Espinasse <g....@fr...> --- options.c | 6 +++--- push.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/options.c b/options.c index 5f1efc5..208db30 100644 --- a/options.c +++ b/options.c @@ -4002,7 +4002,7 @@ add_option (struct options *options, { if (options->inetd != -1)	{ - msg (msglevel, opterr); + msg (msglevel, "%s", opterr); goto err;	} else @@ -4012,7 +4012,7 @@ add_option (struct options *options, { if (options->inetd != -1)	{ - msg (msglevel, opterr); + msg (msglevel, "%s", opterr); goto err;	} else @@ -4022,7 +4022,7 @@ add_option (struct options *options, { if (name != NULL)	{ - msg (msglevel, opterr); + msg (msglevel, "%s", opterr); goto err;	} name = p[z]; diff --git a/push.c b/push.c index 9ddc900..86ac4a7 100644 --- a/push.c +++ b/push.c @@ -178,7 +178,7 @@ send_push_reply (struct context *c) const int extra = 64; /* extra space for possible trailing ifconfig and push-continuation */ const int safe_cap = BCAP (&buf) - extra; - buf_printf (&buf, cmd); + buf_printf (&buf, "%s", cmd); while (e) { @@ -194,7 +194,7 @@ send_push_reply (struct context *c) goto fail;	multi_push = true;	buf_reset_len (&buf); -	buf_printf (&buf, cmd); +	buf_printf (&buf, "%s", cmd); } } if (BLEN (&buf) + l >= safe_cap) -- 1.7.3.4