[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