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. On Thu, May 10, 2012 at 10:28 AM, Adriaan de Jong <dej...@fox-it.com> wrote: > 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.
