On Thu, May 11, 2017 at 9:27 AM, Nikolay Martynov <mar.kolya at gmail.com> wrote: > 2017-05-11 12:20 GMT-04:00 Daniel Lenski <dlenski at gmail.com>: >> Yeah, that's really my only concern here. It might be safer simply to >> pass through packets which are larger than the negotiated or estimated >> MTU, as long as they're otherwise well-formed. I am not sure, however, >> if this could impede MTU detection by higher levels of the protocol >> stack. >> >> What happens if you keep only this part of your patch but don't drop >> the packets? > > I'd have to test this and get back to you. > But I guess I will have similar question for you here: in your > setups and your code base when MTU is not known - how is it currently > handled? 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. 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.) > I kind of feel that in situation when MTU is not known better/safer > approach is to just setup interface with MTU equal to largest possible > MTU - to some definition of 'largest'. I would agree with your approach 100%, if I hadn't been working on supporting a VPN protocol which provides absolutely no way to negotiate the MTU or even figure out a reasonable "largest." > But I'm by no means an expert here, so I'm just asking :). 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). Dan
