Openvpn for Android 4.0 Changeset

PATCH In review Arne Schwabe 9 participants 47 messages May 9, 2012 – May 12, 2012 1 message not in the archive

lore

Share & tools

lore

Arne Schwabe

author

2012-05-09 21:24 UTC #0 lore raw

PATCH 1/1 Openvpn for Android 4.0 Changeset

Hello,

I have developed the port of openvpn for Android 4.0:
https://play.google.com/store/apps/details?id=de.blinkt.openvpn and
http://code.google.com/p/ics-openvpn/

The API of Android 4.0 requires that openvpn runs as completely unprivileged process. There all opening of tun, adding of routes, ifconfig etc. has to be done by another process.

This patch implements an API to allow pushing routes, dns, tun over the management interface (unix socket). Also on Android 4.0 the connection for the control has to be protect via an API call from the Java GUI.

Basically I am using the needok feature of the management protocol to push all relevant information to the GUI or to request information. I have not split the patch into multiple small patches because it should be first discussed if this is right architectural way.

Arne

From 8997c9b0029588a2e2f814f06c9ee1dfe1e4d3a4 Mon Sep 17 00:00:00 2001
From: Arne Schwabe <[email protected]...>
Date: Tue, 1 May 2012 14:04:22 +0200
Subject: [PATCH] rebase on head

---
 src/openvpn/error.c   |   86 +++++++++++++++++++++++++++++--------------------
 src/openvpn/event.c   |    4 ++
 src/openvpn/init.c    |   10 +++++-
 src/openvpn/manage.c  |   11 ++++--
 src/openvpn/options.c |    7 ++++
 src/openvpn/route.c   |    7 +++-
 src/openvpn/socket.c  |   25 ++++++++++++++
 src/openvpn/ssl.c     |    2 +
 src/openvpn/syshead.h |    2 +-
 src/openvpn/tun.c     |   29 +++++++++++++++-
 src/openvpn/tun.h     |   22 ++++++++++++-
 11 files changed, 160 insertions(+), 45 deletions(-)

src/openvpn/error.c +51 ~~-35~~

index d6ad639..6849794 100644
@@ -199,6 +199,11 @@ msg_fp(const unsigned int flags)
 
 int x_msg_line_num; /* GLOBAL */
 
+#include "android/log.h"
+ 
+
+
+
 void x_msg (const unsigned int flags, const char *format, ...)
 {
   struct gc_arena gc;

@@ -214,6 +219,7 @@ void x_msg (const unsigned int flags, const char *format, ...)
   const char *prefix_sep;
 
   void usage_small (void);
+    
 
 #ifndef HAVE_VARARG_MACROS
   /* the macro has checked this otherwise */

@@ -298,58 +304,65 @@ void x_msg (const unsigned int flags, const char *format, ...)
   if (!prefix)
     prefix_sep = prefix = "";
 
+
   /* virtual output capability used to copy output to management subsystem */
   if (!forked)
     {
       const struct virtual_output *vo = msg_get_virtual_output ();
+        
       if (vo)
 	{
 	  openvpn_snprintf (m2, ERR_BUF_SIZE, "%s%s%s",
 			    prefix,
 			    prefix_sep,
 			    m1);
-	  virtual_output_print (vo, flags, m2);
+        virtual_output_print (vo, flags, m2);
 	}
     }
 
-  if (!(flags & M_MSG_VIRT_OUT))
+  if (!(flags & M_MSG_VIRT_OUT) )
     {
-      if (use_syslog && !std_redir && !forked)
-	{
+        if (use_syslog && !std_redir && !forked)
+        {
 #if SYSLOG_CAPABILITY
-	  syslog (level, "%s%s%s",
-		  prefix,
-		  prefix_sep,
-		  m1);
+            syslog (level, "%s%s%s",
+                    prefix,
+                    prefix_sep,
+                    m1); 
+#endif
+        }
+        else // No Syslog
+        {
+            FILE *fp = msg_fp(flags);
+            const bool show_usec = check_debug_level (DEBUG_LEVEL_USEC_TIME);
+            
+            if ((flags & M_NOPREFIX) || suppress_timestamps)
+            {
+                fprintf (fp, "%s%s%s%s",
+                         prefix,
+                         prefix_sep,
+                         m1,
+                         (flags&M_NOLF) ? "" : "\n");
+            }
+            else
+            {
+                fprintf (fp, "%s %s%s%s%s",
+                         time_string (0, 0, show_usec, &gc),
+                         prefix,
+                         prefix_sep,
+                         m1,
+                         (flags&M_NOLF) ? "" : "\n"); 
+            }
+            fflush(fp);
+            ++x_msg_line_num;
+        }
+#ifdef TARGET_ANDROID
+        android_openvpn_log(prefix,prefix_sep,m1);;
 #endif
-	}
-      else
-	{
-	  FILE *fp = msg_fp(flags);
-	  const bool show_usec = check_debug_level (DEBUG_LEVEL_USEC_TIME);
-
-	  if ((flags & M_NOPREFIX) || suppress_timestamps)
-	    {
-	      fprintf (fp, "%s%s%s%s",
-		       prefix,
-		       prefix_sep,
-		       m1,
-		       (flags&M_NOLF) ? "" : "\n");
-	    }
-	  else
-	    {
-	      fprintf (fp, "%s %s%s%s%s",
-		       time_string (0, 0, show_usec, &gc),
-		       prefix,
-		       prefix_sep,
-		       m1,
-		       (flags&M_NOLF) ? "" : "\n");
-	    }
-	  fflush(fp);
-	  ++x_msg_line_num;
-	}
     }
 
+
+    
   if (flags & M_FATAL)
     msg (M_INFO, "Exiting due to fatal error");

@@ -701,7 +714,10 @@ openvpn_exit (const int status)
       if (status == OPENVPN_EXIT_STATUS_GOOD)
 	perf_output_results ();
     }
-
+#ifdef TARGET_ANDROID
+    android_openvpn_exit(status);
+#endif
+    
   exit (status);
 }

src/openvpn/event.c +4 -0

index 2a13e1c..0463d98 100644
@@ -753,6 +753,10 @@ po_wait (struct event_set *es, const struct timeval *tv, struct event_set_return
 	      ++out;
 	      ++j;
 	    }
+      else if(pfdp->revents==0x0020) 
+        {
+            openvpn_exit (OPENVPN_EXIT_STATUS_ERROR);
+        }
 	  else if (pfdp->revents)
 	    {
 	      msg (D_EVENT_ERRORS, "Error: poll: unknown revents=0x%04x", (unsigned int)pfdp->revents);

src/openvpn/init.c +9 -1

index 61ced5d..cc94b81 100644
@@ -1477,6 +1477,13 @@ do_open_tun (struct context *c)
 						&gc);
 	  do_ifconfig (c->c1.tuntap, guess, TUN_MTU_SIZE (&c->c2.frame), c->c2.es);
 	}
+        
+        /* possibly add routes */
+        if(ifconfig_order() == ROUTE_BEFORE_TUN) {
+            if (!c->options.route_delay_defined)
+                do_route (&c->options, c->c1.route_list, c->c1.route_ipv6_list,
+                          c->c1.tuntap, c->plugins, c->c2.es);
+        }
 
       /* open the tun device */
       open_tun (c->options.dev, c->options.dev_type, c->options.dev_node,

@@ -1509,10 +1516,11 @@ do_open_tun (struct context *c)
 		   c->c2.es);
 
       /* possibly add routes */
+        if(ifconfig_order() == ROUTE_AFTER_TUN) {
       if (!c->options.route_delay_defined)
 	do_route (&c->options, c->c1.route_list, c->c1.route_ipv6_list,
 		  c->c1.tuntap, c->plugins, c->c2.es);
-
+        }
       /*
        * Did tun/tap driver give us an MTU?
        */

src/openvpn/manage.c +7 -4

index 1dddd41..1a6c086 100644
@@ -1479,13 +1479,14 @@ man_new_connection_post (struct management *man, const char *description)
 #if UNIX_SOCK_SUPPORT
   if (man->settings.flags & MF_UNIX_SOCK)
     {
-      msg (D_MANAGEMENT, "MANAGEMENT: %s %s",
-	   description,
-	   sockaddr_unix_name (&man->settings.local_unix, "NULL"));
+        msg (D_MANAGEMENT, "MANAGEMENT(unix): %s %s",
+             description,
+             sockaddr_unix_name (&man->settings.local_unix, "NULL"));
+ 
     }
   else
 #endif
-    msg (D_MANAGEMENT, "MANAGEMENT: %s %s",
+    msg (D_MANAGEMENT, "MANAGEMENT(tcp): %s %s",
 	 description,
 	 print_sockaddr (&man->settings.local, &gc));

@@ -2690,6 +2691,7 @@ management_socket_set (struct management *man,
 void
 management_io (struct management *man)
 {
+    msg(D_MANAGEMENT,"M I/O State %d in",man->connection.state);
   switch (man->connection.state)
     {
     case MS_LISTEN:

@@ -2706,6 +2708,7 @@ management_io (struct management *man)
     default:
       ASSERT (0);
     }
+    msg(D_MANAGEMENT,"M I/O State %d out",man->connection.state);
 }
 
 #endif

src/openvpn/options.c +7 -0

index 7769625..bd6382f 100644
@@ -564,6 +564,7 @@ static const char usage_message[] =
 #if OPENSSL_VERSION_NUMBER >= 0x00907000L
   " and CRLs).\n"
 #else /* OPENSSL_VERSION_NUMBER >= 0x00907000L */
+#error WTF!
   ").\n"
   "                  WARNING: no support of CRL available with this version.\n"
 #endif /* OPENSSL_VERSION_NUMBER >= 0x00907000L */

@@ -1140,7 +1141,9 @@ show_tuntap_options (const struct tuntap_options *o)
 }
 
 #endif
+#endif
 
+#if defined(WIN32) || defined(TARGET_ANDROID) 
 static void
 dhcp_option_address_parse (const char *name, const char *parm, in_addr_t *array, int *len, int msglevel)
 {

@@ -6064,6 +6067,8 @@ add_option (struct options *options,
       to->ip_win32_type = index;
       to->ip_win32_defined = true; 
     }
+#endif
+#if defined(WIN32) || defined(TARGET_ANDROID)
   else if (streq (p[0], "dhcp-option") && p[1])
     {
       struct tuntap_options *o = &options->tuntap_options;

@@ -6115,6 +6120,8 @@ add_option (struct options *options,
 	}
       o->dhcp_options = true;
     }
+#endif
+#ifdef WIN32
   else if (streq (p[0], "show-adapters"))
     {
       VERIFY_PERMISSION (OPT_P_GENERAL);

src/openvpn/route.c +6 -1

index 7c25c77..6c3ad90 100644
@@ -1344,6 +1344,11 @@ add_route (struct route *r,
   argv_msg (D_ROUTE, &argv);
   status = openvpn_execve_check (&argv, es, 0, "ERROR: Linux route add command failed");
 
+#elif defined (TARGET_ANDROID)
+#include "jniglue.h"
+
+    addRouteInformation(network, netmask, gateway);
+
 #elif defined (WIN32)
   {
     DWORD ai = TUN_ADAPTER_INDEX_INVALID;

@@ -2371,7 +2376,7 @@ show_routes (int msglev)
   gc_free (&gc);
 }
 
-#elif defined(TARGET_LINUX)
+#elif defined(TARGET_LINUX) || defined(TARGET_ANDROID)
 
 void
 get_default_gateway (struct route_gateway_info *rgi)

src/openvpn/socket.c +25 -0

index 6b1f8d2..364b97e 100644
@@ -41,6 +41,11 @@
 
 #include "memdbg.h"
 
+#ifdef TARGET_ANDROID
+#include "jniglue.h"
+#endif 
+
+
 const int proto_overhead[] = { /* indexed by PROTO_x */
   0,
   IPv4_UDP_HEADER_SIZE, /* IPv4 */

@@ -858,6 +863,11 @@ create_socket_tcp (void)
   }
 #endif
 
+#ifdef TARGET_ANDROID
+    /* Protects the socket from being routed via VPN */
+    android_protect_socket(sd);
+#endif
+
   return sd;
 }

@@ -885,6 +895,12 @@ create_socket_udp (const unsigned int flags)
 #endif
     }
 #endif
+
+#ifdef TARGET_ANDROID
+    /* Protects the socket from being routed via VPN */
+    android_protect_socket(sd);
+#endif
+
   return sd;
 }

@@ -904,6 +920,11 @@ create_socket_udp6 (const unsigned int flags)
 	msg(M_SOCKERR, "UDP: failed setsockopt for IPV6_RECVPKTINFO");
     }
 #endif
+#ifdef TARGET_ANDROID
+    /* Protects the socket from being routed via VPN */
+    android_protect_socket(sd);
+#endif
+
   return sd;
 }

@@ -922,6 +943,10 @@ create_socket_tcp6 (void)
 		    (void *) &on, sizeof (on)) < 0)
       msg (M_SOCKERR, "TCP: Cannot setsockopt SO_REUSEADDR on TCP6 socket");
   }
+#ifdef TARGET_ANDROID
+    /* Protects the socket from being routed via VPN */
+    android_protect_socket(sd);
+#endif
 
   return sd;
 }

src/openvpn/ssl.c +2 -0

index 19512c0..9f570b9 100644
@@ -1650,6 +1650,8 @@ push_peer_info(struct buffer *buf, struct tls_session *session)
       buf_printf (&out, "IV_PLAT=netbsd\n");
 #elif defined(TARGET_FREEBSD)
       buf_printf (&out, "IV_PLAT=freebsd\n");
+#elif defined(TARGET_ANDROID)
+      buf_printf(&out, "IV_PLAT=android\n");
 #elif defined(WIN32)
       buf_printf (&out, "IV_PLAT=win\n");
 #endif

src/openvpn/syshead.h +1 -1

index 3337764..8ce40f7 100644
@@ -212,7 +212,7 @@
 #include <net/if_tap.h>
 #endif
 
-#ifdef TARGET_LINUX
+#if defined(TARGET_LINUX) || defined (TARGET_ANDROID)
 
 #if defined(HAVE_NETINET_IF_ETHER_H)
 #include <netinet/if_ether.h>

src/openvpn/tun.c +27 -2

index 633150f..7aa8627 100644
@@ -49,6 +49,11 @@
 
 #include "memdbg.h"
 
+#ifdef TARGET_ANDROID
+#include "jniglue.h"
+#endif
+
+
 #ifdef WIN32
 
 /* #define SIMULATE_DHCP_FAILED */       /* simulate bad DHCP negotiation */

@@ -768,6 +773,8 @@ do_ifconfig (struct tuntap *tt,
       tt->did_ifconfig = true;
 
 #endif /*ENABLE_IPROUTE*/
+#elif defined(TARGET_ANDROID)
+       addInterfaceInformation(tun_mtu,ifconfig_local, ifconfig_remote_netmask);
 #elif defined(TARGET_SOLARIS)
 
       /* Solaris 2.6 (and 7?) cannot set all parameters in one go...

@@ -1365,7 +1372,24 @@ close_tun_generic (struct tuntap *tt)
 
 #endif
 
-#if defined(TARGET_LINUX)
+#if defined(TARGET_LINUX) || defined(TARGET_ANDROID)
+
+#if defined (TARGET_ANDROID)
+void
+open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt)
+{
+    struct gc_arena gc = gc_new ();
+    int i;
+    for (i = 0; i < tt->options.dns_len; ++i) {
+        android_set_dns(print_in_addr_t(tt->options.dns[i], 0, &gc));
+    }
+
+    if(tt->options.domain)
+        android_set_domain(tt->options.domain);
+    tt->fd = android_open_tun();
+}
+
+#else
 
 #ifdef HAVE_LINUX_IF_TUN_H	/* New driver support */

@@ -1411,7 +1435,7 @@ open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tu
       if (!tt->ipv6)
 	ifr.ifr_flags = IFF_NO_PI;
 
-#if defined(IFF_ONE_QUEUE) && defined(SIOCSIFTXQLEN)
+#if defined(IFF_ONE_QUEUE) && defined(SIOCSIFTXQLEN) && !defined(TARGET_ANDROID)
       ifr.ifr_flags |= IFF_ONE_QUEUE;
 #endif

@@ -1501,6 +1525,7 @@ open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tu
 }
 
 #endif /* HAVE_LINUX_IF_TUN_H */
+#endif /* TARGET_ANDROID */
 
 #ifdef ENABLE_FEATURE_TUN_PERSIST

src/openvpn/tun.h +21 -1

index 9bd990f..095e77e 100644
@@ -38,7 +38,7 @@
 #include "proto.h"
 #include "misc.h"
 
-#ifdef WIN32
+#if defined(WIN32) || defined(TARGET_ANDROID)
 
 #define TUN_ADAPTER_INDEX_INVALID ((DWORD)-1)

@@ -76,6 +76,7 @@ struct tuntap_options {
 
   int netbios_node_type;     /* NBT 1,2,4,8 (46) */
 
+
 #define N_DHCP_ADDR 4        /* Max # of addresses allowed for
 			        DNS, WINS, etc. */

@@ -292,11 +293,30 @@ ifconfig_order(void)
   return IFCONFIG_AFTER_TUN_OPEN;
 #elif defined(WIN32)
   return IFCONFIG_BEFORE_TUN_OPEN;
+#elif defined(TARGET_ANDROID)
+  return IFCONFIG_BEFORE_TUN_OPEN;
 #else
   return IFCONFIG_DEFAULT;
 #endif
 }
 
+#define ROUTE_BEFORE_TUN 0
+#define ROUTE_AFTER_TUN 1
+#define ROUTE_ORDER_DEFAULT ROUTE_AFTER_TUN
+
+static inline int
+route_order(void)
+{
+#if defined(TARGET_ANDROID)
+    return ROUTE_BEFORE_TUN;
+#else
+    return ROUTE_ORDER_DEFAULT;
+#endif
+}
+
+
+
+
 #ifdef WIN32
 
 #define TUN_PASS_BUFFER

Signature · 12 lines

1.7.8.3

From 5a1b05c9410cbbabcee271201d781f425cfd77e5 Mon Sep 17 00:00:00 2001
From: Arne Schwabe <[email protected]...>
Date: Sat, 5 May 2012 12:40:55 +0200
Subject: [PATCH] tmp-dir for all revert debug output

---
 src/openvpn/manage.c  |   11 ++++-------
 src/openvpn/options.c |   11 +++++------
 src/openvpn/tun.c     |    5 ++++-
 3 files changed, 13 insertions(+), 14 deletions(-)

src/openvpn/manage.c +4 -7

index 1a6c086..1dddd41 100644
@@ -1479,14 +1479,13 @@ man_new_connection_post (struct management *man, const char *description)
 #if UNIX_SOCK_SUPPORT
   if (man->settings.flags & MF_UNIX_SOCK)
     {
-        msg (D_MANAGEMENT, "MANAGEMENT(unix): %s %s",
-             description,
-             sockaddr_unix_name (&man->settings.local_unix, "NULL"));
- 
+      msg (D_MANAGEMENT, "MANAGEMENT: %s %s",
+	   description,
+	   sockaddr_unix_name (&man->settings.local_unix, "NULL"));
     }
   else
 #endif
