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?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
