NM 0.7 Fails To Set Custom MTU

Noting that this upstream bug also results in not being able to persistently set static IPs ontop of specific individual settings such as the MTU. I've nominated this for Intrepid's release.

Id like to report progress with testing this on a clean build using ISO revision 0080917.1. What happens now is that NM accepts the custom MTU (1492) and I close the GUI, then open it again, it remains correctly at 1492. However deeper inspection as per below shows NM actually hasnt done anything:

nullack@PPP:~$ sudo ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:1a:92:3f:45:48
          inet addr:192.168.10.2 Bcast:192.168.10.255 Mask:255.255.255.0
          inet6 addr: fe80::21a:92ff:fe3f:4548/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:2703 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2103 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3369748 (3.3 MB) TX bytes:268248 (268.2 KB)
          Interrupt:23 Base address:0xc800

nullack@PPP:~$

this bug had been tagged 'regression-potential', but there is no evidence given that this functionality worked correctly in network-manager as shipped with previous versions of Ubuntu. Please document this in the bug before applying the tag.

Steve the removal of the old network configuration utility in Hardy has forced the issue of needing to be able to do the same function in NM 0.7. Its therefore false to assume that its not a regression based solely on NM functionality, thanks.

With the reports of this being fixed I retested it (Apologies to Alexander I had been on holidays and was not able to look into this previously). On revision:

network-manager:
  Installed: 0.7~~svn20081004t225044-0ubuntu1
  Candidate: 0.7~~svn20081004t225044-0ubuntu1

I find that the MTU value can be changed, but again the MTU remains at the previous value as shown by a "sudo ifconfig eth0" query".i.e. Nothing actually changes. Reopening NM incorrectly shows the new MTU value even though it has not been applied. If the user reboots the MTU value gets reset to the original in NM forgetting the desired value.

This bug is not fixed.

Is this only about system-connections not being saved?

No, user specified MTU values are not being applied or saved

It seems automatic MTU settings are not being applied either. See https://bugs.launchpad.net/ubuntu/+bug/283048

I've been unable to recreate this using network-manager version 0.7~~svn20081015t224738-0ubuntu1. I set the MTU to 1492 and it shows up as 1492 via ifconfig wlan0. Additionally, the custom set MTU persisted after a reboot.

Could you test this again nullack? Thanks in advance.

Hi Brian :) Unfortunately, on the latest main repo revision 0.7~~svn20081015t224738-0ubuntu1 it is not fixed. My test process using wired ethernet was:

sudo ifconfig eth0 query returned MTU 1500
Opened up NM and observed MTU set for automatic on eth0
Edited the MTU to 1492
sudo ifconfig eth0 query returned MTU 1500
Opened up NM and observed MTU set for 1492 but again not applied

Brian I do not have a wireless NIC with which to replicate your configuration, not sure if wireless gives a different test result.

nullack@PPP:~$ sudo ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:1a:92:3f:45:48
          inet addr:192.168.10.2 Bcast:192.168.10.255 Mask:255.255.255.0
          inet6 addr: fe80::21a:92ff:fe3f:4548/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:20008 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16470 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:21499825 (21.4 MB) TX bytes:2933247 (2.9 MB)
          Interrupt:23 Base address:0xc800

Just tested this with network-manager 0.7~~svn20081018t105859-0ubuntu1. The settings do not work until you restart the network connection (understandably). After restarting the connection, ifconfig showed the custom MTU values. I haven't tested if this persists after a reboot.

 Nullack: have you restarted your connection when testing this? That could be where the problem lies.

what do you mean with restarting? Clicking on it again? Yes, thats required for sure.

added openvpn from bug 112248

added -pptp from bug 292799

Bug 112248 is not the same bug at all. 112248 is about the fact that the nm-openvpn plug-in doesn't support configuring even half of the settings possible in OpenVPN configuration files. Rather, theNM plug-in only supports configuring a small subset of what OpenVPN istself supports.

Marin, then fix the title in Bug 112248 and clean up the bug description to make that clear on a quick glance.

Martin, also consider to use the bug that is specifically for that (but -pptp): bug 278309

Alexander: By restarting I mean restarting networking, via the applet. Right clicking on it and deselecting "Enable Networking", then reselecting it.

I have tested this on Jaunty and as far as I can see user setting the MTU within NM do get applied to the network interface. Even after disable and enable networking. NM version is 0.7~~svn20081018t105859`-0ubuntu1.
lsb_release -rd
Description: Ubuntu Jaunty (development branch)
Release: 9.04

apt-cache policy network-manager
network-manager:
  Installed: 0.7~~svn20081018t105859-0ubuntu1
  Candidate: 0.7~~svn20081018t105859-0ubuntu1
  Version table:
 *** 0.7~~svn20081018t105859-0ubuntu1 0
        500 http://nl.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

What did I do:
1. Look at the MTU via "ifconfig eth0" which was 1500
2. Went to Network Connections->eth0->Edit and Customize MTU to 500
3. OK and Close
4. Disable Networking and then Enable Networking
5. Check if the MTU is still there within Network Connections->eth0->Edit
6. Check MTU with "ifconfig eth0"

I have tested this on Jaunty and as far as I can see user setting the MTU within NM do get applied to the network interface. Even after disable and enable networking. NM version is 0.7~~svn20081018t105859`-0ubuntu1.
lsb_release -rd
Description: Ubuntu Jaunty (development branch)
Release: 9.04