-    msg (D_MANAGEMENT, "MANAGEMENT(tcp): %s %s",
+    msg (D_MANAGEMENT, "MANAGEMENT: %s %s",
 	 description,
 	 print_sockaddr (&man->settings.local, &gc));

@@ -2691,7 +2690,6 @@ management_socket_set (struct management *man,
 void
 management_io (struct management *man)
 {
-    msg(D_MANAGEMENT,"M I/O State %d in",man->connection.state);
   switch (man->connection.state)
     {
     case MS_LISTEN:

@@ -2708,7 +2706,6 @@ management_io (struct management *man)
     default:
       ASSERT (0);
     }
-    msg(D_MANAGEMENT,"M I/O State %d out",man->connection.state);
 }
 
 #endif

src/openvpn/options.c +5 -6

index bd6382f..a2d0f6e 100644
@@ -564,7 +564,6 @@ static const char usage_message[] =
 #if OPENSSL_VERSION_NUMBER >= 0x00907000L
   " and CRLs).\n"
 #else /* OPENSSL_VERSION_NUMBER >= 0x00907000L */
-#error WTF!
   ").\n"
   "                  WARNING: no support of CRL available with this version.\n"
 #endif /* OPENSSL_VERSION_NUMBER >= 0x00907000L */

@@ -5472,6 +5471,11 @@ add_option (struct options *options,
       options->occ = false;
     }
 #endif
+  else if (streq (p[0], "tmp-dir") && p[1])
+  {
+      VERIFY_PERMISSION (OPT_P_GENERAL);
+      options->tmp_dir = p[1];
+  }
 #if P2MP
 #if P2MP_SERVER
   else if (streq (p[0], "server") && p[1] && p[2])

@@ -5753,11 +5757,6 @@ add_option (struct options *options,
       warn_multiple_script (options->learn_address_script, "learn-address");
       options->learn_address_script = p[1];
     }
-  else if (streq (p[0], "tmp-dir") && p[1])
-    {
-      VERIFY_PERMISSION (OPT_P_GENERAL);
-      options->tmp_dir = p[1];
-    }
   else if (streq (p[0], "client-config-dir") && p[1])
     {
       VERIFY_PERMISSION (OPT_P_GENERAL);

src/openvpn/tun.c +4 -1

index 7aa8627..238d9fb 100644
@@ -1386,7 +1386,10 @@ open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tu
 
     if(tt->options.domain)
         android_set_domain(tt->options.domain);
-    tt->fd = android_open_tun();
+
+    if((tt->fd = android_open_tun())< 0){
+        msg (M_ERR, "ERROR: Cannot open TUN");
+    }
 }
 
 #else

Signature · 16 lines

1.7.8.3

From 82ef19f76f827026033aefea295e64015ae7c36d Mon Sep 17 00:00:00 2001
From: Arne Schwabe <[email protected]...>
Date: Wed, 9 May 2012 19:27:32 +0200
Subject: [PATCH] working openvpn

---
 src/openvpn/error.c  |    5 +--
 src/openvpn/manage.c |  103 ++++++++++++++++++++++++++++++++++++++++++++++++-
 src/openvpn/manage.h |    7 +++-
 src/openvpn/misc.c   |    2 +-
 src/openvpn/route.c  |   13 +++++-
 src/openvpn/socket.c |   40 +++++++-------------
 src/openvpn/tun.c    |   39 +++++++++++++-----
 7 files changed, 160 insertions(+), 49 deletions(-)

src/openvpn/error.c +1 -4

index 6849794..83a9eb4 100644
@@ -714,10 +714,7 @@ openvpn_exit (const int status)
       if (status == OPENVPN_EXIT_STATUS_GOOD)
 	perf_output_results ();
     }
-#ifdef TARGET_ANDROID
-    android_openvpn_exit(status);
-#endif
-    
+
   exit (status);
 }

src/openvpn/manage.c +100 -3

146 lines not on this page · raw message

src/openvpn/manage.h +6 -1

index f681f8d..c7ffb42 100644
@@ -208,7 +208,7 @@ struct man_persist {
   bool hold_release;
 
   const char *special_state_msg;
-
+    
   counter_type bytes_in;
   counter_type bytes_out;
 };

@@ -303,6 +303,11 @@ struct man_connection {
 #ifdef MANAGMENT_EXTERNAL_KEY
   struct buffer_list *rsa_sig;
 #endif
+#ifdef TARGET_ANDROID
+    int fdtosend;
+    int lastfdreceived;
+#endif
+    
 };
 
 struct management

src/openvpn/misc.c +1 -1

index 2ded9bf..3658c34 100644
@@ -1176,7 +1176,7 @@ get_user_pass_cr (struct user_pass *up,
 	      if (ac)
 		{
 		  char *response = (char *) gc_malloc (USER_PASS_LEN, false, &gc);
-		  struct buffer packed_resp;
+		  struct buffer packed_resp; 
 
 		  buf_set_write (&packed_resp, (uint8_t*)up->password, USER_PASS_LEN);
 		  msg (M_INFO|M_NOPREFIX, "CHALLENGE: %s", ac->challenge_text);

src/openvpn/route.c +10 -3

index 6c3ad90..99674e2 100644
@@ -1345,9 +1345,15 @@ add_route (struct route *r,
   status = openvpn_execve_check (&argv, es, 0, "ERROR: Linux route add command failed");
 
 #elif defined (TARGET_ANDROID)
-#include "jniglue.h"
 
-    addRouteInformation(network, netmask, gateway);
+    struct user_pass up;    
+    struct buffer out = alloc_buf_gc (64, &gc);
+
+    buf_printf (&out, "%s %s", network, netmask);
+
+    strcpy(up.username, buf_bptr(&out));
+    management_query_user_pass(management, &up , "ROUTE", GET_USER_PASS_NEED_OK,(void*) 0);
+
 
 #elif defined (WIN32)
   {

@@ -1852,7 +1858,8 @@ delete_route (struct route *r,
 
   argv_msg (D_ROUTE, &argv);
   openvpn_execve_check (&argv, es, 0, "ERROR: OpenBSD/NetBSD route delete command failed");
-
+#elif defined(TARGET_ANDROID)
+  msg (M_NONFATAL, "Sorry, deleting routes on Android is not possible. The VpnService API allows routes to be set on connect only.");
 #else
   msg (M_FATAL, "Sorry, but I don't know how to do 'route' commands on this operating system.  Try putting your routes in a --route-up script");
 #endif

src/openvpn/socket.c +14 ~~-26~~

index 364b97e..7101097 100644
@@ -38,13 +38,10 @@
 #include "ps.h"
 #include "manage.h"
 #include "misc.h"
+#include "manage.h"
 
-#include "memdbg.h"
-
-#ifdef TARGET_ANDROID
-#include "jniglue.h"
-#endif 
 
+#include "memdbg.h"
 
 const int proto_overhead[] = { /* indexed by PROTO_x */
   0,

@@ -378,7 +375,7 @@ getaddr6 (unsigned int flags,
 
       /*
        * Resolve hostname
-       */
+       */ 
       while (true)
 	{
 	  /* try hostname lookup */

@@ -863,12 +860,7 @@ create_socket_tcp (void)
   }
 #endif
 
-#ifdef TARGET_ANDROID
-    /* Protects the socket from being routed via VPN */
-    android_protect_socket(sd);
-#endif
-
-  return sd;
+    return sd;
 }
 
 static socket_descriptor_t

@@ -896,11 +888,6 @@ create_socket_udp (const unsigned int flags)
     }
 #endif
 
-#ifdef TARGET_ANDROID
-    /* Protects the socket from being routed via VPN */
-    android_protect_socket(sd);
-#endif
-
   return sd;
 }

@@ -920,10 +907,6 @@ create_socket_udp6 (const unsigned int flags)
 	msg(M_SOCKERR, "UDP: failed setsockopt for IPV6_RECVPKTINFO");
     }
 #endif
-#ifdef TARGET_ANDROID
-    /* Protects the socket from being routed via VPN */
-    android_protect_socket(sd);
-#endif
 
   return sd;
 }

@@ -943,10 +926,6 @@ create_socket_tcp6 (void)
 		    (void *) &on, sizeof (on)) < 0)
       msg (M_SOCKERR, "TCP: Cannot setsockopt SO_REUSEADDR on TCP6 socket");
   }
-#ifdef TARGET_ANDROID
-    /* Protects the socket from being routed via VPN */
-    android_protect_socket(sd);
-#endif
 
   return sd;
 }

@@ -984,6 +963,15 @@ create_socket (struct link_socket *sock)
     {
       ASSERT (0);
     }
+#ifdef TARGET_ANDROID
+    struct user_pass up;
+    strcpy(up.username ,__func__);
+    management->connection.fdtosend = sock->sd;
+    management_query_user_pass(management, &up , "PROTECTFD", GET_USER_PASS_NEED_OK,(void*) 0);
+
+
+#endif
+    
 }
 
 /*

@@ -1341,7 +1329,7 @@ socket_connect (socket_descriptor_t *sd,
 }
 
 /* For stream protocols, allocate a buffer to build up packet.
-   Called after frame has been finalized. */
+    Called after frame has been finalized. */
 
 static void
 socket_frame_init (const struct frame *frame, struct link_socket *sock)

src/openvpn/tun.c +28 ~~-11~~

index 238d9fb..158cd61 100644
@@ -46,12 +46,8 @@
 #include "manage.h"
 #include "route.h"
 #include "win32.h"
-
 #include "memdbg.h"
-
-#ifdef TARGET_ANDROID
-#include "jniglue.h"
-#endif
+#include <string.h>
 
 
 #ifdef WIN32

@@ -774,7 +770,16 @@ do_ifconfig (struct tuntap *tt,
 
 #endif /*ENABLE_IPROUTE*/
 #elif defined(TARGET_ANDROID)
-       addInterfaceInformation(tun_mtu,ifconfig_local, ifconfig_remote_netmask);
+        
+        struct user_pass up;    
+        struct buffer out = alloc_buf_gc (64, &gc);
+        
+        buf_printf (&out, "%s %s %d", ifconfig_local, ifconfig_remote_netmask, tun_mtu);
+        
+        strcpy(up.username, buf_bptr(&out));
+        management_query_user_pass(management, &up , "IFCONFIG", GET_USER_PASS_NEED_OK,(void*) 0);
+        
+        
 #elif defined(TARGET_SOLARIS)
 
       /* Solaris 2.6 (and 7?) cannot set all parameters in one go...

@@ -1378,18 +1383,30 @@ close_tun_generic (struct tuntap *tt)
 void
 open_tun (const char *dev, const char *dev_type, const char *dev_node, struct tuntap *tt)
 {
-    struct gc_arena gc = gc_new ();
     int i;
+    struct user_pass up;
+    struct gc_arena gc = gc_new ();
+    
     for (i = 0; i < tt->options.dns_len; ++i) {
-        android_set_dns(print_in_addr_t(tt->options.dns[i], 0, &gc));
+        strcpy(up.username, print_in_addr_t(tt->options.dns[i], 0, &gc));
+        management_query_user_pass(management, &up , "DNSSERVER", GET_USER_PASS_NEED_OK,(void*) 0);
     }
 
-    if(tt->options.domain)
-        android_set_domain(tt->options.domain);
+    if(tt->options.domain) {
+        strcpy(up.username , tt->options.domain);
+        management_query_user_pass(management, &up , "DNSDOMAIN", GET_USER_PASS_NEED_OK,(void*) 0);
+    }
+    
+    strcpy(up.username , dev);
+    management_query_user_pass(management, &up , "OPENTUN", GET_USER_PASS_NEED_OK,(void*) 0);
 
-    if((tt->fd = android_open_tun())< 0){
+    tt->fd = management->connection.lastfdreceived;
+    management->connection.lastfdreceived=-1;
+    
+    if( (tt->fd < 0) || ! (strcmp("ok",up.password)==0)) {
         msg (M_ERR, "ERROR: Cannot open TUN");
     }
+    gc_free (&gc);
 }
 
 #else

Signature · 12 lines

1.7.8.3

From 870b93ef683f68f85e4aad63f3e9ca9325f4bf8f Mon Sep 17 00:00:00 2001
From: Arne Schwabe <[email protected]...>
Date: Wed, 9 May 2012 23:09:43 +0200
Subject: [PATCH] openvpn android working api through unix socket

---
 src/openvpn/error.c  |   15 +--------------
 src/openvpn/init.c   |    2 +-
 src/openvpn/socket.c |    1 -
 3 files changed, 2 insertions(+), 16 deletions(-)

src/openvpn/error.c +1 ~~-14~~

index 83a9eb4..e2e24b1 100644
@@ -199,11 +199,6 @@ msg_fp(const unsigned int flags)
 
 int x_msg_line_num; /* GLOBAL */
 
-#include "android/log.h"
- 
-
-
-
 void x_msg (const unsigned int flags, const char *format, ...)
 {
   struct gc_arena gc;

@@ -219,7 +214,6 @@ void x_msg (const unsigned int flags, const char *format, ...)
   const char *prefix_sep;
 
   void usage_small (void);
-    
 
 #ifndef HAVE_VARARG_MACROS
   /* the macro has checked this otherwise */

@@ -304,12 +298,10 @@ void x_msg (const unsigned int flags, const char *format, ...)
   if (!prefix)
     prefix_sep = prefix = "";
 
-
   /* virtual output capability used to copy output to management subsystem */
   if (!forked)
     {
       const struct virtual_output *vo = msg_get_virtual_output ();
-        
       if (vo)
 	{
 	  openvpn_snprintf (m2, ERR_BUF_SIZE, "%s%s%s",

@@ -331,7 +323,7 @@ void x_msg (const unsigned int flags, const char *format, ...)
                     m1); 
 #endif
         }
-        else // No Syslog
+      else
         {
             FILE *fp = msg_fp(flags);
             const bool show_usec = check_debug_level (DEBUG_LEVEL_USEC_TIME);

@@ -356,13 +348,8 @@ void x_msg (const unsigned int flags, const char *format, ...)
             fflush(fp);
             ++x_msg_line_num;
         }
-#ifdef TARGET_ANDROID
-        android_openvpn_log(prefix,prefix_sep,m1);;
-#endif
     }
 
-
-    
   if (flags & M_FATAL)
     msg (M_INFO, "Exiting due to fatal error");

src/openvpn/init.c +1 -1

index cc94b81..17e4f4a 100644
@@ -2475,7 +2475,7 @@ do_option_warnings (struct context *c)
 {
   const struct options *o = &c->options;
 
-#if 1 /* JYFIXME -- port warning */
+#if 0 /* JYFIXME -- port warning */
   if (!o->ce.port_option_used && (o->ce.local_port == OPENVPN_PORT && o->ce.remote_port == OPENVPN_PORT))
     msg (M_WARN, "IMPORTANT: OpenVPN's default port number is now %d, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.",
 	 OPENVPN_PORT);

src/openvpn/socket.c +0 -1

index 7101097..b92c282 100644
@@ -859,7 +859,6 @@ create_socket_tcp (void)
       msg (M_SOCKERR, "TCP: Cannot setsockopt SO_LINGER on TCP socket");
   }
 #endif
-
     return sd;
 }

Signature · 1 line

1.7.8.3

Alon Bar-Lev

2012-05-09 22:09 UTC #1 lore raw

Hmmm... the fact that you are not using git, and create separate branch for the changes makes it very difficult to peak.

I see a mix of changes and a separate build system which I am not sure is needed. You build openvpn as a shared library, it is OK, I had this on my list, but why not use the current build to do so?

I suggest you clone the repository at github, create a branch and order your changes.

Regards,
Alon Bar-Lev.

Quoted 33 lines · Arne Schwabe

Hello,
I have developed the port of openvpn for Android 4.0:
https://play.google.com/store/apps/details?id=de.blinkt.openvpn and
http://code.google.com/p/ics-openvpn/
The API of Android 4.0 requires that openvpn runs as completely unprivileged process. There all opening of tun, adding of routes, ifconfig etc. has to be done by another process.
This patch implements an API to allow pushing routes, dns, tun over the management interface (unix socket). Also on Android 4.0 the connection for the control has to be protect via an API call from the Java GUI.
Basically I am using the needok feature of the management protocol to push all relevant information to the GUI or to request information. I have not split the patch into multiple small patches because it should be first discussed if this is right architectural way.
Arne
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Openvpn-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Arne Schwabe

author

2012-05-09 22:36 UTC #2 lore raw

Am 10.05.12 00:09, schrieb Alon Bar-Lev:

Quoted 2 lines

Hmmm... the fact that you are not using git, and create separate branch for the changes makes it very difficult to peak.

Sorry. I am new to git and the distributed version systems. I hope this patch is better. I also pushed the changes to
https://github.com/schwabe/openvpn/.

Quoted 3 lines

I see a mix of changes and a separate build system which I am not sure is needed. You build openvpn as a shared library, it is OK, I had this on my list, but why not use the current build to do so?

Building with the android build system was easier for me. Openvpn is only build as a shared library but still used as a standalone executable. This has to do with the apk packaging and the android market. Transforming openvpn into a real library turned out to be more difficult because there multiple points in the code where openvpn more or less calls exit to clean up.

But before discussing the best way of building openvpn on android I would rather like to get input on the other changes.

Quoted 2 lines

I suggest you clone the repository at github, create a branch and order your changes.

that would mean to revert all changes, making the changes in small steps and commiting each step? (I am still trying to learn how to work with git)

Arne

From b9a52d5ee919818a2e2ee525e0800e8e1f06b45f Mon Sep 17 00:00:00 2001
From: Arne Schwabe <[email protected]>
Date: Wed, 9 May 2012 23:18:31 +0200
Subject: [PATCH 1/1] Openvpn for Android ICS API

---
 src/openvpn/error.c   |    2 +-
 src/openvpn/event.c   |    4 ++
 src/openvpn/init.c    |   12 +++++-
 src/openvpn/manage.c  |   99 ++++++++++++++++++++++++++++++++++++++++++++++++-
 src/openvpn/manage.h  |    5 ++
 src/openvpn/options.c |   16 +++++--
 src/openvpn/route.c   |   16 +++++++-
 src/openvpn/socket.c  |   14 ++++++-
 src/openvpn/ssl.c     |    2 +
 src/openvpn/syshead.h |    2 +-
 src/openvpn/tun.c     |   51 ++++++++++++++++++++++++-
 src/openvpn/tun.h     |   22 ++++++++++-
 12 files changed, 228 insertions(+), 17 deletions(-)

src/openvpn/error.c +1 -1

index d6ad639..e2e24b1 100644
@@ -312,7 +312,7 @@ void x_msg (const unsigned int flags, const char *format, ...)
 	}
     }
 
