openvpn-devel Mailing List for OpenVPN

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/04/10 14:15, Samuli Seppänen wrote: > Hi, > > Here's the summary of the previous community meeting. > > --- > > COMMUNITY MEETING > > Place: #openvpn-devel on irc.freenode.net > Date: Thursday, 29th March 2010 > Time: 18:00 UTC > > Planned meeting topics for this meeting were on this page: > > <https://community.openvpn.net/openvpn/wiki/Topics-2010-04-29> [...snip...] > Discussed the "Revamped the script-security warning logging (version 2)" > issue: > > <http://thread.gmane.org/gmane.network.openvpn.devel/3587> > > James will give the above patch an ACK once it's changed to use the > openvpn_snprintf function. Dazo will take care of this small modification. Just one correction. It was not lack of usage of openvpn_snprintf(), but rather make use of sizeof(msg) instead of a fixed value as the second parameter. The initial patch was: openvpn_snprintf(msg, 255,	"WARNING: Failed running command (%s)", hook); James suggested to change 255 to sizeof(msg). This was done before adding the patch. This is now available as commit 339f2a4d4b487afa53fa99d. kind regards, David Sommerseth. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvbTwMACgkQDC186MBRfrpFxACbBhB1cl9ofy1mbaTWk4SsDm5+ T1UAoJVQ0vfw6ibaOa1ZIxq14gk3Kaha =2KUb -----END PGP SIGNATURE----- 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/04/10 09:51, David Sommerseth wrote: > From: David Sommerseth <da...@us...> > > For OpenVPN clients with long living connections, this message is repeated > everytime the connection is renegotiated. This patch removes this behaviour > and will only show this warning once. > > Signed-off-by: David Sommerseth <da...@us...> > --- > misc.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > This patch received an ACK on the developers meeting 2010-04-29 <http://thread.gmane.org/gmane.network.openvpn.devel/3673> Applied to feat_misc and merged into allmerged. Commit 793e2baffbe8b6cc34570046d9329f8abfd68c77 kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvbTaAACgkQDC186MBRfrrkZACgi44P4rcPYDGibCfN/8oR8JlF CD0AoJ8atZqXJRXcaCyee0CdWZqShH5H =OWHH -----END PGP SIGNATURE----- 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/04/10 13:48, David Sommerseth wrote: > From: David Sommerseth <da...@us...> > > This is a first-cut of removing misleading warnings from the logs. > > The main task of this patch is to avoid reporting the SCRIPT_SECURITY_WARNING > over and over again, in addition to not show this warning when it should not > be a problem. This general warning should now only appear once, and only when > --script-security is not set, 0 or 1. In all other cases this warning should > not appear. > > In addition, this warning will come close to the script-hook which most probably > will fail. It will also give a little bit more concrete hint on which script-hook > which failed. If --script-security is 2 or 3, only the execve failure itself will > be shown. This message will on the other hand be shown repeatedly. > > Signed-off-by: David Sommerseth <da...@us...> > --- > common.h | 2 +- > init.c | 2 +- > misc.c | 25 ++++++++++++++++++++++--- > misc.h | 3 +++ > multi.c | 6 +++--- > socket.c | 2 +- > ssl.c | 4 ++-- > win32.c | 5 ++++- > 8 files changed, 37 insertions(+), 12 deletions(-) This patch received an ACK on the developers meeting 2010-04-29 <http://thread.gmane.org/gmane.network.openvpn.devel/3673> Applied to feat_misc and merged into allmerged. Commit 339f2a4d4b487afa53fa99d72c35b16f31e417d3 kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvbTWcACgkQDC186MBRfrqOcACgqZpBjyXOiCIsguEsXtKE1uVJ dQoAnRG2IuNETVCG+d52saKWSTlRzwap =brqt -----END PGP SIGNATURE----- 

