On Thu, 2019-03-21 at 00:13 +0000, Phillips, Tony wrote: > More info. One of my coworkers and I did some more diagnostics this > afternoon: > > He used iperf3 to do some generic benchmarking today, and we poked > around in some tcpdumps taken during 1MB iperf pushes. > > When sending TCP traffic from the open connect client VM to the > target (an ordinary RHEL VM, recall that the VPN is terminated on a > hardware Palo Alto along the way) we observe an average of about > 2.7MB/sec with around 10% of packets getting retransmitted according > to both iperf and netstat -s. The first packet that gets > retransmitted after the TCP socket is opened has relative sequence > number 4142 consistently... as in every time we tried (at least four > separate runs during an hour or so). > > When going in the other direction, we get 36MB/sec with about 0.3% of > packets getting retransmitted. We didn’t do as much poking in these > dumps these since they performed 10x-15x faster, but I would hazard a > bet that in these cases, it’s the ACKs that are getting lost dropped. > > This definitely hints (if not shouts) at a send buffer overflow on > the VPN side. > > So, your observation below references adjusting TUNSETSNDBUF. Can > you give me a quick how-to to do this, and what changes would be > “sane?’
It'd look something like this:
--- a/tun.c
+++ b/tun.c
@@ -222,7 +222,7 @@ intptr_t os_setup_tun(struct openconnect_info *vpninfo)
{
int tun_fd = -1;
struct ifreq ifr;
- int tunerr;
+ int tunerr, sndbuf;
tun_fd = open("/dev/net/tun", O_RDWR);
if (tun_fd < 0) {
@@ -262,6 +262,15 @@ intptr_t os_setup_tun(struct openconnect_info *vpninfo)
}
if (!vpninfo->ifname)
vpninfo->ifname = strdup(ifr.ifr_name);
+ sndbuf=3;
+ if (!ioctl(tun_fd, TUNGETSNDBUF, &sndbuf)) {
+ printf("sndbuf %d\n", sndbuf);
+ //sndbuf <<= 1;
+ sndbuf=131072;
+ ioctl(tun_fd, TUNSETSNDBUF, &sndbuf);
+ ioctl(tun_fd, TUNGETSNDBUF, &sndbuf);
+ printf("sndbuf %d\n", sndbuf);
+ }
/* Ancient vpnc-scripts might not get this right */
set_tun_mtu(vpninfo);
But I don't think that's it; it's set to INT_MAX by default and can't be
increased.
If it *was* that, wouldn't that show up as dropped packets on the tun interface?
Perhaps it's on the other side, as OpenConnect sends UDP packets. Let's
take a look at the loop in dtls_mainloop() in dtls.c.
Firstly, it's looping over *all* incoming packets before it tries to
send any. Perhaps we should make it fairer. Also, can you make it print
a message in the 'Wake me up when it becomes writeable' code path, to
see if that's happening?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/openconnect-devel
