Bugzilla – Bug 157737
System doesn't accept MTU setting with NM
Last modified: 2006-03-21 18:17:27 UTC
Because of DSL (arcor) I want to set MTU <1492 to avoid fragmentation. Configured MTU 1488 for both NICS (eth, wlan) with YaST. Nevertheless, ipstack uses MTU of 1500bytes. eth1 Link encap:Ethernet HWaddr 00:14:22:C3:ED:80 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:169 eth2 Link encap:Ethernet HWaddr 00:13:CE:CE:53:D1 inet addr:192.168.200.103 Bcast:192.168.200.255 Mask:255.255.255.0 inet6 addr: fe80::213:ceff:fece:53d1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:571 errors:0 dropped:25 overruns:0 frame:0 TX packets:477 errors:0 dropped:4 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:285338765 (272.1 Mb) TX bytes:19174345 (18.2 Mb) Interrupt:209 Base address:0xa000 Memory:dfbff000-dfbfffff
Created attachment 72657 [details] ifconfig eth
Created attachment 72658 [details] ifconfig wlan
Please attach the yast logfiles.
Where do I find them?
sorry, I'm a bit stupid today... first set: changing mtu from 1488 to <empty> for eth1, eth2
Created attachment 72768 [details] YaST2: setting mtu to <empty> for eth1, eth2
Created attachment 72770 [details] YaST2: setting mtu to 1488 for eth1, eth2
ifconfig after #7 (had to reconnect WLAN manually after YaST) eth1 Link encap:Ethernet HWaddr 00:14:22:C3:ED:80 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:169 eth2 Link encap:Ethernet HWaddr 00:13:CE:CE:53:D1 inet addr:192.168.200.102 Bcast:192.168.200.255 Mask:255.255.255.0 inet6 addr: fe80::213:ceff:fece:53d1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:365 errors:0 dropped:12 overruns:0 frame:0 TX packets:242 errors:0 dropped:4 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2350988 (2.2 Mb) TX bytes:694108 (677.8 Kb) Interrupt:209 Base address:0x6000 Memory:dfbff000-dfbfffff
Ressigning to Martin.
NetworkManager -> Robert
We won't support user-specified MTU settings for Code10. In the meantime, you can place a script in /etc/NetworkManager/dispatcher.d that sets the MTU for you. $1 is the interface name and $2 is "up" or "down" depending on whether the interface is now up or down.
Ok, just for completeness... Because of the MTU problem we will see a lot of problems with Turnpike VPN. Turnpike tries to set the route mtu to 1350, which doesn't work. Because the stack signals 1500, we get, if we have a "MTU Black Hole" between Server and Client, stucking connections because of truncated packages. Even if the connection doesn't stuck we have horrible throughputs (see attached pic) which was created with a single file download via VPN over a 6MBit DSL. Timeouts up to 15sec are quite normal in this case. Manual setting the MTU to 1350 increased the average throughput to approx. 350kB/sec, without outages.
Created attachment 73098 [details] Screenshot of Network throughput via VPN with 1500MTU
Created attachment 73099 [details] VPN connection 1500MTU
Shouldn't Turnpike be fixed/modified?
I'll read the values from sysconfig, if any, and set them on interface up in NM.
See bug #159354 *** This bug has been marked as a duplicate of 159354 ***
Got a code snipet from zoz which solved my problem. See attached /etc/sysconfig/network/ip-up.d/ifcfg-mtu-hook
Created attachment 74277 [details] NM mtu hook
Yes, this was the dispatcher script I was speaking of. The next build of NM will respect the MTU value, anyhow.