openvpn-devel Mailing List for OpenVPN (Page 2)

Hi, On Sat, Dec 15, 2012 at 11:23:52AM +0100, Tore Anderson wrote: > * Arne Schwabe > > > This patch contains a number of changes. I did not further spit this > > since some changes make only sense being changed together. [..] > > ACK, I tested several different fail-over scenarios and all worked fine. > Also all my pre-existing VPNs (maintained by GNOME NetworkManager) > worked just fine. Thanks for testing. Nevertheless, as this is a HUGE change (and needs patch 02/10...09/10 as prerequisites), I'd put this in 2.4 - so we can release 2.3 "real soon now", without an even longer test/beta/RC phase. (And yes, this is important work!) 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... 

* Arne Schwabe > This patch contains a number of changes. I did not further spit this > since some changes make only sense being changed together. > > Always use connection_list, simplifies the reconnection logic. > > Change meaning of --connect-retry-max and --connect-retry to be used > all connections. This now allows OpenVPN to quit after n unsuccessful > udp connection attempts > > Remove the tcp reconnection logic. Failing a TCP connection will now > cause a USR1 like a UDP connection. Also extend sig->source from bool > to int to specify signal source. This allows a finer grained > reconnection logic if necessary in the future. > > Dual-Stack support: if an address resolves to multiple records each > address is tried in sequential order. Then proceed to next connection > entry. Introduce the field current_remote to represent the current > connecting remote. Also change some fields to struct addrinfo* form > openvn_addr to store multiple addresses needed for the dual stack > support. > > Change meaning from udp and tcp to allow both IPv4 and IPv6. > Introducue new udp4 and tcp4 to force IPv4. ACK, I tested several different fail-over scenarios and all worked fine. Also all my pre-existing VPNs (maintained by GNOME NetworkManager) worked just fine. -- Tore Anderson 

Hi, On Fri, Dec 14, 2012 at 07:14:27PM +0100, Gert Doering wrote: > coverity scanned our source tree, found 201 false positives (they do not > like msg(M_ERR, ...), msg(M_WARN, ...) or msg(M_FATAL, ...)), and 3 > actual code confusions. Small correction: in the most recent run, they only found 201+3 things, of which only 2 are really relevant. Unfortunately, there's much more stuff - 24 issues tagged as "high!", some of them confusion about ASSERT() inside coverity, but some could need some reviewing... volunteers? 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, next one: mtcp.c, about line 470: unsigned int flags = MTP_NONE; if (TUN_OUT(c)) flags |= MTP_TUN_OUT; if (LINK_OUT(c)) flags |= MTP_LINK_OUT; switch (flags) { case MTP_TUN_OUT|MTP_LINK_OUT: case MTP_TUN_OUT: newaction = TA_TUN_WRITE; break; case MTP_LINK_OUT: newaction = TA_SOCKET_WRITE; break; case MTP_NONE: if (mi && socket_read_residual (c->c2.link_socket)) newaction = TA_SOCKET_READ_RESIDUAL; else multi_tcp_set_global_rw_flags (m, mi); break; default: { struct gc_arena gc = gc_new (); msg (M_FATAL, "MULTI TCP: multi_tcp_post bad state, mi=%s flags=%d", multi_instance_string (mi, false, &gc), flags); gc_free (&gc); break; } } coverity is complaining that the "default:" clause can never be reached, as all the possible values for "flags" are covered - and it's obviously right. It's not something critical, more a "code cleanup" thing. (The whole usage of switch/case here reeks a bit, given that I think the code would be simpler by directly setting "newaction" depending on "if (TUN_OUT(c))" etc., not bothering with "flags" in the first place) Cleanup in 2.4? 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, coverity scanned our source tree, found 201 false positives (they do not like msg(M_ERR, ...), msg(M_WARN, ...) or msg(M_FATAL, ...)), and 3 actual code confusions. I'm now going to post them here, to elicit comments on whether we want to fix 'em, just ignore 'em, or throw out all the source and go drink a beer. Issue #1: "logical dead code", in options.c, line 2277: else { notnull (options->cert_file, "certificate file (--cert) or PKCS#12 file (--pkcs12)"); #ifdef MANAGMENT_EXTERNAL_KEY if (!options->management_flags & MF_EXTERNAL_KEY) #endif notnull (options->priv_key_file, "private key file (--key) or PKCS#12 file (--pkcs12)"); } ... if I read this right, this is "operator precedence again", and there need to be brackets #ifdef MANAGMENT_EXTERNAL_KEY if (! (options->management_flags & MF_EXTERNAL_KEY) ) #endif ... Arne? 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... 

Also take a look here: <https://community.openvpn.net/openvpn/wiki/TrafficObfuscation> -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock > This isn't really the correct list for this. You should have posted to -users, instead. Check out obfsproxy: https://www.torproject.org/projects/obfsproxy.html.en > > Cheers > ----- > Eric F Crist > > > > On Dec 14, 2012, at 09:10:49, Ben <ben...@ya...> wrote: > >> To whom it may concern, >> >> I am running a VPN service and have customers located in China who cannot connect via OpenVPN due to recent changes in their firewall. We are looking for solutions to disguise the traffic so the connections won't be reset by the Chinese firewall. >> If you are interested in working with us as a consultant on this project, please reply to this email. >> >> Thanks >> Ben >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d_______________________________________________ >> Openvpn-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

This isn't really the correct list for this. You should have posted to -users, instead. Check out obfsproxy: https://www.torproject.org/projects/obfsproxy.html.en Cheers ----- Eric F Crist On Dec 14, 2012, at 09:10:49, Ben <ben...@ya...> wrote: > To whom it may concern, > > I am running a VPN service and have customers located in China who cannot connect via OpenVPN due to recent changes in their firewall. We are looking for solutions to disguise the traffic so the connections won't be reset by the Chinese firewall. > If you are interested in working with us as a consultant on this project, please reply to this email. > > Thanks > Ben > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d_______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

To whom it may concern, I am running a VPN service and have customers located in China who cannot connect via OpenVPN due to recent changes in their firewall. We are looking for solutions to disguise the traffic so the connections won't be reset by the Chinese firewall. If you are interested in working with us as a consultant on this project, please reply to this email. Thanks Ben

