Hi, On Wed, Feb 08, 2012 at 11:27:10AM -0800, James Ring wrote: > > Exactly. The first three things are sort of "nearly done", the > > "receive file descriptor to use for tun/tap" would need to be > > implemented (tun.c, open_tun(), #ifdef ANDROID_MAGIC_VPN :-) ) > > I was thinking about this a little more. Presumably openvpn will be > forked and exec'd before the file descriptor is available. Presumably > openvpn could connect to a UNIX domain socket inside open_tun() if > ANDROID_MAGIC_VPN is specified. > > Does other code within openvpn care whether the fd is a UNIX socket or > a tun/tap device? I'm guessing there may be some ioctls it wants to > perform on the device.
There aren't any ioctl()s (I'm aware of) for tun/tap devices, but
blocking/non-blocking behaviour might be an interesting problem, and
performance / battery usage won't be helped by copying the packet
around another time...
> Other than that, openvpn would be reading and
> writing IP packets with an encrypted payload and the Java wrapper
> would be responsible for forwarding the bytes between the UNIX domain
> socket and the actual tun device.
Don't show idea that to Jan-Just, he's already complaining that OpenVPN
wastes too many CPU cycles...
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpTbp4zdJW9w.pgp
Description: PGP signature
