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