On Friday 30 April 2010, Gert Doering wrote: > On Fri, Apr 30, 2010 at 06:24:20PM +0100, Davide Brini wrote: > > Well, the obvious (and probably wrong, probably inefficient) way could be > > to just check if the packet at hand is a ping message, and if it is do > > not record it as "activity", eg > > > > if (! is_ping_msg (&c->c2.buf)) > > register_activity (c, size); > > Looks good to me :-) (without having looked at the code in question at > all). > > > This is in two places: in process_outgoing_tun() and > > process_outgoing_link(). > > As you wrote in the next e-mail, this won't ever be "outgoing on tun", > so only one place needs changing... Yes of course, but I realized that too late :) It makes no sense at all to send OpenVPN pings to the kernel. > > However, I'm not sure about the overhead of performing that for each and > > every processed packet. is_ping_msg() calls buf_string_match(), which in > > turn calls memcmp(). > > But, it should also be noted that process_incoming_link() DOES call > > is_ping_msg() for every incoming packet, so... > > I'm a big fan of symmetry here - if the incoming packet path explictly > not-counts ping packets, it's a bit hard to explain to users why the > outgoing packet path *does* count them, and they have to fiddle with > byte counts to get "inactivity". > > I'd go that route... > > Efficiency is a valid concern, of course. Since is_ping_msg() and > buf_string_match() are both (very short) inline functions, and memcmp() > on "normal" architectures is also inlined by gcc, this "should not" add > unduly overhead. (Of course, down that road is hell and windows vista). Ok, thanks for the remarks! I will try to implement it that way then, and see how it goes (perhaps including some basic benchmarking - not entirely sure how to go about that apart from generating loads of traffic and see, but I'll figure out). Then I'll post back (possibly with a patch including changing the description in the man etc.) -- D. 

Hi, On Fri, Apr 30, 2010 at 06:24:20PM +0100, Davide Brini wrote: > Well, the obvious (and probably wrong, probably inefficient) way could be to > just check if the packet at hand is a ping message, and if it is do not record > it as "activity", eg > > if (! is_ping_msg (&c->c2.buf)) > register_activity (c, size); Looks good to me :-) (without having looked at the code in question at all). > This is in two places: in process_outgoing_tun() and process_outgoing_link(). As you wrote in the next e-mail, this won't ever be "outgoing on tun", so only one place needs changing... > However, I'm not sure about the overhead of performing that for each and every > processed packet. is_ping_msg() calls buf_string_match(), which in turn calls > memcmp(). > But, it should also be noted that process_incoming_link() DOES call > is_ping_msg() for every incoming packet, so... I'm a big fan of symmetry here - if the incoming packet path explictly not-counts ping packets, it's a bit hard to explain to users why the outgoing packet path *does* count them, and they have to fiddle with byte counts to get "inactivity". I'd go that route... Efficiency is a valid concern, of course. Since is_ping_msg() and buf_string_match() are both (very short) inline functions, and memcmp() on "normal" architectures is also inlined by gcc, this "should not" add unduly overhead. (Of course, down that road is hell and windows vista). 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 Friday 30 April 2010, Davide Brini wrote: > if (! is_ping_msg (&c->c2.buf)) > register_activity (c, size); > > This is in two places: in process_outgoing_tun() and > process_outgoing_link(). Actually that would probably need to be done only in process_outgoing_link(), as I don't think pings ever make it into the tun device to userspace, since they are discarded by process_incoming_link(). -- D. 

