fields to set MTU and MSS missing

network-manager does not even allow you to set MTU for other connections (which could also be helpful on wired connections, e.g. behind ADSL links). Maybe a generic solution could be found? (Although I don't see currently how one could unite link settings like this for the different VPN daemons with the current architecture.)

Finding a generic solution would be ideal, but given how both VPN back-ends supported by network-manager already operate in vastly different ways, I don't see how this could be done. Besides, I was only talking about being able to configure every variable supported by OpenVPN via the GUI plug-in for the applet, instead of only being able to configure a specific few.

fixed in NM 0.7

i'm using nm 0.7 in intrepid, but i'm still not able to set mtu (or i'm not able to find how to do this)

i mean that it i spossible now to set the mtu for the fisical connections (ethx), but this is not true for vpn connections.
normal lan and internet connections work better at default mtu, and i don't think is a good idea force all traffic to a different mtu.

Alexander, I concur with Max. Where exactly in NM 0.7 from Intrepid is it possible to set MTU/MSS and other arbitrary parameters supported by OpenVPN for the VPN connections? Or did you mean that it is fixed upstream in some version that will appear starting with Jaunty?

why not use the advanced ... ip4settings for the vpn connection in connection editor?

sorry. yeah. please file this missing openvpn feature bug in bugzilla.gnome.org then.

sorry. please use the new bug 258743

Because it doesn't include the possibility to set such parameters.
OpenVPN itself already allows setting such values by manually editing
the configuration file. The problem here is that the NM plug-in for
OpenVPN doesn't even support half of the parameters that OpenVPN
itself offers.

On Mon, Nov 3, 2008 at 12:29 PM, Alexander Sack <email address hidden> wrote:
> why not use the advanced ... ip4settings for the vpn connection in
> connection editor?
>
> ** Changed in: network-manager (Ubuntu)
> Status: Confirmed => Fix Released
>
> --
> fields to set MTU and MSS missing
> https://bugs.launchpad.net/bugs/112248
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "network-manager" source package in Ubuntu: Fix Released
> Status in "network-manager-openvpn" source package in Ubuntu: Invalid
> Status in "network-manager" source package in Baltix: Invalid
>
> Bug description:
> The configuration menu for n-m-openvpn lacks the possibility to setup arbitrary functions recognized by OpenVPN, in my case, non-default MTU and MSS values for the connection, which are necessary to interact with some commercial OS' defaults in a corporate setting.
>

--
Best Regards,
Martin-Éric

Why did you mark this bug as invalid? OpenVPN offers those
parameters. The NM plug-in for OpenVPN is the problem here. This bug
was correctly filed.

On Mon, Nov 3, 2008 at 12:44 PM, Alexander Sack <email address hidden> wrote:
> sorry. please use the new bug 258743
>
> ** Changed in: network-manager-openvpn (Ubuntu)
> Status: Triaged => Invalid
>
> --
> fields to set MTU and MSS missing
> https://bugs.launchpad.net/bugs/112248
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "network-manager" source package in Ubuntu: Fix Released
> Status in "network-manager-openvpn" source package in Ubuntu: Invalid
> Status in "network-manager" source package in Baltix: Invalid
>
> Bug description:
> The configuration menu for n-m-openvpn lacks the possibility to setup arbitrary functions recognized by OpenVPN, in my case, non-default MTU and MSS values for the connection, which are necessary to interact with some commercial OS' defaults in a corporate setting.
>

--
Best Regards,
Martin-Éric

upon special request reopening the -openvpn stuff.

added -pptp because of duplicate bug 112248

i guess -vpn is affected too then.

Why is this a wishlist item? At least for network-manager-pptp, this seems to be a regression from hardy, i.e. the GUI configuration dialog under hardy provided the option of setting a custom MTU for PPTP connections. (The fact that this setting was subsequently ignored is a different issue, namely #258743.

@comment 5:

Thats really bad.
I need to force mtu to be at least maximum of 1440, because behind the tunnel some packets leaving ipsec tunnel (so additional ip header size is added) and connection fails.
Setting mtu is a feature which really shoulw be possible in the interface definition.
At least - why theres no advanced tap where the real "openvpn client config file" can be specified and that one is used instead of the normal interface?

From another bug report which is supposed to be a duplicate:

The network manger plugin for vpnc connections has the mtu (maximum transmission unit) size hard coded in its sources. If one connects to a vpnc concentrator with a mtu size lower than the one used by the plugin (1412) the concentrator rejects all packages above this (its own) size.
One can only change the mtu size via "ifconfig tun0 mtu 1234" or by recompiling the plugin with another mtu size. As it is possible to configure this value while using vpnc directly it should be possible within the plugin too.

The mtu size is coded in "network-manager-vpnc-<VERSION>/src/nm-vpnc-service-vpnc-helper.c" in line 371.

This bug affects all ubuntu versions (8.04 - 9.04). The source code passage mentioned above is not valid for 8.04.

Interestingly, my first glance at the code of the Cisco VPN client for Linux seems to indicate that it would always default at using a MTU of 1300, since it needs to account for the worst case scenario of IP, UDP, and ESP headers that take part of the encapsulation, plus whatever else may be introduced by the added encapsulation that could come from a PPPoE connection. Not sure if it's doing the same thing for Windows or actively testing for a usable MTU value.

Setting the MTU has been important for many users to get their internet connection fully functional. See for example
linkedin very slow on Firefox Linux only
https://bugs.launchpad.net/bugs/314713

This is a mainstram issue IMHO

Hello,

i had the same problem, as our openvpn-server needs the following configuration parameters to be set in the client:

tun-mtu 1500
fragment 1300
mssfix

thus, i added an additional 'Fragmentation'-tab to the advanced configuration dialog for connection, where those options can be set. Importing the options from config files is also supported. The patch is based on the karmic package. In the attached README file there is short description on how to build a new patched deb package.

Hello,

i had the same problem, as our openvpn-server needs the following configuration parameters to be set in the client:

tun-mtu 1500
fragment 1300
mssfix

thus, i added an additional 'Fragmentation'-tab to the advanced configuration dialog for connection, where those options can be set. Importing the options from config files is also supported. The patch is based on the karmic package. In the attached README file there is short description on how to build a new patched deb package.

excuse the double post, launchpad seems to be under heavy load right now, anyway here is the README (i thought i could attach 2 files).

Steps to build patched network-manager-openvpn deb package for karmic.

create new directory and put fragmenation_options.patch in there.

apt-get install build-essential
apt-get build-dep network-manager-openvpn
apt-get source network-manager-openvpn
dpkg-source -x network-manager-openvpn_0.8~a~git.20091008t123607.7c184a9-0ubuntu1.dsc
patch -p0 < fragmentation_options.patch
cd network-manager-openvpn-0.8~a~git.20091008t123607.7c184a9-0ubuntu1
fakeroot debian/rules binary

mkulke 2010/02/04

Magnus,

Thanks for the patch! Unfortunately, this issue is still being discussed upstream (see https://bugzilla.gnome.org/show_bug.cgi?id=603575). I'd go on that aspect with the reporter for that bug and say that the best in all cases is to calculate an MTU (and MSS) from the route to the gateway, unless there is a value specified by the server. A pretty generic solution would be best as well, since this doesn't only affect the openvpn plugin.

Unless you have a reason to believe it really should be available anyway? I just think it's something that would be best to have as automated as possible and not subject users to wondering "what is this fragmentation thing? what do I set there?"

In any case, please do post your patch (cleaned up to exclude the changelog parts) on the above bug if possible, just in case :)

Hello Mathieu,

the options i added are merely arguments for the openvpn client (--mssfix). there is currently no way to query an openvpn-server for those options (it's on the openvpn wishlist, tho). while it seems plausible, that the mtu value could be calculated and applied to a running openvpn session, like described in that gnome bugreport, i don't think this can be done for the --fragment and the --mssfix option. I agree that crowding the dialog with options is not a good idea in general (altho it is in the advanced dialog, where options reside of which most ppl probably have no idea what they are about), maybe one could get rid of the tun-mtu option (as this functionality seems to be in network-manager yet) or add a generic lineedit to the dialog, in which users can put custom arguments ("--mssfix --tun-mtu 1500 --fragment 1300") which are then appended to the client call.

the gnome bugreport is about the vpnc-plugin, i don't think it makes sense posting the patch there, but i posted it to the nm mailinglist.

Am Feb 4, 2010 um 4:34 PM schrieb Mathieu Trudel:

> Magnus,
>
> Thanks for the patch! Unfortunately, this issue is still being discussed
> upstream (see https://bugzilla.gnome.org/show_bug.cgi?id=603575). I'd go
> on that aspect with the reporter for that bug and say that the best in
> all cases is to calculate an MTU (and MSS) from the route to the
> gateway, unless there is a value specified by the server. A pretty
> generic solution would be best as well, since this doesn't only affect
> the openvpn plugin.
>
> Unless you have a reason to believe it really should be available
> anyway? I just think it's something that would be best to have as
> automated as possible and not subject users to wondering "what is this
> fragmentation thing? what do I set there?"
>
> In any case, please do post your patch (cleaned up to exclude the
> changelog parts) on the above bug if possible, just in case :)
>
> ** Bug watch added: GNOME Bug Tracker #603575
> https://bugzilla.gnome.org/show_bug.cgi?id=603575
>
> --
> fields to set MTU and MSS missing
> https://bugs.launchpad.net/bugs/112248
> You received this bug notification because you are a direct subscriber
> of the bug.

i mixed up the version string, so that deb packages built with the patch will be overwritten with the stock deb package. here's a fixed patch:

sudo apt-get install build-essential
sudo apt-get build-dep network-manager-openvpn
apt-get source network-manager-openvpn
dpkg-source -x network-manager-openvpn_0.8~a~git.20091008t123607.7c184a9-0ubuntu1.dsc
patch -p0 < fragmentation_options.patch
cd network-manager-openvpn-0.8~a~git.20091008t123607.7c184a9
fakeroot debian/rules binary

obviously the patch has not been shipped with lucid, the problem is still there. thus i had to assemble a new patch for lucid.

sudo apt-get install build-essential
sudo apt-get build-dep network-manager-openvpn
apt-get source network-manager-openvpn
dpkg -x source network-manager-openvpn_0.8-*.dsc
patch -p0 < fragmentation_options_lucid.patch
cd network-manager-openvpn-0.8
fakeroot debian/rules binary

Magnus: have you tried submitting your patch to upstream?

@Martin-Éric

yup, they said it won't be included in v0.8, because lucid was in in string-freeze yet or something. i checked out the current git sources a few days ago and could not find it, tho.

Magnus: I really don't know what upstream is talking about. Upstreams release whenever they damn well please; it is up to distros to adapt. Perhaps now would be a good time to contact upstream again and attach your patch to the upstream bug?

quote: "Looks pretty good; but I can't commit until we push out 0.8 or the
Ubuntu guys will kill me for adding new translatable strings..."

I'll refrain from commenting on what you quoted. However, I'll reiterate that now is good time to prod upstream to make the commit. :)

Hi Magnus,

Thanks for providing the patch - hopefully it will be accepted upstream for 10.04LTS.
I've installed it manually using the instructions you provided and installed the updated network-manager-openvpn package.
Unfortunately it doesn't work (I checked Use custom fragment size (1300) and Enable mssfix).

syslog:

Oct 7 11:20:46 l1 NetworkManager: <WARN> nm_vpn_connection_connect_cb(): VPN connection 'omiha' failed to connect: 'property 'fragment-size' invalid or not supported'.

Any suggestions?

Jan

HI all,

Another suggestion I'd like to make is to have the ability to use a OpenVPN config file (ie. the GUI would allow you to specify a config file).

Assuming it will take some effort to create a GUI for all the possible OpenVPN options, it would be very helpful if network-manager-openvpn would be able to parse a OpenVPN config file and simply add the options not already generated by network-manager-openvpn itself to the commandline options for OpenVPN in the meantime.