GNOME Bugzilla – Bug 344967
VPN connections overwrite any MTU set on the interface
Last modified: 2008-06-17 17:49:31 UTC
Please describe the problem: Though an mtu setting exists in the NMIP4Config structure, the VPN code in all cases overwrites the MTU on the interface to 1412 bytes. Almost all PPTP require an MTU setting of 1000 (over PPP) and hence 996 bytes on the interface. (4 bytes for PPP stuff) The hard coded setting of 1412 bytes breaks such connections. The attached patch adds the mtu setting to the VPN_IP4_CONFIG signal. If the mtu is set !=0 then the provided setting is used, otherwise the original if mtu is set to zero the 1412-byte behaviour prevails. Steps to reproduce: 1. Create a PPTP VPN connection using the PPPD tunnel plugin 2. Use the connection... Actual results: The connection will 'hang' once a certain amount of data has been sent. (ie. the interface will accept no more traffic) Expected results: Connection to keep functioning Does this happen every time? Yes. (If you have a server requiring MTU != 1412) Other information:
Created attachment 67392 [details] [review] Patch to cause the vpn system to set respect the setting of mtu in the NMIP4Config structure This patch adds an integer (mtu) to the IP4Config message recieved from the VPN plugins and includes the necessary changes for the OpenVPN, vpnc and PPTP plugins too. The behaviour is such that if the mtu is not explicitly set by a plugin then the old 1412 byte default setting is enforced.
I agree with the patch in principle; but we've pretty much frozen the VPN dbus API for 0.6.x so that we don't break stuff again like 0.6.0 -> 0.6.1 with the MSS change. So here's what I'd like to do for _both_ HEAD and 0.6.x: 1) Figure out how to use the dbus dict types, and use key/value pairs rather than specific argument ordering. Then we can match on the key (either an INT option or a string, I don't care). For 0.6.x only: 2) Recognize the old format dbus message and process that like we do now so we don't kill VPN again I took a quick look at dict stuff last week but I didn't find any good examples that weren't bindings and therefore quite obscure. Dan
Created attachment 70106 [details] [review] Minimal patch to make NetworkManagerSystem respect the IP4Config mtu setting This patch changes the core NM core that currently has the MTU hardcoded as 1492 to respect the mtu setting in the IP4Config structure. If mtu is unset (==0) then the present 1492 default is used.
Created attachment 70107 [details] [review] Patch to add a DBUS Dict IP4Config interface to the VPN subsystem This patch is backward compatible but adds a DBUS DICT ENTRY interface to the VPN plugin interface. THe first parameter of the received DBUS signal is tested and, if it is a UINT32, the 'old' message type is processed. It has been tested with old and new plugins and the correct message processing happens and the connections establish. In the latter case, with the "respect MTU" patch, changes to the MTU setting in VPN config are passed through NM to the interface correctly. There are improvements to be made and some questions to answer about the details of the interface (eg. dict entry keys - case, structure etc.) but I'd like get some feed back. I've also just linked against libnm-util... I wasn't sure if this is correct. I can commit if you are happy.
The ability to set the MTU would be a very useful feature. Often you may be behind weird network devices which have a smaller then the normal Ethernet 1500 MTU. This makes the value NM sets by default wrong. It may be an idea to be very conservative with the default MTU anyway. Setting to a value like 996 would help with these types of problems. The sooner this gets into NM the sooner I will be able to have tunnels which work.
For the VPN-config-as-dict patch... I cleaned up the spacing (real tabs, braces on following line), and also converted the option-parsing code to a macro since it's all pretty similar. I also fixed up the print_vpn_config() debug function to work for both cases (new and old), since it was broken for both anyway. You'll likely have conflicts in nm-vpn-service.c, heads up.
MTU patch is committed too
Looks like in NM 0.6.6 we have this problem again (i.e. the MTU if fixed at 1412 and not accordingly to the user settings or the setting from pppd).