How to specify the MTU of ocserv adapters

[Yick Xie]

Hello,

I just read a piece of blog about strongswan's MTU
issue(https://strongswan.net/blog/how-to-resolve-mtu-issue-with-ipsec-tunnel/).
Do you think ip_no_pmtu_disc could be a work-around for dynamic MTU?
During the daily use of AnyConnect, in many cases the client just
discarded the UDP tunnel or even lost the TCP one, especially when
roaming, and that must be related to MTU. As ipv4 in Asia is pretty
expensive, NAT is more and more popular for many ISPs, this is to say
icmp has been largely blocked by mistake or purpose, making pmtu
obsolete. My idea is for TCP the ocserv can utilize MSS clamping to
determine the interface MTU and do not frequently change it; secondly
just let UDP go with fragments even if it changes a lot from time to
time, technically within certain kind of lose in performance, because
UDP's MTU is undetectable. In this way, we don't need to care more
about whether/how the interface MTU is changed, which could just be
adjust properly (or a configurable timer parameter) relying on MSS. I
think it could be more stable than dynamic MTU determination. Were it
feasible, can we put it into experimental feature in future?

Regards,
Yick

2016-05-11 16:18 GMT+08:00 David Woodhouse <dwmw2 at infradead.org>:
> On Wed, 2016-05-11 at 09:23 +0200, Nikos Mavrogiannopoulos wrote:
>> On Tue, May 10, 2016 at 7:53 PM, Yick Xie <yick.xie at gmail.com> wrote:
>> > Hello,
>> > As the title indicated, ocserv just dynamically and frequently adjust
>> > the MTU value of virtual adapters according to peer-endings, which
>> > sometimes even was set to 576. But actually the network is still
>> > stable, only with certain kind of packet loss, yet totally acceptable.
>>
>> That's a nice observation. I've reviewed the code, and as it is now,
>> the MTU is being lowered when the kernel thinks that the MTU is too
>> big (typically when some router sends an ICMP notification for that).
>> However there is only logic to account lowering the MTU, but not
>> raising it when the user's connection is no longer bounded. That is
>> most likely you see clients (probably on mobile networks) drop to 576
>> and never increase their MTU.
>
> Note also that when it goes below 1280 you lose IPv6 connectivity. If
> you really have got an MTU that low on a tunnel with IPv6 configured,
> then perhaps we should either give up and *allow* fragmentation (over a
> Legacy IP network), or fall back to sending (the larger frames?) over
> the TCP connection?
>
> --
> dwmw2
>