apt-cache policy network-manager
network-manager:
  Installed: 0.7~~svn20081018t105859-0ubuntu1
  Candidate: 0.7~~svn20081018t105859-0ubuntu1
  Version table:
 *** 0.7~~svn20081018t105859-0ubuntu1 0
        500 http://nl.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

What did I do:
1. Look at the MTU via "ifconfig eth0" which was 1500
2. Went to Network Connections->eth0->Edit and Customize MTU to 500
3. OK and Close
4. Disable Networking and then Enable Networking
5. Check if the MTU is still there within Network Connections->eth0->Edit
6. Check MTU with "ifconfig eth0"

Sorry for the double post, there was an error on the page and I did not know if I send the post already.

given the comments from Tux, I wonder if this an issue at all? Maybe it just happens when you use system-settings? Note that there might be issues with saving the system-settings still. So ensure that you really have the new MTU value in the applet after restarting your system before saying that this doesnt work.

This bug was found in the Intrepid development cycle; removing regression-potential and marking as regression-release.

This is most certainly still a defect. On Jaunty on revision:

nullack@PPP:~$ sudo apt-cache policy network-manager
network-manager:
  Installed: 0.7~~svn20081018t105859-0ubuntu2
  Candidate: 0.7~~svn20081018t105859-0ubuntu2
  Version table:
 *** 0.7~~svn20081018t105859-0ubuntu2 0
        500 http://archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

My test steps are:

1. Change automatic default mtu field population to 1492
2. Confirm the custom mtu is set
3. Reboot system

The result is always that the MTU has not retained the user preference and has reverted back to an automatic MTU value.

nullack wrote:
> This is most certainly still a defect. On Jaunty on revision:
>
> nullack@PPP:~$ sudo apt-cache policy network-manager
> network-manager:
> Installed: 0.7~~svn20081018t105859-0ubuntu2
> Candidate: 0.7~~svn20081018t105859-0ubuntu2
> Version table:
> *** 0.7~~svn20081018t105859-0ubuntu2 0
> 500 http://archive.ubuntu.com jaunty/main Packages
> 100 /var/lib/dpkg/status
>
>
> My test steps are:
>
> 1. Change automatic default mtu field population to 1492
> 2. Confirm the custom mtu is set
> 3. Reboot system
>
> The result is always that the MTU has not retained the user preference
> and has reverted back to an automatic MTU value.
>
>
Yes, can you check whether the
https://edge.launchpad.net/~network-manager/+archive PPA packages (0.7
final) or intrepid/jaunty fix this for you?

Thanks!

Hi Alexander. I note the network-manager has moved too:

nullack@PPP:~$ sudo apt-cache policy network-manager
[sudo] password for nullack:
network-manager:
  Installed: 0.7-0ubuntu1
  Candidate: 0.7-0ubuntu1
  Version table:
 *** 0.7-0ubuntu1 0
        500 http://archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

So I tried to give it a test but now it seems the security has changed. When I try to edit the auto eth0 link the settings are disabled and there is no unlock facility. I need someone to instruct me how to command line it or in some other way get around the security problem please.

It seems that other bugs are preventing me from being able to rest this:

PolicyKit Implicit and Explicit Authorisations Not Being Applied : 328921

Wrong Network Manager Security Defaults : 328928

nullack: can you please re-test this on jaunty? I tried to reproduce it as part of attempting to reproduce bug 328921 and it looks like both that bug and this one have been addressed (as of daily cd builds 20090305.1), but it'd be great if you could confirm. Thanks!

Steve I'm delighted to say its fixed :) Goodness

Have the same thing in 9.10 :(
In Windows I have about 15mbits through pptp, and in ubuntu - only 3
syslog is spammed by:
Nov 19 23:44:16 invader pptp[5965]: nm-pptp-service-5591 log[decaps_gre:pptp_gre.c:414]: buffering packet 11148 (expecting 11142, lost or reordered)
Nov 19 23:44:16 invader pptp[5965]: nm-pptp-service-5591 log[decaps_gre:pptp_gre.c:414]: buffering packet 11149 (expecting 11142, lost or reordered)
Nov 19 23:44:16 invader pptp[5965]: nm-pptp-service-5591 log[decaps_gre:pptp_gre.c:414]: buffering packet 11150 (expecting 11142, lost or reordered)

I set MTU 1416, 1500, 1300, 1400 and even 150 with "sudo ifconfig ppp0 mtu ****" - no affect

I have this too. But when I tried to make connection with kvpnc, the trouble does not disappeared. Change MTU to 1300-1416 does not change anything. --nobuffer option doesn't help. Maybe it's a pptp problem?..

Have the same problem with buffering packet lost or reordering. PPTP does'nt work properly. Ubuntu 9.10

I'm wondering if this is a pptp problem as well. Changing the MTU has no effect on the (breathtakingly miserable) performance on my system (Jaunty amd64, running the NM package in PPA).

I also have the exact same problem in Ubuntu 9.10. The log gets filled with error messages and it seems some of the packets are lost (chat messages never reaching their destination sometimes).

Apr 9 17:25:47 hackbox pptp[2574]: nm-pptp-service-2541 log[decaps_gre:pptp_gre.c:414]: buffering packet 11808 (expecting 11807, lost or reordered)
Apr 9 17:25:53 hackbox pptp[2574]: nm-pptp-service-2541 log[decaps_gre:pptp_gre.c:414]: buffering packet 11860 (expecting 11859, lost or reordered)
Apr 9 17:25:54 hackbox pptp[2574]: nm-pptp-service-2541 log[decaps_gre:pptp_gre.c:414]: buffering packet 11864 (expecting 11863, lost or reordered)
Apr 9 17:25:58 hackbox pptp[2574]: nm-pptp-service-2541 log[decaps_gre:pptp_gre.c:414]: buffering packet 12023 (expecting 12022, lost or reordered)
Apr 9 17:26:12 hackbox pptp[2574]: nm-pptp-service-2541 log[decaps_gre:pptp_gre.c:414]: buffering packet 12261 (expecting 12260, lost or reordered)
Apr 9 17:26:13 hackbox pptp[2574]: nm-pptp-service-2541 log[decaps_gre:pptp_gre.c:414]: buffering packet 12364 (expecting 12363, lost or reordered)
Apr 9 17:26:13 hackbox pptp[2574]: nm-pptp-service-2541 log[decaps_gre:pptp_gre.c:414]: buffering packet 12365 (expecting 12363, lost or reordered)
Apr 9 17:26:13 hackbox pptp[2574]: nm-pptp-service-2541 log[decaps_gre:pptp_gre.c:414]: buffering packet 12368 (expecting 12366, lost or reordered)

A friend who is running Debian does not have this problem. His packet version of pptp-linux is 1.7.2-4 while the ubuntu version is still on 1.7.2-3. Perhaps this will get fixed when ubuntu updates it, or it works for him because of different hardware etc.

Ignore the above. My friend also gets it if downloading files with 1 MB/sec.

I installed the 1.7-2-4 package manually and it did decrease the number of dropped packets, but did not solve it.

This is a major issue for me on karmic. My VPN connection is extremely unreliable.

This is a MAJOR issue for me on Lucid. I think the above poster's unreliability comes from this:
da@brutus:/var/log$ cat syslog | grep segfault | tail
May 13 11:51:03 brutus kernel: [ 6065.990972] pptpcm[9530]: segfault at bf892d84 ip 0804d5da sp bf8417f0 error 4 in pptp[8048000+e000]
May 13 11:53:01 brutus kernel: [ 6183.604214] pptpcm[10915]: segfault at bffef534 ip 0804d5da sp bff797a0 error 4 in pptp[8048000+e000]
May 13 11:53:03 brutus kernel: [ 6185.997291] pptpcm[10962]: segfault at bf892d84 ip 0804d5da sp bf8417f0 error 4 in pptp[8048000+e000]
May 13 11:53:11 brutus kernel: [ 6194.081491] pptpcm[11056]: segfault at bfc0bea4 ip 0804d5da sp bfa1ff10 error 4 in pptp[8048000+e000]
May 13 11:55:01 brutus kernel: [ 6303.611177] pptpcm[12333]: segfault at bffef534 ip 0804d5da sp bff797a0 error 4 in pptp[8048000+e000]
May 13 11:55:03 brutus kernel: [ 6306.004082] pptpcm[12370]: segfault at bf892d84 ip 0804d5da sp bf8417f0 error 4 in pptp[8048000+e000]
May 13 11:55:11 brutus kernel: [ 6314.087565] pptpcm[12456]: segfault at bfc0bea4 ip 0804d5da sp bfa1ff10 error 4 in pptp[8048000+e000]
May 13 11:57:01 brutus kernel: [ 6423.617406] pptpcm[13743]: segfault at bffef534 ip 0804d5da sp bff797a0 error 4 in pptp[8048000+e000]
May 13 11:57:03 brutus kernel: [ 6426.010406] pptpcm[13772]: segfault at bf892d84 ip 0804d5da sp bf8417f0 error 4 in pptp[8048000+e000]
May 13 11:57:11 brutus kernel: [ 6434.093401] pptpcm[13872]: segfault at bfc0bea4 ip 0804d5da sp bfa1ff10 error 4 in pptp[8048000+e000]

True?