openvpn-devel Mailing List for OpenVPN

Alon Bar-Lev wrote: > Some minor comments. > 1. Please rebase against trunk. Done. > > - gateway); > > + netmask); > > + if (r->gateway) > > + argv_printf_cat (&argv, "gw %s", gateway); > > + else > > + argv_printf_cat (&argv, "dev %s", r->gateway_ifname); > > if (r->metric_defined) > > argv_printf_cat (&argv, "metric %d", r->metric); > > #endif /*CONFIG_FEATURE_IPROUTE*/ > > 2. Please declare a variable at the epilogue of the function > as gateway. I don't understand what do you mean. ??? > + { > > + sscanf (line, "%s\t", gw_if_name); > > + } > > 3. Please don't use scanf this way as it may overflow the buffer. > Use %##s and check that overflow is avoided. I use "%32s\t" now. How do I check for overflow? sscanf always returns 1. Besides, the linux kernel headers declare 32 as maximum iface name length. Even in case of overflow, what shoudl I do ? Return false ? I think leaving it as is is good for 99,999% of cases and in the rest (in case of overflow), either a gateway IP address is present, so no problem, or the route add command will fail (or use the wrong device). Not perfect, but what is in these days ? ;-) Regards, David PS: the new patch, against trunk: diff -u openvpn_trunk/route.c openvpn_patched/route.c --- openvpn_trunk/route.c 2009-01-29 15:00:04.525034400 +0100 +++ openvpn_patched/route.c 2009-01-29 15:03:41.116012000 +0100 @@ -45,7 +45,7 @@ static void add_route (struct route *r, const struct tuntap *tt, unsigned int flags, const struct env_set *es); static void delete_route (const struct route *r, const struct tuntap *tt, unsigned int flags, const struct env_set *es); -static bool get_default_gateway (in_addr_t *ret); +static bool get_default_gateway (in_addr_t *ret, char *gw_if_name); struct route_option_list * new_route_option_list (struct gc_arena *a) @@ -298,7 +298,7 @@ rl->spec.remote_host_defined = true; } - rl->spec.net_gateway_defined = get_default_gateway (&rl->spec.net_gateway); + rl->spec.net_gateway_defined = get_default_gateway (&rl->spec.net_gateway, rl->spec.net_gateway_ifname); if (rl->spec.net_gateway_defined) { setenv_route_addr (es, "net_gateway", rl->spec.net_gateway, -1); @@ -362,6 +362,7 @@ add_route3 (in_addr_t network, in_addr_t netmask, in_addr_t gateway, + char * gateway_ifname, const struct tuntap *tt, unsigned int flags, const struct env_set *es) @@ -372,6 +373,7 @@ r.network = network; r.netmask = netmask; r.gateway = gateway; + r.gateway_ifname = gateway_ifname; add_route (&r, tt, flags, es); } @@ -418,6 +420,7 @@ add_route3 (rl->spec.remote_host, ~0, rl->spec.net_gateway, + rl->spec.net_gateway_ifname, tt, flags, es); @@ -428,6 +431,7 @@ add_route3 (0x00000000, 0x80000000, rl->spec.remote_endpoint, + NULL, tt, flags, es); @@ -436,6 +440,7 @@ add_route3 (0x80000000, 0x80000000, rl->spec.remote_endpoint, + NULL, tt, flags, es); @@ -454,6 +459,7 @@ add_route3 (0, 0, rl->spec.remote_endpoint, + NULL, tt, flags, es); @@ -511,6 +517,7 @@ add_route3 (0, 0, rl->spec.net_gateway, + rl->spec.net_gateway_ifname, tt, flags, es); @@ -678,18 +685,24 @@ #if defined(TARGET_LINUX) #ifdef CONFIG_FEATURE_IPROUTE - buf_printf (&buf, IPROUTE_PATH " route add %s/%d via %s", + buf_printf (&buf, IPROUTE_PATH " route add %s/%d", network, - count_netmask_bits(netmask), - gateway); + count_netmask_bits(netmask)); + if (r->gateway) + argv_printf_cat (&argv, "via %s", gateway); + else + argv_printf_cat (&argv, "dev %s", r->gateway_ifname); if (r->metric_defined) buf_printf (&buf, " metric %d", r->metric); #else - buf_printf (&buf, ROUTE_PATH " add -net %s netmask %s gw %s", + buf_printf (&buf, ROUTE_PATH " add -net %s netmask %s", network, - netmask, - gateway); + netmask); + if (r->gateway) + argv_printf_cat (&argv, "gw %s", gateway); + else + argv_printf_cat (&argv, "dev %s", r->gateway_ifname); if (r->metric_defined) buf_printf (&buf, " metric %d", r->metric); #endif /*CONFIG_FEATURE_IPROUTE*/ @@ -1014,7 +1027,7 @@ } static bool -get_default_gateway (in_addr_t *gateway) +get_default_gateway (in_addr_t *gateway, char *gw_ifname) { struct gc_arena gc = gc_new (); int i; @@ -1242,7 +1255,7 @@ #elif defined(TARGET_LINUX) static bool -get_default_gateway (in_addr_t *gateway) +get_default_gateway (in_addr_t *gateway, char *gw_if_name) { struct gc_arena gc = gc_new (); bool ret = false; @@ -1283,6 +1296,10 @@ if (!net && !mask && metric < lowest_metric) { best_gw = gw; + if (gw_if_name) + { + sscanf (line, "%" IFNAME_MAXLEN_STR "s\t", gw_if_name); + } lowest_metric = metric; best_count = count; } @@ -1292,7 +1309,7 @@ } fclose (fp); - if (best_gw) + if (best_count) { *gateway = best_gw; ret = true; @@ -1370,7 +1387,7 @@ ((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long)) static bool -get_default_gateway (in_addr_t *ret) +get_default_gateway (in_addr_t *ret, char *gw_if_name) { struct gc_arena gc = gc_new (); int s, seq, l, pid, rtm_addrs, i; @@ -1527,7 +1544,7 @@ ((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long)) static bool -get_default_gateway (in_addr_t *ret) +get_default_gateway (in_addr_t *ret, char *gw_if_name) { struct gc_arena gc = gc_new (); int s, seq, l, pid, rtm_addrs, i; @@ -1683,7 +1700,7 @@ ((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long)) static bool -get_default_gateway (in_addr_t *ret) +get_default_gateway (in_addr_t *ret, char *gw_if_name) { struct gc_arena gc = gc_new (); int s, seq, l, rtm_addrs, i; @@ -1782,7 +1799,7 @@ #else static bool -get_default_gateway (in_addr_t *ret) +get_default_gateway (in_addr_t *ret, char *gw_if_name) { return false; } diff -u openvpn_trunk/route.h openvpn_patched/route.h --- openvpn_trunk/route.h 2009-01-29 15:00:04.650032800 +0100 +++ openvpn_patched/route.h 2009-01-29 15:03:46.100323200 +0100 @@ -48,11 +48,15 @@ */ #define ROUTE_DELETE_FIRST 2 +#define IFNAME_MAXLEN 32 +#define IFNAME_MAXLEN_STR "32" + struct route_special_addr { in_addr_t remote_endpoint; bool remote_endpoint_defined; in_addr_t net_gateway; + char net_gateway_ifname[IFNAME_MAXLEN]; bool net_gateway_defined; in_addr_t remote_host; bool remote_host_defined; @@ -79,6 +83,7 @@ in_addr_t network; in_addr_t netmask; in_addr_t gateway; + char * gateway_ifname; bool metric_defined; int metric; }; 

