In syslog after adding that patch:
starttunnel.pl[1159]: Connected as 10.248.160.29, using SSL, with ESP in progress
starttunnel.pl[1159]: Continuing in background; pid 1459
starttunnel.pl[1159]: sndbuf 2147483647
starttunnel.pl[1159]: sndbuf 131072
starttunnel.pl[1159]: ESP session established with server
starttunnel.pl[1159]: ESP tunnel connected; exiting HTTPS mainloop.
>> 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?
So I'm not much of a programmer, but what I did was add:
/* Wake me up when it becomes writeable */
monitor_write_fd(vpninfo, dtls);
+ vpn_progress(vpninfo, PRG_ERR,
+ _("Got to Wake code\n"),
+ gnutls_strerror(ret));
Hopefully that's what you mean ...
..and syslog remains quiet.
-----Original Message-----
From: David Woodhouse [mailto:dwmw2@xxxxxxxxxxxxx]
Sent: Thursday, March 21, 2019 11:45 AM
To: Phillips, Tony; Nikos Mavrogiannopoulos
Cc: openconnect-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [EXTERNAL] Re: What throughput is reasonable?
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?
_______________________________________________
openconnect-devel mailing list
openconnect-devel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/openconnect-devel