A very simple client for --management-external-key based on an on-disk keyfile. Useful for testing. Signed-off-by: Joachim Schipper <joa...@fo...> --- .gitignore | 1 + contrib/management-external-key-client/Makefile | 12 + contrib/management-external-key-client/README | 12 + .../management_external_key.c | 349 ++++++++++++++++++++ 4 files changed, 374 insertions(+) create mode 100644 contrib/management-external-key-client/Makefile create mode 100644 contrib/management-external-key-client/README create mode 100644 contrib/management-external-key-client/management_external_key.c diff --git a/.gitignore b/.gitignore index a04afff..a8fb8a6 100644 --- a/.gitignore +++ b/.gitignore @@ -48,6 +48,7 @@ version.sh msvc-env-local.bat config-msvc-local.h config-msvc-version.h +contrib/management-external-key-client/management_external_key doc/openvpn.8.html distro/rpm/openvpn.spec tests/t_client.sh diff --git a/contrib/management-external-key-client/Makefile b/contrib/management-external-key-client/Makefile new file mode 100644 index 0000000..bad83b0 --- /dev/null +++ b/contrib/management-external-key-client/Makefile @@ -0,0 +1,12 @@ +.PHONY: clean + +#POLARSSL_INCLUDES?=-I/usr/local/include +#POLARSSL_LDFLAGS?=-L/usr/local/lib -static +CFLAGS=-O2 -g -W -Wall -Wextra -Wdeclaration-after-statement ${POLARSSL_INCLUDES} +LDFLAGS=${POLARSSL_LDFLAGS} + +management_external_key: management_external_key.c +	${CC} ${CFLAGS} ${LDFLAGS} -o management_external_key management_external_key.c -lpolarssl + +clean: +	rm -f management_external_key diff --git a/contrib/management-external-key-client/README b/contrib/management-external-key-client/README new file mode 100644 index 0000000..78df077 --- /dev/null +++ b/contrib/management-external-key-client/README @@ -0,0 +1,12 @@ +When given the --management-external-key option, OpenVPN does not use a private +key to sign SSL handshakes, but instead requests a signature over the +management interface. + +This is a simple client for the management interface that uses a private key +stored in a PEM file to create the signatures. + +You'll need PolarSSL to compile this code. Run management_external_key for +instructions. + +Note that this is not production-ready code. It may, however, be useful for +testing purposes. diff --git a/contrib/management-external-key-client/management_external_key.c b/contrib/management-external-key-client/management_external_key.c new file mode 100644 index 0000000..f57a084 --- /dev/null +++ b/contrib/management-external-key-client/management_external_key.c @@ -0,0 +1,349 @@ +/* + * A simple client for openvpn --management-external-key. + * + * Copyright (C) 2012 Fox Crypto B.V. <op...@fo...> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program (see the file COPYING included with this + * distribution); if not, write to the Free Software Foundation, Inc., + * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +/* + * This code depends only on PolarSSL. + */ + +#include <sys/types.h> +#include <sys/socket.h> +#include <netdb.h> + +#include <assert.h> +#include <err.h> +#include <errno.h> +#include <getopt.h> +#include <limits.h> +#include <stdlib.h> +#include <stdio.h> +#include <string.h> +#include <unistd.h> + +#include <polarssl/base64.h> +#include <polarssl/error.h> +#include <polarssl/rsa.h> +#include <polarssl/x509.h> + +#define USAGE ("Usage: %s [-l] [-H host] port key\n" \ + "Client for openvpn --management-external-key\n" \ + "\n" \ + " -H host connect to host instead of localhost\n" \ + " -l request OpenVPN logs\n" \ + " port port of the OpenVPN management interface\n" \ + " key keyfile (in PEM format) to use\n") + +/* Management interface requesting a signature */ +#define RSA_PROMPT_PREFIX ">RSA_SIGN:" +#define RSA_RESP_PREFIX "rsa-sig\r\n" +#define RSA_RESP_SUFFIX "\r\nEND\r\n" + +#ifndef __GNUC__ +#define __attribute__(x) /* gcc only */ +#endif + +int main(int argc, char **argv); +/* Connect to management interface; returns socket or terminates program */ +static inline int open_sock(const char *host, const char *port); +/* Communicate with OpenVPN */ +static inline void management_client(int management_sock, const char *keyfile, + int request_logs) __attribute__((noreturn)); +/* + * Write some initial commands requesting logs etc. Returns 0 on success, or + * nonzero and sets errno. + */ +static inline int write_initial_commands(int management_sock, + int request_logs); +/* + * Handle a line of line_len characters; if partial, line is an incomplete last + * line. + * + * Returns a pointer to a statically allocated string containing a response, or + * NULL on error. + */ +static inline const char *handle_line(const char *line, size_t line_len, + int partial, rsa_context *rsa); +/* Called by handle_line() to handle RSA_SIGN requests */ +static inline const char *rsa_resp(const char *line, size_t line_len, + rsa_context *rsa); +static char handle_line_resp[1024]; +/* Repeated write: like write(), but continue writing on signals etc. */ +static inline ssize_t rwrite(int fd, const void *buf, size_t count); + +int +main(int argc, char **argv) +{ +	const char	*port, *host, *progname, *keyfile; +	int sock, opt, request_logs; + +	/* + * Parse arguments + */ +	progname = argv[0]; + +	request_logs = 0; +	host = "localhost"; + +	while ((opt = getopt(argc, argv, "lH:")) != -1) { +	switch (opt) { +	case 'l': +	request_logs = 1; +	break; +	case 'H': +	host = optarg; +	break; +	default: +	errx(127, USAGE, progname); +	} +	} +	argc -= optind; +	argv += optind; + +	if (argc != 2) +	errx(127, USAGE, progname); + +	port = argv[0]; +	keyfile = argv[1]; + +	/* XXX Management protocol password? */ + +	sock = open_sock(host, port); + +	management_client(sock, keyfile, request_logs); +	/* NOTREACHED */ +} + +static inline int +open_sock(const char *host, const char *port) +{ +	struct addrinfo	*addrs, hints; +	int rv, sock; + +	bzero(&hints, sizeof(hints)); +	hints.ai_family = AF_UNSPEC; +	hints.ai_socktype = SOCK_STREAM; +	if ((rv = getaddrinfo(host, port, NULL, &addrs)) != 0) +	errx(1, "Failed to resolve %s port %s: %s", host, port, + gai_strerror(rv)); + +	if ((sock = socket(AF_INET, SOCK_STREAM, 0)) == -1) +	err(1, "Failed to create socket"); + +	/* Connect to first address; good enough. */ +	if (connect(sock, addrs[0].ai_addr, addrs[0].ai_addrlen) != 0) +	err(1, "Failed to connect to %s port %s", host, port); + +	return sock; +} + +static inline void +management_client(int management_sock, const char *keyfile, int request_logs) +{ +	char buf[4096]; +	const char	*resp; +	size_t buf_len, i, eol; +	ssize_t bytes_read; +	int rv; +	rsa_context rsa; + +	if ((rv = x509parse_keyfile(&rsa, keyfile, NULL)) != 0) { +	error_strerror(rv, buf, sizeof(buf)); +	errx(1, "Failed to load %s: %s", keyfile, buf); +	} + +	if (write_initial_commands(management_sock, request_logs) != 0) +	err(1, "Failed to write initial commands\n"); + +	buf_len = 0; +	while (1) { +	/* + * Read from management interface + */ +	if (sizeof(buf) - buf_len == 0) +	err(1, "Line longer than buffer"); + +	bytes_read = read(management_sock, &buf[buf_len], + sizeof(buf) - buf_len); +	if (bytes_read == -1) { +	if (errno == EAGAIN || errno == EINTR) +	continue; +	err(1, "Failed to read()"); +	} + +	if (bytes_read == 0) { +	(void) handle_line(buf, buf_len, 1, &rsa); +	fprintf(stderr, "Management connection terminated.\n"); +	exit(0); +	} + +	buf_len += bytes_read; + +	i = 0; +	while (1) { +	/* + * Find whole line in buf[i..eol] and parse it. + */ +	for (eol = i; + eol < buf_len && buf[eol] != '\n'; + eol++); +	if (eol == buf_len) +	break; + +	assert(buf[eol] == '\n'); + +	if ((resp = handle_line(&buf[i], eol + 1 - i, 0, &rsa)) + == NULL) +	errx(1, "Failed to handle line"); +	errno = EINVAL; +	if (strlen(resp) > SSIZE_MAX || + rwrite(management_sock, resp, strlen(resp)) != + (ssize_t) strlen(resp)) +	err(1, "Failed to write response (\"%s\")", + resp); + +	i = eol + 1; +	} + +	/* Copy unparsed data to front (fast enough) */ +	bcopy(&buf[i], buf, buf_len - i); +	buf_len -= i; +	} +	/* NOTREACHED */ +} + +static inline int +write_initial_commands(int management_sock, int request_logs) +{ +	const char *initial_commands; + +	if (request_logs) +	initial_commands = "log on all\necho on all\nbytecount 10\n"; +	else +	initial_commands = "echo on all\nbytecount 10\n"; + +	if (rwrite(management_sock, initial_commands, + strlen(initial_commands)) != + (ssize_t) strlen(initial_commands)) +	return -1; + +	return 0; +} + +static inline const char * +handle_line(const char *line, size_t line_len, int partial_line, + rsa_context *rsa) +{ +	size_t i; + +	/* Print line */ +	for (i = 0; i < line_len; i++) +	putchar(line[i]); +	if (partial_line) +	putchar('\n'); + +	if (!partial_line && line_len >= sizeof(RSA_PROMPT_PREFIX) && + strncmp(line, RSA_PROMPT_PREFIX, sizeof(RSA_PROMPT_PREFIX) - 1) + == 0) +	return rsa_resp(line, line_len, rsa); +	else { +	/* Not an RSA_SIGN request, stop processing */ +	handle_line_resp[0] = '\0'; +	return handle_line_resp; +	} +} + +static inline const char * +rsa_resp(const char *line, size_t line_len, rsa_context *rsa) +{ +	unsigned char raw_data[1024], sig[1024]; +	size_t raw_data_len, out_len; + +	/* Base64-decode the relevant part of the line into raw_data */ +	assert(line_len >= sizeof(RSA_PROMPT_PREFIX) - 1); +	assert(strncmp(line, RSA_PROMPT_PREFIX, sizeof(RSA_PROMPT_PREFIX) - 1) + == 0); +	assert(line[line_len - 2] == '\r'); +	assert(line[line_len - 1] == '\n'); + +	raw_data_len = sizeof(raw_data); +	if (base64_decode(raw_data, &raw_data_len, + (const unsigned char *) + &line[sizeof(RSA_PROMPT_PREFIX) - 1], + line_len - (sizeof(RSA_PROMPT_PREFIX) - 1) - 2) != 0) +	goto err; + +	/* + * Sign raw_data. + * + * Note that we need no PRNG (f_prng = NULL) for PKCS1.5 encoding + */ +	if (sizeof(sig) < rsa->len || + rsa_pkcs1_sign(rsa, NULL, NULL, RSA_PRIVATE, SIG_RSA_RAW, + raw_data_len, raw_data, sig) != 0) +	goto err; + +	/* Base64-encode signature */ +	memcpy(handle_line_resp, RSA_RESP_PREFIX, sizeof(RSA_RESP_PREFIX) - 1); + +	out_len = sizeof(handle_line_resp) - (sizeof(RSA_RESP_PREFIX) - 1) - + (sizeof(RSA_RESP_SUFFIX) - 1) + 1; +	if (base64_encode((unsigned char *) + &handle_line_resp[sizeof(RSA_RESP_PREFIX) - 1], &out_len, + sig, rsa->len) != 0) +	goto err; +	out_len += sizeof(RSA_RESP_PREFIX) - 1; + +	memcpy(&handle_line_resp[out_len], RSA_RESP_SUFFIX, + sizeof(RSA_RESP_SUFFIX) - 1); + +	return handle_line_resp; + +err: +	return NULL; +} + +static inline ssize_t +rwrite(int fd, const void *vbuf, size_t count) +{ +	const char * const + buf = vbuf; +	size_t i; +	ssize_t bytes_written; +	int old_errno; + +	old_errno = errno; + +	i = 0; +	do { +	bytes_written = write(fd, &buf[i], count - i); +	if (bytes_written == -1) { +	if (errno == EINTR || errno == EAGAIN) +	continue; +	return bytes_written; +	} +	if (bytes_written == 0) +	goto done; + +	i += bytes_written; +	} while (i < count); + +done: +	errno = old_errno; +	return i; +} -- 1.7.9.5 

