On 2015-10-21 12:52, Daniel Wagner wrote:
> On 10/21/2015 12:45 PM, Sven Schwedas wrote:
>> On 2015-10-21 12:30, Daniel Wagner wrote:
>>> On 10/21/2015 12:25 PM, Patrik Flykt wrote:
>>>> On Wed, 2015-10-21 at 12:12 +0200, Daniel Wagner wrote:
>>>>
>>>>> The use of the different MTU options depend on you server and link
>>>>> configuration. I don't think you can derive it. OpenVPN seems to offer
>>>>> an option to learn the MTU size by doing some measurements but that
>>>>> takes around 3 minutes according documentation. I recommend to just
>>>>> expose those options and let the user decide what he needs.
>>>>
>>>> Well, now the problem is that I have no idea what to add as MTU values
>>>> if I need to... Sven's "documented" problem and solution was to use
>>>> --tun-mtu, if that is the max sized packet that can go through
>>>> unfragmented it looks like the only option one should specify. And
>>>> --fragment seems to be needed always in addition to any of the MTUs?
>>>> Unless it's the default behavior?
>>>
>>> I don't know if there is a sane MTU configuration setting for OpenVPN. I
>>> reread the documentation several times and it seems you need to pick the
>>> options according your configuration.
>>
>> Yeah. Those values are left alone for the large majority of deployments
>> and I've only seen them used to deal with wonky carriers in WWAN
>> deployments.
>>
>> Personally, I'd be fine with using the OpenVPN.ConfigFile parameter for
>> the few cases I end up needing it. (And I'm not even sure whether we're
>> going to migrate to connman.)
> 
> Good point. I completely forgot about ConfigFile. So
> 
>       OpenVPN.MTU <n>
> 
> should map to
> 
>       --tun-mtu <n> --fragment
> 
> ?

I'll admit I don't understand OpenVPN enough to answer that. I know that
we're not specifying it, I was under the impression that the Kernel
network stack fragments itself with tun-mtu set, and that --fragment was
to bypass that for… reasons.

IMO one more reason to leave it out of the connman plugin and defer that
to the config file, lest people start tinkering with it without needing to.

-- 
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167
http://software.tao.at
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Reply via email to