On Thu, May 10, 2012 at 9:49 AM, Alon Bar-Lev <alon.bar...@gmail.com> wrote: > On Thu, May 10, 2012 at 9:35 AM, Adriaan de Jong <dej...@fox-it.com> wrote: >>> -----Original Message----- >>> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com] >>> Sent: donderdag 10 mei 2012 2:10 >>> To: Arne Schwabe >>> Cc: openvpn-devel@lists.sourceforge.net >>> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset >>> >>> On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe <a...@rfc2549.org> wrote: >>> > Am 10.05.12 01:39, schrieb Alon Bar-Lev: >>> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe <a...@rfc2549.org> >>> wrote: >>> >>>> 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/ope >>> >>> 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... >>> >> >>> >> 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 >>> > >>> >>> 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. >> >>> 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.
Or add this functionality to plugin interface? Alon.