On 04/12/12 20:42, Arne Schwabe wrote: > Fix the "WARNING: 'proto' is used inconsistently, local='proto UDP', remote='proto UDPv6'." message. > > Note that the on wire strings are now always TCPv4 and UDPv4 to be compatible to pre2.3 > > Signed-off-by: Arne Schwabe <ar...@rf...> > --- > src/openvpn/socket.c | 22 ++++++++++++++++++---- > 1 file changed, 18 insertions(+), 4 deletions(-) Applied to master and beta/2.3 commit 38727e09df35245ba0cfe335e23e6b43c817ce58 (master) commit 34bc52d611deec62e7fe56622771b58921d52176 (beta/2.3) Author: Arne Schwabe <ar...@rf...> Date: Tue Dec 4 20:42:54 2012 +0100 Fix the proto is used inconsistently warning Signed-off-by: Arne Schwabe <ar...@rf...> Acked-by: Gert Doering <ge...@gr...> Message-Id: 135...@rf... URL: http://article.gmane.org/gmane.network.openvpn.devel/7175 Signed-off-by: David Sommerseth <da...@re...> -- kind regards, David Sommerseth 

On 02/12/12 22:11, Gert Doering wrote: > Rename process_ipv4_header() to process_ip_header() and PIPV4_MSSFIX > flag to PIP_MSSFIX, to make visible that it's no longer IPv4-only. > > Inside process_ip_header(), call out to mss_fixup_ipv6() if --mssfix > is active and IPv6 packet seen. > > Rename mss_fixup() to mss_fixup_ipv4(), implement mss_fixup_ipv6(). > > Signed-off-by: Gert Doering <ge...@gr...> > --- > src/openvpn/forward.c | 26 +++++++++++++-------- > src/openvpn/forward.h | 4 +- > src/openvpn/mss.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++- > src/openvpn/mss.h | 3 +- > src/openvpn/multi.c | 6 ++-- > src/openvpn/proto.c | 19 +++++++++++++-- > src/openvpn/proto.h | 3 +- > 7 files changed, 97 insertions(+), 21 deletions(-) Applied in master and beta/2.3 commit f0e8997a874a89b3fe1f82109c443232e8967b01 (master) commit 729c8464021ff7c41a7fbb03501465eca55909a3 (beta/2.3) Author: Gert Doering <ge...@gr...> Date: Sun Dec 2 22:11:12 2012 +0100 Implement --mssfix handling for IPv6 packets. Signed-off-by: Gert Doering <ge...@gr...> Acked-by: Arne Schwabe <ar...@rf...> Message-Id: 135...@gr... URL: http://article.gmane.org/gmane.network.openvpn.devel/7173 Signed-off-by: David Sommerseth <da...@re...> -- kind regards, David Sommerseth 

