Le 07/30/14 11:37, Gert Doering a écrit : >> Although I didn't try all MTU-related options of OpenVPN, it seems to >> ignore EMSGSIZE. > > Well, handling that error will not lead anywhere, as it just tells us > "the packet got lost, because it was too big".
Maybe not such a good idea but could it somehow be translated to tun/tap interface, like returning an ICMP packet ? >> What I can say is by only adding '--mtu-disc yes' option, the MTU of the >> tun/tap interface remains 1500 and does not change automatically to anything >> else. If a packet is small enough for mtu=1500 but too big for the >> underlying network, then it's simply dropped. > > We won't change the interface MTU (because on half the platforms, we can't, > or it won't have an effect), but OpenVPN is likely to fragment internally. > So "--mtu-disc yes" would need to go along with "--fragment". I've always been dubious about the efficiency of automatic fragmentation (wherever it happens) because it would often split each big packet into 1 big (but little smaller) and 1 very small. So I would leave a way for OpenVPN users to disable IP fragmentation (probably to do MTU discovery) but not automatically enable --fragment (which would become totally useless since the MTU of the tun/tap is small enough).