-  if (!(flags & M_MSG_VIRT_OUT))
+  if (!(flags & M_MSG_VIRT_OUT) )
     {
       if (use_syslog && !std_redir && !forked)
 	{

src/openvpn/event.c +4 -0

index 2a13e1c..0463d98 100644
@@ -753,6 +753,10 @@ po_wait (struct event_set *es, const struct timeval *tv, struct event_set_return
 	      ++out;
 	      ++j;
 	    }
+      else if(pfdp->revents==0x0020) 
+        {
+            openvpn_exit (OPENVPN_EXIT_STATUS_ERROR);
+        }
 	  else if (pfdp->revents)
 	    {
 	      msg (D_EVENT_ERRORS, "Error: poll: unknown revents=0x%04x", (unsigned int)pfdp->revents);

src/openvpn/init.c +10 -2

index 61ced5d..17e4f4a 100644
@@ -1478,6 +1478,13 @@ do_open_tun (struct context *c)
 	  do_ifconfig (c->c1.tuntap, guess, TUN_MTU_SIZE (&c->c2.frame), c->c2.es);
 	}
 
+        /* possibly add routes */
+        if(ifconfig_order() == ROUTE_BEFORE_TUN) {
+            if (!c->options.route_delay_defined)
+                do_route (&c->options, c->c1.route_list, c->c1.route_ipv6_list,
+                          c->c1.tuntap, c->plugins, c->c2.es);
+        }
+
       /* open the tun device */
       open_tun (c->options.dev, c->options.dev_type, c->options.dev_node,
 		c->c1.tuntap);

@@ -1509,10 +1516,11 @@ do_open_tun (struct context *c)
 		   c->c2.es);
 
       /* possibly add routes */
+        if(ifconfig_order() == ROUTE_AFTER_TUN) {
       if (!c->options.route_delay_defined)
 	do_route (&c->options, c->c1.route_list, c->c1.route_ipv6_list,
 		  c->c1.tuntap, c->plugins, c->c2.es);
-
+        }
       /*
        * Did tun/tap driver give us an MTU?
        */

@@ -2467,7 +2475,7 @@ do_option_warnings (struct context *c)
 {
   const struct options *o = &c->options;
 
-#if 1 /* JYFIXME -- port warning */
+#if 0 /* JYFIXME -- port warning */
   if (!o->ce.port_option_used && (o->ce.local_port == OPENVPN_PORT && o->ce.remote_port == OPENVPN_PORT))
     msg (M_WARN, "IMPORTANT: OpenVPN's default port number is now %d, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.",
 	 OPENVPN_PORT);

src/openvpn/manage.c +98 -1

143 lines not on this page · raw message

src/openvpn/manage.h +5 -0

index f681f8d..c7ffb42 100644
@@ -303,6 +303,11 @@ struct man_connection {
 #ifdef MANAGMENT_EXTERNAL_KEY
   struct buffer_list *rsa_sig;
 #endif
+#ifdef TARGET_ANDROID
+    int fdtosend;
+    int lastfdreceived;
+#endif
+    
 };
 
 struct management

src/openvpn/options.c +11 -5

index 7769625..a2d0f6e 100644
@@ -1140,7 +1140,9 @@ show_tuntap_options (const struct tuntap_options *o)
 }
 
 #endif
+#endif
 
+#if defined(WIN32) || defined(TARGET_ANDROID) 
 static void
 dhcp_option_address_parse (const char *name, const char *parm, in_addr_t *array, int *len, int msglevel)
 {

@@ -5469,6 +5471,11 @@ add_option (struct options *options,
       options->occ = false;
     }
 #endif
+  else if (streq (p[0], "tmp-dir") && p[1])
+  {
+      VERIFY_PERMISSION (OPT_P_GENERAL);
+      options->tmp_dir = p[1];
+  }
 #if P2MP
 #if P2MP_SERVER
   else if (streq (p[0], "server") && p[1] && p[2])

@@ -5750,11 +5757,6 @@ add_option (struct options *options,
       warn_multiple_script (options->learn_address_script, "learn-address");
       options->learn_address_script = p[1];
     }
-  else if (streq (p[0], "tmp-dir") && p[1])
-    {
-      VERIFY_PERMISSION (OPT_P_GENERAL);
-      options->tmp_dir = p[1];
-    }
   else if (streq (p[0], "client-config-dir") && p[1])
     {
       VERIFY_PERMISSION (OPT_P_GENERAL);

@@ -6064,6 +6066,8 @@ add_option (struct options *options,
       to->ip_win32_type = index;
       to->ip_win32_defined = true; 
     }
+#endif
+#if defined(WIN32) || defined(TARGET_ANDROID)
   else if (streq (p[0], "dhcp-option") && p[1])
     {
       struct tuntap_options *o = &options->tuntap_options;

@@ -6115,6 +6119,8 @@ add_option (struct options *options,
 	}
       o->dhcp_options = true;
     }
+#endif
+#ifdef WIN32
   else if (streq (p[0], "show-adapters"))
     {
       VERIFY_PERMISSION (OPT_P_GENERAL);

src/openvpn/route.c +14 -2

index 7c25c77..99674e2 100644
@@ -1344,6 +1344,17 @@ add_route (struct route *r,
   argv_msg (D_ROUTE, &argv);
   status = openvpn_execve_check (&argv, es, 0, "ERROR: Linux route add command failed");
 
+#elif defined (TARGET_ANDROID)
+
+    struct user_pass up;    
+    struct buffer out = alloc_buf_gc (64, &gc);
+
+    buf_printf (&out, "%s %s", network, netmask);
+
+    strcpy(up.username, buf_bptr(&out));
+    management_query_user_pass(management, &up , "ROUTE", GET_USER_PASS_NEED_OK,(void*) 0);
+
+
 #elif defined (WIN32)
   {
     DWORD ai = TUN_ADAPTER_INDEX_INVALID;

@@ -1847,7 +1858,8 @@ delete_route (struct route *r,
 
   argv_msg (D_ROUTE, &argv);
   openvpn_execve_check (&argv, es, 0, "ERROR: OpenBSD/NetBSD route delete command failed");
-
+#elif defined(TARGET_ANDROID)
+  msg (M_NONFATAL, "Sorry, deleting routes on Android is not possible. The VpnService API allows routes to be set on connect only.");
 #else
   msg (M_FATAL, "Sorry, but I don't know how to do 'route' commands on this operating system.  Try putting your routes in a --route-up script");
 #endif

@@ -2371,7 +2383,7 @@ show_routes (int msglev)
   gc_free (&gc);
 }
 
-#elif defined(TARGET_LINUX)
+#elif defined(TARGET_LINUX) || defined(TARGET_ANDROID)
 
 void
 get_default_gateway (struct route_gateway_info *rgi)

src/openvpn/socket.c +13 -1

index 6b1f8d2..b92c282 100644
@@ -38,6 +38,8 @@
 #include "ps.h"
 #include "manage.h"
 #include "misc.h"
+#include "manage.h"
+
 
 #include "memdbg.h"

@@ -857,7 +859,6 @@ create_socket_tcp (void)
       msg (M_SOCKERR, "TCP: Cannot setsockopt SO_LINGER on TCP socket");
   }
 #endif
-
   return sd;
 }

@@ -885,6 +886,7 @@ create_socket_udp (const unsigned int flags)
 #endif
     }
 #endif
+
   return sd;
 }

@@ -904,6 +906,7 @@ create_socket_udp6 (const unsigned int flags)
 	msg(M_SOCKERR, "UDP: failed setsockopt for IPV6_RECVPKTINFO");
     }
 #endif
+
   return sd;
 }

@@ -959,6 +962,15 @@ create_socket (struct link_socket *sock)
     {
       ASSERT (0);
     }
+#ifdef TARGET_ANDROID
+    struct user_pass up;
+    strcpy(up.username ,__func__);
+    management->connection.fdtosend = sock->sd;
+    management_query_user_pass(management, &up , "PROTECTFD", GET_USER_PASS_NEED_OK,(void*) 0);
+
+
+#endif
+    
 }
 
 /*

src/openvpn/ssl.c +2 -0

index 19512c0..9f570b9 100644
@@ -1650,6 +1650,8 @@ push_peer_info(struct buffer *buf, struct tls_session *session)
       buf_printf (&out, "IV_PLAT=netbsd\n");
 #elif defined(TARGET_FREEBSD)
       buf_printf (&out, "IV_PLAT=freebsd\n");
+#elif defined(TARGET_ANDROID)
+      buf_printf(&out, "IV_PLAT=android\n");
 #elif defined(WIN32)
       buf_printf (&out, "IV_PLAT=win\n");
 #endif

src/openvpn/syshead.h +1 -1

index 3337764..8ce40f7 100644
@@ -212,7 +212,7 @@
 #include <net/if_tap.h>
 #endif
 
-#ifdef TARGET_LINUX
+#if defined(TARGET_LINUX) || defined (TARGET_ANDROID)
 
 #if defined(HAVE_NETINET_IF_ETHER_H)
 #include <netinet/if_ether.h>

src/openvpn/tun.c +48 -3

82 lines not on this page · raw message

src/openvpn/tun.h +21 -1

index 9bd990f..095e77e 100644
@@ -38,7 +38,7 @@
 #include "proto.h"
 #include "misc.h"
 
-#ifdef WIN32
+#if defined(WIN32) || defined(TARGET_ANDROID)
 
 #define TUN_ADAPTER_INDEX_INVALID ((DWORD)-1)

@@ -76,6 +76,7 @@ struct tuntap_options {
 
   int netbios_node_type;     /* NBT 1,2,4,8 (46) */
 
+
 #define N_DHCP_ADDR 4        /* Max # of addresses allowed for
 			        DNS, WINS, etc. */

@@ -292,11 +293,30 @@ ifconfig_order(void)
   return IFCONFIG_AFTER_TUN_OPEN;
 #elif defined(WIN32)
   return IFCONFIG_BEFORE_TUN_OPEN;
+#elif defined(TARGET_ANDROID)
+  return IFCONFIG_BEFORE_TUN_OPEN;
 #else
   return IFCONFIG_DEFAULT;
 #endif
 }
 
+#define ROUTE_BEFORE_TUN 0
+#define ROUTE_AFTER_TUN 1
+#define ROUTE_ORDER_DEFAULT ROUTE_AFTER_TUN
+
+static inline int
+route_order(void)
+{
+#if defined(TARGET_ANDROID)
+    return ROUTE_BEFORE_TUN;
+#else
+    return ROUTE_ORDER_DEFAULT;
+#endif
+}
+
+
+
+
 #ifdef WIN32
 
 #define TUN_PASS_BUFFER

Signature · 1 line

1.7.5.4

Alon Bar-Lev

2012-05-09 22:50 UTC #3 lore raw

Quoted 6 lines · Arne Schwabe

Am 10.05.12 00:09, schrieb Alon Bar-Lev:
Quoted 2 lines
Hmmm... the fact that you are not using git, and create separate branch for the changes makes it very difficult to peak.
Sorry. I am new to git and the distributed version systems. I hope this patch is better. I also pushed the changes to
https://github.com/schwabe/openvpn/.

This is good but you need to rebase master... something like:

$ git checkout android
$ git rebase master

Quoted 9 lines

Quoted 3 lines
I see a mix of changes and a separate build system which I am not sure is needed. You build openvpn as a shared library, it is OK, I had this on my list, but why not use the current build to do so?
Building with the android build system was easier for me. Openvpn is only build as a shared library but still used as a standalone executable. This has to do with the apk packaging and the android market. Transforming openvpn into a real library turned out to be more difficult because there multiple points in the code where openvpn more or less calls exit to clean up.

Yes, this is well known, someday we will have to deal with this. Maybe sooner... Anyway, I can provide you with a branch that produce both executable and library.

Quoted 2 lines

But before discussing the best way of building openvpn on android I would rather like to get input on the other changes.

Go over the patch, remove all changes that result from plain indentation changes, or addition of new lines.

I also don't understand why the log should be special, and you cannot just use the management interface as-is.

Please also try to avoid mixing windows code and posix code.

Regarding the tun open, I don't understand why you cannot do this before you execute the openvpn, as persisted tun device.

Bottom line, I don't think there is real need to define a new target for android, almost every change you introduce has nothing to do with platform specific.

You should explain clearly why each change is needed... and probably split it into own commit.

Quoted 8 lines

Quoted 3 lines
I suggest you clone the repository at github, create a branch and order your changes.
that would mean to revert all changes, making the changes in small steps and commiting each step? (I am still trying to learn how to work with git)

Right.

If I understand correctly, if I leave out the library creation, and the in-line tap creation, and the management log changes, there are only minor changes, which should be explained one-by-one.

Regards,
Alon.

Arne Schwabe

author

2012-05-09 23:09 UTC #4 lore raw

Am 10.05.12 00:50, schrieb Alon Bar-Lev:

Quoted 10 lines · Arne Schwabe

Quoted 6 lines
Am 10.05.12 00:09, schrieb Alon Bar-Lev:
Quoted 2 lines
Hmmm... the fact that you are not using git, and create separate branch for the changes makes it very difficult to peak.
Sorry. I am new to git and the distributed version systems. I hope this patch is better. I also pushed the changes to
https://github.com/schwabe/openvpn/.
This is good but you need to rebase master... something like:
$ git checkout android
$ git rebase master

I will try tommorow.

Quoted 9 lines

Quoted 6 lines
Building with the android build system was easier for me. Openvpn is only build as a shared library but still used as a standalone executable. This has to do with the apk packaging and the android market. Transforming openvpn into a real library turned out to be more difficult because there multiple points in the code where openvpn more or less calls exit to clean up.
Yes, this is well known, someday we will have to deal with this. Maybe sooner... Anyway, I can provide you with a branch that produce both executable and library.

That is really interesting for me and the android port.

Quoted 5 lines

Quoted 2 lines
But before discussing the best way of building openvpn on android I would rather like to get input on the other changes.
Go over the patch, remove all changes that result from plain indentation changes, or addition of new lines.

Quoted 7 lines

I also don't understand why the log should be special, and you cannot just use the management interface as-is.
Please also try to avoid mixing windows code and posix code.
Regarding the tun open, I don't understand why you cannot do this before you execute the openvpn, as persisted tun device.

Opening tun works as follows:

- Provide information like ip, routes, dns and domain to Android
- call establish() and get a tun with the specified parameters back.

Quoted 4 lines

Bottom line, I don't think there is real need to define a new target for android, almost every change you introduce has nothing to do with platform specific.

Yes. But I needed some target for android. The target mainly deal with how interface configuring/routes/ifconfig etc. is handled. With the Android 4.0 most of these things have to be done differently.

Quoted 5 lines

You should explain clearly why each change is needed... and probably split it into own commit.
Quoted 3 lines
Quoted 2 lines
I suggest you clone the repository at github, create a branch and order your changes.

Quoted 8 lines

Quoted 3 lines
that would mean to revert all changes, making the changes in small steps and commiting each step? (I am still trying to learn how to work with git)
Right.
If I understand correctly, if I leave out the library creation, and the in-line tap creation, and the management log changes, there are only minor changes, which should be explained one-by-one.

Yes. The in line tun creation and the managment interface fd passing are the important changes of the patchset.

Arne

Alon Bar-Lev

2012-05-09 23:12 UTC #5 lore raw

Quoted 56 lines · Arne Schwabe

Am 10.05.12 00:50, schrieb Alon Bar-Lev:
Quoted 10 lines · Arne Schwabe
Quoted 6 lines
Am 10.05.12 00:09, schrieb Alon Bar-Lev:
Quoted 2 lines
Hmmm... the fact that you are not using git, and create separate branch for the changes makes it very difficult to peak.
Sorry. I am new to git and the distributed version systems. I hope this patch is better. I also pushed the changes to
https://github.com/schwabe/openvpn/.
This is good but you need to rebase master... something like:
$ git checkout android
$ git rebase master
I will try tommorow.
Quoted 9 lines
Quoted 6 lines
Building with the android build system was easier for me. Openvpn is only build as a shared library but still used as a standalone executable. This has to do with the apk packaging and the android market. Transforming openvpn into a real library turned out to be more difficult because there multiple points in the code where openvpn more or less calls exit to clean up.
Yes, this is well known, someday we will have to deal with this. Maybe sooner... Anyway, I can provide you with a branch that produce both executable and library.
That is really interesting for me and the android port.
Quoted 5 lines
Quoted 2 lines
But before discussing the best way of building openvpn on android I would rather like to get input on the other changes.
Go over the patch, remove all changes that result from plain indentation changes, or addition of new lines.
Quoted 7 lines
I also don't understand why the log should be special, and you cannot just use the management interface as-is.
Please also try to avoid mixing windows code and posix code.
Regarding the tun open, I don't understand why you cannot do this before you execute the openvpn, as persisted tun device.
Opening tun works as follows:
- Provide information like ip, routes, dns and domain to Android
- call establish() and get a tun with the specified parameters back.
Quoted 4 lines
Bottom line, I don't think there is real need to define a new target for android, almost every change you introduce has nothing to do with platform specific.
Yes. But I needed some target for android. The target mainly deal with how interface configuring/routes/ifconfig etc. is handled. With the Android 4.0 most of these things have to be done differently.
Quoted 10 lines
You should explain clearly why each change is needed... and probably split it into own commit.
Quoted 6 lines
Quoted 2 lines
I suggest you clone the repository at github, create a branch and order your changes.
that would mean to revert all changes, making the changes in small steps and commiting each step? (I am still trying to learn how to work with git)
Right.

Quoted 7 lines

Quoted 3 lines
If I understand correctly, if I leave out the library creation, and the in-line tap creation, and the management log changes, there are only minor changes, which should be explained one-by-one.
Yes. The in line tun creation and the managment interface fd passing are the important changes of the patchset.
Arne

I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use the iproute2 wrapper with suid or sudo to setup its configuration.

Alon.

Arne Schwabe

author

2012-05-09 23:24 UTC #6 lore raw

Quoted 7 lines

I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use the iproute2 wrapper with suid or sudo to setup its configuration.
Alon.

I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Looking at my method at the method that opens the tun device to passed over managment socket might also give an idea how it is done in Android:
http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/OpenVpnService.java#220

Arne

Alon Bar-Lev

2012-05-09 23:39 UTC #7 lore raw

Quoted 8 lines · Arne Schwabe

Quoted 7 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use the iproute2 wrapper with suid or sudo to setup its configuration.
Alon.

Quoted 8 lines

I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Looking at my method at the method that opens the tun device to passed over managment socket might also give an idea how it is done in Android:
http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/OpenVpnService.java#220
Arne

I understand.

But... let's discuss another approach...

Implement android-ip program that uses the Android API, and put "iproute2 android-ip" in configuration.

Now, the interface of the program is similar to what iproute is receiving, but instead of netlink it does android API.

So actually you can receive requests from openvpn via this interface without modifying openvpn...

Maybe I am missing something, please bear with me.

Alon.

Arne Schwabe

author

2012-05-10 00:01 UTC #8 lore raw

Am 10.05.12 01:39, schrieb Alon Bar-Lev:

Quoted 22 lines · Arne Schwabe

Quoted 6 lines
Quoted 6 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use the iproute2 wrapper with suid or sudo to setup its configuration.
Alon.
Quoted 8 lines
I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Looking at my method at the method that opens the tun device to passed over managment socket might also give an idea how it is done in Android:
http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/OpenVpnService.java#220
Arne
I understand.
But... let's discuss another approach...
Implement android-ip program that uses the Android API, and put "iproute2 android-ip" in configuration.

Quoted 8 lines

Now, the interface of the program is similar to what iproute is receiving, but instead of netlink it does android API.
So actually you can receive requests from openvpn via this interface without modifying openvpn...
Maybe I am missing something, please bear with me.

The android API in this case is Java. There is no C API that can be used. Opening the tun device requires passing the fd of the tun device to openvpn. Also the for sockets that should not be routed over the tun device the Java API provides a protect(int fd) API. That means the socket from openvpn needs to passed to the Java GUI to call the protect method.

I see 2 way to accomplish this:

- Using the the java native interface to directly call into java from c and vice versa. This worked but since openvpn was not really usable as a library I got other problem (the google code repository has earlier version of the code which uses this.)
- Keep openvpn as seperate process and pass the fd over a unix socket. (One of the more obscure Unix apis)

The requirement that all information as ip addresses, dns and routes must be available means that the persist-tun device cannot be used if I also want to be to use pull.

Calling an external programs could eliminate the "ROUTE" , "DNS", "DOMAIN" , "IFCONFIG" management commands I have introduced. But the patched implements also two fd passing managment commands "PROTECT-FD" (passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to openvpn).

Arne

Alon Bar-Lev

2012-05-10 00:10 UTC #9 lore raw

Quoted 51 lines · Arne Schwabe

Am 10.05.12 01:39, schrieb Alon Bar-Lev:
Quoted 22 lines · Arne Schwabe
Quoted 6 lines
Quoted 6 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use the iproute2 wrapper with suid or sudo to setup its configuration.
Alon.
Quoted 8 lines
I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Looking at my method at the method that opens the tun device to passed over managment socket might also give an idea how it is done in Android:
http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/OpenVpnService.java#220
Arne
I understand.
But... let's discuss another approach...
Implement android-ip program that uses the Android API, and put "iproute2 android-ip" in configuration.
Quoted 8 lines
Now, the interface of the program is similar to what iproute is receiving, but instead of netlink it does android API.
So actually you can receive requests from openvpn via this interface without modifying openvpn...
Maybe I am missing something, please bear with me.
The android API in this case is Java. There is no C API that can be used. Opening the tun device requires passing the fd of the tun device to openvpn. Also the for sockets that should not be routed over the tun device the Java API provides a protect(int fd) API. That means the socket from openvpn needs to passed to the Java GUI to call the protect method.
I see 2 way to accomplish this:
- Using the the java native interface to directly call into java from c and vice versa. This worked but since openvpn was not really usable as a library I got other problem (the google code repository has earlier version of the code which uses this.)
- Keep openvpn as seperate process and pass the fd over a unix socket. (One of the more obscure Unix apis)
The requirement that all information as ip addresses, dns and routes must be available means that the persist-tun device cannot be used if I also want to be to use pull.

Quoted 8 lines

Calling an external programs could eliminate the "ROUTE" , "DNS", "DOMAIN" , "IFCONFIG" management commands I have introduced. But the patched implements also two fd passing managment commands "PROTECT-FD" (passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to openvpn).
Arne

Great, so we can first shrink the patch!

So two features you implied...

1. pass pre-opened tun device

are you sure there are no alternatives to this? how does the java api receives the handle anyway?

2. the "protect" API.

Can you please explain more about the functionality of the "protect" API? why is this actually required? maybe there are alternatives.

Alon.

Adriaan de Jong

2012-05-10 06:35 UTC #10 lore raw

Quoted 77 lines

-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 2:10
To: Arne Schwabe
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Quoted 2 lines · Arne Schwabe
Am 10.05.12 01:39, schrieb Alon Bar-Lev:
Quoted 1 line
On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe <[email protected]...>
Quoted 9 lines · wrote:
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use the iproute2 wrapper with suid or sudo to setup its configuration.
Alon.
I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Looking at my method at the method that opens the tun device to passed over managment socket might also give an idea how it is done
in Android:
Quoted 1 line
Quoted 1 line
Quoted 1 line
http://code.google.com/p/ics-
openvpn/source/browse/src/de/blinkt/ope
Quoted 13 lines
Quoted 13 lines
Quoted 3 lines
nvpn/OpenVpnService.java#220
Arne
I understand.
But... let's discuss another approach...
Implement android-ip program that uses the Android API, and put "iproute2 android-ip" in configuration.
Now, the interface of the program is similar to what iproute is receiving, but instead of netlink it does android API.
Quoted 7 lines
Quoted 5 lines
So actually you can receive requests from openvpn via this interface without modifying openvpn...
Maybe I am missing something, please bear with me.
The android API in this case is Java. There is no C API that can be used. Opening the tun device requires passing the fd of the tun
device
Quoted 2 lines
to openvpn. Also the for sockets that should not be routed over the tun device the Java API provides a protect(int fd) API. That means
the
Quoted 10 lines
socket from openvpn needs to passed to the Java GUI to call the protect method.
I see 2 way to accomplish this:
- Using the the java native interface to directly call into java from c and vice versa. This worked but since openvpn was not really usable as a library I got other problem (the google code repository has earlier version of the code which uses this.)
- Keep openvpn as seperate process and pass the fd over a unix
socket.
Quoted 9 lines
(One of the more obscure Unix apis)
The requirement that all information as ip addresses, dns and routes must be available means that the persist-tun device cannot be used if I also want to be to use pull.
Calling an external programs could eliminate the "ROUTE" , "DNS", "DOMAIN" , "IFCONFIG" management commands I have introduced. But the patched implements also two fd passing managment commands "PROTECT-
FD"
Quoted 5 lines
(passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to openvpn).
Arne

Quoted 9 lines

Great, so we can first shrink the patch!
So two features you implied...
1. pass pre-opened tun device
are you sure there are no alternatives to this? how does the java api receives the handle anyway?

I agree with Arne's approach of letting the tun driver be passed through the management interface. This is the way things work in Android VPNService land. I still need to go through the code though.

Quoted 5 lines

2. the "protect" API.
Can you please explain more about the functionality of the "protect" API? why is this actually required? maybe there are alternatives.

About the protect API: The VPNService API routes all traffic through the VPN by default. The socket used by OpenVPN needs to be "protected" from this, using a special function call. Therefore, Android Java needs this call.

Adriaan

Alon Bar-Lev

2012-05-10 06:49 UTC #11 lore raw

Quoted 89 lines · Adriaan de Jong

Quoted 77 lines
-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 2:10
To: Arne Schwabe
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Quoted 2 lines · Arne Schwabe
Am 10.05.12 01:39, schrieb Alon Bar-Lev:
Quoted 1 line
On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe <[email protected]...>
Quoted 9 lines · wrote:
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use the iproute2 wrapper with suid or sudo to setup its configuration.
Alon.
I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Looking at my method at the method that opens the tun device to passed over managment socket might also give an idea how it is done
in Android:
Quoted 1 line
Quoted 1 line
Quoted 1 line
http://code.google.com/p/ics-
openvpn/source/browse/src/de/blinkt/ope
Quoted 13 lines
Quoted 13 lines
Quoted 3 lines
nvpn/OpenVpnService.java#220
Arne
I understand.
But... let's discuss another approach...
Implement android-ip program that uses the Android API, and put "iproute2 android-ip" in configuration.
Now, the interface of the program is similar to what iproute is receiving, but instead of netlink it does android API.
Quoted 7 lines
Quoted 5 lines
So actually you can receive requests from openvpn via this interface without modifying openvpn...
Maybe I am missing something, please bear with me.
The android API in this case is Java. There is no C API that can be used. Opening the tun device requires passing the fd of the tun
device
Quoted 2 lines
to openvpn. Also the for sockets that should not be routed over the tun device the Java API provides a protect(int fd) API. That means
the
Quoted 10 lines
socket from openvpn needs to passed to the Java GUI to call the protect method.
I see 2 way to accomplish this:
- Using the the java native interface to directly call into java from c and vice versa. This worked but since openvpn was not really usable as a library I got other problem (the google code repository has earlier version of the code which uses this.)
- Keep openvpn as seperate process and pass the fd over a unix
socket.
Quoted 9 lines
(One of the more obscure Unix apis)
The requirement that all information as ip addresses, dns and routes must be available means that the persist-tun device cannot be used if I also want to be to use pull.
Calling an external programs could eliminate the "ROUTE" , "DNS", "DOMAIN" , "IFCONFIG" management commands I have introduced. But the patched implements also two fd passing managment commands "PROTECT-
FD"
Quoted 5 lines
(passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to openvpn).
Arne
Quoted 9 lines
Great, so we can first shrink the patch!
So two features you implied...
1. pass pre-opened tun device
are you sure there are no alternatives to this? how does the java api receives the handle anyway?
I agree with Arne's approach of letting the tun driver be passed through the management interface. This is the way things work in Android VPNService land. I still need to go through the code though.

Quoted 7 lines

Quoted 5 lines
2. the "protect" API.
Can you please explain more about the functionality of the "protect" API? why is this actually required? maybe there are alternatives.
About the protect API: The VPNService API routes all traffic through the VPN by default. The socket used by OpenVPN needs to be "protected" from this, using a special function call. Therefore, Android Java needs this call.

Thanks!

So why can't we simply open the socket at the UI as well? similar to the tun?

Alon.

Alon Bar-Lev

2012-05-10 06:55 UTC #12 lore raw

Quoted 96 lines · Alon Bar-Lev

Quoted 95 lines · Adriaan de Jong
Quoted 77 lines
-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 2:10
To: Arne Schwabe
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Quoted 2 lines · Arne Schwabe
Am 10.05.12 01:39, schrieb Alon Bar-Lev:
Quoted 1 line
On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe <[email protected]...>
Quoted 9 lines · wrote:
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use the iproute2 wrapper with suid or sudo to setup its configuration.
Alon.
I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Looking at my method at the method that opens the tun device to passed over managment socket might also give an idea how it is done
in Android:
Quoted 1 line
Quoted 1 line
Quoted 1 line
http://code.google.com/p/ics-
openvpn/source/browse/src/de/blinkt/ope
Quoted 13 lines
Quoted 13 lines
Quoted 3 lines
nvpn/OpenVpnService.java#220
Arne
I understand.
But... let's discuss another approach...
Implement android-ip program that uses the Android API, and put "iproute2 android-ip" in configuration.
Now, the interface of the program is similar to what iproute is receiving, but instead of netlink it does android API.
Quoted 7 lines
Quoted 5 lines
So actually you can receive requests from openvpn via this interface without modifying openvpn...
Maybe I am missing something, please bear with me.
The android API in this case is Java. There is no C API that can be used. Opening the tun device requires passing the fd of the tun
device
Quoted 2 lines
to openvpn. Also the for sockets that should not be routed over the tun device the Java API provides a protect(int fd) API. That means
the
Quoted 10 lines
socket from openvpn needs to passed to the Java GUI to call the protect method.
I see 2 way to accomplish this:
- Using the the java native interface to directly call into java from c and vice versa. This worked but since openvpn was not really usable as a library I got other problem (the google code repository has earlier version of the code which uses this.)
- Keep openvpn as seperate process and pass the fd over a unix
socket.
Quoted 9 lines
(One of the more obscure Unix apis)
The requirement that all information as ip addresses, dns and routes must be available means that the persist-tun device cannot be used if I also want to be to use pull.
Calling an external programs could eliminate the "ROUTE" , "DNS", "DOMAIN" , "IFCONFIG" management commands I have introduced. But the patched implements also two fd passing managment commands "PROTECT-
FD"
Quoted 5 lines
(passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to openvpn).
Arne
Quoted 9 lines
Great, so we can first shrink the patch!
So two features you implied...
1. pass pre-opened tun device
are you sure there are no alternatives to this? how does the java api receives the handle anyway?
I agree with Arne's approach of letting the tun driver be passed through the management interface. This is the way things work in Android VPNService land. I still need to go through the code though.
Quoted 5 lines
2. the "protect" API.
Can you please explain more about the functionality of the "protect" API? why is this actually required? maybe there are alternatives.

Quoted 7 lines

Quoted 1 line
About the protect API: The VPNService API routes all traffic through the VPN by default. The socket used by OpenVPN needs to be "protected" from this, using a special function call. Therefore, Android Java needs this call.
Thanks!
So why can't we simply open the socket at the UI as well? similar to the tun?
Alon.

Or add this functionality to plugin interface?

Alon.

Adriaan de Jong

2012-05-10 07:00 UTC #13 lore raw

In reply to Alon Bar-Lev

That would be another option. In the model we were using (which might be different), the order is as follows:

1. openvpn is started
2. openvpn opens a socket to the remote host
2. openvpn establishes the control channel across this socket
3. openvpn passes socket and control channel data (IP, routing, DNS, etc) through the management interface to the android app
4. android app passes these to the VPNService and receives an opened tun
5. android app passes the tun to openvpn
6. openvpn proceeds as usual

To answer your follow up:
There's no need for the extra complexity of a plugin here. The management interface is a great tool, completely separating OpenVPN from its management interface.

Adriaan

Quoted 126 lines

-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 8:49
To: Adriaan de Jong
Cc: Arne Schwabe; [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Quoted 9 lines · Adriaan de Jong
Quoted 9 lines
-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 2:10
To: Arne Schwabe
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe <[email protected]...>
Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 2 lines
Am 10.05.12 01:39, schrieb Alon Bar-Lev:
Quoted 1 line
On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe <[email protected]...>
Quoted 5 lines · wrote:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use the iproute2 wrapper with suid or sudo to setup its configuration.
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Alon.
I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Quoted 22 lines
Quoted 22 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Looking at my method at the method that opens the tun device to passed over managment socket might also give an idea how it is done
in Android:
Quoted 1 line
Quoted 1 line
Quoted 1 line
http://code.google.com/p/ics-
openvpn/source/browse/src/de/blinkt/ope
Quoted 16 lines
Quoted 16 lines
Quoted 3 lines
nvpn/OpenVpnService.java#220
Arne
I understand.
But... let's discuss another approach...
Implement android-ip program that uses the Android API, and put "iproute2 android-ip" in configuration.
Now, the interface of the program is similar to what iproute is receiving, but instead of netlink it does android API.
So actually you can receive requests from openvpn via this interface without modifying openvpn...
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Maybe I am missing something, please bear with me.
The android API in this case is Java. There is no C API that can be used. Opening the tun device requires passing the fd of the tun
device
Quoted 1 line
to openvpn. Also the for sockets that should not be routed over
the
Quoted 9 lines
Quoted 9 lines
Quoted 1 line
tun device the Java API provides a protect(int fd) API. That means
the
Quoted 7 lines
socket from openvpn needs to passed to the Java GUI to call the protect method.
I see 2 way to accomplish this:
- Using the the java native interface to directly call into java from c and vice versa. This worked but since openvpn was not
really
Quoted 1 line
Quoted 1 line
Quoted 1 line
usable as a library I got other problem (the google code
repository
Quoted 20 lines
Quoted 20 lines
Quoted 2 lines
has earlier version of the code which uses this.)
- Keep openvpn as seperate process and pass the fd over a unix
socket.
Quoted 10 lines
(One of the more obscure Unix apis)
The requirement that all information as ip addresses, dns and routes must be available means that the persist-tun device cannot be used if I also want to be to use pull.
Calling an external programs could eliminate the "ROUTE" , "DNS", "DOMAIN" , "IFCONFIG" management commands I have introduced. But the patched implements also two fd passing managment commands "PROTECT-
FD"
Quoted 5 lines
(passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to openvpn).
Arne
Quoted 7 lines
Quoted 7 lines
Great, so we can first shrink the patch!
So two features you implied...
1. pass pre-opened tun device
are you sure there are no alternatives to this? how does the java
api
Quoted 4 lines
Quoted 2 lines
receives the handle anyway?
I agree with Arne's approach of letting the tun driver be passed
through the management interface. This is the way things work in Android VPNService land. I still need to go through the code though.
Quoted 8 lines
Quoted 6 lines
2. the "protect" API.
Can you please explain more about the functionality of the "protect" API? why is this actually required? maybe there are alternatives.
About the protect API: The VPNService API routes all traffic through
the VPN by default. The socket used by OpenVPN needs to be "protected" from this, using a special function call. Therefore, Android Java needs this call.
Thanks!
So why can't we simply open the socket at the UI as well? similar to the tun?
Alon.

Alon Bar-Lev

2012-05-10 07:17 UTC #14 lore raw

Thank you,

Yes, I understand.

If I narrow this to "feature requests", basically we say that:
1. we want direct tun management to the management interface.
2. we want to have some logic when openvpn socket is opened.
3. Pass pre opened tun.

(1) - direct tun management to the management interface

Until now I thought it should go to the plugin interface as in any privilege separation model, the user will not be able to do any change in networking.

But... I think it will be fairly simple to do so, with the new tun interface[1] I am working of.

It introduces a tun engine, with a standard interface, it will be easy to support several tun engines at same time selecting one by configuration.

So we can have tun-engine-management.c to delegate all to the management interface. It can be used if management interface is tcp as well...

For example the linux tune engine[2] is very simple.

A management engine can be stacked overriding the tun_ifconfig, tun_init*.

BUT: I still think that currently it will be much simpler to do this using iproute2 wrapper that uses the android API.

For (2) - custom socket creation

I still think that the plugin API is the right approach, you simply implement openvpn-plugin-android, that opens the socket for the openvpn process. It is not more complex than passing this via the management interface, and can be used if management interface is not unix domain socket...

(3) pre opened tun

This should be simple, as fd can be created and inherited by the openvpn process.

What do you think?

Alon

[1] https://github.com/alonbl/openvpn/tree/tun
[2] https://github.com/alonbl/openvpn/blob/0205f085e8b77c6a6d49c38f20f9e49f41154f61/src/openvpn/tun-engine-linux.c

Quoted 141 lines · Adriaan de Jong

That would be another option. In the model we were using (which might be different), the order is as follows:
1. openvpn is started
2. openvpn opens a socket to the remote host
2. openvpn establishes the control channel across this socket
3. openvpn passes socket and control channel data (IP, routing, DNS, etc) through the management interface to the android app
4. android app passes these to the VPNService and receives an opened tun
5. android app passes the tun to openvpn
6. openvpn proceeds as usual
To answer your follow up:
There's no need for the extra complexity of a plugin here. The management interface is a great tool, completely separating OpenVPN from its management interface.
Adriaan
Quoted 126 lines
-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 8:49
To: Adriaan de Jong
Cc: Arne Schwabe; [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Quoted 9 lines · Adriaan de Jong
Quoted 9 lines
-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 2:10
To: Arne Schwabe
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe <[email protected]...>
Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 2 lines
Am 10.05.12 01:39, schrieb Alon Bar-Lev:
Quoted 1 line
On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe <[email protected]...>
Quoted 5 lines · wrote:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use the iproute2 wrapper with suid or sudo to setup its configuration.
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Alon.
I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Quoted 22 lines
Quoted 22 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Looking at my method at the method that opens the tun device to passed over managment socket might also give an idea how it is done
in Android:
Quoted 1 line
Quoted 1 line
Quoted 1 line
http://code.google.com/p/ics-
openvpn/source/browse/src/de/blinkt/ope
Quoted 16 lines
Quoted 16 lines
Quoted 3 lines
nvpn/OpenVpnService.java#220
Arne
I understand.
But... let's discuss another approach...
Implement android-ip program that uses the Android API, and put "iproute2 android-ip" in configuration.
Now, the interface of the program is similar to what iproute is receiving, but instead of netlink it does android API.
So actually you can receive requests from openvpn via this interface without modifying openvpn...
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Maybe I am missing something, please bear with me.
The android API in this case is Java. There is no C API that can be used. Opening the tun device requires passing the fd of the tun
device
Quoted 1 line
to openvpn. Also the for sockets that should not be routed over
the
Quoted 9 lines
Quoted 9 lines
Quoted 1 line
tun device the Java API provides a protect(int fd) API. That means
the
Quoted 7 lines
socket from openvpn needs to passed to the Java GUI to call the protect method.
I see 2 way to accomplish this:
- Using the the java native interface to directly call into java from c and vice versa. This worked but since openvpn was not
really
Quoted 1 line
Quoted 1 line
Quoted 1 line
usable as a library I got other problem (the google code
repository
Quoted 20 lines
Quoted 20 lines
Quoted 2 lines
has earlier version of the code which uses this.)
- Keep openvpn as seperate process and pass the fd over a unix
socket.
Quoted 10 lines
(One of the more obscure Unix apis)
The requirement that all information as ip addresses, dns and routes must be available means that the persist-tun device cannot be used if I also want to be to use pull.
Calling an external programs could eliminate the "ROUTE" , "DNS", "DOMAIN" , "IFCONFIG" management commands I have introduced. But the patched implements also two fd passing managment commands "PROTECT-
FD"
Quoted 5 lines
(passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to openvpn).
Arne
Quoted 7 lines
Quoted 7 lines
Great, so we can first shrink the patch!
So two features you implied...
1. pass pre-opened tun device
are you sure there are no alternatives to this? how does the java
api
Quoted 4 lines
Quoted 2 lines
receives the handle anyway?
I agree with Arne's approach of letting the tun driver be passed
through the management interface. This is the way things work in Android VPNService land. I still need to go through the code though.
Quoted 8 lines
Quoted 6 lines
2. the "protect" API.
Can you please explain more about the functionality of the "protect" API? why is this actually required? maybe there are alternatives.
About the protect API: The VPNService API routes all traffic through
the VPN by default. The socket used by OpenVPN needs to be "protected" from this, using a special function call. Therefore, Android Java needs this call.
Thanks!
So why can't we simply open the socket at the UI as well? similar to the tun?
Alon.

Adriaan de Jong

2012-05-10 07:28 UTC #15 lore raw

I still prefer using the management interface. It keeps the interface to the Java stuff very clean (socket-based). Further you potentially allow other systems, such as Apple or Windows Phone to do the same. It avoids messy JNI stuff, and fits into the spirit of the management interface. It's the simplest solution.

Quoted 226 lines

-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 9:17
To: Adriaan de Jong
Cc: Arne Schwabe; [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Thank you,
Yes, I understand.
If I narrow this to "feature requests", basically we say that:
1. we want direct tun management to the management interface.
2. we want to have some logic when openvpn socket is opened.
3. Pass pre opened tun.
(1) - direct tun management to the management interface
Until now I thought it should go to the plugin interface as in any privilege separation model, the user will not be able to do any change in networking.
But... I think it will be fairly simple to do so, with the new tun interface[1] I am working of.
It introduces a tun engine, with a standard interface, it will be easy to support several tun engines at same time selecting one by configuration.
So we can have tun-engine-management.c to delegate all to the management interface. It can be used if management interface is tcp as well...
For example the linux tune engine[2] is very simple.
A management engine can be stacked overriding the tun_ifconfig, tun_init*.
BUT: I still think that currently it will be much simpler to do this using iproute2 wrapper that uses the android API.
For (2) - custom socket creation
I still think that the plugin API is the right approach, you simply implement openvpn-plugin-android, that opens the socket for the openvpn process. It is not more complex than passing this via the management interface, and can be used if management interface is not unix domain socket...
(3) pre opened tun
This should be simple, as fd can be created and inherited by the openvpn process.
What do you think?
Alon
[1] https://github.com/alonbl/openvpn/tree/tun
[2]
https://github.com/alonbl/openvpn/blob/0205f085e8b77c6a6d49c38f20f9e49f
41154f61/src/openvpn/tun-engine-linux.c
Quoted 1 line · Adriaan de Jong
That would be another option. In the model we were using (which might
be different), the order is as follows:
Quoted 7 lines
1. openvpn is started
2. openvpn opens a socket to the remote host 2. openvpn establishes the control channel across this socket 3. openvpn passes socket and control channel data (IP, routing, DNS, etc) through the management interface to the android app 4. android app passes these to the VPNService and receives an opened tun 5. android app passes the tun
to
Quoted 4 lines
openvpn 6. openvpn proceeds as usual
To answer your follow up:
There's no need for the extra complexity of a plugin here. The
management interface is a great tool, completely separating OpenVPN from its management interface.
Quoted 30 lines
Adriaan
Quoted 27 lines
-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 8:49
To: Adriaan de Jong
Cc: Arne Schwabe; [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Quoted 9 lines · Adriaan de Jong
Quoted 9 lines
-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 2:10
To: Arne Schwabe
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe <[email protected]...>
Quoted 7 lines · wrote:
Quoted 7 lines
Quoted 3 lines
Am 10.05.12 01:39, schrieb Alon Bar-Lev:
Quoted 2 lines
On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe
<[email protected]...>
Quoted 3 lines · wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
iproute2 wrapper with suid or sudo to setup its
configuration.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Alon.
I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Looking at my method at the method that opens the tun device to passed over managment socket might also give an idea how
it
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
is done
in Android:
Quoted 1 line
Quoted 1 line
Quoted 1 line
http://code.google.com/p/ics-
openvpn/source/browse/src/de/blinkt/ope
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
nvpn/OpenVpnService.java#220
Arne
I understand.
But... let's discuss another approach...
Implement android-ip program that uses the Android API, and
put
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
"iproute2 android-ip" in configuration.
Now, the interface of the program is similar to what iproute
is
Quoted 15 lines
Quoted 15 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
receiving, but instead of netlink it does android API.
So actually you can receive requests from openvpn via this interface without modifying openvpn...
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Maybe I am missing something, please bear with me.
The android API in this case is Java. There is no C API that can be used. Opening the tun device requires passing the fd of the tun
device
Quoted 1 line
to openvpn. Also the for sockets that should not be routed over
the
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
tun device the Java API provides a protect(int fd) API. That means
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
the
Quoted 6 lines
socket from openvpn needs to passed to the Java GUI to call the protect method.
I see 2 way to accomplish this:
- Using the the java native interface to directly call into
java
Quoted 36 lines
Quoted 36 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
from c and vice versa. This worked but since openvpn was not
really
Quoted 1 line
Quoted 1 line
Quoted 1 line
usable as a library I got other problem (the google code
repository
Quoted 21 lines
Quoted 21 lines
Quoted 2 lines
has earlier version of the code which uses this.)
- Keep openvpn as seperate process and pass the fd over a unix
socket.
Quoted 11 lines
(One of the more obscure Unix apis)
The requirement that all information as ip addresses, dns and routes must be available means that the persist-tun device cannot be used if I also want to be to use pull.
Calling an external programs could eliminate the "ROUTE" , "DNS", "DOMAIN" , "IFCONFIG" management commands I have introduced. But the patched implements also two fd passing managment commands
"PROTECT-
FD"
Quoted 5 lines
(passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to openvpn).
Arne
Quoted 7 lines
Quoted 7 lines
Great, so we can first shrink the patch!
So two features you implied...
1. pass pre-opened tun device
are you sure there are no alternatives to this? how does the java
api
Quoted 3 lines
Quoted 2 lines
receives the handle anyway?
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
I agree with Arne's approach of letting the tun driver be passed
through the management interface. This is the way things work in Android VPNService land. I still need to go through the code though.
Quoted 4 lines
Quoted 4 lines
2. the "protect" API.
Can you please explain more about the functionality of the
"protect"
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
API? why is this actually required? maybe there are alternatives.
About the protect API: The VPNService API routes all traffic through
the VPN by default. The socket used by OpenVPN needs to be
"protected"
Quoted 9 lines
Quoted 9 lines
from this, using a special function call. Therefore, Android Java needs this call.
Thanks!
So why can't we simply open the socket at the UI as well? similar to the tun?
Alon.

Alon Bar-Lev

2012-05-10 08:03 UTC #16 lore raw

I guess you refer to (2), right?
I don't think the spirit of the management interface was to pass fds... as it was written in tcp.
A plugin does not mean that you need to write JNI, as it can communicate using a different unix domain socket to upstream anyway...

Something like:

open fd=45 for management
open fd=77 for plugin communication
fork openvpn
openvpn calls plugin to setup custom socket
plugin uses fd=77 to communicate with UI and returns a socket

==> minimal changes to openvpn to a custom solution that most probably has no reuse.

Quoted 228 lines · Adriaan de Jong

I still prefer using the management interface. It keeps the interface to the Java stuff very clean (socket-based). Further you potentially allow other systems, such as Apple or Windows Phone to do the same. It avoids messy JNI stuff, and fits into the spirit of the management interface. It's the simplest solution.
Quoted 226 lines
-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 9:17
To: Adriaan de Jong
Cc: Arne Schwabe; [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Thank you,
Yes, I understand.
If I narrow this to "feature requests", basically we say that:
1. we want direct tun management to the management interface.
2. we want to have some logic when openvpn socket is opened.
3. Pass pre opened tun.
(1) - direct tun management to the management interface
Until now I thought it should go to the plugin interface as in any privilege separation model, the user will not be able to do any change in networking.
But... I think it will be fairly simple to do so, with the new tun interface[1] I am working of.
It introduces a tun engine, with a standard interface, it will be easy to support several tun engines at same time selecting one by configuration.
So we can have tun-engine-management.c to delegate all to the management interface. It can be used if management interface is tcp as well...
For example the linux tune engine[2] is very simple.
A management engine can be stacked overriding the tun_ifconfig, tun_init*.
BUT: I still think that currently it will be much simpler to do this using iproute2 wrapper that uses the android API.
For (2) - custom socket creation
I still think that the plugin API is the right approach, you simply implement openvpn-plugin-android, that opens the socket for the openvpn process. It is not more complex than passing this via the management interface, and can be used if management interface is not unix domain socket...
(3) pre opened tun
This should be simple, as fd can be created and inherited by the openvpn process.
What do you think?
Alon
[1] https://github.com/alonbl/openvpn/tree/tun
[2]
https://github.com/alonbl/openvpn/blob/0205f085e8b77c6a6d49c38f20f9e49f
41154f61/src/openvpn/tun-engine-linux.c
Quoted 1 line · Adriaan de Jong
That would be another option. In the model we were using (which might
be different), the order is as follows:
Quoted 7 lines
1. openvpn is started
2. openvpn opens a socket to the remote host 2. openvpn establishes the control channel across this socket 3. openvpn passes socket and control channel data (IP, routing, DNS, etc) through the management interface to the android app 4. android app passes these to the VPNService and receives an opened tun 5. android app passes the tun
to
Quoted 4 lines
openvpn 6. openvpn proceeds as usual
To answer your follow up:
There's no need for the extra complexity of a plugin here. The
management interface is a great tool, completely separating OpenVPN from its management interface.
Quoted 30 lines
Adriaan
Quoted 27 lines
-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 8:49
To: Adriaan de Jong
Cc: Arne Schwabe; [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Quoted 9 lines · Adriaan de Jong
Quoted 9 lines
-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 2:10
To: Arne Schwabe
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe <[email protected]...>
Quoted 7 lines · wrote:
Quoted 7 lines
Quoted 3 lines
Am 10.05.12 01:39, schrieb Alon Bar-Lev:
Quoted 2 lines
On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe
<[email protected]...>
Quoted 3 lines · wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
iproute2 wrapper with suid or sudo to setup its
configuration.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Alon.
I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Looking at my method at the method that opens the tun device to passed over managment socket might also give an idea how
it
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
is done
in Android:
Quoted 1 line
Quoted 1 line
Quoted 1 line
http://code.google.com/p/ics-
openvpn/source/browse/src/de/blinkt/ope
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
nvpn/OpenVpnService.java#220
Arne
I understand.
But... let's discuss another approach...
Implement android-ip program that uses the Android API, and
put
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
"iproute2 android-ip" in configuration.
Now, the interface of the program is similar to what iproute
is
Quoted 15 lines
Quoted 15 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
receiving, but instead of netlink it does android API.
So actually you can receive requests from openvpn via this interface without modifying openvpn...
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Maybe I am missing something, please bear with me.
The android API in this case is Java. There is no C API that can be used. Opening the tun device requires passing the fd of the tun
device
Quoted 1 line
to openvpn. Also the for sockets that should not be routed over
the
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
tun device the Java API provides a protect(int fd) API. That means
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
the
Quoted 6 lines
socket from openvpn needs to passed to the Java GUI to call the protect method.
I see 2 way to accomplish this:
- Using the the java native interface to directly call into
java
Quoted 36 lines
Quoted 36 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
from c and vice versa. This worked but since openvpn was not
really
Quoted 1 line
Quoted 1 line
Quoted 1 line
usable as a library I got other problem (the google code
repository
Quoted 21 lines
Quoted 21 lines
Quoted 2 lines
has earlier version of the code which uses this.)
- Keep openvpn as seperate process and pass the fd over a unix
socket.
Quoted 11 lines
(One of the more obscure Unix apis)
The requirement that all information as ip addresses, dns and routes must be available means that the persist-tun device cannot be used if I also want to be to use pull.
Calling an external programs could eliminate the "ROUTE" , "DNS", "DOMAIN" , "IFCONFIG" management commands I have introduced. But the patched implements also two fd passing managment commands
"PROTECT-
FD"
Quoted 5 lines
(passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to openvpn).
Arne
Quoted 7 lines
Quoted 7 lines
Great, so we can first shrink the patch!
So two features you implied...
1. pass pre-opened tun device
are you sure there are no alternatives to this? how does the java
api
Quoted 3 lines
Quoted 2 lines
receives the handle anyway?
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
I agree with Arne's approach of letting the tun driver be passed
through the management interface. This is the way things work in Android VPNService land. I still need to go through the code though.
Quoted 4 lines
Quoted 4 lines
2. the "protect" API.
Can you please explain more about the functionality of the
"protect"
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
API? why is this actually required? maybe there are alternatives.
About the protect API: The VPNService API routes all traffic through
the VPN by default. The socket used by OpenVPN needs to be
"protected"
Quoted 9 lines
Quoted 9 lines
from this, using a special function call. Therefore, Android Java needs this call.
Thanks!
So why can't we simply open the socket at the UI as well? similar to the tun?
Alon.

Samuli Seppänen

2012-05-10 08:49 UTC #46 lore raw

In reply to Arne Schwabe

Quoted 15 lines

Hello,
I have developed the port of openvpn for Android 4.0:
https://play.google.com/store/apps/details?id=de.blinkt.openvpn and
http://code.google.com/p/ics-openvpn/
The API of Android 4.0 requires that openvpn runs as completely unprivileged process. There all opening of tun, adding of routes, ifconfig etc. has to be done by another process.
This patch implements an API to allow pushing routes, dns, tun over the management interface (unix socket). Also on Android 4.0 the connection for the control has to be protect via an API call from the Java GUI.

Quoted 7 lines

Basically I am using the needok feature of the management protocol to push all relevant information to the GUI or to request information. I have not split the patch into multiple small patches because it should be first discussed if this is right architectural way.
Arne

Hi Arne,

This is very neat, thanks! I wish I had an Android phone to test with this...

Signature · 5 lines

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

Jan Just Keijser

2012-05-10 08:53 UTC #47 lore raw

Hi,

Quoted 20 lines · Samuli Seppänen

Quoted 20 lines
Hello,
I have developed the port of openvpn for Android 4.0:
https://play.google.com/store/apps/details?id=de.blinkt.openvpn and
http://code.google.com/p/ics-openvpn/
The API of Android 4.0 requires that openvpn runs as completely unprivileged process. There all opening of tun, adding of routes, ifconfig etc. has to be done by another process.
This patch implements an API to allow pushing routes, dns, tun over the management interface (unix socket). Also on Android 4.0 the connection for the control has to be protect via an API call from the Java GUI.
Basically I am using the needok feature of the management protocol to push all relevant information to the GUI or to request information. I have not split the patch into multiple small patches because it should be first discussed if this is right architectural way.

Quoted 8 lines

Quoted 2 lines
Arne
Hi Arne,
This is very neat, thanks! I wish I had an Android phone to test with this...

FYI: actually, you can run android 4 on your PC (Linux/Win/Mac) quite nicely - simply download the android SDK. Performance is actually pretty good!

cheers,

JJK

David Sommerseth

2012-05-10 09:06 UTC #44 lore raw

In reply to Arne Schwabe

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 7 lines · Arne Schwabe

Quoted 2 lines
I suggest you clone the repository at github, create a branch and order your changes.
that would mean to revert all changes, making the changes in small steps and commiting each step? (I am still trying to learn how to work with git)

Using github is no requirement. From what I see, all your patches was gathered into a single file. For this initial review, I see no issues with that. And the changeset isn't really that big.

Having that said, it's a good approach to have many smaller changesets which have well defined changes which "belongs" together. When debugging later on, there's a neat feature in git which is called 'git bisect', which can help you find out which commit causes the trouble.
Smaller changes gives then a better idea how to fix it, than bigger
changes. But of course, it makes no sense to have each line change as a separate commit. See the build/cleanup commits from Alon or the PolarSSL commits (git log 0a18017..be960aa)

For the future, you may also find it easier to configure 'git send-email' when submitting your patches, see our quick crash course on how to do that. Basically, if I have five commits you want to send to the mailing list - all I do is:

    $ git send-email HEAD~5

And then patches are formatted and sent via SMTP. If you want to have a "cover letter", then do:

   $ git format-patch --cover HEAD~5
   (you may review 000{1..5}-*.patch)
   (edit 0000-cover-letter.patch)
   $ git send-email 0000-cover-letter.patch HEAD~5
   *or*
   $ git send-email 0000-cover-letter.patch 000[12345]-*.patch

This makes sure all your mails are nicely threaded.

git crash course:
<https://community.openvpn.net/openvpn/wiki/GitCrashCourse#Preparingforsendingpatchesviamail>

There's also other nice tweaks you can do with git there.

And that's all I want to say about git/github or anything like that in this thread. The rest of this thread will be about the patch contents itself from my side.

kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+rhP8ACgkQDC186MBRfrrGWgCgqe1emSRs8LXAwE33SS9eUDs4 0ggAnjqUxh1gXYPLX2iqEpvfA4FIxfdX
=g4z8
-----END PGP SIGNATURE-----

David Sommerseth

2012-05-10 09:48 UTC #17 lore raw

In reply to Adriaan de Jong

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 5 lines · Adriaan de Jong

I still prefer using the management interface. It keeps the interface to the Java stuff very clean (socket-based). Further you potentially allow other systems, such as Apple or Windows Phone to do the same. It avoids messy JNI stuff, and fits into the spirit of the management interface. It's the simplest solution.

I agree. The plug-in approach seems a bit overkill to me. The approach using the management API makes it far simpler.

Bear in mind that Windows Phone 7 support will probably be asked for at some point - we have no idea how that will really work out now. We have users wanting support for iPhone/iPad. The plug-in approach means to write both a suitable plug-in for the platform and the front-end app. Using just the management API, you just need to write the GUI which does all the needed gluing on the native platforms in that app, just how it wants it.

kind regards,

David Sommerseth

Quoted 55 lines

Quoted 55 lines
-----Original Message----- From: Alon Bar-Lev [mailto:[email protected]...] Sent: donderdag 10 mei 2012 9:17
To: Adriaan de Jong Cc: Arne Schwabe; [email protected] Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Thank you,
Yes, I understand.
If I narrow this to "feature requests", basically we say that: 1. we want direct tun management to the management interface. 2. we want to have some logic when openvpn socket is opened. 3. Pass pre opened tun.
(1) - direct tun management to the management interface
Until now I thought it should go to the plugin interface as in any privilege separation model, the user will not be able to do any change in networking.
But... I think it will be fairly simple to do so, with the new tun interface[1] I am working of.
It introduces a tun engine, with a standard interface, it will be easy to support several tun engines at same time selecting one by configuration.
So we can have tun-engine-management.c to delegate all to the management interface. It can be used if management interface is tcp as well...
For example the linux tune engine[2] is very simple.
A management engine can be stacked overriding the tun_ifconfig, tun_init*.
BUT: I still think that currently it will be much simpler to do this using iproute2 wrapper that uses the android API.
For (2) - custom socket creation
I still think that the plugin API is the right approach, you simply implement openvpn-plugin-android, that opens the socket for the openvpn process. It is not more complex than passing this via the management interface, and can be used if management interface is not unix domain socket...
(3) pre opened tun
This should be simple, as fd can be created and inherited by the openvpn process.
What do you think?

Quoted 7 lines

Quoted 7 lines
Alon
[1] https://github.com/alonbl/openvpn/tree/tun [2]
https://github.com/alonbl/openvpn/blob/0205f085e8b77c6a6d49c38f20f9e49f

41154f61/src/openvpn/tun-engine-linux.c

Quoted 54 lines

Quoted 54 lines
Quoted 2 lines · Adriaan de Jong
That would be another option. In the model we were using (which might
be different), the order is as follows:
Quoted 7 lines
1. openvpn is started 2. openvpn opens a socket to the remote host 2. openvpn establishes the control channel across this socket 3. openvpn passes socket and control channel data (IP, routing, DNS, etc) through the management interface to the android app 4. android app passes these to the VPNService and receives an opened tun 5. android app passes the tun
to
Quoted 4 lines
openvpn 6. openvpn proceeds as usual
To answer your follow up: There's no need for the extra complexity of a plugin here. The
management interface is a great tool, completely separating OpenVPN from its management interface.
Quoted 29 lines
Adriaan
Quoted 26 lines
-----Original Message----- From: Alon Bar-Lev [mailto:[email protected]...] Sent: donderdag 10 mei 2012 8:49 To: Adriaan de Jong Cc: Arne Schwabe; [email protected] Subject: Re:
[Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Quoted 9 lines · Adriaan de Jong
Quoted 9 lines
-----Original Message----- From: Alon Bar-Lev [mailto:[email protected]...] Sent: donderdag 10 mei 2012 2:10 To: Arne Schwabe Cc:
[email protected] Subject: Re:
[Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe
<[email protected]...>
Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 3 lines
Am 10.05.12 01:39, schrieb Alon Bar-Lev:
Quoted 2 lines
On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe
<[email protected]...>
Quoted 4 lines · wrote:
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
iproute2 wrapper with suid or sudo to setup its
configuration.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Alon.

Quoted 8 lines

Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

Looking at my method at the method that opens the tun device

Quoted 110 lines

Quoted 110 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
to passed over managment socket might also give an idea how
it
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
is done
in Android:
Quoted 1 line
Quoted 1 line
Quoted 1 line
http://code.google.com/p/ics-
openvpn/source/browse/src/de/blinkt/ope
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
nvpn/OpenVpnService.java#220
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
Arne
I understand.
But... let's discuss another approach...
Implement android-ip program that uses the Android API, and
put
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
"iproute2 android-ip" in configuration.
Now, the interface of the program is similar to what iproute
is
Quoted 17 lines
Quoted 17 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
receiving, but instead of netlink it does android
API.
So actually you can receive requests from openvpn via this interface without modifying openvpn...
Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Maybe I am missing something, please bear with me.
The android API in this case is Java. There is no C API that can be used. Opening the tun device requires passing the fd of the tun
device
Quoted 2 lines
to openvpn. Also the for sockets that should not be routed over
the
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
tun device the Java API provides a protect(int fd) API. That means
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
the
Quoted 7 lines
socket from openvpn needs to passed to the Java GUI to call the protect method.
I see 2 way to accomplish this:
- Using the the java native interface to directly call into
java
Quoted 42 lines
Quoted 42 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
from c and vice versa. This worked but since openvpn was not
really
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
usable as a library I got other problem (the google code
repository
Quoted 22 lines
Quoted 22 lines
Quoted 3 lines
has earlier version of the code which uses this.) - Keep openvpn as seperate process and pass the fd over a unix
socket.
Quoted 11 lines
(One of the more obscure Unix apis)
The requirement that all information as ip addresses, dns and routes must be available means that the persist-tun device cannot be used if I also want to be to use pull.
Calling an external programs could eliminate the "ROUTE" , "DNS", "DOMAIN" , "IFCONFIG" management commands I have introduced. But the patched implements also two fd passing managment commands "PROTECT-
FD"
Quoted 5 lines
(passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to openvpn).
Arne
Quoted 8 lines
Quoted 8 lines
Great, so we can first shrink the patch!
So two features you implied...
1. pass pre-opened tun device
are you sure there are no alternatives to this? how does the java
api
Quoted 5 lines
Quoted 2 lines
receives the handle anyway?
I agree with Arne's approach of letting the tun driver be passed
Quoted 8 lines
Quoted 8 lines
through the management interface. This is the way things work in Android VPNService land. I still need to go through the code though.
Quoted 5 lines
Quoted 5 lines
2. the "protect" API.
Can you please explain more about the functionality of the
"protect"
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
API? why is this actually required? maybe there are alternatives.
About the protect API: The VPNService API routes all traffic through
the VPN by default. The socket used by OpenVPN needs to be
"protected"
Quoted 3 lines
Quoted 3 lines
from this, using a special function call. Therefore, Android Java needs this call.

Quoted 9 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Thanks!
So why can't we simply open the socket at the UI as well? similar to the tun?
Alon.
------------------------------------------------------------------------------

Live Security Virtual Conference

Quoted 9 lines

Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Openvpn-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+rjuwACgkQDC186MBRfrqP6gCgmgwzFDG8bgpB62JcjZgAv+sf ezMAn03te751+mCr67qjhwkWEq6bYTno
=5IVP
-----END PGP SIGNATURE-----

Adriaan de Jong

2012-05-10 09:50 UTC #18 lore raw

Quoted 23 lines

-----Original Message-----
From: David Sommerseth [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 11:49
To: Alon Bar-Lev
Cc: Adriaan de Jong; [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · Adriaan de Jong
I still prefer using the management interface. It keeps the interface to the Java stuff very clean (socket-based). Further you potentially allow other systems, such as Apple or Windows Phone to do the same.
It
Quoted 2 lines
avoids messy JNI stuff, and fits into the spirit of the management interface. It's the simplest solution.
I agree. The plug-in approach seems a bit overkill to me. The approach using the management API makes it far simpler.

Quoted 9 lines

Bear in mind that Windows Phone 7 support will probably be asked for at some point - we have no idea how that will really work out now. We have users wanting support for iPhone/iPad. The plug-in approach means to write both a suitable plug-in for the platform and the front-end app. Using just the management API, you just need to write the GUI which does all the needed gluing on the native platforms in that app, just how it wants it.

In fact, it's theoretically even a way to remove the need for root rights for the OpenVPN executable, and moving them towards a different, simpler app.

Adriaan

Alon Bar-Lev

2012-05-10 12:37 UTC #45 lore raw

In reply to David Sommerseth

Quoted 9 lines · David Sommerseth

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 4 lines · Arne Schwabe
Quoted 2 lines
I suggest you clone the repository at github, create a branch and order your changes.

Quoted 7 lines

Quoted 3 lines
that would mean to revert all changes, making the changes in small steps and commiting each step? (I am still trying to learn how to work with git)
Using github is no requirement. From what I see, all your patches was gathered into a single file. For this initial review, I see no issues with that. And the changeset isn't really that big.

I only asked for, and indeed it was easier to review than original offering.

Alon.

Samuli Seppänen

2012-05-10 12:42 UTC #19 lore raw

In reply to Adriaan de Jong

Quoted 31 lines

Quoted 22 lines
-----Original Message-----
From: David Sommerseth [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 11:49
To: Alon Bar-Lev
Cc: Adriaan de Jong; [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · Adriaan de Jong
I still prefer using the management interface. It keeps the interface to the Java stuff very clean (socket-based). Further you potentially allow other systems, such as Apple or Windows Phone to do the same.
It
Quoted 2 lines
avoids messy JNI stuff, and fits into the spirit of the management interface. It's the simplest solution.
I agree. The plug-in approach seems a bit overkill to me. The approach using the management API makes it far simpler.
Quoted 9 lines
Bear in mind that Windows Phone 7 support will probably be asked for at some point - we have no idea how that will really work out now. We have users wanting support for iPhone/iPad. The plug-in approach means to write both a suitable plug-in for the platform and the front-end app. Using just the management API, you just need to write the GUI which does all the needed gluing on the native platforms in that app, just how it wants it.

Quoted 3 lines

In fact, it's theoretically even a way to remove the need for root rights for the OpenVPN executable, and moving them towards a different, simpler app.

Speaking of Windows Phone 7 and iPhone/iPad.... afaik[1] their respective application stores prohibit apps with reciprocal licenses (e.g. GPLv2). Is there any way to work around this arbitrary limitations without a complete rewrite? Having to root one's iPhone/iPad/Windows Phone to use OpenVPN sounds silly.

Signature · 9 lines

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock


[1]
<http://arstechnica.com/information-technology/2011/02/windows-phone-marketplace-bans-the-gpl-and-the-app-store-should-too>

Alon Bar-Lev

2012-05-10 12:46 UTC #21 lore raw

In reply to David Sommerseth

Quoted 4 lines · David Sommerseth

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/05/12 09:28, Adriaan de Jong wrote:

Quoted 8 lines

Quoted 5 lines
I still prefer using the management interface. It keeps the interface to the Java stuff very clean (socket-based). Further you potentially allow other systems, such as Apple or Windows Phone to do the same. It avoids messy JNI stuff, and fits into the spirit of the management interface. It's the simplest solution.
I agree. The plug-in approach seems a bit overkill to me. The approach using the management API makes it far simpler.

It can be either management interface or socket between UI and plugin.

The issue is monolithic vs modular.

OpenVPN is already exploded in feature that are needed by specific installations.

For every new feature was need to add we should ask our-selves if it can be added using modular approach and what is missing in the public interfaces in order to do the task.

Of course adding features as #ifdefs is simpler at first, but later on they tend to be complex to maintain and untested, moving to modular components can delegate the maintenance and making the core product quality higher.

If we need to allow directing custom commands to specific plugin via the management - this I can understand.
But patching the core for these tasks is something I think we should avoid.

Alon.

Mendelt Siebenga

2012-05-10 14:03 UTC #22 lore raw

In reply to David Sommerseth

Let me introduce myself first as this is my first post to this mailing list.

I'm Mendelt Siebenga, a new colleague of Adriaan de Jong. I started working for Fox IT a couple of weeks ago. I've been working on something similar to what Arne has been doing but my background is more in higher level Java-y coding so getting familiar with the OpenVPN code has taken me a lot of time. I'm impressed by the progress Arne has made. I'd like to jump in and add some suggestions and hopefully clarify some technical aspects. Adriaan and me arrived at a very similar solution as Arne for getting OpenVPN to work on Android 4 so maybe it's helpful if we clarify how we got to the decisions we made.

Android has a lot of limitations on how you can get access to a TUN device without rooting your phone. Basically what you need to do is:
- Pass a file descriptor of the socket used by OpenVPN to a system call to protect it. This prevents traffic to this socket being routed over the vpn itself.
- Pass all routing information, dns servers etc. To a system call. This call sets up routing and returns a file descriptor to the TUN device. Both of these system calls are Java only.

So in order to get this to work with OpenVPN you need to be able to:
- Get a file descriptor for the socket OpenVPN uses
- Prevent OpenVPN from adding routes itself and get routing information to pass to the Android API
- Pass an opened TUN device to OpenVPN.

We considered two ways of doing this:
- Modify OpenVPN to make it possible to use JNI to call into OpenVPN directly from Java code.
- Modify OpenVPN to add the needed functionality to the management interface like Arne did.

The first option is probably easier to implement on the Java side but it requires a lot of changes in the OpenVPN code. The second option needs a couple of relatively simple changes in OpenVPN and makes it possible for these changes to be reused in other contexts. Being able to get routing information and pass TUN devices to OpenVPN might be useful for some of the GUI projects too.

One thing we did differently is that we don't use JNI at all. We use the existing build system to cross compile OpenVpn as a normal arm-linux executable, package it inside the android apk, write it to flash when it is needed and then execute it from the apk as a separate process. After this we were planning to use the management interface in the same way Arne has implemented.

In order to make Arne's changes more reusable I would suggest a couple of small changes:

- Split the changes up into three features: 1. send socket on the management interface. 2. Send routing info on management interface 3. Receive the TUN device on the management interface

- Use command line options or options in the configuration file to enable these features instead of relying on #ifdef TARGET_ANDROID

- Add some checks to warn about nonsensical settings. For example using these features without a management interface or with a management interface on a tcp/ip socket or on an OS that doesn't support sending filedescriptors over domain sockets should result in an error message.

I'm not really sure about putting these changes off into a separate plugin. I personally like to modularize code as much as possible, but my guess is that in this case adding the hooks to the plugin interface that are necessary to allow this functionality to be implemented as a plugin will add more clutter to OpenVPN than just adding them to the core. I'm not sure what the plans are for the plugin interface but I can imagine that if it becomes more powerful over time we might be able to spin off these changes as a separate plugin later.

Kind regards,
Mendelt Siebenga

-----Original Message-----
From: David Sommerseth [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 11:49
To: Alon Bar-Lev
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 5 lines · Adriaan de Jong

I still prefer using the management interface. It keeps the interface to the Java stuff very clean (socket-based). Further you potentially allow other systems, such as Apple or Windows Phone to do the same. It avoids messy JNI stuff, and fits into the spirit of the management interface. It's the simplest solution.

I agree. The plug-in approach seems a bit overkill to me. The approach using the management API makes it far simpler.

kind regards,

David Sommerseth

Quoted 55 lines

Quoted 55 lines
-----Original Message----- From: Alon Bar-Lev [mailto:[email protected]...] Sent: donderdag 10 mei 2012 9:17
To: Adriaan de Jong Cc: Arne Schwabe; [email protected] Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Thank you,
Yes, I understand.
If I narrow this to "feature requests", basically we say that: 1. we want direct tun management to the management interface. 2. we want to have some logic when openvpn socket is opened. 3. Pass pre opened tun.
(1) - direct tun management to the management interface
Until now I thought it should go to the plugin interface as in any privilege separation model, the user will not be able to do any change in networking.
But... I think it will be fairly simple to do so, with the new tun interface[1] I am working of.
It introduces a tun engine, with a standard interface, it will be easy to support several tun engines at same time selecting one by configuration.
So we can have tun-engine-management.c to delegate all to the management interface. It can be used if management interface is tcp as well...
For example the linux tune engine[2] is very simple.
A management engine can be stacked overriding the tun_ifconfig, tun_init*.
BUT: I still think that currently it will be much simpler to do this using iproute2 wrapper that uses the android API.
For (2) - custom socket creation
I still think that the plugin API is the right approach, you simply implement openvpn-plugin-android, that opens the socket for the openvpn process. It is not more complex than passing this via the management interface, and can be used if management interface is not unix domain socket...
(3) pre opened tun
This should be simple, as fd can be created and inherited by the openvpn process.
What do you think?

Quoted 8 lines

Quoted 8 lines
Alon
[1] https://github.com/alonbl/openvpn/tree/tun [2]
https://github.com/alonbl/openvpn/blob/0205f085e8b77c6a6d49c38f20f9e4
9f

41154f61/src/openvpn/tun-engine-linux.c

Quoted 52 lines

Quoted 52 lines
Quoted 2 lines · Adriaan de Jong
That would be another option. In the model we were using (which might
be different), the order is as follows:
Quoted 7 lines
1. openvpn is started 2. openvpn opens a socket to the remote host
2. openvpn establishes the control channel across this socket 3. openvpn passes socket and control channel data (IP, routing, DNS, etc) through the management interface to the android app 4. android app passes these to the VPNService and receives an opened tun 5. android app passes the tun
to
Quoted 4 lines
openvpn 6. openvpn proceeds as usual
To answer your follow up: There's no need for the extra complexity of a plugin here. The
management interface is a great tool, completely separating OpenVPN from its management interface.
Quoted 27 lines
Adriaan
Quoted 24 lines
-----Original Message----- From: Alon Bar-Lev [mailto:[email protected]...] Sent: donderdag 10 mei 2012 8:49 To: Adriaan de Jong Cc: Arne Schwabe; [email protected] Subject: Re:
[Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Quoted 7 lines · Adriaan de Jong
Quoted 7 lines
-----Original Message----- From: Alon Bar-Lev [mailto:[email protected]...] Sent: donderdag 10 mei 2012 2:10 To: Arne Schwabe Cc:
[email protected] Subject: Re:
[Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe <[email protected]...>
Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 3 lines
Am 10.05.12 01:39, schrieb Alon Bar-Lev:
Quoted 2 lines
On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe
<[email protected]...>
Quoted 4 lines · wrote:
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
I need a better description of the tun process... so far I did not understand why you cannot use standard approach of creating persistent tun with non root access and then use
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
iproute2 wrapper with suid or sudo to setup its
configuration.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Alon.

Quoted 8 lines

Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
I have no root access on the telephone. But Android 4.0 provides an API for VPNs
(http://developer.android.com/reference/android/net/VpnService.html).
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

Looking at my method at the method that opens the tun device

Quoted 96 lines

Quoted 96 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
to passed over managment socket might also give an idea how
it
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
is done
in Android:
Quoted 1 line
Quoted 1 line
Quoted 1 line
http://code.google.com/p/ics-
openvpn/source/browse/src/de/blinkt/ope
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
nvpn/OpenVpnService.java#220
Arne
I understand.
But... let's discuss another approach...
Implement android-ip program that uses the Android API, and
put
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
"iproute2 android-ip" in configuration.
Now, the interface of the program is similar to what iproute
is
Quoted 15 lines
Quoted 15 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
receiving, but instead of netlink it does android API.
So actually you can receive requests from openvpn via this interface without modifying openvpn...
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Maybe I am missing something, please bear with me.
The android API in this case is Java. There is no C API that can be used. Opening the tun device requires passing the fd of the tun
device
Quoted 1 line
to openvpn. Also the for sockets that should not be routed over
the
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
tun device the Java API provides a protect(int fd) API. That means
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
the
Quoted 6 lines
socket from openvpn needs to passed to the Java GUI to call the protect method.
I see 2 way to accomplish this:
- Using the the java native interface to directly call into
java
Quoted 35 lines
Quoted 35 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
from c and vice versa. This worked but since openvpn was not
really
Quoted 1 line
Quoted 1 line
Quoted 1 line
usable as a library I got other problem (the google code
repository
Quoted 20 lines
Quoted 20 lines
Quoted 2 lines
has earlier version of the code which uses this.) - Keep openvpn as seperate process and pass the fd over a unix
socket.
Quoted 10 lines
(One of the more obscure Unix apis)
The requirement that all information as ip addresses, dns and routes must be available means that the persist-tun device cannot be used if I also want to be to use pull.
Calling an external programs could eliminate the "ROUTE" , "DNS", "DOMAIN" , "IFCONFIG" management commands I have introduced. But the patched implements also two fd passing managment commands "PROTECT-
FD"
Quoted 5 lines
(passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to openvpn).
Arne
Quoted 7 lines
Quoted 7 lines
Great, so we can first shrink the patch!
So two features you implied...
1. pass pre-opened tun device
are you sure there are no alternatives to this? how does the java
api
Quoted 3 lines
Quoted 2 lines
receives the handle anyway?
Quoted 8 lines
Quoted 8 lines
Quoted 1 line
I agree with Arne's approach of letting the tun driver be passed
through the management interface. This is the way things work in Android VPNService land. I still need to go through the code though.
Quoted 4 lines
Quoted 4 lines
2. the "protect" API.
Can you please explain more about the functionality of the
"protect"
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
API? why is this actually required? maybe there are alternatives.
About the protect API: The VPNService API routes all traffic through
the VPN by default. The socket used by OpenVPN needs to be
"protected"
Quoted 3 lines
Quoted 3 lines
from this, using a special function call. Therefore, Android Java needs this call.

Quoted 9 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Thanks!
So why can't we simply open the socket at the UI as well? similar to the tun?
Alon.
------------------------------------------------------------------------------

Live Security Virtual Conference

Quoted 9 lines

Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Openvpn-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+rjuwACgkQDC186MBRfrqP6gCgmgwzFDG8bgpB62JcjZgAv+sf ezMAn03te751+mCr67qjhwkWEq6bYTno
=5IVP
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Openvpn-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Arne Schwabe

author

2012-05-10 14:16 UTC #23 lore raw

I generaly agree with Mendelt. A few additions

Quoted 2 lines

We considered two ways of doing this:
- Modify OpenVPN to make it possible to use JNI to call into OpenVPN

directly from Java code.

I implemented that in the first version of my app (<= 0.4.6). But that involed evil trickery like set_jmp/long_jmp and had other deficits like memory leaks when stopping a connection and opening a new one.

Quoted 1 line

- Modify OpenVPN to add the needed functionality to the management

interface like Arne did.

Quoted 2 lines

The first option is probably easier to implement on the Java side but

it requires a lot of changes in the OpenVPN code. The second option needs a couple of relatively simple changes in OpenVPN and makes it possible for these changes to be reused in other contexts. Being able to get routing information and pass TUN devices to OpenVPN might be useful for some of the GUI projects too.

Quoted 2 lines

One thing we did differently is that we don't use JNI at all. We use

the existing build system to cross compile OpenVpn as a normal arm-linux executable, package it inside the android apk, write it to flash when it is needed and then execute it from the apk as a separate process. After this we were planning to use the management interface in the same way Arne has implemented.

My newest version does also does not use JNI at all :). (aport from a tiny wrapper around close(int fd) since I have not yet found another way to close a FileSocket in java).

I build openvpn as library so I only have to write a tiny wrapper to the flash which calls main of the openvpn library.

Quoted 1 line

In order to make Arne's changes more reusable I would suggest a couple

of small changes:

Quoted 2 lines

- Split the changes up into three features: 1. send socket on the

management interface. 2. Send routing info on management interface 3. Receive the TUN device on the management interface

Quoted 2 lines

- Use command line options or options in the configuration file to

enable these features instead of relying on #ifdef TARGET_ANDROID

Quoted 2 lines

- Add some checks to warn about nonsensical settings. For example using

these features without a management interface or with a management interface on a tcp/ip socket or on an OS that doesn't support sending filedescriptors over domain sockets should result in an error message.

Quoted 3 lines

I'm not really sure about putting these changes off into a separate

plugin. I personally like to modularize code as much as possible, but my guess is that in this case adding the hooks to the plugin interface that are necessary to allow this functionality to be implemented as a plugin will add more clutter to OpenVPN than just adding them to the core. I'm not sure what the plans are for the plugin interface but I can imagine that if it becomes more powerful over time we might be able to spin off these changes as a separate plugin later.

Quoted 1 line

I agree on these.

Signature · 2 lines

Arne Schwabe, M.Sc. - http://www.uni-paderborn.de/cs/cn/
Computer Science, University of Paderborn, Germany,  +49 5251 60-1756

Alon Bar-Lev

2012-05-10 14:32 UTC #24 lore raw

In reply to Mendelt Siebenga

Hello Mendelt,

Thank you for taking the time to explain the process, now at least I can comment better.

On Thu, May 10, 2012 at 5:03 PM, Mendelt Siebenga
<[email protected]...> wrote:
<snip>

Quoted 3 lines

Android has a lot of limitations on how you can get access to a TUN device without rooting your phone. Basically what you need to do is:
- Pass a file descriptor of the socket used by OpenVPN to a system call to protect it. This prevents traffic to this socket being routed over the vpn itself.
- Pass all routing information, dns servers etc. To a system call. This call sets up routing and returns a file descriptor to the TUN device.

This is new!
So you need the complete IP and routing settings *BEFORE* you open the tun, this was not clear from the discussion.

<snip>

Quoted 1 line

I'm not really sure about putting these changes off into a separate plugin. I personally like to modularize code as much as possible, but my guess is that in this case adding the hooks to the plugin interface that are necessary to allow this functionality to be implemented as a plugin will add more clutter to OpenVPN than just adding them to the core. I'm not sure what the plans are for the plugin interface but I can imagine that if it becomes more powerful over time we might be able to spin off these changes as a separate plugin later.

This is exactly what I am afraid of, merge now monolithic code in a hope that in future someone will clean up the mess. To be able to provide a solution now to users an external patch may be used, nothing wrong with this.

I prefer to work a little harder and implement the modular infrastructure required to support this scenario and other that may exist, this without breaking assumptions, such as management interface can be TCP connection.

So what I recommend extending the tun engine interface I recently implemented[1] for 2.4, and add an engine to delegate calls to the openvpn plugin framework, the tun engine interface already supports opening the tun, configuring the tun etc... maybe minor changes are required, I will be happy to work on this.

We also add an option for a plugin to use the management interface and expose something like: plugin <id> command.

Then [[[JUST A SUGGESTION]] the UI (java) will open unix domain socket in addition to the management interface and put its number in environment ANDROID_CONTROL_FD=XXX.

A special android plugin will be loaded which register to the tun engine notifications, it will be able to interact with the UI via the management interface, but for two special tasks it will use the custom unix domain control fd in addition, for example via the management interface it will forward the network details, then ask for tun fd, and will get the fd via the control channel.

This way you will be able to maintain the android custom code as a whole, while the openvpn project will benefit from the ability to expose all plugins via the management interface for any task and be able to perform routing and networking setting via plugin (which was also discussed for privilege separation model).

Alon.

[1] https://github.com/alonbl/openvpn/compare/master...tun

Adriaan de Jong

2012-05-10 14:43 UTC #25 lore raw

Quoted 76 lines

-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 16:33
To: Mendelt Siebenga
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Hello Mendelt,
Thank you for taking the time to explain the process, now at least I can comment better.
On Thu, May 10, 2012 at 5:03 PM, Mendelt Siebenga
<[email protected]...> wrote:
<snip>
Quoted 1 line
Android has a lot of limitations on how you can get access to a TUN
device without rooting your phone. Basically what you need to do is:
Quoted 1 line
- Pass a file descriptor of the socket used by OpenVPN to a system
call to protect it. This prevents traffic to this socket being routed over the vpn itself.
Quoted 1 line
- Pass all routing information, dns servers etc. To a system call.
This call sets up routing and returns a file descriptor to the TUN device.
This is new!
So you need the complete IP and routing settings *BEFORE* you open the tun, this was not clear from the discussion.
<snip>
Quoted 1 line
I'm not really sure about putting these changes off into a separate
plugin. I personally like to modularize code as much as possible, but my guess is that in this case adding the hooks to the plugin interface that are necessary to allow this functionality to be implemented as a plugin will add more clutter to OpenVPN than just adding them to the core. I'm not sure what the plans are for the plugin interface but I can imagine that if it becomes more powerful over time we might be able to spin off these changes as a separate plugin later.
This is exactly what I am afraid of, merge now monolithic code in a hope that in future someone will clean up the mess. To be able to provide a solution now to users an external patch may be used, nothing wrong with this.
I prefer to work a little harder and implement the modular infrastructure required to support this scenario and other that may exist, this without breaking assumptions, such as management interface can be TCP connection.
So what I recommend extending the tun engine interface I recently implemented[1] for 2.4, and add an engine to delegate calls to the openvpn plugin framework, the tun engine interface already supports opening the tun, configuring the tun etc... maybe minor changes are required, I will be happy to work on this.
We also add an option for a plugin to use the management interface and expose something like: plugin <id> command.
Then [[[JUST A SUGGESTION]] the UI (java) will open unix domain socket in addition to the management interface and put its number in environment ANDROID_CONTROL_FD=XXX.
A special android plugin will be loaded which register to the tun engine notifications, it will be able to interact with the UI via the management interface, but for two special tasks it will use the custom unix domain control fd in addition, for example via the management interface it will forward the network details, then ask for tun fd, and will get the fd via the control channel.
This way you will be able to maintain the android custom code as a whole, while the openvpn project will benefit from the ability to expose all plugins via the management interface for any task and be able to perform routing and networking setting via plugin (which was also discussed for privilege separation model).

Quoted 4 lines

Alon.
[1] https://github.com/alonbl/openvpn/compare/master...tun

Basically, what you're asking is that a reasonably simple patch is extended into a revamp of the management system. While I agree that more modularisation is important for OpenVPN, stopping all progress and killing off a useful feature is not the way to achieve that. Shall we agree to discuss the technical merits of the patch, and not the grand vision of how OpenVPN should look? Don't throw out the good for the perfect :).

Modularisation work is planned for 2.4, and adding a management-interface controlled tun module would be a great idea there. I still disagree on using the plugin interface for that. A modularised system is fine there.

Adriaan

Alon Bar-Lev

2012-05-10 14:50 UTC #26 lore raw

Quoted 76 lines · Adriaan de Jong

Quoted 76 lines
-----Original Message-----
From: Alon Bar-Lev [mailto:[email protected]...]
Sent: donderdag 10 mei 2012 16:33
To: Mendelt Siebenga
Cc: [email protected]
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Hello Mendelt,
Thank you for taking the time to explain the process, now at least I can comment better.
On Thu, May 10, 2012 at 5:03 PM, Mendelt Siebenga
<[email protected]...> wrote:
<snip>
Quoted 1 line
Android has a lot of limitations on how you can get access to a TUN
device without rooting your phone. Basically what you need to do is:
Quoted 1 line
- Pass a file descriptor of the socket used by OpenVPN to a system
call to protect it. This prevents traffic to this socket being routed over the vpn itself.
Quoted 1 line
- Pass all routing information, dns servers etc. To a system call.
This call sets up routing and returns a file descriptor to the TUN device.
This is new!
So you need the complete IP and routing settings *BEFORE* you open the tun, this was not clear from the discussion.
<snip>
Quoted 1 line
I'm not really sure about putting these changes off into a separate
plugin. I personally like to modularize code as much as possible, but my guess is that in this case adding the hooks to the plugin interface that are necessary to allow this functionality to be implemented as a plugin will add more clutter to OpenVPN than just adding them to the core. I'm not sure what the plans are for the plugin interface but I can imagine that if it becomes more powerful over time we might be able to spin off these changes as a separate plugin later.
This is exactly what I am afraid of, merge now monolithic code in a hope that in future someone will clean up the mess. To be able to provide a solution now to users an external patch may be used, nothing wrong with this.
I prefer to work a little harder and implement the modular infrastructure required to support this scenario and other that may exist, this without breaking assumptions, such as management interface can be TCP connection.
So what I recommend extending the tun engine interface I recently implemented[1] for 2.4, and add an engine to delegate calls to the openvpn plugin framework, the tun engine interface already supports opening the tun, configuring the tun etc... maybe minor changes are required, I will be happy to work on this.
We also add an option for a plugin to use the management interface and expose something like: plugin <id> command.
Then [[[JUST A SUGGESTION]] the UI (java) will open unix domain socket in addition to the management interface and put its number in environment ANDROID_CONTROL_FD=XXX.
A special android plugin will be loaded which register to the tun engine notifications, it will be able to interact with the UI via the management interface, but for two special tasks it will use the custom unix domain control fd in addition, for example via the management interface it will forward the network details, then ask for tun fd, and will get the fd via the control channel.
This way you will be able to maintain the android custom code as a whole, while the openvpn project will benefit from the ability to expose all plugins via the management interface for any task and be able to perform routing and networking setting via plugin (which was also discussed for privilege separation model).

Quoted 6 lines

Quoted 4 lines
Alon.
[1] https://github.com/alonbl/openvpn/compare/master...tun
Basically, what you're asking is that a reasonably simple patch is extended into a revamp of the management system. While I agree that more modularisation is important for OpenVPN, stopping all progress and killing off a useful feature is not the way to achieve that. Shall we agree to discuss the technical merits of the patch, and not the grand vision of how OpenVPN should look? Don't throw out the good for the perfect :).

I wrote that I will help to make it true, and already shown the major work done in this direction.

Anyway your argument may be heard from everyone who try to add any change to any software, yes, I need just this simple change... this probably not wise, as sooner or later you have unmaintainable software, which is lose-lose solution.

Quoted 1 line

Modularisation work is planned for 2.4, and adding a management-interface controlled tun module would be a great idea there. I still disagree on using the plugin interface for that. A modularised system is fine there.

Why? plugin is adding a custom logic, and you need custom logic. As I wrote it does not imply that you implement your JNI there.

Alon.

David Sommerseth

2012-05-10 15:17 UTC #27 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 106 lines · Alon Bar-Lev

Quoted 88 lines · Adriaan de Jong
Quoted 83 lines
-----Original Message----- From: Alon Bar-Lev [mailto:[email protected]...] Sent: donderdag 10 mei 2012 16:33 To: Mendelt Siebenga Cc:
[email protected] Subject: Re:
[Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
Hello Mendelt,
Thank you for taking the time to explain the process, now at least I can comment better.
On Thu, May 10, 2012 at 5:03 PM, Mendelt Siebenga
<[email protected]...> wrote: <snip>
Quoted 2 lines
Android has a lot of limitations on how you can get access to a TUN
device without rooting your phone. Basically what you need to do is:
Quoted 2 lines
- Pass a file descriptor of the socket used by OpenVPN to a system
call to protect it. This prevents traffic to this socket being routed over the vpn itself.
Quoted 2 lines
- Pass all routing information, dns servers etc. To a system call.
This call sets up routing and returns a file descriptor to the TUN device.
This is new! So you need the complete IP and routing settings *BEFORE* you open the tun, this was not clear from the discussion.
<snip>
Quoted 2 lines
I'm not really sure about putting these changes off into a separate
plugin. I personally like to modularize code as much as possible, but my guess is that in this case adding the hooks to the plugin interface that are necessary to allow this functionality to be implemented as a plugin will add more clutter to OpenVPN than just adding them to the core. I'm not sure what the plans are for the plugin interface but I can imagine that if it becomes more powerful over time we might be able to spin off these changes as a separate plugin later.
This is exactly what I am afraid of, merge now monolithic code in a hope that in future someone will clean up the mess. To be able to provide a solution now to users an external patch may be used, nothing wrong with this.
I prefer to work a little harder and implement the modular infrastructure required to support this scenario and other that may exist, this without breaking assumptions, such as management interface can be TCP connection.
So what I recommend extending the tun engine interface I recently implemented[1] for 2.4, and add an engine to delegate calls to the openvpn plugin framework, the tun engine interface already supports opening the tun, configuring the tun etc... maybe minor changes are required, I will be happy to work on this.
We also add an option for a plugin to use the management interface and expose something like: plugin <id> command.
Then [[[JUST A SUGGESTION]] the UI (java) will open unix domain socket in addition to the management interface and put its number in environment ANDROID_CONTROL_FD=XXX.
A special android plugin will be loaded which register to the tun engine notifications, it will be able to interact with the UI via the management interface, but for two special tasks it will use the custom unix domain control fd in addition, for example via the management interface it will forward the network details, then ask for tun fd, and will get the fd via the control channel.
This way you will be able to maintain the android custom code as a whole, while the openvpn project will benefit from the ability to expose all plugins via the management interface for any task and be able to perform routing and networking setting via plugin (which was also discussed for privilege separation model).
Quoted 4 lines
Alon.
[1] https://github.com/alonbl/openvpn/compare/master...tun
Quoted 7 lines
Basically, what you're asking is that a reasonably simple patch is extended into a revamp of the management system. While I agree that more modularisation is important for OpenVPN, stopping all progress and killing off a useful feature is not the way to achieve that. Shall we agree to discuss the technical merits of the patch, and not the grand vision of how OpenVPN should look? Don't throw out the good for the perfect :).
I wrote that I will help to make it true, and already shown the major work done in this direction.
Anyway your argument may be heard from everyone who try to add any change to any software, yes, I need just this simple change... this probably not wise, as sooner or later you have unmaintainable software, which is lose-lose solution.

Quoted 7 lines

Quoted 4 lines
Modularisation work is planned for 2.4, and adding a management-interface controlled tun module would be a great idea there. I still disagree on using the plugin interface for that. A modularised system is fine there.
Why? plugin is adding a custom logic, and you need custom logic. As I wrote it does not imply that you implement your JNI there.

Okay ... fine ... there are plenty of big visions for a future version of OpenVPN, and it will become more modular, yes. I think we all agree there.

What is far more important now is the review the *current* patch, this review process have so far derailed completely. Lets put this current discussion aside. Later on we will discuss this how to modularise OpenVPN anyway.

Let's give the other aspects of this patch a fair review, please. If there are approaches to get consider modularisation go smoother in the future, fine. But this review should not be about modularisation itself. And if this patch is fine in the other aspects, for this patch inclusion should be a no-brainer. Getting a new platform support in less than 30KB is a great achievement.

And the reason I'm stressing this review is that we have OpenVPN Tech having a closed Android implementation, there's Arne's approach, Fox-IT has been working on it and there's even one more closed-source implementation (I forgot the name now). Let's gather around Arne's and Fox-ITs efforts and get that in shape so we can get a pure Open Source solution on the table before we're loosing users to these other implementations. Those users won't wait around until we have modularised OpenVPN, as they couldn't really care less - even though we developers might think they do care about such things. And Android users are asking for OpenVPN more and more often these days. We need to stay relevant for those users.

Development is all about iterations. Let's see what we can do NOW to get Arne's approach reviewed properly, see if there are things which can be do to simplify the future somewhat ... but don't make this depend on a complete modularisation of OpenVPN first.

kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk+r2/UACgkQDC186MBRfrr1mwCY1kTyko04YWPtUjVWAdl5zlOQ KwCeOmbmvbTi4yHNtn6P5LVhHuyzGc8=
=JtHp
-----END PGP SIGNATURE-----

Alon Bar-Lev

2012-05-10 15:20 UTC #28 lore raw

Quoted 4 lines · David Sommerseth

Development is all about iterations. Let's see what we can do NOW to get Arne's approach reviewed properly, see if there are things which can be do to simplify the future somewhat ... but don't make this depend on a complete modularisation of OpenVPN first.

There is nothing wrong in maintaining external patches until upstream properly merged the change.
I've been maintaining such patches for years, with user base that was happy. What's the rush? if users wants a solution they have it ready.

Alon.

Alon Bar-Lev

2012-05-10 15:33 UTC #29 lore raw

Quoted 7 lines · Alon Bar-Lev

Quoted 4 lines · David Sommerseth
Development is all about iterations. Let's see what we can do NOW to get Arne's approach reviewed properly, see if there are things which can be do to simplify the future somewhat ... but don't make this depend on a complete modularisation of OpenVPN first.

Quoted 6 lines

There is nothing wrong in maintaining external patches until upstream properly merged the change.
I've been maintaining such patches for years, with user base that was happy. What's the rush? if users wants a solution they have it ready.
Alon.

Can you please remind me how much time the android kernel patches were maintained outside of mainline?
And why?

Alon.

Fabian Knittel

2012-05-10 21:11 UTC #30 lore raw

In reply to David Sommerseth

Hi,

2012/5/10 David Sommerseth <[email protected]...>:

Quoted 12 lines · Alon Bar-Lev

Quoted 2 lines
Why? plugin is adding a custom logic, and you need custom logic. As I wrote it does not imply that you implement your JNI there.
Okay ... fine ... there are plenty of big visions for a future version of OpenVPN, and it will become more modular, yes. I think we all agree there.
What is far more important now is the review the *current* patch, this review process have so far derailed completely. Lets put this current discussion aside. Later on we will discuss this how to modularise OpenVPN anyway.

To allow OpenVPN to be properly refactored afterwards, the important part is probably to get the external interfaces correct (which never works in practice, but it would be nice to get close...).

The main undecided points regarding the interface side of things appear to be:
* How to pass the fds back and forth: Special-case the management interface for unix domain sockets or use a dedicated unix domain socket for special operations. Could this potentially be the same interface that was discussed for some of the windows privilege separation approaches?
* How to call OpenVPN from Java. Via thin JNI wrapper or as a regular executable.
* The precise names of the newly introduced management commands.

Anything else?

Cheers
Fabian

Arne Schwabe

author

2012-05-10 22:07 UTC #31 lore raw

I am listing a few requirements that are not discussed before but may still be important and non obvious. These at least people not involved with the Android platform a better picture of required changes.

Quoted 4 lines

To allow OpenVPN to be properly refactored afterwards, the important part is probably to get the external interfaces correct (which never works in practice, but it would be nice to get close...).

Quoted 9 lines

The main undecided points regarding the interface side of things appear to be:
* How to pass the fds back and forth: Special-case the management interface for unix domain sockets or use a dedicated unix domain socket for special operations. Could this potentially be the same interface that was discussed for some of the windows privilege separation approaches?
* How to call OpenVPN from Java. Via thin JNI wrapper or as a regular executable.
* The precise names of the newly introduced management commands.

* How to pass routing and other information over the managment interface. This is important since OpenVpn for Linux needs ROUTE_AFTER_TUN and IFCONFIG_AFTER_TUN and the Android API needs both before TUN.
* If the TARGET_ANDROID (or call it TARGET_UNPRIVILEGED_USES_FDPASSING or something generic) is an extra target or if TARGET_LINUX and TARGET_ANDROID should one target. This will complicate a lot of things without refactoring (see the before/after point)
* Openvpn for Android is the first platform which does allow non CIDR routes (I think). In my port I print a warning in the GUI if I encounter something stupid like 10.0.0.0 netmask 255.0.255.0. The same goes the netmask of the ifconfig command.

Arne

P.S.: Sorry for double email, I sent from the wrong email in the first try.

Alon Bar-Lev

2012-05-11 04:05 UTC #33 lore raw

In reply to Fabian Knittel

Quoted 20 lines · Fabian Knittel

Hi,
2012/5/10 David Sommerseth <[email protected]...>:
Quoted 12 lines · Alon Bar-Lev
Quoted 2 lines
Why? plugin is adding a custom logic, and you need custom logic. As I wrote it does not imply that you implement your JNI there.
Okay ... fine ... there are plenty of big visions for a future version of OpenVPN, and it will become more modular, yes. I think we all agree there.
What is far more important now is the review the *current* patch, this review process have so far derailed completely. Lets put this current discussion aside. Later on we will discuss this how to modularise OpenVPN anyway.
To allow OpenVPN to be properly refactored afterwards, the important part is probably to get the external interfaces correct (which never works in practice, but it would be nice to get close...).

Quoted 6 lines

The main undecided points regarding the interface side of things appear to be:
* How to pass the fds back and forth: Special-case the management interface for unix domain sockets or use a dedicated unix domain socket for special operations. Could this potentially be the same interface that was discussed for some of the windows privilege separation approaches?

Again, this is not the case of privileged separation as the process *IS* privileged to do the networking setup.
People, don't get confused between running under root or not with privileges! Regular user can have privileges like creating tun and modify network setting without being root, as in this case, this is not privilege separation!

And again, these UI specific issues should should be modularize and not go into mainline as-is.

Quoted 2 lines

* How to call OpenVPN from Java. Via thin JNI wrapper or as a regular executable.

Again, this is not the question.
The question is do we want to make a library out of VPN with some interface such as openvpn_main() or not, the JNI question is totally unrelated to the mainline project.

Quoted 1 line

* The precise names of the newly introduced management commands.

If we provide plugin interface to management interface this can be a contract between the UI and the plugin, so that mainline should not be changed every time there is a special UI need.

If we provide tun engine implementation that supports the management interface, all platforms can benefit from this change.

Quoted 5 lines

Anything else?
Cheers
Fabian

Fabian Knittel

2012-05-11 12:28 UTC #34 lore raw

Hi Alon,

2012/5/11 Alon Bar-Lev <[email protected]...>:

Quoted 9 lines

Quoted 6 lines · Fabian Knittel
The main undecided points regarding the interface side of things appear to be:
* How to pass the fds back and forth: Special-case the management interface for unix domain sockets or use a dedicated unix domain socket for special operations. Could this potentially be the same interface that was discussed for some of the windows privilege separation approaches?

Quoted 6 lines

Again, this is not the case of privileged separation as the process *IS* privileged to do the networking setup.
People, don't get confused between running under root or not with privileges! Regular user can have privileges like creating tun and modify network setting without being root, as in this case, this is not privilege separation!

To be honest, I'm not sure what you're talking about. My point was, that the ideas and approaches gathered in the wiki[0] might influence the interface we're discussing right now. Specifically, Heiko's interactive service would probably need a similar interface. (In your COM+-approach this would be the interface between OpenVPNUI.Network and OpenVPNUI.Tunnel, but as you're suggesting to use COM+, the shape of an advanced management interface or unix-domain-socket-like interface is ... of no real value.)

0: https://community.openvpn.net/openvpn/wiki/PrivilegeSeparation

Quoted 2 lines

And again, these UI specific issues should should be modularize and not go into mainline as-is.

My point was, that we should agree on a stable interface first. In the next step, we can decide whether a specific implementation of that interface is worthy of inclusion. Unless of course, you're thinking about COM+ as one of the UI interfaces. But in my opinion, if Windows has a communication channel that is close to the semantics and capabilities of a UNIX domain socket, we should probably use that as _the_ interface and not needlessly start maintaining a separate interface per UI/plattform.

[...]

Quoted 3 lines

The question is do we want to make a library out of VPN with some interface such as openvpn_main() or not, the JNI question is totally unrelated to the mainline project.

I agree that your question is more to the point.

My opinion regarding the question is, that I don't yet see a need for a library interface. Executable + unix domain sockets seem just fine.

Quoted 5 lines

Quoted 1 line
* The precise names of the newly introduced management commands.
If we provide plugin interface to management interface this can be a contract between the UI and the plugin, so that mainline should not be changed every time there is a special UI need.

If we create a contract that can be upheld by both a plugin and the core, then we can agree on the contract first and agree or change the implementation of the contract later. If we take several UI needs into consideration, we might not need a zoo of management-UI-plugins.

Quoted 2 lines

If we provide tun engine implementation that supports the management interface, all platforms can benefit from this change.

Sounds great. Why not make the management interface contract of that tun engine the main topic of this discussion? That's what I'm aiming at. That way, hopefully the short-term patch can go in and the contract won't need to change as soon as 2.4 delivers the advanced modularisation.

Cheers
Fabian

Gert Doering

2012-05-11 18:56 UTC #36 lore raw

In reply to Adriaan de Jong

Hi,

Quoted 9 lines · Adriaan de Jong

That would be another option. In the model we were using (which might be different), the order is as follows:
1. openvpn is started
2. openvpn opens a socket to the remote host
2. openvpn establishes the control channel across this socket
3. openvpn passes socket and control channel data (IP, routing, DNS, etc) through the management interface to the android app
4. android app passes these to the VPNService and receives an opened tun
5. android app passes the tun to openvpn
6. openvpn proceeds as usual

This looks very reasonable to me.

(As for the patch itself, I had no time to go through it yet, sorry)

Changing the build environment to build a shared library out of openvpn is something I do not fully understand yet, though - and don't view a particular useful goal right now.

gert

Signature · 4 lines

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

Gert Doering

2012-05-11 18:59 UTC #20 lore raw

In reply to Samuli Seppänen

Hi,

Quoted 5 lines · Samuli Seppänen

Speaking of Windows Phone 7 and iPhone/iPad.... afaik[1] their respective application stores prohibit apps with reciprocal licenses (e.g. GPLv2). Is there any way to work around this arbitrary limitations without a complete rewrite? Having to root one's iPhone/iPad/Windows Phone to use OpenVPN sounds silly.

The main problem on iThings right now is not the license but the missing access to their internal VPN API - and to use classic tun devices you need root access...

gert

Signature · 4 lines

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

Alon Bar-Lev

2012-05-11 19:20 UTC #35 lore raw

In reply to Fabian Knittel

Quoted 12 lines · Fabian Knittel

Hi Alon,
2012/5/11 Alon Bar-Lev <[email protected]...>:
Quoted 9 lines
Quoted 6 lines · Fabian Knittel
The main undecided points regarding the interface side of things appear to be:
* How to pass the fds back and forth: Special-case the management interface for unix domain sockets or use a dedicated unix domain socket for special operations. Could this potentially be the same interface that was discussed for some of the windows privilege separation approaches?

Quoted 8 lines

Quoted 6 lines
Again, this is not the case of privileged separation as the process *IS* privileged to do the networking setup.
People, don't get confused between running under root or not with privileges! Regular user can have privileges like creating tun and modify network setting without being root, as in this case, this is not privilege separation!
To be honest, I'm not sure what you're talking about.

Sorry about that.

Quoted 8 lines

My point was,
that the ideas and approaches gathered in the wiki[0] might influence the interface we're discussing right now. Specifically, Heiko's interactive service would probably need a similar interface. (In your COM+-approach this would be the interface between OpenVPNUI.Network and OpenVPNUI.Tunnel, but as you're suggesting to use COM+, the shape of an advanced management interface or unix-domain-socket-like interface is ... of no real value.)

In the windows case I also demonstrated that a simpler solution can be implemented without modifying the way openvpn behaves in term of management interface.

Quoted 9 lines

0: https://community.openvpn.net/openvpn/wiki/PrivilegeSeparation
Quoted 2 lines
And again, these UI specific issues should should be modularize and not go into mainline as-is.
My point was, that we should agree on a stable interface first. In the next step, we can decide whether a specific implementation of that interface is worthy of inclusion.

This is good, but we cannot discuss interfaces if people role out the possibility of different solutions.

Quoted 6 lines

Unless of course, you're thinking
about COM+ as one of the UI interfaces. But in my opinion, if Windows has a communication channel that is close to the semantics and capabilities of a UNIX domain socket, we should probably use that as _the_ interface and not needlessly start maintaining a separate interface per UI/plattform.

*YES* the COM+ approach shows that the OpenVPN-GUI project can use *EXISTING* openvpn (maybe with minor modifications), and provide the full *SOLUTION* for windows platform including privilege separation.

This by providing the COM+ objects and optional plugins.

This way the windows specific solution can be maintained completely independently.

The same applies to this solution as well.
If we can do this without introducing android specific code into the core, but reach to a state that all can be implemented in a plugin, then the android solution will be maintained by appropriate interested parties.

BTW: both windows and android has something in common - the need for performing the ip setting in plugin.

in windows case, the UI may implement a plugin to call the OpenVPNUI.Network object.
in the android case, the UI may implement a plugin to call the management interface.
So we need this anyway.

Quoted 9 lines

[...]
Quoted 3 lines
The question is do we want to make a library out of VPN with some interface such as openvpn_main() or not, the JNI question is totally unrelated to the mainline project.
I agree that your question is more to the point.
My opinion regarding the question is, that I don't yet see a need for a library interface. Executable + unix domain sockets seem just fine.

Right, for now it is sufficient.

Quoted 10 lines

Quoted 5 lines
Quoted 1 line
* The precise names of the newly introduced management commands.
If we provide plugin interface to management interface this can be a contract between the UI and the plugin, so that mainline should not be changed every time there is a special UI need.
If we create a contract that can be upheld by both a plugin and the core, then we can agree on the contract first and agree or change the implementation of the contract later. If we take several UI needs into consideration, we might not need a zoo of management-UI-plugins.

I don't think we will be able to avoid a plugin per special UI need... But I am sure we can avoid modifying the core code every time a new special UI appears.

Quoted 8 lines

Quoted 2 lines
If we provide tun engine implementation that supports the management interface, all platforms can benefit from this change.
Sounds great. Why not make the management interface contract of that tun engine the main topic of this discussion? That's what I'm aiming at. That way, hopefully the short-term patch can go in and the contract won't need to change as soon as 2.4 delivers the advanced modularisation.

I don't believe in short term patches... as we won't be able to remove the implementation when the right functionality is implemented. For now there is nothing wrong to provide out of tree patch for the android users while we work on the proper solution.

My view of proper solution is:

1. Expose the management interface to plugins:
a. ability to send command to plugin and receive response. b. ability of plugin to send request and get response. c. ability of plugin to send logs.

2. Have plugin specific configuration.

3. Implement stackable tun engine to delegate tun management to plugins.

4. Implement android specific plugin to:
a. request protect of socket
a.1. send request via management interface
a.2. send the fd via separate inherited unix domain socket (if required). b. send ip information to management.
c. request tun fd
c.1. send request via management interface
c.2. receive handle via separate inherited unix domain socket.

As far as I understand the above solves the entire issue, and makes openvpn stronger, as the added functionality may be reused for other implementations.

As far as the tun engine is concerned I can do that side. I will be happy if someone else can take the management side, but I can do this as well.
The rest should be trivial.

Quoted 3 lines

Cheers
Fabian

Alon.

Gert Doering

2012-05-11 19:22 UTC #32 lore raw

In reply to Arne Schwabe

Hi,

Quoted 4 lines · Arne Schwabe

* Openvpn for Android is the first platform which does allow non CIDR routes (I think). In my port I print a warning in the GUI if I encounter something stupid like 10.0.0.0 netmask 255.0.255.0. The same goes the netmask of the ifconfig command.

I don't think we can really support that anyway - the IETF has deprecated this sort of netmasks in RFC1519 (introduction of CIDR, section 4.2), and all major operating systems do not support it anymore.

So the server side would not be able to handle that, unless running on Android as well...

I'm not sure whether the openvpn code currently enforces it, but I *am* sure that it will explode on Linux and FreeBSD as soon as you try to actually ifconfig/route such networks.

gert

Signature · 4 lines

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

Alon Bar-Lev

2012-05-11 21:56 UTC #38 lore raw

In reply to a message not in the archive

Quoted 15 lines · Arne Schwabe

Am 11.05.12 20:56, schrieb Gert Doering:
Quoted 3 lines
Changing the build environment to build a shared library out of openvpn is something I do not fully understand yet, though - and don't view a particular useful goal right now.
The shared library is not used as real shared library. I build libopenvpn as complete library and then build a miniature executable that calls the main method of the shared library and therefore exactly behaves like openvpn as executable.
The reason for this is that libraries are managed by the android package system. For executables I have to carry them as data files and write them to a cache partition. By putting the main code into the library I can minimise the amount of data that is written twice to the /data parition on Android.

Quoted 6 lines

The building as library and using android build system should seen as something that is useful for my particular Android application and not as a general thing or requirement.
Arne

I would like you to try to do so using libtool...

Just replace:
---
sbin_PROGRAMS = openvpn
openvpn_SOURCES = ....
---
with:
---
lib_LTLIBRARIES = openvpn.la
openvpn_la_SOURCES = ...
openvpn_la_LDFLAGS = \
-module -shared -avoid-version -no-undefined
---

And add -Dmain=openvpn_main to AM_CFLAGS.

Alon.

Alon Bar-Lev

2012-05-11 21:58 UTC #39 lore raw

Quoted 38 lines · Alon Bar-Lev

Quoted 15 lines · Arne Schwabe
Am 11.05.12 20:56, schrieb Gert Doering:
Quoted 3 lines
Changing the build environment to build a shared library out of openvpn is something I do not fully understand yet, though - and don't view a particular useful goal right now.
The shared library is not used as real shared library. I build libopenvpn as complete library and then build a miniature executable that calls the main method of the shared library and therefore exactly behaves like openvpn as executable.
The reason for this is that libraries are managed by the android package system. For executables I have to carry them as data files and write them to a cache partition. By putting the main code into the library I can minimise the amount of data that is written twice to the /data parition on Android.
Quoted 6 lines
The building as library and using android build system should seen as something that is useful for my particular Android application and not as a general thing or requirement.
Arne
I would like you to try to do so using libtool...
Just replace:
---
sbin_PROGRAMS = openvpn
openvpn_SOURCES = ....
---
with:
---
lib_LTLIBRARIES = openvpn.la
openvpn_la_SOURCES = ...
openvpn_la_LDFLAGS = \
-module -shared -avoid-version -no-undefined
---

Quoted 3 lines

And add -Dmain=openvpn_main to AM_CFLAGS.
Alon.

You should also change:
---
openvpn_LDADD = ...
---
to:
---
openvpn_la_LDADD = ...
---

Arne Schwabe

author

2012-05-11 22:08 UTC #43 lore raw

In reply to Gert Doering

Am 11.05.12 20:56, schrieb Gert Doering:

Quoted 3 lines

Changing the build environment to build a shared library out of openvpn is something I do not fully understand yet, though - and don't view a particular useful goal right now.

The shared library is not used as real shared library. I build libopenvpn as complete library and then build a miniature executable that calls the main method of the shared library and therefore exactly behaves like openvpn as executable.

The reason for this is that libraries are managed by the android package system. For executables I have to carry them as data files and write them to a cache partition. By putting the main code into the library I can minimise the amount of data that is written twice to the /data parition on Android.

The building as library and using android build system should seen as something that is useful for my particular Android application and not as a general thing or requirement.

Arne

Arne Schwabe

author

2012-05-11 22:18 UTC #40 lore raw

In reply to Alon Bar-Lev

Quoted 18 lines

Quoted 15 lines
I would like you to try to do so using libtool...
Just replace:
---
sbin_PROGRAMS = openvpn
openvpn_SOURCES = ....
---
with:
---
lib_LTLIBRARIES = openvpn.la
openvpn_la_SOURCES = ...
openvpn_la_LDFLAGS = \
-module -shared -avoid-version -no-undefined
---
Quoted 3 lines
And add -Dmain=openvpn_main to AM_CFLAGS.
Alon.

Quoted 8 lines

You should also change:
---
openvpn_LDADD = ...
---
to:
---
openvpn_la_LDADD = ...
---

I can try this sometime later but for the moment I happy with building the openvpn with the android ndk build system as there a other things that I prefer to tweaking the build system.

Arne

Gert Doering

2012-05-12 08:10 UTC #41 lore raw

In reply to a message not in the archive

Hi,

Quoted 9 lines · Arne Schwabe

Am 11.05.12 20:56, schrieb Gert Doering:
Quoted 3 lines
Changing the build environment to build a shared library out of openvpn is something I do not fully understand yet, though - and don't view a particular useful goal right now.
The shared library is not used as real shared library. I build libopenvpn as complete library and then build a miniature executable that calls the main method of the shared library and therefore exactly behaves like openvpn as executable.

Quoted 5 lines

The reason for this is that libraries are managed by the android package system. For executables I have to carry them as data files and write them to a cache partition. By putting the main code into the library I can minimise the amount of data that is written twice to the /data parition on Android.

I'm still not sure I fully understand what Android is doing there - but I don't need to :-) - so that explanation is good enough for me.

gert

Signature · 4 lines

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

Alon Bar-Lev

2012-05-12 08:18 UTC #42 lore raw

Quoted 18 lines · Gert Doering

Hi,
Quoted 9 lines · Arne Schwabe
Am 11.05.12 20:56, schrieb Gert Doering:
Quoted 3 lines
Changing the build environment to build a shared library out of openvpn is something I do not fully understand yet, though - and don't view a particular useful goal right now.
The shared library is not used as real shared library. I build libopenvpn as complete library and then build a miniature executable that calls the main method of the shared library and therefore exactly behaves like openvpn as executable.
Quoted 5 lines
The reason for this is that libraries are managed by the android package system. For executables I have to carry them as data files and write them to a cache partition. By putting the main code into the library I can minimise the amount of data that is written twice to the /data parition on Android.

Quoted 4 lines

I'm still not sure I fully understand what Android is doing there - but I don't need to :-) - so that explanation is good enough for me.
gert

Gert, even if we don't understand the android details, it is obvious that either:

a. upstream should merge and maintain yet another parallel build system.

b. downstream should maintain another parallel build.

This should be absolutely avoided if there are alternatives before accepting any explanation.

Alon.