On 30/11/12 20:17, Arne Schwabe wrote: > --- > src/openvpn/socket.c | 2 +- > src/openvpn/socket.h | 5 ----- > 2 files changed, 1 insertion(+), 6 deletions(-) Applied to master and beta/2.3 commit 740137f6bb7b3565054c3a8e894ceca93f2ff0e4 (master) commit e99982218b5549894a94cc3c5f6209219d911ba1 (beta/2.3) Author: Arne Schwabe <ar...@rf...> Date: Fri Nov 30 20:17:47 2012 +0100 Remove dnsflags_to_socktype, it is not used anywhere Signed-off-by: Arne Schwabe <ar...@rf...> Acked-by: Gert Doering <ge...@gr...> Message-Id: 135...@rf... URL: http://article.gmane.org/gmane.network.openvpn.devel/7160 Signed-off-by: David Sommerseth <da...@re...> -- kind regards, David Sommerseth 

i recieved your mail

Hi, On Fri, Dec 07, 2012 at 12:32:10AM +0100, David TAILLANDIER wrote: > Windows 7 64bit OpenVPN 2.3_rc1 x86_64-w64-mingw32 > > If the client configuration file contains "ip-win32 netsh", OpenVPN > issue the following system command : > c:\windows\system32\netsh.exe interface ip set address Local Area > Connection 2 static 10.8.0.6 255.255.255.252 > > The command fails when the interface name contains spaces, so it must be > surrounded by double-quotes : "Local Area Connection 2" Have you actually seen this fail *in openvpn's log*, or have you tried the command show in the log in cmd.exe, and seen it fail there? The openvpn argv_printf/execve mechanics is... magic, so the interface name ends up in its own argv[] parameter towards netsh.exe, and quotes are not(!) needed - to the contrary, if you add quotes there, they become part of the interface name, and netsh will complain. Copy-pasting the command from the log to cmd.exe will not work, as cmd.exe would indeed need the quotes. I've just checked the code - while I never used "ip-win32 netsh", I did the netsh calls for IPv6 routing, and they do not quotes either - and work great for interface names with blanks in them (my test system uses "My Tap Adapter"). 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... 

 Windows 7 64bit OpenVPN 2.3_rc1 x86_64-w64-mingw32 If the client configuration file contains "ip-win32 netsh", OpenVPN issue the following system command : c:\windows\system32\netsh.exe interface ip set address Local Area Connection 2 static 10.8.0.6 255.255.255.252 The command fails when the interface name contains spaces, so it must be surrounded by double-quotes : "Local Area Connection 2" Workaround : rename the interface to something without spaces. 

