I generaly agree with Mendelt. A few additions > 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. > - 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. 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. > 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. > I agree on these. -- Arne Schwabe, M.Sc. - http://www.uni-paderborn.de/cs/cn/ Computer Science, University of Paderborn, Germany, +49 5251 60-1756
