On Thu, 2014-04-03 at 10:10 +0200, Ortwin Gl?ck wrote: > > 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 :-) OK, thanks. Time to resort to bisecting then, I suppose. But let's blame Eric preemptively anyway... and perhaps manually start your bisection right at commit f54b31114 :) > > > >> > >>>> 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 Eric, any ideas on that one? This one is on the public-side network between VPN client and server. (The other misbehaviour discussed above with the 200ms delays was on traffic *inside* the VPN, going out through the tun0 device. Which gets turned into these packets which are misbehaving differently.) Ortwin: is TSO definitely still enabled in 3.14? What NIC? -- 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/20140403/78e240ee/attachment-0001.bin>