Some minor comments. 1. Please rebase against trunk. On 1/29/09, David Balazic <Dav...@he...> wrote: > diff -u -r openvpn-2.1_rc15/route.c openvpn-2.1_rc15_gwfix/route.c > --- openvpn-2.1_rc15/route.c 2008-11-17 00:48:04.000000000 +0000 > +++ openvpn-2.1_rc15_gwfix/route.c 2008-12-18 19:59:36.455394121 +0000 > @@ -805,20 +814,26 @@ > > #if defined(TARGET_LINUX) > #ifdef CONFIG_FEATURE_IPROUTE > - argv_printf (&argv, "%s route add %s/%d via %s", > + argv_printf (&argv, "%s route add %s/%d", > iproute_path, > network, > - count_netmask_bits(netmask), > - gateway); > + count_netmask_bits(netmask)); > + if (r->gateway) > + argv_printf_cat (&argv, "via %s", gateway); > + else > + argv_printf_cat (&argv, "dev %s", r->gateway_ifname); > if (r->metric_defined) > argv_printf_cat (&argv, "metric %d", r->metric); > > #else > - argv_printf (&argv, "%s add -net %s netmask %s gw %s", > + argv_printf (&argv, "%s add -net %s netmask %s", > ROUTE_PATH, > network, > - netmask, > - gateway); > + netmask); > + if (r->gateway) > + argv_printf_cat (&argv, "gw %s", gateway); > + else > + argv_printf_cat (&argv, "dev %s", r->gateway_ifname); > if (r->metric_defined) > argv_printf_cat (&argv, "metric %d", r->metric); > #endif /*CONFIG_FEATURE_IPROUTE*/ 2. Please declare a variable at the epilogue of the function as gateway. > @@ -1516,6 +1531,10 @@ > if (!net && !mask && metric < lowest_metric) > { > best_gw = gw; > + if (gw_if_name) > + { > + sscanf (line, "%s\t", gw_if_name); > + } > lowest_metric = metric; > best_count = count; > } 3. Please don't use scanf this way as it may overflow the buffer. Use %##s and check that overflow is avoided. Alon. 

