openvpn-devel Mailing List for OpenVPN (Page 3)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/05/12 18:55, Alon Bar-Lev wrote: > Hello, > > Now, I also have the courage to ask one more question regarding > build.... > > We currently have: - auth-pam - defer - down-root - examples I'm just giving a summary here of the discussion, how I see the discussion. And hope we can close this one soon. The thread is long and many of the arguments are repeated several times. Basically, the situation is as now: Those who opposes a split now are Adriaan, Gert and I, which are all active with development in the tree. Seth has also voted against. And Eric says "not before v3.0". Those in favour are Alon, Samuli and Eric after v3.0. - ---------------------------------------------- Then let's look at the commit history for these plug-ins which are discussed. The git log goes back to the old BETA21 SVN branch. auth-pam/auth-pam.c - 17 changes auth-pam/pamdl.c - 7 changes auth-pam/pamdl.h - 6 changes down-root/down-root.c - 12 changes That is the total number of changes to each of these files since September 26, 2005. Further, all *nix platforms have the concept of root users and can do seteuid() stuff (which makes down-root useful) and all uses PAM as recommended default (which makes auth-pam useful) - ----------------------------------------------- So to summarize it, how I see it: * There is resistance to such a split * These modules are generally useful on all *nix platforms * They are not requiring a lot of extra maintenance at all currently * Current inclusion in main tree makes package maintainers more happy When the maintenance burden of having these *two* plug-ins in the main tree gets so big it affects the core openvpn development and release cycles - that's the time it is appropriate to consider a split. So, please! Can we rather spend our precious time and energy to fix *real* bugs? <https://community.openvpn.net/openvpn/report/1> And this is the last thing I'm going to say in this discussion. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+v+T0ACgkQDC186MBRfrp5TACfeIKA5P2GBfKVO031KnXpmo2W UEkAoJEsZEgN7y5z9qcPjHa1/C3U5i6b =1/kX -----END PGP SIGNATURE----- 

On Sun, May 13, 2012 at 4:07 PM, Gert Doering <ge...@gr...> wrote: > Hi, > > On Sun, May 13, 2012 at 03:24:59PM +0300, Alon Bar-Lev wrote: >> > If we ignore the examples, we really only have "auth-pam" and "down-root" >> > in the main distribution today, and those are useful in many cases - so >> > I'd go for "always build and install them". >> >> And always have pam dependency for this example? > > FreeBSD, NetBSD, all Linuxes and Solaris have PAM anyway. > > So make this "if pam libraries + headers are detected, install auth-pam, > otherwise, not". We already discussed the automatic detection and integrity failure as result. > >> These plugins should be optional I don't see any value in enforcing >> them and their dependencies. > > If these plugins are useful for a large number of users, there is no > point in not installing them by default. They are not. Exactly because the are not useful, I am for the split. Anyway, if you follow the apache example there is explicit enable/disable to each. BTW: Packager of what platform are you? Alon. 

Hi, On Sun, May 13, 2012 at 03:24:59PM +0300, Alon Bar-Lev wrote: > > If we ignore the examples, we really only have "auth-pam" and "down-root" > > in the main distribution today, and those are useful in many cases - so > > I'd go for "always build and install them". > > And always have pam dependency for this example? FreeBSD, NetBSD, all Linuxes and Solaris have PAM anyway. So make this "if pam libraries + headers are detected, install auth-pam, otherwise, not". > These plugins should be optional I don't see any value in enforcing > them and their dependencies. If these plugins are useful for a large number of users, there is no point in not installing them by default. 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... 

On Sun, May 13, 2012 at 3:19 PM, Gert Doering <ge...@gr...> wrote: > Hi, > > On Sun, May 13, 2012 at 02:26:05PM +0300, Alon Bar-Lev wrote: >> OK... now you are talking... so you say that like apache we need to >> integrate the plugins to main build system, this was the other >> alternative. > > This would make more sense to me.  Either have them as optional > "configure" components, or just build and install all of them all > the time. > > If we ignore the examples, we really only have "auth-pam" and "down-root" > in the main distribution today, and those are useful in many cases - so > I'd go for "always build and install them". And always have pam dependency for this example? These plugins should be optional I don't see any value in enforcing them and their dependencies. Alon. 

Hi, On Sun, May 13, 2012 at 02:26:05PM +0300, Alon Bar-Lev wrote: > OK... now you are talking... so you say that like apache we need to > integrate the plugins to main build system, this was the other > alternative. This would make more sense to me. Either have them as optional "configure" components, or just build and install all of them all the time. If we ignore the examples, we really only have "auth-pam" and "down-root" in the main distribution today, and those are useful in many cases - so I'd go for "always build and install them". 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... 

