[PATCH] fix DTLS_OVERHEAD and GlobalProtect ESP overhead calculation

[David Woodhouse]

On Tue, 2017-08-15 at 14:17 -0700, Daniel Lenski wrote:
> Aha, thanks, I'll look at dtls_get_data_mtu() and try to get this exactly right.

Thanks. I am being distracted by real work — can I leave you to
continue my initial pass over the code? Really I was just looking at
each function one at a time with fresh eyes and no context, and
concentrating on the details. Including spaces — I'm sure there are
better tools but when changing the way a variable 'foo' is handled, or
just looking for where it's set, I often do just do a trivial search
for 'foo = '. And if you ever assign to foo without the spaces, that
will directly lead to bugs ;)

> One frustrating thing about GP is that I literally have *no clue* what
> the MTU "inside" the VPN looks like.
> 
> At least one user has reported
> (https://github.com/dlenski/openconnect/issues/43) that the VPN is
> much faster when using --mtu with a value that's several times higher
> than the apparent "wire MTU." Which means that fragmenting and
> reassembling packets between the local host and the VPN gateway is
> significantly more efficient than passing the smaller packets through.

Hm, interesting. I wonder if that can be accurately described as "using
--mtu with a value that is a precise multiple of the apparent wire
MTU".

That is, if we over-estimate the MTU by just a byte so that every
packet we send turns into a sanely-sized packet followed by a tiny one-
byte packet, that does pessimise the overhead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20170816/dd3b57c3/attachment.bin>