Hi! I'm resending this patch. Originally I sent it here [1]. In short: In the diff (agains 2.1_rc15) is the solution for the old* problem of (not) detecting default gateway on linux systems if it is a device route. It was tested by one affected user (Antonis Tsolomitis, see the thread "openvpn and ppp" on the openvpn-users list). Successfully. If I forgot anything, ask. Regards, David *See mail list threads: "Redirect-gateway on dialup" <http://thread.gmane.org/gmane.network.openvpn.user/20407> "redirect-gateway + http-proxy + ppp problem" <http://thread.gmane.org/gmane.network.openvpn.user/20994> "Cannot redirect gateway after pppd connection" <http://thread.gmane.org/gmane.network.openvpn.user/23972> "openvpn and ppp" <http://thread.gmane.org/gmane.network.openvpn.user/25117> [1]: http://article.gmane.org/gmane.network.openvpn.devel/2472 The patch: diff -u -r openvpn-2.1_rc15/route.c openvpn-2.1_rc15_gwfix/route.c --- openvpn-2.1_rc15/route.c	2008-11-17 00:48:04.000000000 +0000 +++ openvpn-2.1_rc15_gwfix/route.c	2008-12-18 19:59:36.455394121 +0000 @@ -371,7 +371,7 @@ rl->spec.default_metric_defined = true; } - rl->spec.net_gateway_defined = get_default_gateway (&rl->spec.net_gateway, NULL); + rl->spec.net_gateway_defined = get_default_gateway (&rl->spec.net_gateway, NULL, rl->spec.net_gateway_ifname); if (rl->spec.net_gateway_defined) { setenv_route_addr (es, "net_gateway", rl->spec.net_gateway, -1); @@ -440,6 +440,7 @@ add_route3 (in_addr_t network, in_addr_t netmask, in_addr_t gateway, + char * gateway_ifname, const struct tuntap *tt, unsigned int flags, const struct env_set *es) @@ -450,6 +451,7 @@ r.network = network; r.netmask = netmask; r.gateway = gateway; + r.gateway_ifname = gateway_ifname; add_route (&r, tt, flags, es); } @@ -473,6 +475,7 @@ static void add_bypass_routes (struct route_bypass *rb, in_addr_t gateway, + char * gateway_ifname, const struct tuntap *tt, unsigned int flags, const struct env_set *es) @@ -484,6 +487,7 @@	add_route3 (rb->bypass[i], ~0, gateway, + gateway_ifname, tt, flags, es); @@ -536,12 +540,13 @@ add_route3 (rl->spec.remote_host,	~0,	rl->spec.net_gateway, +	rl->spec.net_gateway_ifname,	tt,	flags,	es); /* route DHCP/DNS server traffic through original default gateway */ - add_bypass_routes (&rl->spec.bypass, rl->spec.net_gateway, tt, flags, es); + add_bypass_routes (&rl->spec.bypass, rl->spec.net_gateway, rl->spec.net_gateway_ifname, tt, flags, es); if (rl->flags & RG_DEF1) { @@ -549,6 +554,7 @@ add_route3 (0x00000000, 0x80000000, rl->spec.remote_endpoint, + NULL, tt, flags, es); @@ -557,6 +563,7 @@ add_route3 (0x80000000, 0x80000000, rl->spec.remote_endpoint, + NULL, tt, flags, es); @@ -575,6 +582,7 @@ add_route3 (0, 0, rl->spec.remote_endpoint, + NULL, tt, flags, es); @@ -635,6 +643,7 @@ add_route3 (0, 0, rl->spec.net_gateway, + rl->spec.net_gateway_ifname, tt, flags, es); @@ -805,20 +814,26 @@ #if defined(TARGET_LINUX) #ifdef CONFIG_FEATURE_IPROUTE - argv_printf (&argv, "%s route add %s/%d via %s", + argv_printf (&argv, "%s route add %s/%d", iproute_path, network, - count_netmask_bits(netmask), - gateway); + count_netmask_bits(netmask)); + if (r->gateway) + argv_printf_cat (&argv, "via %s", gateway); + else + argv_printf_cat (&argv, "dev %s", r->gateway_ifname); if (r->metric_defined) argv_printf_cat (&argv, "metric %d", r->metric); #else - argv_printf (&argv, "%s add -net %s netmask %s gw %s", + argv_printf (&argv, "%s add -net %s netmask %s",	ROUTE_PATH, network, - netmask, - gateway); + netmask); + if (r->gateway) + argv_printf_cat (&argv, "gw %s", gateway); + else + argv_printf_cat (&argv, "dev %s", r->gateway_ifname); if (r->metric_defined) argv_printf_cat (&argv, "metric %d", r->metric); #endif /*CONFIG_FEATURE_IPROUTE*/ @@ -1253,7 +1268,7 @@ } bool -get_default_gateway (in_addr_t *gw, in_addr_t *netmask) +get_default_gateway (in_addr_t *gw, in_addr_t *netmask, char *gw_ifname) { struct gc_arena gc = gc_new (); bool ret_bool = false; @@ -1475,7 +1490,7 @@ #elif defined(TARGET_LINUX) bool -get_default_gateway (in_addr_t *gateway, in_addr_t *netmask) +get_default_gateway (in_addr_t *gateway, in_addr_t *netmask, char *gw_if_name) { struct gc_arena gc = gc_new (); bool ret = false; @@ -1516,6 +1531,10 @@ if (!net && !mask && metric < lowest_metric) { best_gw = gw; + if (gw_if_name) +	{ + sscanf (line, "%s\t", gw_if_name); +	} lowest_metric = metric; best_count = count; } @@ -1525,7 +1544,7 @@	} fclose (fp); - if (best_gw) + if (best_count)	{ *gateway = best_gw; if (netmask) @@ -1607,7 +1626,7 @@ ((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long)) bool -get_default_gateway (in_addr_t *ret, in_addr_t *netmask) +get_default_gateway (in_addr_t *ret, in_addr_t *netmask, char *gw_if_name) { struct gc_arena gc = gc_new (); int s, seq, l, pid, rtm_addrs, i; @@ -1769,7 +1788,7 @@ ((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long)) bool -get_default_gateway (in_addr_t *ret, in_addr_t *netmask) +get_default_gateway (in_addr_t *ret, in_addr_t *netmask, char *gw_if_name) { struct gc_arena gc = gc_new (); int s, seq, l, pid, rtm_addrs, i; @@ -1930,7 +1949,7 @@ ((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long)) bool -get_default_gateway (in_addr_t *ret, in_addr_t *netmask) +get_default_gateway (in_addr_t *ret, in_addr_t *netmask, char *gw_if_name) { struct gc_arena gc = gc_new (); int s, seq, l, rtm_addrs, i; @@ -2034,7 +2053,7 @@ #else bool -get_default_gateway (in_addr_t *ret, in_addr_t *netmask) +get_default_gateway (in_addr_t *ret, in_addr_t *netmask, char *gw_ifname) { return false; } @@ -2152,7 +2171,7 @@ in_addr_t gwip = 0; bool ret = false; - if (!get_default_gateway (&gwip, NULL)) + if (!get_default_gateway (&gwip, NULL, NULL)) { msg (M_WARN, "GDGMA: get_default_gateway failed"); goto err; @@ -2249,7 +2268,7 @@ DWORD a_index; const IP_ADAPTER_INFO *ai; - if (!get_default_gateway (&gwip, NULL)) + if (!get_default_gateway (&gwip, NULL, NULL)) { msg (M_WARN, "GDGMA: get_default_gateway failed"); goto err; diff -u -r openvpn-2.1_rc15/route.h openvpn-2.1_rc15_gwfix/route.h --- openvpn-2.1_rc15/route.h	2008-10-06 07:22:20.000000000 +0000 +++ openvpn-2.1_rc15_gwfix/route.h	2008-12-18 18:29:54.996393885 +0000 @@ -61,6 +61,7 @@ in_addr_t remote_endpoint; bool remote_endpoint_defined; in_addr_t net_gateway; + char net_gateway_ifname[32]; bool net_gateway_defined; in_addr_t remote_host; bool remote_host_defined; @@ -95,6 +96,7 @@ in_addr_t network; in_addr_t netmask; in_addr_t gateway; + char * gateway_ifname; bool metric_defined; int metric; }; @@ -156,7 +158,7 @@ bool is_special_addr (const char *addr_str); -bool get_default_gateway (in_addr_t *ip, in_addr_t *netmask); +bool get_default_gateway (in_addr_t *ip, in_addr_t *netmask, char *gw_if_name); #if AUTO_USERID bool get_default_gateway_mac_addr (unsigned char *macaddr); diff -u -r openvpn-2.1_rc15/tun.c openvpn-2.1_rc15_gwfix/tun.c --- openvpn-2.1_rc15/tun.c	2008-11-17 00:48:04.000000000 +0000 +++ openvpn-2.1_rc15_gwfix/tun.c	2008-12-18 11:26:07.951394102 +0000 @@ -274,7 +274,7 @@ in_addr_t lan_gw = 0; in_addr_t lan_netmask = 0; - if (get_default_gateway (&lan_gw, &lan_netmask)) + if (get_default_gateway (&lan_gw, &lan_netmask, NULL)) { const in_addr_t lan_network = lan_gw & lan_netmask; const in_addr_t network = ip & netmask; @@ -301,7 +301,7 @@ in_addr_t lan_gw = 0; in_addr_t lan_netmask = 0; - if (get_default_gateway (&lan_gw, &lan_netmask)) + if (get_default_gateway (&lan_gw, &lan_netmask, NULL)) { const in_addr_t lan_network = lan_gw & lan_netmask; if (lan_network == 0xC0A80000 || lan_network == 0xC0A80100) --------------------------------------------------------------------- http://www.nosoftwarepatents.com Innovation, not litigation ! --- David Balažic mailto:dav...@he... HERMES Softlab http://www.hermes-softlab.com Zagrebska cesta 104 Phone: +386 2 450 8947 SI-2000 Maribor Slovenija --------------------------------------------------------------------- "Be excellent to each other." - Bill S. Preston, Esq. & "Ted" Theodore Logan --------------------------------------------------------------------- 

