Ad --sudo argument to allow running authentication unprivileged
Actually I'm having second thoughts about this; there are multiple better
ways to do it. Most importantly, just precreating the tun device and then
using sudo for the vpnc-script, running all of openconnect unprivileged.
This hack works, but it's a bunch of work to make it *right*. We can't
just exec `openconnect -C $COOKIE` because that exposes the cookie to
ps on the command line, so we'd need to do something more complex and
feed it to stdin. And we'd *also* need to pass through a bunch more
arguments (like --vpnc-script and anything else that affects the
connecting process).
It's also fairly trivial to do this approach in a shell script using
first `openconnect --authenticate` and then `openconnect --cookie-on-stdin`
without having to write C code for it.
Signed-off-by: David Woodhouse <email address hidden>
Some users are reporting that transfer speeds with the default queue
length of 10 packets are poor. Increasing to 32 shouldn't be causing
too much bufferbloat, and appears to resolve the issue.
There's more to be understood here; OpenConnect is in the middle of
multiple other queues for the inbound and outbound traffic paths, and
we should never be starving any of them. And for a bunch of protocols
OpenConnect isn't even honouring the queue length. For *incoming* as
a VPN client, that's probably a bad idea anyway; if packets have made
it all the way across the Internet and the wet piece of string that
connects our client, then we should make sure we accept them and don't
let them build up in the UDP socket receive buffers to the point where
the kernel drops them.
My previous testing of this was in 2008, and was focused on performance
across a local 1GbE connection, which will behave differently.
This change will enable vhost-net by default. That does also help, but
isn't the only factor. And it doesn't help much until the queue length
is higher anyway.
Signed-off-by: David Woodhouse <email address hidden>
However, many users still find suggestions to use `--interface tunX`
floating around the web, and try them. The resulting error message from
OpenConnect is somewhat confusing:
Cannot open '/dev/tunX': Invalid argument
Set up tun device failed
Perhaps we could improve the logic to precisely detect whether or not the OS
wants us to use "tun" or "utun", but that would require a contribution by
someone who understands and cares about Mac OS. In the absence of that, we
can simply add a warning to Mac OS users who attempt to use "tun", telling them
that it's probably wrong.
Signed-off-by: Daniel Lenski <email address hidden>
