Followup: OpenConnect unusably slow

[David Woodhouse]

On Wed, 2013-06-19 at 17:23 +0200, Thomas Richter wrote:
> If this is of any help: This is a DSL line by the German Telekom, which 
> is up to my knowledge PPPoe between my router and their system. But what 
> the MTU is, or whether MTU actually applies to this technology I do not 
> know.

Your MTU is likely to be 1492. There's 8 bytes of overhead for the PPP
part of PPPoE, which we subtract from the normal Ethernet MTU of 1500.

I note that then you are missing the incoming DTLS packets, you are
*actually* receiving one fragment out of the pair. This is often a
symptom of a poor network connection or driver. What's "special" about
fragmented packets (if they're fragmented locally) is that they are sent
in *quick* succession, really closely together. And often the second one
is lost.

However, in your case in the problematic period I'm looking at
(07:36:52) you are receiving the *second* fragment out of each packet
(offset 744 onwards), not the first. Which is really weird. That's
almost as if some firewall kicked in and started rejecting the start of
those packets (which contains the UDP port number etc.) but still had to
allow the fragments because it didn't know whether it could drop them.
Or something weird like that.

Can you get a packet capture from the public-facing side of your home
network, on the outbound interface of your DSL router? Or as far
"upstream" as you can, preferably on the outside of your NAT?

It would be interesting to get a packet capture from a router at the VPN
server end if you can, too. We'd check that they really are *sending*
the offending packets, and whether they're receiving any ICMP responses.

> > It's entirely possible that some complete retard would respond to this
> > breakage by deciding to fragment *all* outbound packets to a maximum of
> > 750 bytes, instead of fixing the broken firewall.
> >
> > It isn't necessarily related to your local network at all. It *might*
> > have been doing that before, on your working system. It probably was.
> 
> Anyhow, I kept playing a bit, and set the MTU to 700 manually in a test 
> script. Result is that network connectivity becomes normal. So indeed, 
> packet segmentation *is* the source of the evil.

How precise is that? Does 700 work and 701 fail with missing packets?
I'd have thought it would be higher.

> However, why did this work before, 

I don't know. Can you make one of your machines fail again by
downgrading (perhaps just openconnect and openssl) to what you had
before? Even if you just install the old openconnect and relevant
libraries in a chroot? It would be very interesting to compare.

> and - probably more important - how I  can make it work with the network manager?

Simple answer:
 mv /usr/sbin/openconnect /usr/sbin/openconnect.real
 cat >> /usr/sbin/openconnect <<EOF
 #!/bin/sh
 exec $0.real --mtu=700 "$@"
 EOF
 chmod +x /usr/sbin/openconnect

Ideally, we should add an option to the NetworkManager config properly,
for this and --no-dtls. And/or maybe just an arbitrary 'passthrough' of
manually-entered options to add to the openconnect command line.

> Neither do I. Did openconnect possibly adjust the MTU dynamically in 
> earlier releases?

No. ISTR your "upgraded" machines are still on the pathetically ancient
3.20 release; I dread to think what you were using before that. Perhaps
it was *so* old that it didn't do DTLS at all?

Newer versions will attempt to do some slightly more complex MTU
negotiation with the server (if the server is new enough to support
that), but it's all a bit hit-and-miss. The Cisco scheme for doing this
is very unreliable, and made even more so because we're not sure we
fully understand it. I'd certainly suggest trying 5.01 and seeing what
happens with it.

When you're on the university network and things are working, do you
*still* see these weirdly fragmented packets?

Alternatively, if you're at home and you do something else to trigger
incoming UDP packets from elsewhere, are *they* weirdly fragmented and
sometimes missing?

-- 
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/20130619/a117a330/attachment.bin>