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>
