-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/05/12 09:28, Adriaan de Jong 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.
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 >> -----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. > ------------------------------------------------------------------------------ > > 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 Openvpn-devel@lists.sourceforge.net > 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-----