Hello Seth, Thank you this is interesting. I don't know pfSense... do you have the nation of plugin which is independent from the core? I mean pre-defined interface, which is backward compatible? I looked briefly on the source tree and did not find my way... A counter example of nagios is cacti... which provides plugins as their own... :) So basically you think that openvpn or openvpn-plugin package should install all plugins, and depend on the union of all, right? Alon. On Sun, May 13, 2012 at 2:40 PM, Seth Mos <set...@dd...> wrote: > Chiming in here, > > Although pfSense is basically a giant tarbal, it has the benefit of being sure that all parts of it fit together. We also have installable packages and we frequently see issues with that. We are trying to solve some of them using PBI packages just so that each "package" always has it's dependencies in check. > > Although we are just a "consumer", we'd rather have a single FreeBSD port that we build then 5 ports we need to update, with all the required dependencies. > > Our github repo is split into one for packages, tools and pfSense. But each is really a standalone thing, because there is no overlap. Which probably my point, the plugin is useless without the main. > > The one git repo for pfSense is pretty manageable, even more so through git with Pull requests. The single biggest jump in commits and patches from the community is moving to GitHub. It makes contributions so much easier. That said, even for us the amount of simultaneous active coders is about 5, although we do see small patches and pull requests from about 30 or so people a year. > > I see nagios using nagios-plugins, that has seperate releases from the main nagios. So there's that too. > > Just a few thoughts from the other end. > > Really, really, _really_ looking forward to Viscosity and Tunnelblick shipping Ipv6 enabled clients. Pretty please. > > Cheers, > > Seth > pfSense developer > > Op 13 mei 2012, om 13:12 heeft Gert Doering het volgende geschreven: > >> Hi, >> >> On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote: >>>>> Can't we progress? >>>> >>>> Why is that progress? >>>> >>>> Change always has drawbacks.  If the plus sides outweighs the drawbacks, >>>> change is good.  Change for change's sake, "just because you can change >>>> it", is not. >>> >>> Yes, but still from your responses I don't see any drawback... maybe I >>> am slow learner... >> >> Drawback to maintainers and sysadmins has already been mentioned by >> ecrist and me.  Try being a sysadmin for a few weeks and figure out >> which bits of xorg you need to download to install xinit, assuming >> you have a system without any X libraries and headers yet (in the xorg >> example: splitting off "xinit" might actually make sense, but splitting >> the basic infrastructure to build anything into about 50 different >> "xyz-library" and "xyz-headers" packages is crazyness). >> >> But the onus is not particularily on me: you have not put forward >> convincing arguments why splitting off a very small number of files >> that only make use in the context of OpenVPN into their own repository >> has any *advantage*. >> >> The handwavy argument "it will attract more users!" can be countered by >> similarily handwaving "I, as a user, hate to download multiple packages >> to figure out how to start contributing, and so it will scare *away* >> users". >> >> >> As a counterexample, look at Apache.  They have heaps of modules in >> the main tarball, and have no issues with frequent release and with >> attracting developers.  And still, modules maintained by non-apache >> developers can be developed externally, without having to splitt off >> all existing modules beforehand. >> >> 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... >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ >> Openvpn-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel > 

Chiming in here, Although pfSense is basically a giant tarbal, it has the benefit of being sure that all parts of it fit together. We also have installable packages and we frequently see issues with that. We are trying to solve some of them using PBI packages just so that each "package" always has it's dependencies in check. Although we are just a "consumer", we'd rather have a single FreeBSD port that we build then 5 ports we need to update, with all the required dependencies. Our github repo is split into one for packages, tools and pfSense. But each is really a standalone thing, because there is no overlap. Which probably my point, the plugin is useless without the main. The one git repo for pfSense is pretty manageable, even more so through git with Pull requests. The single biggest jump in commits and patches from the community is moving to GitHub. It makes contributions so much easier. That said, even for us the amount of simultaneous active coders is about 5, although we do see small patches and pull requests from about 30 or so people a year. I see nagios using nagios-plugins, that has seperate releases from the main nagios. So there's that too. Just a few thoughts from the other end. Really, really, _really_ looking forward to Viscosity and Tunnelblick shipping Ipv6 enabled clients. Pretty please. Cheers, Seth pfSense developer Op 13 mei 2012, om 13:12 heeft Gert Doering het volgende geschreven: > Hi, > > On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote: >>>> Can't we progress? >>> >>> Why is that progress? >>> >>> Change always has drawbacks. If the plus sides outweighs the drawbacks, >>> change is good. Change for change's sake, "just because you can change >>> it", is not. >> >> Yes, but still from your responses I don't see any drawback... maybe I >> am slow learner... > > Drawback to maintainers and sysadmins has already been mentioned by > ecrist and me. Try being a sysadmin for a few weeks and figure out > which bits of xorg you need to download to install xinit, assuming > you have a system without any X libraries and headers yet (in the xorg > example: splitting off "xinit" might actually make sense, but splitting > the basic infrastructure to build anything into about 50 different > "xyz-library" and "xyz-headers" packages is crazyness). > > But the onus is not particularily on me: you have not put forward > convincing arguments why splitting off a very small number of files > that only make use in the context of OpenVPN into their own repository > has any *advantage*. > > The handwavy argument "it will attract more users!" can be countered by > similarily handwaving "I, as a user, hate to download multiple packages > to figure out how to start contributing, and so it will scare *away* > users". > > > As a counterexample, look at Apache. They have heaps of modules in > the main tarball, and have no issues with frequent release and with > attracting developers. And still, modules maintained by non-apache > developers can be developed externally, without having to splitt off > all existing modules beforehand. > > 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... > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

