Bug 791280 - MTU only at 576 with cable internet provicer via dhcp (eth0) - regression in iscdhcpclient?
MTU only at 576 with cable internet provicer via dhcp (eth0) - regression in ...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE 12.1
Classification: openSUSE
Component: Network
Final
x86 openSUSE 12.1
: P5 - None : Major (vote)
: ---
Assigned To: Marius Tomaschewski
E-mail List
maint:released:sle11-sp2:50573
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-26 17:39 UTC by andreas bittner
Modified: 2013-04-04 16:05 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
wireshark capture of dhcp packages (1.43 KB, application/octet-stream)
2012-12-03 12:49 UTC, andreas bittner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description andreas bittner 2012-11-26 17:39:20 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.
debian/ubuntu bugs:
http://osdir.com/ml/ubuntu-bugs/2011-12/msg27989.html
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/881558
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638267
bug excerpt:
.....
Bug Description
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
178- new_interface_mtu=''

The correct syntax is -le not -lt.
This has also been reported in debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638267
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.
.....



Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
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
dhcpcd-3.2.3-47.70.1.2.i586
dhcp-client-4.2.4.P2-0.6.13.1.i586
dhcp-4.2.4.P2-0.6.13.1.i586
tuxmachine:/sbin # rpm -qi dhcp
Name        : dhcp
Version     : 4.2.4.P2
Release     : 0.6.13.1
Architecture: i586
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
Description :
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.

Authors:
--------
    Internet Systems Consortium, Inc. <info@isc.org>
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
          collisions:0 txqueuelen:1000
          RX bytes:1193927023 (1138.6 Mb)  TX bytes:191201024 (182.3 Mb)
          Interrupt:41 Base address:0xa000
		  
ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        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
Comment 1 andreas bittner 2012-11-27 11:16:09 UTC
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
/etc/dhclient.conf

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?


dhcpcd-test eth0
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 83.169.184.130
DHCPGIADDR='83.169.168.162'
IPADDR='188.x.x.x'
NETMASK='255.255.248.0'
NETWORK='188.x.x.0'
BROADCAST='188.x.x.x'
MTU='576'
ROUTES=''
GATEWAYS='188.193.135.254'
HOSTNAME='x1-6-00-x-x-x-x-x'
DNSSERVERS='83.169.184.225 83.169.184.161'
DHCPSID='83.169.184.130'
LEASETIME='5352'
RENEWALTIME='2676'
REBINDTIME='4683'
INTERFACE='eth0'
CLASSID='dhcpcd 3.2.3'
CLIENTID='01:00:x:x:x:x:x'
DHCPCHADDR='00:x:x:x:x:x'
LOGSERVER='0.0.0.0'
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?
thanks.
Comment 2 andreas bittner 2012-11-27 11:44:46 UTC
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.
Comment 3 andreas bittner 2012-11-27 12:05:29 UTC
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.

regards.
Comment 4 Marius Tomaschewski 2012-11-30 16:27:42 UTC
OK, thanks!

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.

Please start:
   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 &
then execute:
   dhcpcd-test eth0

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
option: DHCPCD_USER_OPTIONS='-M'.

Further, you may set your mtu as needed in the ifcfg file -- when
default (1500) does not work for unfragmented packets.
Comment 5 Marius Tomaschewski 2012-11-30 16:38:22 UTC
(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.
Comment 6 Marius Tomaschewski 2012-11-30 16:41:34 UTC
(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.
Comment 7 andreas bittner 2012-12-03 12:49:34 UTC
Created attachment 515409 [details]
wireshark capture of dhcp packages

did the capture according to this bugreport posting with wireshark.
Comment 8 Marius Tomaschewski 2012-12-03 17:14:26 UTC
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:

--- /etc/dhclient.conf
+++ /etc/dhclient.conf
@@ -41,7 +41,7 @@
 # Request several well known/usefull dhcp options.
 request subnet-mask, broadcast-address, routers,
 	rfc3442-classless-static-routes,
-	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,
 	netbios-name-servers, netbios-dd-server,

Basically, you only need the following minimal request:

request subnet-mask, broadcast-address, routers, domain-name-servers;
Comment 9 andreas bittner 2012-12-03 23:36:09 UTC
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?

thanks. regards.
Comment 10 Marius Tomaschewski 2012-12-04 08:42:33 UTC
(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
          /etc/dhclient.conf file.

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...
Comment 15 Bernhard Wiedemann 2013-01-31 12:00:36 UTC
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 /
Comment 16 Swamp Workflow Management 2013-02-07 15:05:00 UTC
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
CVE References: 
Sources used:
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
Comment 17 Swamp Workflow Management 2013-02-19 19:10:44 UTC
Update released for: dhcp, dhcp-client, dhcp-debuginfo, dhcp-debugsource, dhcp-devel, dhcp-relay, dhcp-server
Products:
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)
Comment 18 Swamp Workflow Management 2013-04-04 16:05:51 UTC
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
Sources used:
openSUSE 11.4 (src):    dhcp-4.2.4.P2-0.34.1