Hello Mendelt, Thank you for taking the time to explain the process, now at least I can comment better.
On Thu, May 10, 2012 at 5:03 PM, Mendelt Siebenga <mendelt.siebe...@fox-it.com> wrote: <snip> > Android has a lot of limitations on how you can get access to a TUN device > without rooting your phone. Basically what you need to do is: > - Pass a file descriptor of the socket used by OpenVPN to a system call to > protect it. This prevents traffic to this socket being routed over the vpn > itself. > - Pass all routing information, dns servers etc. To a system call. This call > sets up routing and returns a file descriptor to the TUN device. This is new! So you need the complete IP and routing settings *BEFORE* you open the tun, this was not clear from the discussion. <snip> > 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. This is exactly what I am afraid of, merge now monolithic code in a hope that in future someone will clean up the mess. To be able to provide a solution now to users an external patch may be used, nothing wrong with this. I prefer to work a little harder and implement the modular infrastructure required to support this scenario and other that may exist, this without breaking assumptions, such as management interface can be TCP connection. So what I recommend extending the tun engine interface I recently implemented[1] for 2.4, and add an engine to delegate calls to the openvpn plugin framework, the tun engine interface already supports opening the tun, configuring the tun etc... maybe minor changes are required, I will be happy to work on this. We also add an option for a plugin to use the management interface and expose something like: plugin <id> command. Then [[[JUST A SUGGESTION]] the UI (java) will open unix domain socket in addition to the management interface and put its number in environment ANDROID_CONTROL_FD=XXX. A special android plugin will be loaded which register to the tun engine notifications, it will be able to interact with the UI via the management interface, but for two special tasks it will use the custom unix domain control fd in addition, for example via the management interface it will forward the network details, then ask for tun fd, and will get the fd via the control channel. This way you will be able to maintain the android custom code as a whole, while the openvpn project will benefit from the ability to expose all plugins via the management interface for any task and be able to perform routing and networking setting via plugin (which was also discussed for privilege separation model). Alon. [1] https://github.com/alonbl/openvpn/compare/master...tun
