fix occ proto strings

There are two things addressed here.

 1) regression introduced by commit f1bdbe5:
    Since TCP is not an alias for TCPv4 anymore the occ string
    contained TCP_CLIENT as proto, which is not understood by peers.
    Since only the "v4" version of the proto strings are understood
    the code was simplified.
 2) wrong occ proto string for TCP servers:
    Servers were also sending out the proto with client suffix. Fixed
    by passing in a boolean and returning the server version if true.

Also renamed the method to reflect better what it is used for.

Signed-off-by: Heiko Hund <heiko@openvpn.net>

Author: d12fk

openvpn/ssl/proto.hpp

@@ -803,7 +803,7 @@ namespace openvpn {
 	out << ",dev-type " << layer.dev_type();
 	out << ",link-mtu " << tun_mtu + link_mtu_adjust() + l2extra;
 	out << ",tun-mtu " << tun_mtu + l2extra;
-	out << ",proto " << protocol.str_client(true);
+	out << ",proto " << protocol.occ_str(server);
 
 	{
 	  const char *compstr = comp_ctx.options_string();

openvpn/transport/protocol.hpp

@@ -245,28 +245,24 @@ namespace openvpn {
 	}
     }
 
-    const char *str_client(const bool force_ipv4) const
+    // OpenVPN has always sent UDPv4, TCPv4_* over the wire.
+    // Keep all strings v4 for backward compatibility.
+    const char *occ_str(const bool server) const
     {
       switch (type_)
 	{
 	case UDP:
-	  return "UDP";
 	case UDPv4:
-	  return "UDPv4";
 	case UDPv6:
-	  return force_ipv4 ? "UDPv4" : "UDPv6";
+	  return "UDPv4";
 	case TCP:
-	  return "TCP_CLIENT";
 	case TCPv4:
-	  return "TCPv4_CLIENT";
 	case TCPv6:
-	  return force_ipv4 ? "TCPv4_CLIENT" : "TCPv6_CLIENT";
+	  return server ? "TCPv4_SERVER" : "TCPv4_CLIENT";
 	case TLS:
-	  return "TLS";
 	case TLSv4:
-	  return "TLSv4";
 	case TLSv6:
-	  return force_ipv4 ? "TLSv4" : "TLSv6";
+	  return "TLSv4";
 	default:
 	  return "UNDEF_PROTO";
 	}