pMTU discovery

[David Woodhouse]

On Thu, 2012-05-31 at 11:44 +0200, Bernhard Schmidt wrote:
> a) I'm assuming the ASA is calculating this from the Base-MTU, which
> is a field openconnect is not sending. We haven't tried this on 
> MTU-challenged paths yet, is AnyConnect just guessing or actively 
> measuring this?

Maybe getting it from getsockopt(TCP_MAXSEG)? Although it's the IP MTU
that it's sending, not the MSS, so maybe not.

In fact, the server should do pMTU discovery for *itself* rather than
asking the client to do it. But unfortunately these servers are often
deployed by strange people who like to block all incoming ICMP. So it
looks like they're doing things backwards in order to cope.

> b) Does anyone have more details? Might sending Base-MTU additionally
> be enough? 

Yeah, probably. I think we *should* be using TCP_MAXSEG. Try getting it
with getsockopt(), adding the header overheads to adjusting it so that
in the normal case it comes out as 1500, and sending it.


What *exactly* are the "MTU problems on the link" that you have when you
don't get this right? Are they on CSTP or DTLS packets, or both? In
which direction? And what happens to the offending packets? Is the
server sending DTLS packets with the DF bit set?

Or is your problem *internal*, and the problem is actually that the MTU
of the VPN becomes smaller with openconnect. And you have *internal*
firewalls that block ICMP and break your network?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120531/3393914f/attachment.bin>