[Patch] Allows tun_mainloop to handle multiple packets in single read.
David Woodhouse
dwmw2 at infradead.org
Sun Nov 27 12:11:28 EST 2011
On Mon, 2011-11-28 at 01:00 +0900, Kazuyoshi Aizawa wrote:
> One of option would be to use I_LINK/I_UNLINK ioctl command instead of
> I_PLINK/I_PUNLINK. So that streams associated with tun driver will
> disappear when corresponding file descriptor is close.
That sounds like a good plan; thanks. It brings me to another thing that
I noticed isn't supported on Solaris, that you can possibly help with.
On Linux, we can make a persistent tun device and change its ownership,
so that openconnect can run as a non-root user. Then, it only needs
privileges to open the tun device.
Since you have the persistent link in Solaris, we should be able to fix
the '--interface' option so that it opens a specific existing device,
shouldn't we?
One of the problems I was having was that after aborting once,
openconnect could no longer re-open the 'stale' device. How would it
open an existing device?
> I know that openvpn uses I_PLINK, thought it WAS using I_LINK...
> I'm sorry but I'm not sure how come it was changed...and I don't know
> what is the benefit of it. there might be but...
I just checked in the OpenVPN 'historical' repository. It seems that
from the very first time it was ported to Solaris (v1.1.1.9) it has
*always* said 'link_type = I_PLINK; /* was: I_LINK */':
http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-historical-cvs.git;a=commitdiff;h=996ecf89c09ae23b5184486afc7f196992810271#patch24
So I don't know *when* it was I_LINK; evidently not in any version of
openvpn that was actually released :)
--
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20111127/66ce4418/attachment.bin>
More information about the openconnect-devel
mailing list