On 1/29/09, David Balazic <Dav...@he...> wrote: > Hi! > > I sent a patch recently to the openvpn-devel list and got > no reply whatsoever. Did I miss something ? Is there a procedure > that I did not follow ? Send the patch again. At the subject specify [PATCH] Place the patch inline, be sure your mail client does not remove tabs, by sending the message first to your-self and try to apply it. Alon. 

David Sommerseth a écrit : > From what I've heard from other sources as well, this is usually the > normal procedure ... pop the patch to this mailing list .... and watch > if something happens ... or not .... you might get a response, and you > might not. Who knows ... It is a good summary of the management of openvpn. Hopefully it's not a program that deals with security, otherwise we would be worried... -- Thomas 

 David Balazic wrote: > Hi! > > I sent a patch recently to the openvpn-devel list and got > no reply whatsoever. Did I miss something ? Is there a procedure > that I did not follow ? From what I've heard from other sources as well, this is usually the normal procedure ... pop the patch to this mailing list .... and watch if something happens ... or not .... you might get a response, and you might not. Who knows ... kind regards, David Sommerseth > That patch is to fix a longstanding bug that users encountered. > > Regards, > David > > PS: the mail message in question is : > Fix for "Cannot read current default gateway" problem on Linux > http://article.gmane.org/gmane.network.openvpn.devel/2472 > >> -----Original Message----- >> From: Alon Bar-Lev [mailto:alo...@gm...] >> Sent: Tuesday, January 27, 2009 5:32 PM >> To: ope...@li... >> Subject: Re: [Openvpn-devel] [PATCH] Fix non-C89 comments >> >> Sent this to James. >> Did not apply. >> >> My queue is at: >> http://svn.openvpn.net/projects/openvpn/contrib/alon >> >> On 1/27/09, Matthias Andree >> <ma+...@dt...> wrote: >>> Hi, >>> >>> openvpn uses non-C89 //-style comments in two places. >> Patch to convert >>> these to /* ... */ style comments attached. >>> >>> Best >>> >>> -- >>> >>> Matthias Andree >>> >>> >> -------------------------------------------------------------- >> ---------------- >>> This SF.net email is sponsored by: >>> SourcForge Community >>> SourceForge wants to tell your story. >>> http://p.sf.net/sfu/sf-spreadtheword >>> _______________________________________________ >>> Openvpn-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel >>> >>> >>> >> -------------------------------------------------------------- >> ---------------- >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Openvpn-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