On Friday 30 April 2010, David Sommerseth wrote: > >> I agree that that would be a wise change. However, I wonder: why change > >> the amount of bytes, if you can also simply not count the ping packets? > >> To me, it would seem a much more accurate way of determining whether the > >> connection is idle or not, because there's always the possibility of > >> duplicate ping packets (even although that's unlikely) or other errors. > >> Or would that cause a too great load on the server? > > > > Sounds like a good idea. Do any devs have an idea how difficult > > (code-vise) that'd be? > > I've not gone too deep into this code path yet, but I believe from what > I could see, the byte counter is located on a different place than the > "ping initiator". That means that telling the "byte counter code" that > "this is our own packet, don't count it" is not as trivial to fix as it > sounds like. > > It looks like we just put 16 bytes of "static randomness" (defined in > ping.c) and push that into the some session buffers. Then later on, in > another function pushes what ever is queued up for transmission. > > But this need to be investigated further ... and if someone is quicker > than me to figure it out, patches are, as always, more than welcome! Well, the obvious (and probably wrong, probably inefficient) way could be to just check if the packet at hand is a ping message, and if it is do not record it as "activity", eg if (! is_ping_msg (&c->c2.buf)) register_activity (c, size); This is in two places: in process_outgoing_tun() and process_outgoing_link(). However, I'm not sure about the overhead of performing that for each and every processed packet. is_ping_msg() calls buf_string_match(), which in turn calls memcmp(). But, it should also be noted that process_incoming_link() DOES call is_ping_msg() for every incoming packet, so... -- D. 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/04/10 15:13, Samuli Seppänen wrote: > >> On 30-04-10 14:56, Samuli Seppänen wrote: >> >>> Hi all, >>> >>> In yesterday's meeting we discussed this issue: >>> >>> <http://thread.gmane.org/gmane.network.openvpn.devel/3556> >>> >>> In a nutshell, OpenVPN's ping packets (--ping<seconds>) keep the >>> connection alive even if user uses the --inactive<seconds> option to >>> close inactive connections. Now, the --inactive option has an optional >>> <bytes> parameter, which allows closing the connection if less than >>> <bytes> of traffic is received in<seconds>. Setting all of these >>> parameters correctly should allow --inactivity to "ignore" the OpenVPN >>> ping traffic. >>> >>> Has somebody already solved this issue by setting correct values for >>> --inactive and --ping parameters? Our idea is to change the code so that >>> the --ping and --inactive options are not mutually exclusive even if the >>> optional<bytes> option is not defined. >>> >>> I hope I have not been too confusing :). For more information about the >>> --inactive and --ping options, see "man openvpn" or >>> >>> <http://openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html >>> >> I agree that that would be a wise change. However, I wonder: why change >> the amount of bytes, if you can also simply not count the ping packets? >> To me, it would seem a much more accurate way of determining whether the >> connection is idle or not, because there's always the possibility of >> duplicate ping packets (even although that's unlikely) or other errors. >> Or would that cause a too great load on the server? >> > Sounds like a good idea. Do any devs have an idea how difficult > (code-vise) that'd be? I've not gone too deep into this code path yet, but I believe from what I could see, the byte counter is located on a different place than the "ping initiator". That means that telling the "byte counter code" that "this is our own packet, don't count it" is not as trivial to fix as it sounds like. It looks like we just put 16 bytes of "static randomness" (defined in ping.c) and push that into the some session buffers. Then later on, in another function pushes what ever is queued up for transmission. But this need to be investigated further ... and if someone is quicker than me to figure it out, patches are, as always, more than welcome! kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEUEARECAAYFAkva6rcACgkQDC186MBRfroTcQCeIZTmEXg2zEAtFiF3v0eQsvY/ /nQAlRSsZWXJSlfPT8L5cJT48uwuZm4= =NuJi -----END PGP SIGNATURE----- 

 > On 30-04-10 14:56, Samuli Seppänen wrote: > >> Hi all, >> >> In yesterday's meeting we discussed this issue: >> >> <http://thread.gmane.org/gmane.network.openvpn.devel/3556> >> >> In a nutshell, OpenVPN's ping packets (--ping<seconds>) keep the >> connection alive even if user uses the --inactive<seconds> option to >> close inactive connections. Now, the --inactive option has an optional >> <bytes> parameter, which allows closing the connection if less than >> <bytes> of traffic is received in<seconds>. Setting all of these >> parameters correctly should allow --inactivity to "ignore" the OpenVPN >> ping traffic. >> >> Has somebody already solved this issue by setting correct values for >> --inactive and --ping parameters? Our idea is to change the code so that >> the --ping and --inactive options are not mutually exclusive even if the >> optional<bytes> option is not defined. >> >> I hope I have not been too confusing :). For more information about the >> --inactive and --ping options, see "man openvpn" or >> >> <http://openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html >> > I agree that that would be a wise change. However, I wonder: why change > the amount of bytes, if you can also simply not count the ping packets? > To me, it would seem a much more accurate way of determining whether the > connection is idle or not, because there's always the possibility of > duplicate ping packets (even although that's unlikely) or other errors. > Or would that cause a too great load on the server? > Sounds like a good idea. Do any devs have an idea how difficult (code-vise) that'd be? -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hi all, In yesterday's meeting we discussed this issue: <http://thread.gmane.org/gmane.network.openvpn.devel/3556> In a nutshell, OpenVPN's ping packets (--ping <seconds>) keep the connection alive even if user uses the --inactive <seconds> option to close inactive connections. Now, the --inactive option has an optional <bytes> parameter, which allows closing the connection if less than <bytes> of traffic is received in <seconds>. Setting all of these parameters correctly should allow --inactivity to "ignore" the OpenVPN ping traffic. Has somebody already solved this issue by setting correct values for --inactive and --ping parameters? Our idea is to change the code so that the --ping and --inactive options are not mutually exclusive even if the optional <bytes> option is not defined. I hope I have not been too confusing :). For more information about the --inactive and --ping options, see "man openvpn" or <http://openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html> -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

