Bug 132348 - NetworkManager removes IP address from eth0 after ifup sets it up
Summary: NetworkManager removes IP address from eth0 after ifup sets it up
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-11 05:10 UTC by G.Wolfe Woodbury
Modified: 2007-11-30 22:10 UTC (History)
0 users

Clone Of:
Last Closed: 2004-09-12 14:56:13 UTC

Attachments (Terms of Use)
debugging trace of ifconfig, NM, ifconfig and mii-tool (2.57 KB, text/plain)
2004-09-12 04:27 UTC, G.Wolfe Woodbury
no flags Details
lshal output from tembo machine (31.02 KB, text/plain)
2004-09-12 05:31 UTC, G.Wolfe Woodbury
no flags Details

Description G.Wolfe Woodbury 2004-09-11 05:10:02 UTC
Description of problem:
   NM removes the IP address of interface eth0 when it re-initializes
the device.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. fresh install of development/rawhide of 2004-09-10
2. boot normally
Actual results:

  Initscripts(ifup) runs first and initializes device properly from
DHCP server; then NM starts up and (re)initializes the device
incorrectly, not setting the IP address received from the DHCP server.
This removes the IPv4 address from the interface eth0, but the other
flags show the interface "UP RUNNING <etc>"

Expected results:
  It should set the IPv4 address correctly.

Additional info:
  As discussed in the bug for ifup (#132038), there is a conflict
between NM and the "normal" (initscripts) setup of the eth0 interface.
I think that there needs to be a better definition of the interactions
between NM and initscripts, so that they don't step on each other so

Comment 1 Dan Williams 2004-09-12 00:26:17 UTC
G.Wolfe, should I mark this bug as a dupe of 132038?

Comment 2 G.Wolfe Woodbury 2004-09-12 04:26:15 UTC
Well, the error is in NM, not ifup, so it's your choice.

Comment 3 G.Wolfe Woodbury 2004-09-12 04:27:49 UTC
Created attachment 103754 [details]
debugging trace of ifconfig, NM, ifconfig and mii-tool

Comment 4 G.Wolfe Woodbury 2004-09-12 04:34:41 UTC
Tembo is an AMD-k6/2 400MHz; ASUS P5A-B mobo; tulip on-board and eth1
is a 3c509TX; 320MB RAM; ATI Mach64 video; IDE drives and CD-RW;

Consistently, running NetworkManager tries to re-initialize eth0 (the
tulip on-board) and fails to properly transfer the information
received from the DHCP server to the device.  I can see the DHCP
transactions logged on the server:
Sep 12 00:24:11 wolves dhcpd: DHCPREQUEST for from
00:40:05:30:cc:8c via eth0
Sep 12 00:24:11 wolves dhcpd: DHCPACK on to
00:40:05:30:cc:8c via eth0

There is clearly something wrong with NM.

Comment 5 Dan Williams 2004-09-12 05:19:11 UTC
G. Wolfe:

Here's problem #1:

[root@tembo ~]# mii-tool
eth0: negotiated 100baseTx-FD, link ok
SIOCGMIIPHY on 'eth1' failed: Operation not supported

Link checking is unsupported on that device, so NM won't use it. 
Furthermore, its quite interesting to me that even mii-tool doesn't
see eth1, there's a problem here thats lower-level than NM.

So next, what happens if you:

ip link set dev eth0 up
dhclient -1 eth0

What happens on the k6/2, and what hapnes on the DHCP server?  NM
simply uses dhclient to do the DCHP bit, and doesn't actually modify
the IP address, route info, or nameservers at all.  It might however
be removing that information later on if it cannot find any devices to

Could you also post the output of 'mii-tool eth1' ?

Comment 6 Dan Williams 2004-09-12 05:20:25 UTC
Oh, and also of 'lshal' ?


Comment 7 G.Wolfe Woodbury 2004-09-12 05:31:12 UTC
Created attachment 103755 [details]
lshal output from tembo machine

Comment 8 G.Wolfe Woodbury 2004-09-12 05:49:59 UTC
I'm not worried about the eth1 device on the K6/2, it's an ISA card
and had to be hand-configured by system-config-network to be seen. 
It's the secondary access to the internet from the LAN so it's not

The eth0 on tembo(K6/2) configures quite nicely by initscripts/ifup
and has never given me a real bit of trouble (until NM entered the

The DHCP transactions between tembo and wolves(P3#1.8GHz running FC1)
are normal and as expected:
Sep 11 17:25:33 wolves dhcpd: DHCPREQUEST for from 
00:40:05:30:cc:8c via eth0
Sep 11 17:25:33 wolves dhcpd: DHCPACK on to
00:40:05:30:cc:8c via eth0

was tembo's last boot request sequence (seen from wolves)

Comment 9 Dan Williams 2004-09-12 14:56:13 UTC
Ok, given the details (no link checking for ne2k-pci/tulip, ISA eth1
unknown to HAL) the behavior of NetworkManager is expected so far.  I
think in your case, you'll just have to not use NM (which I'm sure is
fine with you :), or else we have to get link-checking working on
ne2k-pci driver.

NetworkManager is no longer enabled by default when you install it, so
this shouldn't be a problem for you any longer.

Thanks for the info.

Note You need to log in before you can comment on or make changes to this bug.