Hi! I sent a patch recently to the openvpn-devel list and got no reply whatsoever. Did I miss something ? Is there a procedure that I did not follow ? That patch is to fix a longstanding bug that users encountered. Regards, David PS: the mail message in question is : Fix for "Cannot read current default gateway" problem on Linux http://article.gmane.org/gmane.network.openvpn.devel/2472 > -----Original Message----- > From: Alon Bar-Lev [mailto:alo...@gm...] > Sent: Tuesday, January 27, 2009 5:32 PM > To: ope...@li... > Subject: Re: [Openvpn-devel] [PATCH] Fix non-C89 comments > > Sent this to James. > Did not apply. > > My queue is at: > http://svn.openvpn.net/projects/openvpn/contrib/alon > > On 1/27/09, Matthias Andree > <ma+...@dt...> wrote: > > Hi, > > > > openvpn uses non-C89 //-style comments in two places. > Patch to convert > > these to /* ... */ style comments attached. > > > > Best > > > > -- > > > > Matthias Andree > > > > > -------------------------------------------------------------- > ---------------- > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > Openvpn-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > > > > > > > -------------------------------------------------------------- > ---------------- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > 

On Tue, 27 Jan 2009, Alon Bar-Lev wrote: > > Perhaps the choice of version control system used for OpenVPN could > > deserve a second thought -- Mercurial or better Git might support such > > models or merge queues much better than Subversion does. > > > > Nope. > subversion is the simplest one to use. That's a moot point and depending on requirement no longer true (seems to me this assertion has always been untrue WRT Mercurial that prints helpful usage hints all along the way) -- let me state just three points where I find Mercurial (Hg) or GIT superior to SVN, and that the basic day-to-day operation is done with the usual set of checkout, diff, branch, merge, commit, log commands in either of the systems. (1) selective (partial/interactive) commits of hunks (built-in with Git, try git commit -i or -p; for Mercurial, there's the record extension that ships with the tarball proper) (2) "properties" (svn propedit ... eek) and (3) cheap & fast & really lightweight tags and branches. No need to remember URLs and type three lines even for basic operations such as tagging or branching. SVN is lightweight on the server's repository database, but heavy on my fingers and local file system... Further advocacy, comparisons, and tutorials are for other places of the Internet than this list; let me just point towards Mercurial + MQ, Git or StGit if you want patch queue handling. Historical note: If you've last looked at an early Mercurial 0.X version (current is 1.1.X), or a Git version before 1.5 (current is beyond 1.6.1), you might want to know that lots of things have improved, particularly usability and documentation. Git has evolved into a real version control system that's usable. -- Matthias Andree 