D/OpenVPN-DaemonMonitor[/sdcard/openvpn/ic3s.ovpn]-daemon-stdout( 7158): Fri Apr 30 14:00:08 2010 us=851287 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:4: route (2.1.1) D/OpenVPN-DaemonMonitor[/sdcard/openvpn/ic3s.ovpn]-daemon-stdout( 7158): Fri Apr 30 14:00:08 2010 us=851623 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: route (2.1.1) Hi, I try to push routes from the server to the client, if I connect with windows or linux on a pc it works fine but not with openvpn on my Motorola Milestone / Droid. Any Ideas? 

Hi all, Next week's meeting will be dedicated to discussion about OpenVPN's roadmap. In this meeting James Yonan will present his views of the future of OpenVPN 3.0 and it's relationship with 2.x series. We'll try to keep the discussion at a relatively high-level, without going into gory details such as "OpenVPN 2.2 will include the following features...". Preliminary meeting agenda is available here: <https://community.openvpn.net/openvpn/wiki/Topics-2010-05-06> The concrete goals for 2.x releases will be discussed in detail on the mailing lists after the meeting. --- OPENVPN ROADMAP MEETING Place: #openvpn-devel on irc.freenode.net Date: Thursday, 6th March 2010 Time: 18:00 UTC -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hi, Here's the summary of the previous community meeting. --- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net Date: Thursday, 29th March 2010 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2010-04-29> Next meeting next week, same place, same time. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY Discussed the VLAN tagging patchset. Agreed that "feat_passtos" branch needs to be tested before VLAN tagging patches can be included in "allmerged" branch. Feat_passtos patch was sent to -devel ml a while back: <http://thread.gmane.org/gmane.network.openvpn.devel/3165> Discussed tasks which we know we should do, but can't do immediately. Agreed that we should start using Trac to track these. Samuli promised to move existing content from Secure Computing "Open tasks" wiki page to Trac. Discussed Trac spam prevention. Agreed that some of the Trac wiki pages should be protected against editing by "normal" authenticated users. Discussed the "Using --inactive and --ping seems to defeat each other" issue: <http://thread.gmane.org/gmane.network.openvpn.devel/3556> Agreed that we need to find a proper default value for --inactive arguments (seconds & bytecount) which avoids OpenVPN pings from keeping the connection open. Samuli promised to ask if our users could help us with this issue. If that fails, a new Trac task will be created. Discussed the "Avoid repetition of "this config may cache passwords in memory" (v2)" issue: <http://thread.gmane.org/gmane.network.openvpn.devel/3591> James ACK'd the above patch. Discussed the "Revamped the script-security warning logging (version 2)" issue: <http://thread.gmane.org/gmane.network.openvpn.devel/3587> James will give the above patch an ACK once it's changed to use the openvpn_snprintf function. Dazo will take care of this small modification. Discussed OpenVPN roadmap. Agreed to make the next Thursday's meeting a dedicated "Roadmap" meeting. In this meeting James will present his views of the future of OpenVPN 3.0 and it's relationship with 2.x series. Discussion will be kept at a relatively high-level, without going into gory details such as "OpenVPN 2.2 will include the following features...". Agreed that users need to be involved in defining the future of OpenVPN. Discussed OpenVPN coding conventions / coding style. Agreed that we need to use "GNU Indent" (or similar tool) to make sure all code is formatted similarly. Agreed that some parts of the current code may have to reformatted before forcing people to use a specific coding style. Discussed code security issues. Agreed that all patches should be checked with (security) auditing tools such as Valgrind and Coverity. James promised to write the first version of "Coding security guidelines" document, which can then updated as required. Discussed problems with getting developers with no prior OSS development experience involved. Samuli has noticed that many people who provide useful patches are not confident enough to send them to the -devel mailinglists. Agreed that something has to be done to lower the (psychological) barrier of entry to OpenVPN development. Mentoring was suggested as one possibility. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hello list, I have a suggestion for further development which I don't know if it is technically achievable. Anyway, here's our problem: We run a network which consists of multiple routers behind eachother. Routers login via OpenVPN to other routers, get fixed IP addresses based on their certificate and get individual settings pushed (ccd). Imagine the following simple situation: Network1---->Router A----->Router B---->Router C---->Network2 in ccd file for Router B on Router C an iroute entry exists for network 1 (which is propagated to Router C via BGP) to properly route packets from network 2 -> network1 ("iroute network1"). Now we add a network 3 behind Router A network1 \ ---> Router A ----> Router B ----> Router C ---> Network2 network3 / Routes get propagated via BGP to Router C (network3 appears in routing table of Router C). But, packets from network 2 don't make it to network 3. We have to add "iroute network 3" on ccd config for Router B on Router C and reconnect Router B to Router C to get packets routed to network 3. From what I understood is that OpenVPN needs the information for network 3 on Router C to know which VPN tunnel to use to get packets back. Our intention is that as soon as network 3 is propagated to Router C packet flow works without the need to edit files and reconnect tunnels. Btw., Routers get fixed IP addresses through ccd. Hopefully my explanation is clear enough. Thx for looking at this... Regards, Sebastian 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/04/10 10:08, Gert Doering wrote: > Hi, > > On Thu, Apr 29, 2010 at 10:03:23AM +0200, David Sommerseth wrote: >>> If we include it in feat_ipv6_payload, it won't have merge conflicts - but >>> then you only get the TAP-on-Solaris in combination with all the IPv6 stuff, >>> which people might not want. >>> >>> David? >> >> You seem to have pretty well good control over this TUN/TAP >> infrastructure. So I have no problems with you pulling whatever you >> find useful into your IPv6 branch, which covers this. > > OK, if nobody objects, I'll integrate the rest of these patches into > "my" tun.c, and commit to the IPv6 payload branch. (Will take a few > days...) > > If someone urgently needs TAP support for Solaris later on, but refuses > to use the IPv6 stuff, we can still sort out what to do then. Agreed! And I really struggle to see this being a reality, unless the IPv6 branch got stability issues for IPv4 only users. Which I can't say is an issue now. Send me a PULL REQUEST when you're ready, and I'll get it into allmerged after ACK. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvZQQ0ACgkQDC186MBRfroX0QCeL1nQ61nh+MDY1l0YUsS0gsQ0 D58AmgNK+LWCqJSNGzCeFh8QgouMdlXi =no9p -----END PGP SIGNATURE----- 

