Work around Solaris getaddrinfo() returing ai_protocol=0

Create_socket() and sub-functions assume that the ai_protocol value
returned by getaddrinfo() is IPPROTO_UDP or IPPROTO_TCP.  On Solaris,
it is "0", because Solaris's socket() call will then "select the right
protocol" - but it breaks our code.  So remove ASSERT()s on ai_protocol,
and also accept properly set ai_socktype (SOCK_DGRAM/SOCK_STREAM) values
if ai_protocol is not set.

Signed-off-by: Gert Doering <gert@greenie.muc.de>
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20140407201711.GN16637@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8428
Fix typo in sample build script to use LDFLAGS

Came in as github pull request #15

Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-By: Arne Schwabe <arne@rfc2549.org>
Fix SOCKSv5 method selection

So, RFC 1928 doesn't say anything about the METHODS field in the Method
Selection message being ordered in terms of preference or anything, and
the server is free to pick any of the METHODS offered by the client.

Always sending a Method Selection message with NO AUTHENTICATION REQUIRED
and USERNAME/PASSWORD set is broken on two fronts:

 * If the OpenVPN client can't handle the server picking USERNAME/PASSWORD
   due to the credentials being missing, it shouldn't offer it to the
server.

 * If the OpenVPN client has credentials, then it should always attempt to
   authenticate.  This is a security product.  "You can misconfigure it and
   it will work" is not acceptable.  Setting a username/password when the
   SOCKS server doesn't require/support that as an option is the user not
   configuring it correctly, and should be treated as such.

Also verify that the SOCKS server returned the auth that was requested.

URL: https://github.com/OpenVPN/openvpn/pull/14
Fix trac #377, trac #148
Acked-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20140413130102.GR16637@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8488

Signed-off-by: Gert Doering <gert@greenie.muc.de>
IPv6 address/route delete fix for Win8

Use "store=active" for IPv6 address and route deletion - seems to be
required on Windows 8 and up, and not doing it will break OpenVPN
reconnection (old addresses are not properly deleted, thus address can
not be configured on connect).

Reported-by: Cedric <cedric+openvpn@bgtn.net>
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Cedric Tabary <cedric+openvpn@bgtn.net>
Message-Id: <20140413170648.GU16637@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8499