Matthias Andree wrote: > On Tue, 27 Jan 2009, Alon Bar-Lev wrote: > >> Sent this to James. >> Did not apply. >> >> My queue is at: >> http://svn.openvpn.net/projects/openvpn/contrib/alon > > Perhaps the choice of version control system used for OpenVPN could > deserve a second thought -- Mercurial or better Git might support such > models or merge queues much better than Subversion does. I'm on top of this -- Alon's queue including Jos Vos's [PATCH] Fix non-C89 comments has been merged: ------------------------------------------------------------------------ r3899 | james | 2009-01-27 12:22:42 -0700 (Tue, 27 Jan 2009) | 2 lines Changed paths: M /branches/BETA21/openvpn/proto.h M /branches/BETA21/openvpn/route.c Fixed some issues with C++ style comments that leaked into the code. ------------------------------------------------------------------------ r3900 | james | 2009-01-27 12:32:46 -0700 (Tue, 27 Jan 2009) | 2 lines Changed paths: M /branches/BETA21/openvpn/error.c M /branches/BETA21/openvpn/ntlm.c M /branches/BETA21/openvpn/pkcs11.c M /branches/BETA21/openvpn/win32.h Fixed some compile-time warnings. ------------------------------------------------------------------------ r3901 | james | 2009-01-27 13:05:48 -0700 (Tue, 27 Jan 2009) | 2 lines Changed paths: M /branches/BETA21/openvpn/configure.ac Updated configure.ac to work on MinGW. ------------------------------------------------------------------------ r3902 | james | 2009-01-27 13:10:49 -0700 (Tue, 27 Jan 2009) | 2 lines Changed paths: M /branches/BETA21/openvpn/common.h Updated common.h types for _WIN64. ------------------------------------------------------------------------ r3903 | james | 2009-01-27 14:18:51 -0700 (Tue, 27 Jan 2009) | 3 lines Changed paths: M /branches/BETA21/openvpn/ssl.c Fixed issue involving an #ifdef in a macro reference that breaks early gcc compilers. ------------------------------------------------------------------------ James 

 Alon Bar-Lev wrote: > On 1/27/09, Matthias Andree <ma+...@dt...> wrote: >> On Tue, 27 Jan 2009, Alon Bar-Lev wrote: >> >> > Sent this to James. >> > Did not apply. >> > >> > My queue is at: >> > http://svn.openvpn.net/projects/openvpn/contrib/alon >> >> >> Perhaps the choice of version control system used for OpenVPN could >> deserve a second thought -- Mercurial or better Git might support such >> models or merge queues much better than Subversion does. >> > > Nope. > subversion is the simplest one to use. > > Alon. Luckily for us who find git a lot easier than svn, there is always git-svn ... even though it's slow to do the fetching, it's a lot more comfortable to use. But once the fetching is done, it's as quick as a SCM should be. I really do not intend to start a flame war over what's best or not - respect that there are different opinions ... but I have used both svn and git, and I am of a complete different opinion regarding what is the simplest one. kind regards, David Sommerseth 

On 1/27/09, Matthias Andree <ma+...@dt...> wrote: > On Tue, 27 Jan 2009, Alon Bar-Lev wrote: > > > Sent this to James. > > Did not apply. > > > > My queue is at: > > http://svn.openvpn.net/projects/openvpn/contrib/alon > > > Perhaps the choice of version control system used for OpenVPN could > deserve a second thought -- Mercurial or better Git might support such > models or merge queues much better than Subversion does. > Nope. subversion is the simplest one to use. Alon. 

On Tue, 27 Jan 2009, Alon Bar-Lev wrote: > Sent this to James. > Did not apply. > > My queue is at: > http://svn.openvpn.net/projects/openvpn/contrib/alon Perhaps the choice of version control system used for OpenVPN could deserve a second thought -- Mercurial or better Git might support such models or merge queues much better than Subversion does. -- Matthias Andree 

On Tue, 27 Jan 2009, Jos Vos wrote: > On Tue, Jan 27, 2009 at 04:45:19PM +0100, Matthias Andree wrote: > > > Come on, nobody needs support for outdated operating systems and rogue > > releases of GCC. There has never been a GCC 2.96, and Redhat 7.3 has > > been out of security support for more than half a decade now, and if > > OpenVPN 2.1 breaks on such systems, that's perhaps some more incentive > > for their users to upgrade. See: > > > > * <http://gcc.gnu.org/gcc-2.96.html> > > * <http://www.redhat.com/security/updates/eol/> > > The rc10 ChangeLog says > > * Fixed separate compile errors in options.c and ntlm.c that occur > on strict C compilers (such as old versions of gcc) that require > that C variable declarations occur at the start of a {} block, > not in the middle. > > so I thought this might fall into the same category (although I don't > know if this way of using the C preprocessor is formally allowed or > not). But I don't mind *not* sharing this kind of patches anymore in > the future, if that bothers people too much. Sorry, I didn't mean to offend you, <lang='nl'>en dank je wel voor jouw patch</lang>; I was merely stumbling across "gcc-2.96/RH 7.3" which made me misinterpret the real motivation. The official gcc 2.95.3 doesn't compile ssl.c either, and apparently it's rightfully refusing to (I checked the opencsw.org compiler on Solaris 8 SPARC). I checked around a bit, and for not having a current C standard handy, I'll relay this Apple developer document instead, without checking it: http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/cpp/Directives-Within-Macro-Arguments.html#Directives-Within-Macro-Arguments where Apple effectively state that the behaviour OpenVPN requests is undefined. If they're right, the behaviour used in ssl.c that you fixed was a GCC 3.2+ extension, so your patch fixes a real bug rather than compability with ancient compilers. I stand corrected. Sorry for the harsh tone. Take care, -- Matthias Andree 

