Followup: OpenConnect unusably slow

Thomas Richter richter at
Wed Jun 19 11:23:37 EDT 2013

Hi David,

> On Tue, 2013-06-18 at 11:25 +0200, Thomas Richter wrote:
>> Which is really strange, because the MTU size of the real network is normal:
> It could be done at any point between you and the server. It could even
> be that the server is sending them that way to start with.
> There are a lot of stupid people out there who like to filter ICMP, and
> don't realise that ICMP is *required* for your network to function. If
> you filter it, things start breaking — in particular, if you send a
> packet which is too large for some downstream link to accommodate it,
> you'll never get the notification and never *know* that you need to send
> smaller packets.

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 

> 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.

However, why did this work before, and - probably more important - how I 
can make it work with the network manager? Using a manual openconnect 
script to log in might do fine for a while, but I would prefer a better 
integration into the network manager. Is this a possibility? Is there 
possibly a script the network manager calls to run openconnect, so I can 
fiddle in the MTU there? Or is this hard-wired?

>> Besides, wouldn't this show up also without openconnect? Network
>> connectivity is fine without openconnect, so what's specific to
>> openconnect that this problem is only happening if it is enabled? Is it
>> because it is UDP for DTLS?
> It should also show up without openconnect. It's *vaguely* possible that
> some router is prioritising TCP over UDP traffic so you don't notice it
> for TCP. But I don't see why that would happen only to upgraded
> machines.

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

So long,

More information about the openconnect-devel mailing list