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.
> -----Original Message----- > From: Alon Bar-Lev [mailto:alon.bar...@gmail.com] > Sent: donderdag 10 mei 2012 9:17 > To: Adriaan de Jong > Cc: Arne Schwabe; openvpn-devel@lists.sourceforge.net > 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 > > On Thu, May 10, 2012 at 10:00 AM, Adriaan de Jong <dej...@fox-it.com> > wrote: > > 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 > > > >> -----Original Message----- > >> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com] > >> Sent: donderdag 10 mei 2012 8:49 > >> To: Adriaan de Jong > >> Cc: Arne Schwabe; openvpn-devel@lists.sourceforge.net > >> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 > >> Changeset > >> > >> 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.