Added to: http://svn.openvpn.net/projects/openvpn/contrib/alon/BETA21-oldgcc Up to james to merge. On 1/27/09, Jos Vos <jo...@xo...> wrote: > Hi, > > While there were some incompatibilities with older GCC releases > resolved from RC9 to RC15 (I didn't try the releases RC10-RC14), > a new incompatibility was introduced concerning the C preprocessor > in ssl.c: #ifdef's in macro calls do not seem to be allowed with > GCC 2.96. > > Attached a brute-force patch to fix that. This patch was tested > on Red Hat Linux 7.3 with GCC 2.96. > > Regards, > > > -- > -- Jos Vos <jo...@xo...> > -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 > -- Amsterdam, The Netherlands | Fax: +31 20 6948204 > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > > 

On Tue, Jan 27, 2009 at 04:45:19PM +0100, Matthias Andree wrote: > Come on, nobody needs support for outdated operating systems and rogue > releases of GCC. There has never been a GCC 2.96, and Redhat 7.3 has > been out of security support for more than half a decade now, and if > OpenVPN 2.1 breaks on such systems, that's perhaps some more incentive > for their users to upgrade. See: > > * <http://gcc.gnu.org/gcc-2.96.html> > * <http://www.redhat.com/security/updates/eol/> The rc10 ChangeLog says * Fixed separate compile errors in options.c and ntlm.c that occur on strict C compilers (such as old versions of gcc) that require that C variable declarations occur at the start of a {} block, not in the middle. so I thought this might fall into the same category (although I don't know if this way of using the C preprocessor is formally allowed or not). But I don't mind *not* sharing this kind of patches anymore in the future, if that bothers people too much. And yes, I do know the status of old RH and GCC releases and I do know that this patch is not necessary for "normal" use. -- -- Jos Vos <jo...@xo...> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 

Sent this to James. Did not apply. My queue is at: http://svn.openvpn.net/projects/openvpn/contrib/alon On 1/27/09, Matthias Andree <ma+...@dt...> wrote: > Hi, > > openvpn uses non-C89 //-style comments in two places. Patch to convert > these to /* ... */ style comments attached. > > Best > > -- > > Matthias Andree > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > > 

Hi, openvpn uses non-C89 //-style comments in two places. Patch to convert these to /* ... */ style comments attached. Best -- Matthias Andree 

On Tue, 27 Jan 2009, Jos Vos wrote: > While there were some incompatibilities with older GCC releases > resolved from RC9 to RC15 (I didn't try the releases RC10-RC14), > a new incompatibility was introduced concerning the C preprocessor > in ssl.c: #ifdef's in macro calls do not seem to be allowed with > GCC 2.96. > > Attached a brute-force patch to fix that. This patch was tested > on Red Hat Linux 7.3 with GCC 2.96. Come on, nobody needs support for outdated operating systems and rogue releases of GCC. There has never been a GCC 2.96, and Redhat 7.3 has been out of security support for more than half a decade now, and if OpenVPN 2.1 breaks on such systems, that's perhaps some more incentive for their users to upgrade. See: * <http://gcc.gnu.org/gcc-2.96.html> * <http://www.redhat.com/security/updates/eol/> -- Matthias Andree 

Hi, While there were some incompatibilities with older GCC releases resolved from RC9 to RC15 (I didn't try the releases RC10-RC14), a new incompatibility was introduced concerning the C preprocessor in ssl.c: #ifdef's in macro calls do not seem to be allowed with GCC 2.96. Attached a brute-force patch to fix that. This patch was tested on Red Hat Linux 7.3 with GCC 2.96. Regards, -- -- Jos Vos <jo...@xo...> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Short version: After temporary loss of the physical connection, OpenVPN does not reestablish the tunnel due to a routing loop. I think this is a Windows issue that OpenVPN should try to work around. We are running v2.1_rc15 on the clients, rc15 on one server and rc13 on the other two. Long version: I have configured the routing computer on our wireless network to intercept OpenVPN traffic destined to our normal OpenVPN server and serve it locally. It adds the "redirect-gateway def1" option so that all traffic on the wireless link will be protected by the VPN. To ensure that a reconnection attempt to a different server address will not be looped into the tunnel, I added two /32 routes for the server addresses to the wireless gateway. This worked great in hard-wired testing on that subnet. In wireless use, we find that Windows will dump SOME of the routes created by OpenVPN when the radio changes APs (or for whatever reason drops momentarily). It seems to be deleting routes which use the gateway of that interface (or maybe just anything on that subnet?). So specifically: Wireless subnet: 172.21.166.0/24 Gateway (and OpenVPN server): 172.21.166.254 Public server addresses: 65.120.131.235 & .238 The gateway uses iptables to internally redirect requests to the public addresses to itself. The client computers think they are still talking to the public address. push "route 65.120.131.235 255.255.255.255 172.21.166.254" push "route 65.120.131.238 255.255.255.255 172.21.166.254" push "redirect-gateway def1" After anything that makes Windows reset the physical interface, the route table no longer contains the 65.120.131.* routes. My guess is that it deleted any routes that used 172.21.166.* as a gateway, and then re-added 172.21.166.254 as the default after DHCP finished negotiating. I can see two possible OpenVPN fixes for this, but I have not even dared to look at the code yet. When trying to reconnect after a ping-timeout: 1) Remove all OpenVPN-added routes first, or 2) Re-add/fix all OpenVPN-added routes first. Either would work in my situation, but some people may want to choose between the two. Daniel Johnson Pro...@us... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFJefql6vGcUBY+ge8RAjoAAJ9NzJE/p3qxJlwnv5cWIwpfBS6b0gCghNHr bObdcQYAH1Ob7Z93t9ATzHg= =xN7F -----END PGP SIGNATURE----- 