On Sun, May 13, 2012 at 2:12 PM, Gert Doering <ge...@gr...> wrote: > Hi, > > On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote: >> >> Can't we progress? >> > >> > Why is that progress? >> > >> > Change always has drawbacks.  If the plus sides outweighs the drawbacks, >> > change is good.  Change for change's sake, "just because you can change >> > it", is not. >> >> Yes, but still from your responses I don't see any drawback... maybe I >> am slow learner... > > Drawback to maintainers and sysadmins has already been mentioned by > ecrist and me.  Try being a sysadmin for a few weeks and figure out > which bits of xorg you need to download to install xinit, assuming > you have a system without any X libraries and headers yet (in the xorg > example: splitting off "xinit" might actually make sense, but splitting > the basic infrastructure to build anything into about 50 different > "xyz-library" and "xyz-headers" packages is crazyness). First, I was gentoo developer for some time, and maintained, among other, openvpn packages. The case of xorg is not similar, you keep using this example while in the openvpn case we have a core and a set of optional plugins, that's all. So please give appropriate example. One example of your approach is the bluez project, which insist of using in-tree plugins not because it is the simpler approach, but this way it can enforce GPL license on all plugins and make sure they are stay opened. > But the onus is not particularily on me: you have not put forward > convincing arguments why splitting off a very small number of files > that only make use in the context of OpenVPN into their own repository > has any *advantage*. I think I already stated some advantages, you can ether accept or reject but at least they are focus on the subject at hand: 1. we remove dependencies from the core openvpn package. 2. we can release a fix in plugin without releasing the complete openvpn. 3. plugins are optional, user may install the plugin as separate pacakge if needed. 4. we can delegate maintenance of plugin. 5. we can attract more people to the community. 6. simpler to track the history of atomic components in the mean of source control. > > The handwavy argument "it will attract more users!" can be countered by > similarily handwaving "I, as a user, hate to download multiple packages > to figure out how to start contributing, and so it will scare *away* > users". Hmmmm... I think that you are at the xorg example again... > As a counterexample, look at Apache.  They have heaps of modules in > the main tarball, and have no issues with frequent release and with > attracting developers.  And still, modules maintained by non-apache > developers can be developed externally, without having to splitt off > all existing modules beforehand. OK... now you are talking... so you say that like apache we need to integrate the plugins to main build system, this was the other alternative. > > 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, On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote: > >> Can't we progress? > > > > Why is that progress? > > > > Change always has drawbacks.  If the plus sides outweighs the drawbacks, > > change is good.  Change for change's sake, "just because you can change > > it", is not. > > Yes, but still from your responses I don't see any drawback... maybe I > am slow learner... Drawback to maintainers and sysadmins has already been mentioned by ecrist and me. Try being a sysadmin for a few weeks and figure out which bits of xorg you need to download to install xinit, assuming you have a system without any X libraries and headers yet (in the xorg example: splitting off "xinit" might actually make sense, but splitting the basic infrastructure to build anything into about 50 different "xyz-library" and "xyz-headers" packages is crazyness). But the onus is not particularily on me: you have not put forward convincing arguments why splitting off a very small number of files that only make use in the context of OpenVPN into their own repository has any *advantage*. The handwavy argument "it will attract more users!" can be countered by similarily handwaving "I, as a user, hate to download multiple packages to figure out how to start contributing, and so it will scare *away* users". As a counterexample, look at Apache. They have heaps of modules in the main tarball, and have no issues with frequent release and with attracting developers. And still, modules maintained by non-apache developers can be developed externally, without having to splitt off all existing modules beforehand. 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... 

On Sun, May 13, 2012 at 12:35 PM, Gert Doering <ge...@gr...> wrote: > Hi, > > On Sun, May 13, 2012 at 12:30:37PM +0300, Alon Bar-Lev wrote: >> An healthy community dealing with openvpn need to gather all resources >> that are acting at that niche. >> There is no reason why we should not invite these maintainer to be >> part of the openvpn project, on the contrary, we gain more resources, >> more professionals. > > And how exactly will "fragment the openvpn source tree into many small > packages" invite more contribution? > > I, for one, will think twice about contributing to a project where I have > to figure out which of the 470 packages I need to download before I can > even *start* looking at things. > >> Why should we define the scope of the openvpn project based on the >> legacy james svn tree? > > Why not? > >> Can't we progress? > > Why is that progress? > > Change always has drawbacks.  If the plus sides outweighs the drawbacks, > change is good.  Change for change's sake, "just because you can change > it", is not. Yes, but still from your responses I don't see any drawback... maybe I am slow learner... I try to summarize people view and get: 1. it is hard to push changes to specific git repository... it is not actually hard though. 2. it is hard to maintain several packages at distro level, well, as shown in the other examples and plugins it is not the case. 3. it will grow to 500 packages like xorg, while it is not the case even in nightmares... and we are talking about pure optional components. > >> I would like to see this community growing... all UI/management/plugin >> developers working under the same roof. >> >> It is healthy to the project = more resources. >> It is healthy to the users = one stop shop, better integration. > > *one stop*.  Thanks for saying that.  This is a strong argument against > fragmenting our source tree. > > (I see you coming up with "why not have the different platform backends > in their own repositories each, because a FreeBSD developer would not > need the source files for Linux" next - and there is madness, not sanity) Well, not for now.... :) Although the thought came to mind when evaluating the polarssl implementation... Alon. 

Hi, On Sun, May 13, 2012 at 12:30:37PM +0300, Alon Bar-Lev wrote: > An healthy community dealing with openvpn need to gather all resources > that are acting at that niche. > There is no reason why we should not invite these maintainer to be > part of the openvpn project, on the contrary, we gain more resources, > more professionals. And how exactly will "fragment the openvpn source tree into many small packages" invite more contribution? I, for one, will think twice about contributing to a project where I have to figure out which of the 470 packages I need to download before I can even *start* looking at things. > Why should we define the scope of the openvpn project based on the > legacy james svn tree? Why not? > Can't we progress? Why is that progress? Change always has drawbacks. If the plus sides outweighs the drawbacks, change is good. Change for change's sake, "just because you can change it", is not. > I would like to see this community growing... all UI/management/plugin > developers working under the same roof. > > It is healthy to the project = more resources. > It is healthy to the users = one stop shop, better integration. *one stop*. Thanks for saying that. This is a strong argument against fragmenting our source tree. (I see you coming up with "why not have the different platform backends in their own repositories each, because a FreeBSD developer would not need the source files for Linux" next - and there is madness, not sanity) 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... 

On Sun, May 13, 2012 at 12:23 PM, Gert Doering <ge...@gr...> wrote: > Hi, > > On Sun, May 13, 2012 at 12:10:48PM +0300, Alon Bar-Lev wrote: >> And, if not split, they these two plugins should integrated within >> build system. > > This is certainly true. > >> The custom make files are not doing any good, but I >> still don't understand the difference between these two and other >> plugins out there. > > They are maintained by the openvpn project, and other plugins are not. > > That difference should be quite obious, no? This is exactly my point. An healthy community dealing with openvpn need to gather all resources that are acting at that niche. There is no reason why we should not invite these maintainer to be part of the openvpn project, on the contrary, we gain more resources, more professionals. Why should we define the scope of the openvpn project based on the legacy james svn tree? Can't we progress? I would like to see this community growing... all UI/management/plugin developers working under the same roof. It is healthy to the project = more resources. It is healthy to the users = one stop shop, better integration. Alon. 

Hi, On Sun, May 13, 2012 at 12:10:48PM +0300, Alon Bar-Lev wrote: > And, if not split, they these two plugins should integrated within > build system. This is certainly true. > The custom make files are not doing any good, but I > still don't understand the difference between these two and other > plugins out there. They are maintained by the openvpn project, and other plugins are not. That difference should be quite obious, no? 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... 

On Sun, May 13, 2012 at 12:01 PM, Gert Doering <ge...@gr...> wrote: > Try to build Xorg or teTeX yourself, from packages, and learn from it. We are not xorg... [yet]. Anyway, I think the modular xorg and kde processes are a great success. It allowed them to delegate maintenance, and handle shorter release cycles for each component. Now people can update their xinit without receiving ~50 unneeded changes. Stabilization process is also much shorter now, as most of the components are static. I showed Eric that the freebsd already maintains[1] the auth-radius, auth-ldap in modular way. Not sure why the auth-pam and down-root are any different. We need to strive to join efforts with these other plugin maintainer, hosting them on the openvpn project resources, and build healthy community. And, if not split, they these two plugins should integrated within build system. The custom make files are not doing any good, but I still don't understand the difference between these two and other plugins out there. Alon. [1] http://www.freebsd.org/cgi/ports.cgi?query=openvpn&stype=all 

Hi, On Sat, May 12, 2012 at 05:22:52PM -0400, Eric Crist wrote: > My two cents on this is as follows: > > As a package maintainer, I think this is going to prove to be a lot of > work. It means there are more packages to maintain, over the one I > need to now. Yeah. From a sysadmin perspective, super-modular projects like Xorg or teTeX really make my life miserable - and I do not see particular gain in moving things that are part of "the openvpn package" into separate projects. (Windows TAP is fine, as it's really a project on its own, useful for openvpn, but not that closely tied to it) > HOWEVER, from the OpenVPN development process, I think it's best > to split things out, as Alon suggests, with one caveat. Let's wait > for 3.0. That's already going to be a massive change to our source > tree and overall build process, and I think it would be the right > time to push that out. Even then. Modular source doesn't mean everything gets fragmented in 500 teeny little packages where package maintainers or sysadmins have to figure out which 395 of those they need, and which ones can be skipped. Try to build Xorg or teTeX yourself, from packages, and learn from it. 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... 

My two cents on this is as follows: As a package maintainer, I think this is going to prove to be a lot of work. It means there are more packages to maintain, over the one I need to now. HOWEVER, from the OpenVPN development process, I think it's best to split things out, as Alon suggests, with one caveat. Let's wait for 3.0. That's already going to be a massive change to our source tree and overall build process, and I think it would be the right time to push that out. Hope this helps. ----- Eric F Crist 

On Sat, May 12, 2012 at 10:31 PM, Alon Bar-Lev <alo...@gm...> wrote: > Platform independent interface for tun provider. > > Split the long tun.c into platform specific files using > tun_engine interface. > > There is more to be done in order to clean up the code, > however this is a good starting point. > > Signed-off-by: Alon Bar-Lev <alo...@gm...> > --- >  configure.ac                             |    6 + >  src/openvpn/Makefile.am                  |   12 + >  src/openvpn/error.c                      |    2 +- >  src/openvpn/forward.c                    |   28 +- >  src/openvpn/helper.c                     |    2 +- >  src/openvpn/init.c                       |   41 +- >  src/openvpn/multi.c                      |    2 +- >  src/openvpn/options.c                    |   20 +- >  src/openvpn/options.h                    |    5 +- >  src/openvpn/route.c                      |    1 + >  src/openvpn/sig.c                        |    4 +- >  src/openvpn/syshead.h                    |   56 - >  src/openvpn/tun-engine-common-bsd.c      |  103 + >  src/openvpn/tun-engine-common-bsd.h      |   34 + >  src/openvpn/tun-engine-common.c          |  518 +++ >  src/openvpn/tun-engine-common.h          |   85 + >  src/openvpn/tun-engine-darwin.c          |  226 ++ >  src/openvpn/tun-engine-dragonfly.c       |  193 ++ >  src/openvpn/tun-engine-freebsd.c         |  229 ++ >  src/openvpn/tun-engine-generic.c         |   97 + >  src/openvpn/tun-engine-linux-options.h   |   37 + >  src/openvpn/tun-engine-linux.c           |  515 +++ >  src/openvpn/tun-engine-netbsd.c          |  318 ++ >  src/openvpn/tun-engine-openbsd.c         |  259 ++ >  src/openvpn/tun-engine-options.h         |   37 + >  src/openvpn/tun-engine-solaris.c         |  491 +++ >  src/openvpn/tun-engine-windows-options.h |   92 + >  src/openvpn/tun-engine-windows-util.h    |   83 + >  src/openvpn/tun-engine-windows.c         | 2757 ++++++++++++++++ >  src/openvpn/tun-engine.h                 |   95 + >  src/openvpn/tun.c                        | 5019 ++---------------------------- >  src/openvpn/tun.h                        |  457 +--- >  32 files changed, 6542 insertions(+), 5282 deletions(-) >  create mode 100644 src/openvpn/tun-engine-common-bsd.c >  create mode 100644 src/openvpn/tun-engine-common-bsd.h >  create mode 100644 src/openvpn/tun-engine-common.c >  create mode 100644 src/openvpn/tun-engine-common.h >  create mode 100644 src/openvpn/tun-engine-darwin.c >  create mode 100644 src/openvpn/tun-engine-dragonfly.c >  create mode 100644 src/openvpn/tun-engine-freebsd.c >  create mode 100644 src/openvpn/tun-engine-generic.c >  create mode 100644 src/openvpn/tun-engine-linux-options.h >  create mode 100644 src/openvpn/tun-engine-linux.c >  create mode 100644 src/openvpn/tun-engine-netbsd.c >  create mode 100644 src/openvpn/tun-engine-openbsd.c >  create mode 100644 src/openvpn/tun-engine-options.h >  create mode 100644 src/openvpn/tun-engine-solaris.c >  create mode 100644 src/openvpn/tun-engine-windows-options.h >  create mode 100644 src/openvpn/tun-engine-windows-util.h >  create mode 100644 src/openvpn/tun-engine-windows.c >  create mode 100644 src/openvpn/tun-engine.h > Too large for mailing list. Please review at[1][2]. Alon. [1] https://github.com/alonbl/openvpn/commit/c0c64bfa5369fb4abe7045a995fae2d33a34570f [2] https://github.com/alonbl/openvpn/commit/c0c64bfa5369fb4abe7045a995fae2d33a34570f.patch 

It is a wrapper of frame_add_to_extra_tun, no sense to keep both around. Signed-off-by: Alon Bar-Lev <alo...@gm...> --- src/openvpn/init.c | 2 +- src/openvpn/tun.h | 6 ------ 2 files changed, 1 insertions(+), 7 deletions(-) diff --git a/src/openvpn/init.c b/src/openvpn/init.c index eb4c5df..0bd3f75 100644 --- a/src/openvpn/init.c +++ b/src/openvpn/init.c @@ -2437,7 +2437,7 @@ do_init_frame (struct context *c) * Adjust frame size based on the --tun-mtu-extra parameter. */ if (c->options.ce.tun_mtu_extra_defined) - tun_adjust_frame_parameters (&c->c2.frame, c->options.ce.tun_mtu_extra); + frame_add_to_extra_tun (&c->c2.frame, c->options.ce.tun_mtu_extra); /* * Adjust frame size based on link socket parameters. diff --git a/src/openvpn/tun.h b/src/openvpn/tun.h index 7a8e769..f96bb50 100644 --- a/src/openvpn/tun.h +++ b/src/openvpn/tun.h @@ -255,12 +255,6 @@ bool is_tun_p2p (const struct tuntap *tt); * Inline functions */ -static inline void -tun_adjust_frame_parameters (struct frame* frame, int size) -{ - frame_add_to_extra_tun (frame, size); -} - /* * Should ifconfig be called before or after * tun dev open? -- 1.7.3.4 

No dependencies and init.c is the only user. Signed-off-by: Alon Bar-Lev <alo...@gm...> --- src/openvpn/init.c | 18 ++++++++++++++++++ src/openvpn/tun.c | 17 ----------------- src/openvpn/tun.h | 2 -- 3 files changed, 18 insertions(+), 19 deletions(-) diff --git a/src/openvpn/init.c b/src/openvpn/init.c index 61ced5d..eb4c5df 100644 --- a/src/openvpn/init.c +++ b/src/openvpn/init.c @@ -59,6 +59,24 @@ static struct context *static_context; /* GLOBAL */ static void do_init_first_time (struct context *c); +static +void +warn_on_use_of_common_subnets (void) +{ + struct gc_arena gc = gc_new (); + struct route_gateway_info rgi; + const int needed = (RGI_ADDR_DEFINED|RGI_NETMASK_DEFINED); + + get_default_gateway (&rgi); + if ((rgi.flags & needed) == needed) + { + const in_addr_t lan_network = rgi.gateway.addr & rgi.gateway.netmask; + if (lan_network == 0xC0A80000 || lan_network == 0xC0A80100) +	msg (M_WARN, "NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet."); + } + gc_free (&gc); +} + void context_clear (struct context *c) { diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 033c1e2..31684f4 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -242,23 +242,6 @@ check_addr_clash (const char *name, gc_free (&gc); } -void -warn_on_use_of_common_subnets (void) -{ - struct gc_arena gc = gc_new (); - struct route_gateway_info rgi; - const int needed = (RGI_ADDR_DEFINED|RGI_NETMASK_DEFINED); - - get_default_gateway (&rgi); - if ((rgi.flags & needed) == needed) - { - const in_addr_t lan_network = rgi.gateway.addr & rgi.gateway.netmask; - if (lan_network == 0xC0A80000 || lan_network == 0xC0A80100) -	msg (M_WARN, "NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet."); - } - gc_free (&gc); -} - /* * Complain if --dev tap and --ifconfig is used on an OS for which * we don't have a custom tap ifconfig template below. diff --git a/src/openvpn/tun.h b/src/openvpn/tun.h index bea1554..7a8e769 100644 --- a/src/openvpn/tun.h +++ b/src/openvpn/tun.h @@ -251,8 +251,6 @@ const char *ifconfig_options_string (const struct tuntap* tt, bool remote, bool bool is_tun_p2p (const struct tuntap *tt); -void warn_on_use_of_common_subnets (void); - /* * Inline functions */ -- 1.7.3.4 

Commeted out as "too many false positives". Signed-off-by: Alon Bar-Lev <alo...@gm...> --- src/openvpn/route.c | 1 - src/openvpn/tun.c | 43 ------------------------------------------- src/openvpn/tun.h | 4 ---- 3 files changed, 0 insertions(+), 48 deletions(-) diff --git a/src/openvpn/route.c b/src/openvpn/route.c index 7c25c77..f36c324 100644 --- a/src/openvpn/route.c +++ b/src/openvpn/route.c @@ -1030,7 +1030,6 @@ add_routes (struct route_list *rl, struct route_ipv6_list *rl6, const struct tun for (i = 0; i < rl->n; ++i)	{ struct route *r = &rl->routes[i]; - check_subnet_conflict (r->network, r->netmask, "route"); if (flags & ROUTE_DELETE_FIRST) delete_route (r, tt, flags, &rl->rgi, es); add_route (r, tt, flags, &rl->rgi, es); diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 71abbf3..033c1e2 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -242,44 +242,6 @@ check_addr_clash (const char *name, gc_free (&gc); } -/* - * Issue a warning if ip/netmask (on the virtual IP network) conflicts with - * the settings on the local LAN. This is designed to flag issues where - * (for example) the OpenVPN server LAN is running on 192.168.1.x, but then - * an OpenVPN client tries to connect from a public location that is also running - * off of a router set to 192.168.1.x. - */ -void -check_subnet_conflict (const in_addr_t ip, - const in_addr_t netmask, - const char *prefix) -{ -#if 0 /* too many false positives */ - struct gc_arena gc = gc_new (); - in_addr_t lan_gw = 0; - in_addr_t lan_netmask = 0; - - if (get_default_gateway (&lan_gw, &lan_netmask) && lan_netmask) - { - const in_addr_t lan_network = lan_gw & lan_netmask; - const in_addr_t network = ip & netmask; - - /* do the two subnets defined by network/netmask and lan_network/lan_netmask intersect? */ - if ((network & lan_netmask) == lan_network - || (lan_network & netmask) == network) -	{ - msg (M_WARN, "WARNING: potential %s subnet conflict between local LAN [%s/%s] and remote VPN [%s/%s]", - prefix, - print_in_addr_t (lan_network, 0, &gc), - print_in_addr_t (lan_netmask, 0, &gc), - print_in_addr_t (network, 0, &gc), - print_in_addr_t (netmask, 0, &gc)); -	} - } - gc_free (&gc); -#endif -} - void warn_on_use_of_common_subnets (void) { @@ -485,11 +447,6 @@ init_tun (const char *dev, /* --dev option */ remote_public, tt->local, tt->remote_netmask); - - if (tt->type == DEV_TYPE_TAP || (tt->type == DEV_TYPE_TUN && tt->topology == TOP_SUBNET)) - check_subnet_conflict (tt->local, tt->remote_netmask, "TUN/TAP adapter"); - else if (tt->type == DEV_TYPE_TUN) - check_subnet_conflict (tt->local, IPV4_NETMASK_HOST, "TUN/TAP adapter");	} /* diff --git a/src/openvpn/tun.h b/src/openvpn/tun.h index 9bd990f..bea1554 100644 --- a/src/openvpn/tun.h +++ b/src/openvpn/tun.h @@ -251,10 +251,6 @@ const char *ifconfig_options_string (const struct tuntap* tt, bool remote, bool bool is_tun_p2p (const struct tuntap *tt); -void check_subnet_conflict (const in_addr_t ip, - const in_addr_t netmask, - const char *prefix); - void warn_on_use_of_common_subnets (void); /* -- 1.7.3.4 

Platform independent interface for tun provider. Split the long tun.c into platform specific files using tun_engine interface. Functionality is the same. Maintenance will be much easier! new options, like stacking several interfaces and delegate partial control to plugin. There is more to be done in order to clean up the code, however this is a good starting point. Some more minor cleanups. Tested on Linux, FreeBSD, Windows. Branch should be merge after syshead[1]. Most probably patch exceeds list limitation, review is available[2]. This is for 2.4, please review quickly this so won't need to rebase. Special thanks to Eric Crist for his FreeBSD help. [1] https://github.com/alonbl/openvpn/compare/build...syshead [2] https://github.com/alonbl/openvpn/compare/syshead...tun Alon Bar-Lev (4): cleanup: remove check_subnet_conflict cleanup: move warn_on_use_of_common_subnets to init.c cleanup: remove tun_adjust_frame_parameters cleanup: tun: tun_engine interface configure.ac | 6 + src/openvpn/Makefile.am | 12 + src/openvpn/error.c | 2 +- src/openvpn/forward.c | 28 +- src/openvpn/helper.c | 2 +- src/openvpn/init.c | 61 +- src/openvpn/multi.c | 2 +- src/openvpn/options.c | 20 +- src/openvpn/options.h | 5 +- src/openvpn/route.c | 2 +- src/openvpn/sig.c | 4 +- src/openvpn/syshead.h | 56 - src/openvpn/tun-engine-common-bsd.c | 103 + src/openvpn/tun-engine-common-bsd.h | 34 + src/openvpn/tun-engine-common.c | 518 +++ src/openvpn/tun-engine-common.h | 85 + src/openvpn/tun-engine-darwin.c | 226 ++ src/openvpn/tun-engine-dragonfly.c | 193 ++ src/openvpn/tun-engine-freebsd.c | 229 ++ src/openvpn/tun-engine-generic.c | 97 + src/openvpn/tun-engine-linux-options.h | 37 + src/openvpn/tun-engine-linux.c | 515 +++ src/openvpn/tun-engine-netbsd.c | 318 ++ src/openvpn/tun-engine-openbsd.c | 259 ++ src/openvpn/tun-engine-options.h | 37 + src/openvpn/tun-engine-solaris.c | 491 +++ src/openvpn/tun-engine-windows-options.h | 92 + src/openvpn/tun-engine-windows-util.h | 83 + src/openvpn/tun-engine-windows.c | 2757 ++++++++++++++++ src/openvpn/tun-engine.h | 95 + src/openvpn/tun.c | 5053 ++---------------------------- src/openvpn/tun.h | 469 +--- 32 files changed, 6548 insertions(+), 5343 deletions(-) create mode 100644 src/openvpn/tun-engine-common-bsd.c create mode 100644 src/openvpn/tun-engine-common-bsd.h create mode 100644 src/openvpn/tun-engine-common.c create mode 100644 src/openvpn/tun-engine-common.h create mode 100644 src/openvpn/tun-engine-darwin.c create mode 100644 src/openvpn/tun-engine-dragonfly.c create mode 100644 src/openvpn/tun-engine-freebsd.c create mode 100644 src/openvpn/tun-engine-generic.c create mode 100644 src/openvpn/tun-engine-linux-options.h create mode 100644 src/openvpn/tun-engine-linux.c create mode 100644 src/openvpn/tun-engine-netbsd.c create mode 100644 src/openvpn/tun-engine-openbsd.c create mode 100644 src/openvpn/tun-engine-options.h create mode 100644 src/openvpn/tun-engine-solaris.c create mode 100644 src/openvpn/tun-engine-windows-options.h create mode 100644 src/openvpn/tun-engine-windows-util.h create mode 100644 src/openvpn/tun-engine-windows.c create mode 100644 src/openvpn/tun-engine.h -- 1.7.3.4 

Signed-off-by: Alon Bar-Lev <alo...@gm...> --- configure.ac | 2 +- src/openvpn/syshead.h | 146 ++++++++++++------------------------------------- 2 files changed, 36 insertions(+), 112 deletions(-) diff --git a/configure.ac b/configure.ac index cca9508..97eb5f0 100644 --- a/configure.ac +++ b/configure.ac @@ -643,7 +643,7 @@ old_CFLAGS="${CFLAGS}" CFLAGS="${CFLAGS} ${TAP_CFLAGS}" AC_CHECK_HEADERS(	[ \ -	net/if_tun.h net/tun/if_tun.h \ +	net/if_tun.h net/tun/if_tun.h net/if_tap.h \	linux/if_tun.h \	tap-windows.h \	], diff --git a/src/openvpn/syshead.h b/src/openvpn/syshead.h index d5a9af1..1b9cbe0 100644 --- a/src/openvpn/syshead.h +++ b/src/openvpn/syshead.h @@ -31,6 +31,10 @@ #ifdef WIN32 #include <windows.h> #include <winsock2.h> +#include <ws2tcpip.h> +#include <iphlpapi.h> +#include <ntddndis.h> +#include <wininet.h> #endif #ifdef HAVE_SYS_TYPES_H @@ -135,18 +139,6 @@ #include <grp.h> #endif -#ifdef HAVE_NETDB_H -#include <netdb.h> -#endif - -#ifdef HAVE_NETINET_IN_H -#include <netinet/in.h> -#endif - -#ifdef HAVE_RESOLV_H -#include <resolv.h> -#endif - #ifdef HAVE_SYS_POLL_H #include <sys/poll.h> #endif @@ -155,6 +147,10 @@ #include <sys/epoll.h> #endif +#ifdef HAVE_SYS_MMAN_H +#include <sys/mman.h> +#endif + #ifdef ENABLE_SELINUX #include <selinux/selinux.h> #endif @@ -163,29 +159,47 @@ #include <libgen.h> #endif -#ifdef TARGET_SOLARIS #ifdef HAVE_STRINGS_H #include <strings.h> #endif -#else + #ifdef HAVE_STRING_H #include <string.h> #endif + +#ifdef HAVE_STROPTS_H +#include <stropts.h> +#endif + +#ifdef HAVE_NETDB_H +#include <netdb.h> #endif #ifdef HAVE_ARPA_INET_H #include <arpa/inet.h> #endif +#ifdef HAVE_NETINET_IN_H +#include <netinet/in.h> +#endif + +#ifdef HAVE_NETINET_IP_H +#include <netinet/ip.h> +#endif + +#ifdef HAVE_NETINET_TCP_H +#include <netinet/tcp.h> +#endif + #ifdef HAVE_NET_IF_H #include <net/if.h> #endif -#ifdef TARGET_NETBSD -#include <net/if_tap.h> +#ifdef HAVE_RESOLV_H +#include <resolv.h> #endif -#ifdef TARGET_LINUX +#if defined(TARGET_LINUX) #if defined(HAVE_NETINET_IF_ETHER_H) #include <netinet/if_ether.h> @@ -195,10 +209,6 @@ #include <linux/if_tun.h> #endif -#ifdef HAVE_NETINET_IP_H -#include <netinet/ip.h> -#endif - #ifdef HAVE_LINUX_SOCKIOS_H #include <linux/sockios.h> #endif @@ -211,17 +221,7 @@ #include <linux/errqueue.h> #endif -#ifdef HAVE_NETINET_TCP_H -#include <netinet/tcp.h> -#endif - -#endif /* TARGET_LINUX */ - -#ifdef TARGET_SOLARIS - -#ifdef HAVE_STROPTS_H -#include <stropts.h> -#endif +#elif defined(TARGET_SOLARIS) #ifdef HAVE_NET_IF_TUN_H #include <net/if_tun.h> @@ -231,41 +231,7 @@ #include <sys/sockio.h> #endif -#ifdef HAVE_NETINET_IN_SYSTM_H -#include <netinet/in_systm.h> -#endif - -#ifdef HAVE_NETINET_IP_H -#include <netinet/ip.h> -#endif - -#ifdef HAVE_NETINET_TCP_H -#include <netinet/tcp.h> -#endif - -#endif /* TARGET_SOLARIS */ - -#ifdef TARGET_OPENBSD - -#ifdef HAVE_SYS_UIO_H -#include <sys/uio.h> -#endif - -#ifdef HAVE_NETINET_IN_SYSTM_H -#include <netinet/in_systm.h> -#endif - -#ifdef HAVE_NETINET_IP_H -#include <netinet/ip.h> -#endif - -#ifdef HAVE_NET_IF_TUN_H -#include <net/if_tun.h> -#endif - -#endif /* TARGET_OPENBSD */ - -#ifdef TARGET_FREEBSD +#elif defined(TARGET_OPENBSD) || defined(TARGET_FREEBSD) || defined(TARGET_NETBSD) || defined(TARGET_DRAGONFLY) #ifdef HAVE_SYS_UIO_H #include <sys/uio.h> @@ -275,60 +241,18 @@ #include <netinet/in_systm.h> #endif -#ifdef HAVE_NETINET_IP_H -#include <netinet/ip.h> -#endif - #ifdef HAVE_NET_IF_TUN_H #include <net/if_tun.h> #endif -#endif /* TARGET_FREEBSD */ - -#ifdef TARGET_NETBSD - -#ifdef HAVE_NET_IF_TUN_H -#include <net/if_tun.h> -#endif - -#ifdef HAVE_NETINET_TCP_H -#include <netinet/tcp.h> -#endif - -#endif /* TARGET_NETBSD */ - -#ifdef TARGET_DRAGONFLY - -#ifdef HAVE_SYS_UIO_H -#include <sys/uio.h> -#endif - -#ifdef HAVE_NETINET_IN_SYSTM_H -#include <netinet/in_systm.h> -#endif - -#ifdef HAVE_NETINET_IP_H -#include <netinet/ip.h> -#endif - #ifdef HAVE_NET_TUN_IF_TUN_H #include <net/tun/if_tun.h> #endif -#endif /* TARGET_DRAGONFLY */ - -#ifdef WIN32 -#include <iphlpapi.h> -#include <ntddndis.h> -#include <wininet.h> -#include <shellapi.h> -/* The following two headers are needed of PF_INET6 */ -#include <winsock2.h> -#include <ws2tcpip.h> +#ifdef HAVE_NET_IF_TAP_H +#include <net/if_tap.h> #endif -#ifdef HAVE_SYS_MMAN_H -#include <sys/mman.h> #endif /* -- 1.7.3.4 

Signed-off-by: Alon Bar-Lev <alo...@gm...> --- configure.ac | 1 + src/openvpn/syshead.h | 7 ------- 2 files changed, 1 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index 193d287..cca9508 100644 --- a/configure.ac +++ b/configure.ac @@ -270,6 +270,7 @@ case "$host" in	*-*-linux*)	AC_DEFINE([TARGET_LINUX], [1], [Are we running on Linux?])	AC_DEFINE_UNQUOTED([TARGET_PREFIX], ["L"], [Target prefix]) +	AC_DEFINE([ENABLE_MEMSTATS], [1], [Enable --memstats option])	;;	*-*-solaris*)	AC_DEFINE([TARGET_SOLARIS], [1], [Are we running on Solaris?]) diff --git a/src/openvpn/syshead.h b/src/openvpn/syshead.h index c4dfd0b..d5a9af1 100644 --- a/src/openvpn/syshead.h +++ b/src/openvpn/syshead.h @@ -613,11 +613,4 @@ */ #define ENABLE_CLIENT_NAT -/* - * Enable --memstats option - */ -#ifdef TARGET_LINUX -#define ENABLE_MEMSTATS -#endif - #endif -- 1.7.3.4 

Signed-off-by: Alon Bar-Lev <alo...@gm...> --- configure.ac | 11 +++++++++++ src/openvpn/syshead.h | 8 -------- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 2c80ef4..193d287 100644 --- a/configure.ac +++ b/configure.ac @@ -490,6 +490,17 @@ AC_CHECK_DECLS(	,	[[${SOCKET_INCLUDES}]] ) +AC_CHECK_DECLS( +	[SOL_IP], +	, +	[AC_CHECK_DECLS( +	[IPPROTO_IP], +	[AC_DEFINE_UNQUOTED([SOL_IP], [IPPROTO_IP], [SOL_IP emulation])], +	[AC_MSG_ERROR([cannot find SOL_IP or IPPROTO_IP])], +	[[${SOCKET_INCLUDES}]] +	)], +	[[${SOCKET_INCLUDES}]] +) dnl We emulate signals in Windows AC_CHECK_DECLS( diff --git a/src/openvpn/syshead.h b/src/openvpn/syshead.h index f908752..c4dfd0b 100644 --- a/src/openvpn/syshead.h +++ b/src/openvpn/syshead.h @@ -367,14 +367,6 @@ #endif /* - * Does this platform define SOL_IP - * or only bsd-style IPPROTO_IP ? - */ -#ifndef SOL_IP -#define SOL_IP IPPROTO_IP -#endif - -/* * Do we have a syslog capability? */ #if defined(HAVE_OPENLOG) && defined(HAVE_SYSLOG) -- 1.7.3.4 

Signed-off-by: Alon Bar-Lev <alo...@gm...> --- src/openvpn/syshead.h | 14 -------------- 1 files changed, 0 insertions(+), 14 deletions(-) diff --git a/src/openvpn/syshead.h b/src/openvpn/syshead.h index 657c884..f908752 100644 --- a/src/openvpn/syshead.h +++ b/src/openvpn/syshead.h @@ -375,14 +375,6 @@ #endif /* - * Disable ESEC - */ -#if 0 -#undef EXTENDED_SOCKET_ERROR_CAPABILITY -#define EXTENDED_SOCKET_ERROR_CAPABILITY 0 -#endif - -/* * Do we have a syslog capability? */ #if defined(HAVE_OPENLOG) && defined(HAVE_SYSLOG) @@ -548,12 +540,6 @@ #define EPOLL 0 #endif -/* Disable EPOLL */ -#if 0 -#undef EPOLL -#define EPOLL 0 -#endif - /* * Should we allow ca/cert/key files to be * included inline, in the configuration file? -- 1.7.3.4