Am 02.12.12 22:11, schrieb Gert Doering: > Rename process_ipv4_header() to process_ip_header() and PIPV4_MSSFIX > flag to PIP_MSSFIX, to make visible that it's no longer IPv4-only. > > Inside process_ip_header(), call out to mss_fixup_ipv6() if --mssfix > is active and IPv6 packet seen. > > Rename mss_fixup() to mss_fixup_ipv4(), implement mss_fixup_ipv6(). > > I have no setup with broken mss but I looked through the patch and I think is the right fix. Arne 

Hi, On Tue, Dec 04, 2012 at 08:42:54PM +0100, Arne Schwabe wrote: > Fix the "WARNING: 'proto' is used inconsistently, local='proto UDP', remote='proto UDPv6'." message. > > Note that the on wire strings are now always TCPv4 and UDPv4 to be compatible to pre2.3 The patch does what advertised, so I ACK it, and it should go into 2.3 OTOH, I want to put up the question whether sending "proto foo" in the occ option string is of any use *at all* - because if the --proto setting on both ends do not match, the connection won't even reach the point where it could recognize the fact that "oh, it's because incompatible --proto settings!". So to achieve a null-feature, we have quite a bit of code in "proto_remote()" in socket.c... "Just throwing it out" for 2.3 will cause warnings with pre-2.3 clients connecting to a (hypothetical) 2.3 server which does not send "proto", (or vice versa). What could do is to add some more code (sigh) to make OpenVPN 2.3 *ignore* proto mismatches and missing "proto foo" strings in OCC, and stop sending it in 2.4 altogether (so a 2.3<->2.4 combination would not warn, and if 2.2<->2.4 warns, put it into the FAQ). Maybe we should also add the same time stop warning about tun-ipv6 mismatches, because the case where there server has tun-ipv6 configured, and the client learns it due to "push tun-ipv6" will cause a useless warning today... 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... 

Fix the "WARNING: 'proto' is used inconsistently, local='proto UDP', remote='proto UDPv6'." message. Note that the on wire strings are now always TCPv4 and UDPv4 to be compatible to pre2.3 Signed-off-by: Arne Schwabe <ar...@rf...> --- src/openvpn/socket.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c index 505cf3b..2adfe8a 100644 --- a/src/openvpn/socket.c +++ b/src/openvpn/socket.c @@ -2560,6 +2560,10 @@ addr_family_name (int af) * * This is used for options compatibility * checking. + * + * IPv6 and IPv4 protocols are comptabile but OpenVPN + * has always sent UDPv4, TCPv4 over the wire. Keep these + * strings for backward compatbility */ int proto_remote (int proto, bool remote) @@ -2569,10 +2573,20 @@ proto_remote (int proto, bool remote) { switch (proto) { -	case PROTO_TCPv4_SERVER: return PROTO_TCPv4_CLIENT; -	case PROTO_TCPv4_CLIENT: return PROTO_TCPv4_SERVER; -	case PROTO_TCPv6_SERVER: return PROTO_TCPv6_CLIENT; -	case PROTO_TCPv6_CLIENT: return PROTO_TCPv6_SERVER; + case PROTO_TCPv4_SERVER: return PROTO_TCPv4_CLIENT; + case PROTO_TCPv4_CLIENT: return PROTO_TCPv4_SERVER; + case PROTO_TCPv6_SERVER: return PROTO_TCPv4_CLIENT; + case PROTO_TCPv6_CLIENT: return PROTO_TCPv4_SERVER; + case PROTO_UDPv6: return PROTO_UDPv4; + } + } + else + { + switch (proto) + { + case PROTO_TCPv6_SERVER: return PROTO_TCPv4_SERVER; + case PROTO_TCPv6_CLIENT: return PROTO_TCPv4_CLIENT; + case PROTO_UDPv6: return PROTO_UDPv4; } } return proto; -- 1.7.9.5 

Hi all, Samuli Seppänen wrote: > Hi, > > Here's the summary of the previous IRC meeting. > > > it's great to hear that the openvpn community is getting together again at FOSDEM 2013 ! One small practial remark , however: the train schedule between Amsterdam en Brussels is about to change; the train andj and I took last year no longer runs in 2013; instead you have to make a reservation for a new *faster* train , the Fyra. If somebody is interested in taking this route (Amsterdam/Schiphol -> Brussels) then contact me for details. And it's great to hear that an iOS client is forthcoming - people have been pestering me about that for ages! cheers, JJK > COMMUNITY MEETING > > Place: #openvpn-devel on irc.freenode.net > Date: Thursday 29th Nov 2012 > Time: 18:00 UTC > > Planned meeting topics for this meeting were on this page: > > <https://community.openvpn.net/openvpn/wiki/Topics-2012-11-29> > > Next meeting will be announced in advance, but will probably be on the same > weekday and at the same time. Your local meeting time is easy to check > from services such as > > <http://www.timeanddate.com/worldclock> > > or with > > $ date -u > > > SUMMARY > > cron2, dazo, ecrist, krzee, jamesyonan, mattock, novaflash, plaisthos, > raidz and swg0101 participated in this meeting. > > -- > > Started the meeting with short round of introductions. Some were not > formally introduced, but are included here. On the community side: > > - cron2: The OpenVPN IPv6+BSD+Solaris developer, buildbot farmer (Germany) > - dazo: master of plugins and git, does patch management, cleanups and > lots of other good work (Norway) > - d12fk: develops the new openvpn-gui for Windows (Germany) > - ecrist: takes care of forums, easy-rsa maintenance, #openvpn channel, > etc. (Unites States) > - krzee: takes care of the forums and IRC with ecrist; a mystical figure > (somewhere in the Caribbean) > - plaisthos: did the Android port; in charge of overhauling the socket.c > code (Germany) > > On the company side: > > - jamesyonan: Father of OpenVPN (United States/Colorado) > - mattock: Community manager, server administrator, does OSS releases, > testing, etc. (Finland) > - novaflash: Support technician (Netherlands) > - raidz: Support engineer, network engineer, and janitor (United > States/California) > - swg0101: Support and development (United States) > > A few non-participants were also mentioned: > > - andj: Added polarssl support to openvpn and is maintaining that part > (Netherlands) > - juanjo: The other IPv6 guy who we seldom see (from where?) > > --- > > Jamesyonan gave a short introduction of the new C++ codebase: > > - about 30K lines of C++ code > - an object-oriented rethinking of openvpn from the ground up > - design similar to original OpenVPN 3.0: > <http://community.openvpn.net/openvpn/wiki/RoadMap> > - is very modular in the sense that SSL/crypto libraries, transport > protocols, etc. can be modularized > - fairly prototypical/incomplete at this stage; only the client-side has > been implemented > - has been tested against Access Server (based on OpenVPN 2.1.x) and > OpenVPN 2.3* servers > - is 100% protocol compatible with 2.x branches > - has most 2.x's options > - is being used in the OpenVPN tech android client and the upcoming iOS > client > - may (at some point) supplant the 2.x branch, but that'll probably take > at least 1-2 years > > Some more technical tidbits: > > - core leverages on Boost Asio as it's async i/o layer > - C++ is really ready for prime time in system programming / networking > space > - C++ 2003 that's used seems to work very well on different compilers > - C++ static polymorphism (templates) is great for network programming > where we have small objects that have polymorphic properties, such as > IPv4 vs IPv6 addresses > > --- > > Discussed open sourcing the C++ codebase: > > According to jamesyonan, the plan is to release this probably under GPL > within the next couple months, but the company needs the ability to > relicense the C++ core because of (Apple) app store issues. It was > agreed that having OpenVPN on that platform is a must. To accomplish > this, relicensing the codebase is necessary. The consensus was that this > can be done in a way that's acceptable to all parties, without resorting > to the classic "copyright handover" scheme, which was not ok for everyone. > > The alternative would be to release the C++ codebase under a permissive > license (e.g. BSD), but that would allow companies such as Apple or > Microsoft to "steal" it. This was not seen as a good option, either. > > --- > > Discussed the role of OpenVPN 2.3 within the company: > > The company is planning to migrate the Access Server to OpenVPN 2.3*. > Before the meeting mattock had already managed to get the Access Server > running with OpenVPN-2.3-rc1 in a few hours, with only few minor > modifications. Tests run by raidz during the meeting revealed no further > issues. More details will follow later. > > --- > > Discussed having a joint company/community meeting in FOSDEM > (https://fosdem.org/2013). Most of the present developers seem to be > coming, but nobody has dared book the flights or hotel yet. > > --- > > Decided to arrange a second meeting next Thursday at the same time. The > meeting will focus on helping James move to 2.3 and Git (from 2.1.x and > SVN). > > --- > > Full chatlog as an attachment > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > TUNE You got it built. Now make it sing. Tune shows you how. > http://goparallel.sourceforge.net > ------------------------------------------------------------------------ > > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel 

Rename process_ipv4_header() to process_ip_header() and PIPV4_MSSFIX flag to PIP_MSSFIX, to make visible that it's no longer IPv4-only. Inside process_ip_header(), call out to mss_fixup_ipv6() if --mssfix is active and IPv6 packet seen. Rename mss_fixup() to mss_fixup_ipv4(), implement mss_fixup_ipv6(). Signed-off-by: Gert Doering <ge...@gr...> --- src/openvpn/forward.c | 26 +++++++++++++-------- src/openvpn/forward.h | 4 +- src/openvpn/mss.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++- src/openvpn/mss.h | 3 +- src/openvpn/multi.c | 6 ++-- src/openvpn/proto.c | 19 +++++++++++++-- src/openvpn/proto.h | 3 +- 7 files changed, 97 insertions(+), 21 deletions(-) diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c index 57c7846..024cd58 100644 --- a/src/openvpn/forward.c +++ b/src/openvpn/forward.c @@ -985,9 +985,9 @@ process_incoming_tun (struct context *c) { /* * The --passtos and --mssfix options require - * us to examine the IPv4 header. + * us to examine the IP header (IPv4 or IPv6). */ - process_ipv4_header (c, PIPV4_PASSTOS|PIPV4_MSSFIX|PIPV4_CLIENT_NAT, &c->c2.buf); + process_ip_header (c, PIPV4_PASSTOS|PIP_MSSFIX|PIPV4_CLIENT_NAT, &c->c2.buf); #ifdef PACKET_TRUNCATION_CHECK /* if (c->c2.buf.len > 1) --c->c2.buf.len; */ @@ -1009,10 +1009,10 @@ process_incoming_tun (struct context *c) } void -process_ipv4_header (struct context *c, unsigned int flags, struct buffer *buf) +process_ip_header (struct context *c, unsigned int flags, struct buffer *buf) { if (!c->options.ce.mssfix) - flags &= ~PIPV4_MSSFIX; + flags &= ~PIP_MSSFIX; #if PASSTOS_CAPABILITY if (!c->options.passtos) flags &= ~PIPV4_PASSTOS; @@ -1027,9 +1027,9 @@ process_ipv4_header (struct context *c, unsigned int flags, struct buffer *buf) * us to examine the IPv4 header. */ #if PASSTOS_CAPABILITY - if (flags & (PIPV4_PASSTOS|PIPV4_MSSFIX)) + if (flags & (PIPV4_PASSTOS|PIP_MSSFIX)) #else - if (flags & PIPV4_MSSFIX) + if (flags & PIP_MSSFIX) #endif	{ struct buffer ipbuf = *buf; @@ -1042,8 +1042,8 @@ process_ipv4_header (struct context *c, unsigned int flags, struct buffer *buf) #endif /* possibly alter the TCP MSS */ - if (flags & PIPV4_MSSFIX) -	mss_fixup (&ipbuf, MTU_TO_MSS (TUN_MTU_SIZE_DYNAMIC (&c->c2.frame))); + if (flags & PIP_MSSFIX) +	mss_fixup_ipv4 (&ipbuf, MTU_TO_MSS (TUN_MTU_SIZE_DYNAMIC (&c->c2.frame))); #ifdef ENABLE_CLIENT_NAT /* possibly do NAT on packet */ @@ -1061,6 +1061,12 @@ process_ipv4_header (struct context *c, unsigned int flags, struct buffer *buf) route_list_add_vpn_gateway (c->c1.route_list, c->c2.es, dhcp_router);	} } + else if (is_ipv6 (TUNNEL_TYPE (c->c1.tuntap), &ipbuf)) + { + /* possibly alter the TCP MSS */ + if (flags & PIP_MSSFIX) +	mss_fixup_ipv6 (&ipbuf, MTU_TO_MSS (TUN_MTU_SIZE_DYNAMIC (&c->c2.frame))); + }	} } } @@ -1217,9 +1223,9 @@ process_outgoing_tun (struct context *c) /* * The --mssfix option requires - * us to examine the IPv4 header. + * us to examine the IP header (IPv4 or IPv6). */ - process_ipv4_header (c, PIPV4_MSSFIX|PIPV4_EXTRACT_DHCP_ROUTER|PIPV4_CLIENT_NAT|PIPV4_OUTGOING, &c->c2.to_tun); + process_ip_header (c, PIP_MSSFIX|PIPV4_EXTRACT_DHCP_ROUTER|PIPV4_CLIENT_NAT|PIPV4_OUTGOING, &c->c2.to_tun); if (c->c2.to_tun.len <= MAX_RW_SIZE_TUN (&c->c2.frame)) { diff --git a/src/openvpn/forward.h b/src/openvpn/forward.h index 0f829bd..1830a00 100644 --- a/src/openvpn/forward.h +++ b/src/openvpn/forward.h @@ -228,12 +228,12 @@ void process_outgoing_tun (struct context *c); bool send_control_channel_string (struct context *c, const char *str, int msglevel); #define PIPV4_PASSTOS (1<<0) -#define PIPV4_MSSFIX (1<<1) +#define PIP_MSSFIX (1<<1) /* v4 and v6 */ #define PIPV4_OUTGOING (1<<2) #define PIPV4_EXTRACT_DHCP_ROUTER (1<<3) #define PIPV4_CLIENT_NAT (1<<4) -void process_ipv4_header (struct context *c, unsigned int flags, struct buffer *buf); +void process_ip_header (struct context *c, unsigned int flags, struct buffer *buf); #if P2MP void schedule_exit (struct context *c, const int n_seconds, const int signal); diff --git a/src/openvpn/mss.c b/src/openvpn/mss.c index 8981bad..64fd722 100644 --- a/src/openvpn/mss.c +++ b/src/openvpn/mss.c @@ -38,8 +38,13 @@ * problems which arise from protocol * encapsulation. */ + +/* + * IPv4 packet: find TCP header, check flags for "SYN" + * if yes, hand to mss_fixup_dowork() + */ void -mss_fixup (struct buffer *buf, int maxmss) +mss_fixup_ipv4 (struct buffer *buf, int maxmss) { const struct openvpn_iphdr *pip; int hlen; @@ -69,6 +74,56 @@ mss_fixup (struct buffer *buf, int maxmss) } } +/* + * IPv6 packet: find TCP header, check flags for "SYN" + * if yes, hand to mss_fixup_dowork() + * (IPv6 header structure is sufficiently different from IPv4...) + */ +void +mss_fixup_ipv6 (struct buffer *buf, int maxmss) +{ + const struct openvpn_ipv6hdr *pip6; + struct buffer newbuf; + + if (BLEN (buf) < (int) sizeof (struct openvpn_ipv6hdr)) + return; + + verify_align_4 (buf); + pip6 = (struct openvpn_ipv6hdr *) BPTR (buf); + + /* do we have the full IPv6 packet? + * "payload_len" does not include IPv6 header (+40 bytes) + */ + if (BLEN (buf) != (int) ntohs(pip6->payload_len)+40 ) + return; + + /* follow header chain until we reach final header, then check for TCP + * + * An IPv6 packet could, theoretically, have a chain of multiple headers + * before the final header (TCP, UDP, ...), so we'd need to walk that + * chain (see RFC 2460 and RFC 6564 for details). + * + * In practice, "most typically used" extention headers (AH, routing, + * fragment, mobility) are very unlikely to be seen inside an OpenVPN + * tun, so for now, we only handle the case of "single next header = TCP" + */ + if ( pip6->nexthdr != OPENVPN_IPPROTO_TCP ) + return; + + newbuf = *buf; + if ( buf_advance( &newbuf, 40 ) ) + { + struct openvpn_tcphdr *tc = (struct openvpn_tcphdr *) BPTR (&newbuf); + if (tc->flags & OPENVPN_TCPH_SYN_MASK) + mss_fixup_dowork (&newbuf, (uint16_t) maxmss-20); + } +} + +/* + * change TCP MSS option in SYN/SYN-ACK packets, if present + * this is generic for IPv4 and IPv6, as the TCP header is the same + */ + void mss_fixup_dowork (struct buffer *buf, uint16_t maxmss) { diff --git a/src/openvpn/mss.h b/src/openvpn/mss.h index 0b290c3..0d32943 100644 --- a/src/openvpn/mss.h +++ b/src/openvpn/mss.h @@ -28,7 +28,8 @@ #include "proto.h" #include "error.h" -void mss_fixup (struct buffer *buf, int maxmss); +void mss_fixup_ipv4 (struct buffer *buf, int maxmss); +void mss_fixup_ipv6 (struct buffer *buf, int maxmss); void mss_fixup_dowork (struct buffer *buf, uint16_t maxmss); #endif diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c index 9876b80..ab3f10c 100644 --- a/src/openvpn/multi.c +++ b/src/openvpn/multi.c @@ -2411,13 +2411,13 @@ multi_get_queue (struct mbuf_set *ms) if (mbuf_extract_item (ms, &item)) /* cleartext IP packet */ { - unsigned int pipv4_flags = PIPV4_PASSTOS; + unsigned int pip_flags = PIPV4_PASSTOS; set_prefix (item.instance); item.instance->context.c2.buf = item.buffer->buf; if (item.buffer->flags & MF_UNICAST) /* --mssfix doesn't make sense for broadcast or multicast */ -	pipv4_flags |= PIPV4_MSSFIX; - process_ipv4_header (&item.instance->context, pipv4_flags, &item.instance->context.c2.buf); +	pip_flags |= PIP_MSSFIX; + process_ip_header (&item.instance->context, pip_flags, &item.instance->context.c2.buf); encrypt_sign (&item.instance->context, true); mbuf_free_buf (item.buffer); diff --git a/src/openvpn/proto.c b/src/openvpn/proto.c index 2cf8314..b437f1a 100644 --- a/src/openvpn/proto.c +++ b/src/openvpn/proto.c @@ -36,11 +36,12 @@ #include "memdbg.h" /* - * If raw tunnel packet is IPv4, return true and increment + * If raw tunnel packet is IPv<X>, return true and increment * buffer offset to start of IP header. */ +static bool -is_ipv4 (int tunnel_type, struct buffer *buf) +is_ipv_X ( int tunnel_type, struct buffer *buf, int ip_ver ) { int offset; const struct openvpn_iphdr *ih; @@ -68,12 +69,24 @@ is_ipv4 (int tunnel_type, struct buffer *buf) ih = (const struct openvpn_iphdr *) (BPTR (buf) + offset); - if (OPENVPN_IPH_GET_VER (ih->version_len) == 4) + /* IP version is stored in the same bits for IPv4 or IPv6 header */ + if (OPENVPN_IPH_GET_VER (ih->version_len) == ip_ver) return buf_advance (buf, offset); else return false; } +bool +is_ipv4 (int tunnel_type, struct buffer *buf) +{ + return is_ipv_X( tunnel_type, buf, 4 ); +} +bool +is_ipv6 (int tunnel_type, struct buffer *buf) +{ + return is_ipv_X( tunnel_type, buf, 6 ); +} + #ifdef PACKET_TRUNCATION_CHECK void diff --git a/src/openvpn/proto.h b/src/openvpn/proto.h index 8cd4ede..f91e787 100644 --- a/src/openvpn/proto.h +++ b/src/openvpn/proto.h @@ -219,10 +219,11 @@ struct ip_tcp_udp_hdr { - sizeof(struct openvpn_tcphdr)) /* - * If raw tunnel packet is IPv4, return true and increment + * If raw tunnel packet is IPv4 or IPv6, return true and increment * buffer offset to start of IP header. */ bool is_ipv4 (int tunnel_type, struct buffer *buf); +bool is_ipv6 (int tunnel_type, struct buffer *buf); #ifdef PACKET_TRUNCATION_CHECK void ipv4_packet_size_verify (const uint8_t *data, -- 1.7.8.6 

Hi, in the next mail you'll find a patch to extend the existing --mssfix code to handle IPv6 packets as well. The actual mssfix implementation is only about half the change, but I took the liberty to rename process_ipv4_header() to process_ip_header(), and (after discussion on IRC) the PIPV4_MSSFIX flag to PIP_MSSFIX - to make it obvious that this is no longer "IPv4 only". The code has been tested on our corporate VPN server for 3 days now, and did what advertised - adjusted MSS; not breaking anything else. It does fix the connectivity problems one of my users had - sitting behind a router with broken PMTU handling *and* broken IPv4 fragment handling, which killed IPv6 SSH-Sessions (all crypted, not compressible) quite reliably. Testing this is a bit tricky - the t_client framework won't cover it (as it doesn't do TCP payload tests yet), so to actually *see* the change you either need to have a broken network wrt IPv4 PMTU/fragment handling before, or look at TCP SYN / SYN ACK packets with wireshark. Anyway, I believe it's ready for inclusion in RC2, and should most definitely be in 2.3-RELEASE (as we'll see more users with broken networks then). gert 

Hi, ACK, this can go into 2.3 - dead code removal. gert On Fri, Nov 30, 2012 at 08:17:47PM +0100, Arne Schwabe wrote: > --- > src/openvpn/socket.c | 2 +- > src/openvpn/socket.h | 5 ----- > 2 files changed, 1 insertion(+), 6 deletions(-) > > diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c > index 505cf3b..21a4b2b 100644 > --- a/src/openvpn/socket.c > +++ b/src/openvpn/socket.c > @@ -158,7 +158,7 @@ openvpn_getaddrinfo (unsigned int flags, > CLEAR(hints); > hints.ai_family = ai_family; > hints.ai_flags = AI_NUMERICHOST; > - hints.ai_socktype = dnsflags_to_socktype(flags); > + hints.ai_socktype = SOCK_STREAM; > > status = getaddrinfo(hostname, NULL, &hints, res); > > diff --git a/src/openvpn/socket.h b/src/openvpn/socket.h > index 44f1098..9cb01fa 100644 > --- a/src/openvpn/socket.h > +++ b/src/openvpn/socket.h > @@ -478,11 +478,6 @@ bool unix_socket_get_peer_uid_gid (const socket_descriptor_t sd, int *uid, int * > #define GETADDR_UPDATE_MANAGEMENT_STATE (1<<8) > #define GETADDR_RANDOMIZE (1<<9) > > -/* [ab]use flags bits to get socktype info downstream */ > -/* TODO(jjo): resolve tradeoff between hackiness|args-overhead */ > -#define GETADDR_DGRAM (1<<10) > -#define dnsflags_to_socktype(flags) ((flags & GETADDR_DGRAM) ? SOCK_DGRAM : SOCK_STREAM) > - > in_addr_t getaddr (unsigned int flags, > const char *hostname, > int resolve_retry_seconds, > -- > 1.7.9.5 > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > TUNE You got it built. Now make it sing. Tune shows you how. > http://goparallel.sourceforge.net > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > -- 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 Sat, Dec 01, 2012 at 06:32:56PM +0800, Marcia Martins wrote: > I can t open my vpn since 2 weeks ago and I can t acess VPN website site to contact sameone to help me. So this is why you go to a *developers* list? Ask whoever set up the VPN for you to fix 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... 

On 30.11.2012 20:17, Arne Schwabe wrote: > Change meaning from udp and tcp to allow both IPv4 and IPv6. Introducue new udp4 and tcp4 to force IPv4. The tcp4 and tcp6 should only temporary. I will later follow up with a patch which cleans up the protocol names and options. But I did not want this patch to get even bigger. Arne 

I can t open my vpn since 2 weeks ago and I can t acess VPN website site to contact sameone to help me.