Hi, On Thu, Apr 29, 2010 at 10:03:23AM +0200, David Sommerseth wrote: > > If we include it in feat_ipv6_payload, it won't have merge conflicts - but > > then you only get the TAP-on-Solaris in combination with all the IPv6 stuff, > > which people might not want. > > > > David? > > You seem to have pretty well good control over this TUN/TAP > infrastructure. So I have no problems with you pulling whatever you > find useful into your IPv6 branch, which covers this. OK, if nobody objects, I'll integrate the rest of these patches into "my" tun.c, and commit to the IPv6 payload branch. (Will take a few days...) If someone urgently needs TAP support for Solaris later on, but refuses to use the IPv6 stuff, we can still sort out what to do then. 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 29/04/10 09:03, Gert Doering wrote: > Hi, > > On Thu, Apr 29, 2010 at 01:02:37PM +0900, Kazuyoshi Aizawa wrote: >> I've attached a patch for tun.c which includes support for tap >> interface for solaris/opensolaris. >> The code is based on OpneVPN 2.1.1. And it has a routine to >> plumb/unplumb tap interface like ifconfig command. >> >> tap driver for solarsi/opensolaris is here: >> http://www.whiteboard.ne.jp/~admin2/tuntap/ > > Thanks for your work!. I have already used bits from there when adding > IPv6 payload support to OpenVPN on Solaris :-) > > Question to the community: how do we want to integrate the tun.c changes > for Solaris? Its own branch, feat_misc branch, feat_ipv6_payload branch? > > If we include it in feat_ipv6_payload, it won't have merge conflicts - but > then you only get the TAP-on-Solaris in combination with all the IPv6 stuff, > which people might not want. > > David? You seem to have pretty well good control over this TUN/TAP infrastructure. So I have no problems with you pulling whatever you find useful into your IPv6 branch, which covers this. If given a separate branch, I'm not going to be the one who solves potential conflicts unless they're bloody obvious and trivial. So I'll just be going to push someone to fix these branches so they can be merged. Gert, I'll let you know decide if you feel this is good for inclusion into your tree. If you prefer to have it separately, including the work needed to make these branches merge-able, I'm fine with that. It's easier to track things if they have separate branches, but if this patch is close to what you do in your tree, I don't see it that important to split it out. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvZPUsACgkQDC186MBRfrpElQCdHZPAXh0LuPfiKtNWRt2+e6IK UEIAnjXlVySWFUgOxxhU3bCp3mv5hlSI =SydE -----END PGP SIGNATURE----- 

Hi, On Thu, Apr 29, 2010 at 04:39:35PM +0900, Kazuyoshi Aizawa wrote: > Thank you for your support. > Please find attached patch with diff -uw. Thanks. I wouldn't claim to understand why the specific changes are needed, but this way it is obvious that the changes really only affect the Solaris-specific part of tun.c. 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 Gert, Thank you for your support. Please find attached patch with diff -uw. Thanks, Kazuyoshi 2010/4/29 Gert Doering <ge...@gr...>: > Hi again, > > On Thu, Apr 29, 2010 at 01:02:37PM +0900, Kazuyoshi Aizawa wrote: >> I've attached a patch for tun.c which includes support for tap >> interface for solaris/opensolaris. > > I've glanced through the patch, and there's also changes in the Win32 > part of the tun.c, for example this chunk: > > > ----------------------- quote ---------------------- > @@ -3333,19 +3409,19 @@ >   bool ret = false; >   const IP_ADAPTER_INDEX_MAP *inter = get_interface_info (adapter_index, &gc); > > -  if (inter) > -    { > -      DWORD status = IpRenewAddress ((IP_ADAPTER_INDEX_MAP *)inter); > -      if (status == NO_ERROR) > +      if (inter) >        { > -         msg (D_TUNTAP_INFO, "TAP: DHCP address renewal succeeded"); > -         ret = true; > +         DWORD status = IpRenewAddress ((IP_ADAPTER_INDEX_MAP *)inter); > +         if (status == NO_ERROR) > +           { > +             msg (D_TUNTAP_INFO, "TAP: DHCP address renewal succeeded"); > +             ret = true; > +           } > +         else > +           msg (M_WARN, "WARNING: Failed to renew DHCP IP address lease on TAP-Win32 adapter: %s (code=%u)", > +                strerror_win32 (status, &gc), > +                (unsigned int)status); >        } > -      else > -       msg (M_WARN, "WARNING: Failed to renew DHCP IP address lease on TAP-Win32 adapter: %s (code=%u)", > -            strerror_win32 (status, &gc), > -            (unsigned int)status); > -    } >   gc_free (&gc); >   return ret; >  } > ----------------------- quote ---------------------- > > > From a first glance, this looks like "whitespace changes only". > > For easier review: would you be so kind and re-send your patch with > "diff -uw" (-w = ignore white space changes)? > > thanks, > > 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 Thu, Apr 29, 2010 at 9:07 AM, Heiko Hund <hh...@as...> wrote: >> > If the service is started by the GUI it still makes sense to use user >> > specific proxy settings, doesn't it? One could consider auto-proxy for >> > auto-started VPNs a misconfiguration, as well. Or am I mislead? >> >> If this is a service that is started, it cannot access your proxy >> without more tweaks. > > Currently not that's true, but the service interface needs to be extended to > pass data between the GUI and openvpn in the future anyways. ‎True. The proxy should be provided via the management interface. The OpenVPN GUI should be rewritten in order to use the management interface and only the management interface. This will solve a lot of issues especially in Windows environment. In Linux it is not that important, as OpenVPN can run in none privileged mode. 

Hi again, On Thu, Apr 29, 2010 at 01:02:37PM +0900, Kazuyoshi Aizawa wrote: > I've attached a patch for tun.c which includes support for tap > interface for solaris/opensolaris. I've glanced through the patch, and there's also changes in the Win32 part of the tun.c, for example this chunk: ----------------------- quote ---------------------- @@ -3333,19 +3409,19 @@ bool ret = false; const IP_ADAPTER_INDEX_MAP *inter = get_interface_info (adapter_index, &gc); - if (inter) - { - DWORD status = IpRenewAddress ((IP_ADAPTER_INDEX_MAP *)inter); - if (status == NO_ERROR) + if (inter)	{ - msg (D_TUNTAP_INFO, "TAP: DHCP address renewal succeeded"); - ret = true; + DWORD status = IpRenewAddress ((IP_ADAPTER_INDEX_MAP *)inter); + if (status == NO_ERROR) + { + msg (D_TUNTAP_INFO, "TAP: DHCP address renewal succeeded"); + ret = true; + } + else + msg (M_WARN, "WARNING: Failed to renew DHCP IP address lease on TAP-Win32 adapter: %s (code=%u)", + strerror_win32 (status, &gc), + (unsigned int)status);	} - else -	msg (M_WARN, "WARNING: Failed to renew DHCP IP address lease on TAP-Win32 adapter: %s (code=%u)", - strerror_win32 (status, &gc), - (unsigned int)status); - } gc_free (&gc); return ret; } ----------------------- quote ---------------------- >From a first glance, this looks like "whitespace changes only". For easier review: would you be so kind and re-send your patch with "diff -uw" (-w = ignore white space changes)? thanks, 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 Thu, Apr 29, 2010 at 01:02:37PM +0900, Kazuyoshi Aizawa wrote: > I've attached a patch for tun.c which includes support for tap > interface for solaris/opensolaris. > The code is based on OpneVPN 2.1.1. And it has a routine to > plumb/unplumb tap interface like ifconfig command. > > tap driver for solarsi/opensolaris is here: > http://www.whiteboard.ne.jp/~admin2/tuntap/ Thanks for your work!. I have already used bits from there when adding IPv6 payload support to OpenVPN on Solaris :-) Question to the community: how do we want to integrate the tun.c changes for Solaris? Its own branch, feat_misc branch, feat_ipv6_payload branch? If we include it in feat_ipv6_payload, it won't have merge conflicts - but then you only get the TAP-on-Solaris in combination with all the IPv6 stuff, which people might not want. David? 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 Thursday 29 April 2010 03:44:37 Jason Haar wrote: > On 04/29/2010 02:38 AM, Heiko Hund wrote: > > If the service is started by the GUI it still makes sense to use user > > specific proxy settings, doesn't it? One could consider auto-proxy for > > auto-started VPNs a misconfiguration, as well. Or am I mislead? > > I think it's critical. Most enterprise networks have egress filtering > (ie default to blocking outbound with business-exceptions) and web > access via proxies. They will use WPAD (via HTTP or DHCP) or perhaps > they are a Windows shop and use Active Directory policies to "tell" MSIE > how to operate on a particular network. Don't forget enterprise networks > tend to span continents and so static entries are not appropriate - > different proxies for different sites within the same company are common. I agree. Had assumed that WinHttpGetIEProxyConfigForCurrentUser and InternetQueryOption are returning the proxy from WPAD if IE is set to automatic mode. Do you know if they do? Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro GmbH & Co. KG | An der RaumFabrik 33a | 76227 Karlsruhe | Germany Astaro GmbH & Co. KG Commercial Register: Mannheim HRA 702710 Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH An der RaumFabrik 33a | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen 

On Wednesday 28 April 2010 16:45:47 Alon Bar-Lev wrote: > On Wed, Apr 28, 2010 at 5:38 PM, Heiko Hund <hh...@as...> wrote: > > On Wednesday 28 April 2010 16:24:31 Alon Bar-Lev wrote: > >> The IE API is user specific. > >> As OpenVPN runs as a service using own user or system account, IE API > >> is not suitable. > > > > Sadly I haven't found the WinHttpGetProxyForUrl API in MinGW W32API. So, > > use of this might rather be a long-term goal as it takes a while to get > > it included. > > No problem to add simple prototypes and perform GetProcAddress(). Not pretty, but yes. > > If the service is started by the GUI it still makes sense to use user > > specific proxy settings, doesn't it? One could consider auto-proxy for > > auto-started VPNs a misconfiguration, as well. Or am I mislead? > > If this is a service that is started, it cannot access your proxy > without more tweaks. Currently not that's true, but the service interface needs to be extended to pass data between the GUI and openvpn in the future anyways. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro GmbH & Co. KG | An der RaumFabrik 33a | 76227 Karlsruhe | Germany Astaro GmbH & Co. KG Commercial Register: Mannheim HRA 702710 Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH An der RaumFabrik 33a | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen 

http://www.verisign.com/code-signing/content-signing-certificates/microsoft-authenticode/index.html On Wed, Apr 28, 2010 at 10:38 PM, Peter Stuge <pe...@st...> wrote: > Jon Onstott wrote: >> I would like to go ahead and compile and sign the TAP drivers >> myself.  Does anyone know which certificate would be best to >> purchase? > > There was some discussion about this on the libusb mailinglist just > the other day. It seems there may be a good deal to be had with > VeriSign right now, but it's not absolutely clear if it's the right > kind of certificate. (See Tim's post about WinQual vs. signing.) > > http://sourceforge.net/mailarchive/forum.php?thread_name=l2wa276da401004271651uc1557d88r1106a473ade1b29%40mail.gmail.com&forum_name=libusb-devel > > > //Peter > > ------------------------------------------------------------------------------ > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >