Bugzilla – Bug 791280
MTU only at 576 with cable internet provicer via dhcp (eth0) - regression in iscdhcpclient?
Last modified: 2013-04-04 16:05:51 UTC
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11
moved an opensuse box to 12.1/x86, latest updates applied, multiple ethernet cards and the internet provider changed from xdsl/pppoe to cableinternet via simple dhcpv4 on ethernet card (pcie/onboard, realtek)
now I am wondering why my MTU for the eth0 interface that connects to the cable modem gets set to 576 according to my research that is the lowest common mtu value that is available according to various ethernet and dhcp specs.
some research landed me over at some ubuntu/debian bugs talking about some bad dhcp script of the isc-dhcp-client, but which is supposedly fixed in isc-dhcp 4.2.2-1, but opensuse 12.1 has even newer?
I didnt have the chance to mess with enforcing some different MTU value on this affected box, or bootup some other more recent opensuse 12.2 linux with that cable modem or even try a windows machine directly with the cable modem just to see if the mtu 576 is an issue there as well. I am currently only able to remotely access this machine, thats why I am trying to avoid to disabling the network by messing things up, maybe I can help more at a later time.
so maybe anyone can look into this if the isc-dhcp is really buggy and unfixed with opensuse 12.1, and if those ubuntu/debian bugs with isc-dhcp are valid and legit and somehow went missing in opensuse or some regeression got re-introduced with a later isc-dhcp again?
thanks for helping to sort this out.
the following lines of /sbin/dhclient-script fails to detect MTU of 576:
~$ grep -A1 -n 'lt 576' /sbin/dhclient-script
177:if [ -z "$new_interface_mtu" ] || [ "$new_interface_mtu" -lt 576 ]; then
The correct syntax is -le not -lt.
This has also been reported in debian:
But should be a simple fix and not require a new package.
The result of this error is that the MTU of an interface configured by DHCP is dropped down to 576.
Steps to Reproduce:
I am originally reporting this as the ethernet throughput on this cable internet connected box is rather very low and sluggish and very jumpy, ssh sessions for example are very erratic and weird, so that made me to looking for the reason for this behavior and I then came across those MTU 576 issues. But then again I was also thinking about some kernel/driver(realtek) issues or incompatibilities or similar. Not quite sure.
tuxmachine:/sbin # grep 576 *
dhclient-script: $(( $new_interface_mtu )) -lt 576 ] ;
dhclient-script: # 68 is the minimal legal value, but 576 the real life minimum
tuxmachine:/sbin # ls -lart dhc*
-rwxr-xr-x 1 root root 76284 Oct 29 2011 dhcpcd
-rwxr-x--- 1 root root 19771 Sep 17 13:41 dhclient-script
-rwxr-xr-x 1 root root 1802884 Sep 17 13:41 dhclient
lrwxrwxrwx 1 root root 8 Nov 14 14:51 dhclient6 -> dhclient
rpm -aq | grep -i dhc
tuxmachine:/sbin # rpm -qi dhcp
Name : dhcp
Version : 4.2.4.P2
Release : 0.6.13.1
Install Date: Wed Nov 14 14:50:27 2012
Group : Productivity/Networking/Boot/Servers
Size : 1735945
License : BSD-3-Clause
Signature : RSA/SHA256, Wed Sep 26 16:45:42 2012, Key ID b88b2fd43dbdc284
Source RPM : dhcp-4.2.4.P2-0.6.13.1.src.rpm
Build Date : Mon Sep 17 13:41:41 2012
Build Host : build19
Relocations : (not relocatable)
Packager : http://bugs.opensuse.org
Vendor : openSUSE
URL : http://www.isc.org/software/dhcp
Summary : Common Files Used by ISC DHCP Software
This package contains common programs used by both the ISC DHCP
server ("dhcp-server" package) and client ("dhcp-client") as the
omshell and common manual pages.
Internet Systems Consortium, Inc. <email@example.com>
Distribution: openSUSE 12.1
tuxmachine:/sbin # cat /etc/SuSE-release
openSUSE 12.1 (i586)
VERSION = 12.1
CODENAME = Asparagus
tuxmachine:/sbin # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:xx:xx:xx:xx:xx
inet addr:188.xxx.xxx.xxx Bcast:188.xxx.xxx.255 Mask:255.255.248.0
UP BROADCAST RUNNING MULTICAST MTU:576 Metric:1
RX packets:3346973 errors:0 dropped:0 overruns:0 frame:0
TX packets:1212233 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:1193927023 (1138.6 Mb) TX bytes:191201024 (182.3 Mb)
Interrupt:41 Base address:0xa000
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Supports Wake-on: pumbg
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
grep eth0 /var/log/boot.msg
<6>[ 6.558160] r8169 0000:02:00.0: eth0: RTL8168b/8111b at 0xf7dde000, 00:xx:xx:xx:xx:xx, XID 18000000 IRQ 40
done eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B
eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B
I have tried a windows vista based laptop (realtek expresscard based) directly at the cable modem, and windows netsh command at least constantly gave me information that the MTU of the nic/lan card was always at 1500bytes, it successfully acquired an ipv4 address and Internet worked fine.
Back with opensuse 12.1/x86 I have tried another bunch of things, I found years old discussion on these lowest values as MTU with 576 and very many were talking about cable providers with linux :((
some people advised to go for
and edit the request line to minimum:
request subnet-mask, broadcast-address, routers;
which I did, and I even deleted all the cache files of the dhcpclient. Whats also kinda confusing is all the naming of packages, sometimes its dhcp-client, sometimes its dhclient, dhcpcd and whatnot..... confusing
What also seems odd about the dhcp with the german cableinternet provider is the very low lease times in a few thousand seconds worth of lease time only? Although some documentation was speaking about those numbers were being minutes, but thats somehow not the case here?
info, eth0: hardware address = 00:xx:xx:xx:xx:xx
info, eth0: broadcasting for a lease
debug, eth0: sending DHCP_DISCOVER with xid 0x38dae200
debug, eth0: waiting for 10 seconds
debug, eth0: got a packet with xid 0x38dae200
info, eth0: offered 188.x.x.x from 184.108.40.206
info, eth0: exiting
will try to boot some usb sticks with some more current opensuse isos in recovery mode to see if the mtu gets set differently there.
any hints on this bug at all?
I actually tried to fiddle around with dhcpcd a bit, and -d and --test and also -M
with -M set at commandline on eth0, the whole eth0 interface stays at the mtu of 1500 and Internet connection seems to run more happily?
Still this whole thing is weird, as experimenting with a connected windowsXP machine to this opensuse linux router with the windows machine running some ping -f (dont defrag) tests, seems to hint that packets of 1472bytes seem to go through, adding the 28bytes header gives us 1500bytes total which is the default maximum ethernet packet size, thus demonstrating that this cableinternet is working fine with mtu set at 1500.
So now the real question is why is the opensuse networking stack and components set the mtu via dhcp to 576 on this cableinternet setup. Who is to be blamed with the trouble, is it the cableinternet provider sending some weird replies in their dhcp packets, but then again the windowsvista machine worked fine or maybe simply didnt care for mtu stuff and uses mtu of 1500 as default or constant on all wired ethernet interfaces? whatever. I am no real lowlevel expert of any of this.
If opensuse could sort this out in some properly documented or standard adhering ways, would be best and probably would help other opensuse users and the community as well, or maybe I can even give some feedback at the cableinternet provider but only if we can debug this issue really extensively and collect and assamble all the facts and standards that are involved so that this issue can be handled properly.
Thanks and regards.
I have tried several usb boot sticks with more or less current opensuse builds, the newest was build-time october 1st 2012 19:xx, I think thats milestone0 or milestone1 of 12.2 as x64 build was the stick I could come up with. They behave all the same in rescue mode on this same hardware.
They all receive MTU information at least interpreted as 576 from the cableinternet provider via dhcp and on the command-line if i DONT put -M as parameter for dhcpcd then they re-set the eth0 for MTU with 576. If I use -M parameter manually for testing the eth0 interface stays at 1500MTU and works just fine.
Question now is, how can an Interface be kept at 1500MTU if its wired ethernet via yast2 or some config files the best ways without being too hacky.
And further down the road if opensuse or the dhcp package upstream developers or whoever else can address this odd behaviour or make it more plugandplay interoperable or show me some more information on what to report back to tech folks with this cableinternet provider or how to deal with issues like this.
OK, I'm going to apply the
- $(( $new_interface_mtu )) -lt 576 ] ;
+ $(( $new_interface_mtu )) -le 576 ] ;
fix to include 576 in the invalid range.
We are so kind to ask for the MTU and the ISP dhcp server (or your
cable modem?) reports some crap lower than this.
ip link set up dev eth0 # just to make sure it is up
wireshark -k -i eth0 -f 'udp port 67 or udp port 68' -w dhcp.cap &
when dhcpcd-test is done, attach the "dhcp.cap".
To avoid that clients asks for, edit /etc/dhclient.conf and
remove the "interface-mtu" from request.
For dhcpcd, edit /etc/sysconfig/network/dhcp and set the -M
Further, you may set your mtu as needed in the ifcfg file -- when
default (1500) does not work for unfragmented packets.
(In reply to comment #1)
> What also seems odd about the dhcp with the german cableinternet provider is
> the very low lease times in a few thousand seconds worth of lease time only?
> Although some documentation was speaking about those numbers were being
> minutes, but thats somehow not the case here?
No, the times are in secs. "Usually", you'll get the same IP address, but
you have to start a renew after 44 minutes (2676/60). When you don't do,
the lease (& IP address) will expire after 78 minutes.
(In reply to comment #3)
> Question now is, how can an Interface be kept at 1500MTU if its wired ethernet
> via yast2 or some config files the best ways without being too hacky.
You can use "yast2 sysconfig" to set -M in /etc/sysconfig/network/dhcp.
Created attachment 515409 [details]
wireshark capture of dhcp packages
did the capture according to this bugreport posting with wireshark.
Yes, the dhcp-server (ISP) provides the 576 MTU...
As I already wrote in comment 4, set DHCPCD_USER_OPTIONS='-M' when
you are using dhcpcd. Otherwise remove the interface-mtu option from
the request statement:
@@ -41,7 +41,7 @@
# Request several well known/usefull dhcp options.
request subnet-mask, broadcast-address, routers,
- interface-mtu, host-name, domain-name, domain-search,
+ host-name, domain-name, domain-search,
domain-name-servers, nis-domain, nis-servers,
nds-context, nds-servers, nds-tree-name,
Basically, you only need the following minimal request:
request subnet-mask, broadcast-address, routers, domain-name-servers;
I already had that minimal request line in the config file last week, and that didnt help. I now have additionally the -M parameter in the other config file in sysconfig directory, that helps
so should I then contact this ISP and tell them about their misbehaviour or something? Is somebody disrespecting any RFCs or standards or anything?
(In reply to comment #9)
> I already had that minimal request line in the config file last week, and that
> didnt help. I now have additionally the -M parameter in the other config file
> in sysconfig directory, that helps
Sure... sysconfig can use two different dhcp clients:
dhcpcd: default client, needs DHCPCD_USER_OPTIONS='-M' parameter
dhclient: ISC client from "dhcp-client" package, makes use of the
The dhclient is used only, when you change the DHCLIENT_BIN to
"dhclient" in /etc/sysconfig/network/dhcp. Otherwise dhcpcd.
> so should I then contact this ISP and tell them about their misbehaviour
> or something? Is somebody disrespecting any RFCs or standards or anything?
No, I don't see anything would break some RFCs... The server reports
what the administrator configured. It is expected, the admin provides
an MTU, which is suitable for the connection, ...
This low and inconsistent mtu (I guess, your gateway isn't using 576)
causes a lot of "Path MTU Discovery" resends and when some firewall
blocks the ICMP notifications on the path, ...
You can try to report it to the ISP as it disrupts you and lowers the
througput; I which you luck! But I don't think they will change this...
This is an autogenerated message for OBS integration:
This bug (791280) was mentioned in
https://build.opensuse.org/request/show/150556 Maintenance /
https://build.opensuse.org/request/show/150558 Maintenance /
openSUSE-RU-2013:0257-1: An update that has 5 recommended fixes can now be installed.
Category: recommended (low)
Bug References: 784640,788787,791280,791289,794578
openSUSE 12.2 (src): dhcp-4.2.4.P2-0.1.8.1
openSUSE 12.1 (src): dhcp-4.2.4.P2-0.6.17.1
Update released for: dhcp, dhcp-client, dhcp-debuginfo, dhcp-debugsource, dhcp-devel, dhcp-relay, dhcp-server
SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP2 (i386, x86_64)
SLE-SDK 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP2 (i386, x86_64)
openSUSE-SU-2013:0625-1: An update that solves one vulnerability and has 6 fixes is now available.
Category: security (moderate)
Bug References: 783002,784640,788787,791280,791289,794578,811934
CVE References: CVE-2013-2266
openSUSE 11.4 (src): dhcp-4.2.4.P2-0.34.1