I am using openvpn to test IP fragmentation with small MTU values. I would like to set the tun/tap interface to have an MTU of 68 bytes, the minimum allowed by RFC 791. But openvpn defines a constant TUN_MTU_MIN with a value of 100. Can someone explain why the MTU must be this large? 

Hi, I have to setup and configure a VPLS (Virtual Private LAN Service) network. I am a real beginner in openvpn and I'd like to know if i can do that with openvpn? if openvpn supports VPLS or if there esist any plug-in for this one? Many thanks, Pete 

The installation is working properly and the TAP driver is just fine. You have to run it as Admin because the route(or I have to check the UAC...) but there is no issue to install and use! OpenVPN is Win7 ready. Let me know if you need to run any kind of test or I could help. Best regards, Istvan On Wed, Jan 21, 2009 at 5:08 PM, James Yonan <ji...@yo...> wrote: > I've patched the NSIS installer to omit the Windows version check. > > Try this installer: > > http://openvpn.net/beta/openvpn-2.1_rc15e-install.exe > > James > > István Szukács wrote: > >> Hi folks! >> >> >> I am wondering if you have ever had success to run openvpn on windows 7. >> The problem is the latest installer( >> http://openvpn.net/release/openvpn-2.1_rc15-install.exe) says this >> version is not supporting windows.... I try to install >> http://openvpn.se/files/install_packages/openvpn-2.0.9-gui-1.0.3-install.exe, >> works fine except the fact that the tap driver is not signed and because of >> this it remains disabled and you cannot use openvpn(but runs well up to the >> point when initialize the driver). >> >> If you could point me a doc how to make it run on win7 it would be much >> appreciated. If I could help with anything the win7 build let me know.... >> >> >> Regards, >> Istvan >> >> >> -- >> the sun shines for all >> >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Openvpn-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel >> > -- the sun shines for all 

Thanks a million I am going to check it soon. Regards, Istvan On Wed, Jan 21, 2009 at 5:08 PM, James Yonan <ji...@yo...> wrote: > I've patched the NSIS installer to omit the Windows version check. > > Try this installer: > > http://openvpn.net/beta/openvpn-2.1_rc15e-install.exe > > James > > István Szukács wrote: > >> Hi folks! >> >> >> I am wondering if you have ever had success to run openvpn on windows 7. >> The problem is the latest installer( >> http://openvpn.net/release/openvpn-2.1_rc15-install.exe) says this >> version is not supporting windows.... I try to install >> http://openvpn.se/files/install_packages/openvpn-2.0.9-gui-1.0.3-install.exe, >> works fine except the fact that the tap driver is not signed and because of >> this it remains disabled and you cannot use openvpn(but runs well up to the >> point when initialize the driver). >> >> If you could point me a doc how to make it run on win7 it would be much >> appreciated. If I could help with anything the win7 build let me know.... >> >> >> Regards, >> Istvan >> >> >> -- >> the sun shines for all >> >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Openvpn-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel >> > -- the sun shines for all 

I've patched the NSIS installer to omit the Windows version check. Try this installer: http://openvpn.net/beta/openvpn-2.1_rc15e-install.exe James István Szukács wrote: > Hi folks! > > > I am wondering if you have ever had success to run openvpn on windows 7. > The problem is the latest > installer(http://openvpn.net/release/openvpn-2.1_rc15-install.exe) says > this version is not supporting windows.... I try to install > http://openvpn.se/files/install_packages/openvpn-2.0.9-gui-1.0.3-install.exe, > works fine except the fact that the tap driver is not signed and because > of this it remains disabled and you cannot use openvpn(but runs well up > to the point when initialize the driver). > > If you could point me a doc how to make it run on win7 it would be much > appreciated. If I could help with anything the win7 build let me know.... > > > Regards, > Istvan > > > -- > the sun shines for all > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > > > ------------------------------------------------------------------------ > > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel