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>
