questions on MTU

[David Woodhouse]

On Sun, 2013-06-02 at 11:00 +0200, Nikos Mavrogiannopoulos wrote:
> Hello,
>  I have some issues with MTU on a particular link and I am trying to
> figure out MTU handling in openconnect. It seems openconnect sends to
> the server the MTU value of the link (as seen from calculate_mtu()) and
> then it sets as vpninfo->actual_mtu the value that was received by the
> server.

That's my understanding of the protocol, yes.

Remember, a *lot* of Cisco "admins" are stupid enough to block ICMP, so
pMTU discovery is often broken around Cisco kit. There's a lot of
ugliness here to try to work around that brain-damage, I think.

There is some discussion of this in the comments preceding the
calculate_mtu() function in cstp.c. Let's ignore the "old protocol" for
now and concentrate on the new one...

We *attempt* to tell the server the MTU of the external link between us
and it. And then the server removes the protocol overheads and gives us
back *separate* MTU values for CSTP and DTLS. It's not clear how we're
supposed to handle two separate MTU values on the same tun device, so we
just take the smaller of the two and store that as 'actual_mtu'. That
one is the MTU for the tunnel device.

And then, having been given that value by the server, all we do is try
to ensure that GnuTLS is going to *let* us send packets which are at
least that large. That's what the gnutls_dtls_set_data_mtu() call is
for; just to stop GnuTLS from telling us that a packet is too big.

The interesting part of this whole thing is in calculate_mtu(). The code
you patched is really not doing a lot at all. By that point it just
needs to be big *enough* for the value that has already been negotiated.

-- 
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/20130607/dcfc862a/attachment.bin>