After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 344967 - VPN connections overwrite any MTU set on the interface
VPN connections overwrite any MTU set on the interface
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2006-06-15 09:30 UTC by Antony Mee
Modified: 2008-06-17 17:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to cause the vpn system to set respect the setting of mtu in the NMIP4Config structure (8.31 KB, patch)
2006-06-15 09:51 UTC, Antony Mee
none Details | Review
Minimal patch to make NetworkManagerSystem respect the IP4Config mtu setting (1.15 KB, patch)
2006-08-03 02:51 UTC, Antony Mee
committed Details | Review
Patch to add a DBUS Dict IP4Config interface to the VPN subsystem (9.83 KB, patch)
2006-08-03 03:03 UTC, Antony Mee
committed Details | Review

Description Antony Mee 2006-06-15 09:30:18 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:
Comment 1 Antony Mee 2006-06-15 09:51:04 UTC
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.
Comment 2 Dan Williams 2006-06-15 14:22:16 UTC
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
Comment 3 Antony Mee 2006-08-03 02:51:32 UTC
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.
Comment 4 Antony Mee 2006-08-03 03:03:50 UTC
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.
Comment 5 Tim Ansell 2006-08-07 08:13:44 UTC
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.
Comment 6 Dan Williams 2006-08-07 18:29:37 UTC
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.
Comment 7 Dan Williams 2006-08-07 18:41:57 UTC
MTU patch is committed too
Comment 8 Ludovico Cavedon 2008-06-17 17:49:31 UTC
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).