On 02.04.2014 18:17, David Woodhouse wrote: > 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. That was my first idea too :-) > >> >>>> 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? Yes they would be split into one larger and a smaller chunk. > Does that misbehaviour *also* persist with 3.13? In 3.13 that looks entirely different. Here I get nice huge frames (chopped up by the NIC with segmentation offload) 18:31:10.798668 IP SSL-local.40251 > SSL-remote.https: Flags [.], seq 2471220:2475508, ack 84847, win 65535, length 4288 > 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. OK, nice!
