[Patch] Allows tun_mainloop to handle multiple packets in single read.

[Kazuyoshi Aizawa]

Hi David,

2011/11/28 David Woodhouse <dwmw2 at infradead.org>:
> 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?

Umm, I think there's no simple way to reuse existing interface.
When control stream(*1) is closed, protocol stream(*2) is unlinked
from PPA(*3)
Simply put, once openconnect  daemon is terminated, tun driver itself
forgets about instance number it was linked...so it is no longer usable.

Note, It is tunclose() of tun driver which performs unlink when openconect
daemon is terminated.(even it was terminated abnormally)

(*1) control stream: corresponds to socket which sent TUNNEWPPA ioctl command.
(*2) protocol stream: corresponds to socket which sent I_PLINK ioctl command.
(*3) Physical Point of Attachment. almost same as instance number.

I've modified tuntap driver to enable it to remember instance number, and
also created a patch for openconect and enabled it to proceed even if instance
already exists.

I attached a patch to this email, and modified tuntap driver is here:
  https://github.com/kaizawa/tuntap/zipball/enable_reopen

It is really experimental code.
And I'm not sure if it works as expected since I have no longer
access to anyconnect server.
Honestly, I hesitate to modify implementation of tuntap driver like this...

>
> 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?

You can remove existing interface using new tunctl command.
And I think you can implement same logic to openconnect daemon to
remove existing interface if it exists.
If you want me to do, I can write a patch.

Otherwise it would also be good to use I_LINK command, so that instance
will automatically removed even daemon process is terminated abnormally.

Thanks,

Kazuyoshi

>
>> 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: tun.c.patch.enable_reopen
Type: application/octet-stream
Size: 1707 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20111204/cde41f83/attachment.obj>