Re: [Openvpn-devel] [PATCH] Fix --mtu-disc option with IPv6 transport

[Julien M. <jm...@ne...>]

Le 07/29/14 23:05, Gert Doering a écrit :
>> For example:
>>   A --[mtu=1500]-- B --[mtu=1400]-- C
>>
>> Given a UDP6 socket on A with IPV6_MTU_DISCOVER=IP_PMTUDISC_DO,
>>     sendto(1452 bytes, B) will succeed
>> but sendto(1452 bytes, C) will return EMSGSIZE (except for the first send to C)
>> Yes, at some point, there are icmp packets.
> 
> So (being lazy again, sorry) how is the maximum message size communicated
> back to OpenVPN?  Ancilliary data again?

ICMP packets contains the size and ping/ping6 even reports it (this is real example with mtu=1433 between B & C):

# ping6 -c 1 -M do -s 1452 B
PING B (...) 1452 data bytes
1460 bytes from B: icmp_seq=1 ttl=255 time=0.430 ms
# ping6 -c 1 -M do -s 1454 B
PING B(...) 1454 data bytes
From B icmp_seq=1 Packet too big: mtu=1500
# ping6 -c 1 -M do -s 1452 C
PING C(...) 1452 data bytes
From C icmp_seq=1 Packet too big: mtu=1433

On the other hand, there is an option --mtu-test that "sends ping packets of various sizes" to "empirically measure MTU" which can "take about 3 minutes". And OpenVPN is not the only software to do this kind of thing.

So maybe several ways to do MTU discovery? Well, I'm not sure. I don't know all the details yet about MTU, and how to use --mtu-test exactly in my case, but I think this will be useful.

What I've experienced is that fragmentation is bad for perf and that some routers on the internet don't route fragmented UDP packets properly, which is why I've switched to TCP-only for the moment:
  http://git.erp5.org/gitweb/re6stnet.git/commit/cd653523a1474ff9f8956a331c42235454887f65

>>> (Last not least, because I'm too lazy to look: is that patch against
>>> git master or against release/2.3?)
>>
>> master
> 
> Thanks.  I'll need to look at the code paths, but I think it warrants
> inclusion in 2.3 as well - it's not affecting anything that is IPv4, 
> and fixes a bug for IPv6.

I initially wrote it for 2.3 but rebasing on master conflicted due to 30077d1
For 2.3, proto_sa_family must be declared in socket.h and
  sock->info.af
replaced by:
  proto_sa_family(sock->info.proto)