On Wed, 2014-04-02 at 17:58 +0200, Ortwin Gl?ck wrote: > I have just noticed that this is a regression in kernel 3.14! Works fine > in 3.12 and 3.13. > > Sorry to bother you. I will bisect and speak to kernel folks. Does it go away if you echo 0 > /proc/sys/net/ipv4/tcp_autocorking > > >> No. Time Source Destination Protocol Length Info > >> 1100 0.214 tun-local tun-remote SSHv2 1280 Encrypted request packet len=1228 > >> 1101 0.000 SSL-local SSL-remote TLSv1 1126 Application Data > >> 1102 0.000 SSL-local SSL-remote TLSv1 328 Application Data > > > > A packet is 'sent' over the tun interface. OpenConnect immediately sends > > it. It takes *two* packets to send it, since your MTU inside the tunnel > > is larger than your MTU outside the tunnel. > > No matter what value I pass to --mtu I always end up with 2 packets - > just their sizes change. What do you suggest? Hm, that's odd. You pass a *much* smaller MTU value and you actually see smaller packets like 1000 bytes on the tun device? And they're *still* split into multiple packets on the wire for the public network? Does that misbehaviour *also* persist with 3.13? Btw, you mentioned the fact that OpenConnect allocates packets for each connection and copies data around. That's true only for the SSL connection; we expect to be using compression there so I don't bother with the zero-copy on that path. For DTLS the path is a lot more efficient and *shouldn't* involve data copies. We allocate a buffer in advance while we're waiting for data to arrive on the tun or dtls socket, we receive into that buffer and then send from it. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140402/83e238e6/attachment.bin>
