On Thu, 2017-05-11 at 10:03 -0700, Daniel Lenski wrote: > On Thu, May 11, 2017 at 9:27 AM, Nikolay Martynov wrote: > In the GlobalProtect mainloop > (https://github.com/dlenski/openconnect/blob/globalprotect/gpst.c#L615) > I don't pay attention to the size of the packet at all as long as it's > well-formed. We tend to allocate receive buffers big enough for the negotiated MTU, so I hope you're paying *some* attention to how much data you're receiving :) > There is no mechanism whatsoever to request or advertise the MTU of > the HTTPS tunnel, so I don't really have another choice. (Clearly, > this is a poor design? but I didn't design it.) And it looks like Juniper is also sending 1500-byte packets after negotiating an MTU of 1400. Not negotiating is bad design. Negotiating and then violating the agreement is worse :) > I'm not either. Perhaps David Woodhouse can weigh in on why he decided > to drop the connection when Juniper packets exceed the MTU (this was > added back in a47d69d3544e8d067c08aeb82e770daf8f635348). Because it was (supposedly!) a 'can never happen' condition. If they're actually going to send larger packets then ? as long as we make bloody sure we're not going to overflow our allocations ? I suspect we're better off actually receiving them. If they made them through, why drop? And if we *are* going to drop, shouldn't we be sending ICMP back? -------------- 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/20170512/7539a92d/attachment.bin>
