Bug 132348 - NetworkManager removes IP address from eth0 after ifup sets it up
NetworkManager removes IP address from eth0 after ifup sets it up
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-11 01:10 EDT by G.Wolfe Woodbury
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-12 10:56:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description G.Wolfe Woodbury 2004-09-11 01:10:02 EDT
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):
0.2-1

How reproducible:
Always

Steps to Reproduce:
1. fresh install of development/rawhide of 2004-09-10
2. boot normally
3.
  
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
badly.
Comment 1 Dan Williams 2004-09-11 20:26:17 EDT
G.Wolfe, should I mark this bug as a dupe of 132038?
Comment 2 G.Wolfe Woodbury 2004-09-12 00:26:15 EDT
Well, the error is in NM, not ifup, so it's your choice.
Comment 3 G.Wolfe Woodbury 2004-09-12 00:27:49 EDT
Created attachment 103754 [details]
debugging trace of ifconfig, NM, ifconfig and mii-tool
Comment 4 G.Wolfe Woodbury 2004-09-12 00:34:41 EDT
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 10.11.12.2 from
00:40:05:30:cc:8c via eth0
Sep 12 00:24:11 wolves dhcpd: DHCPACK on 10.11.12.2 to
00:40:05:30:cc:8c via eth0

There is clearly something wrong with NM.
Comment 5 Dan Williams 2004-09-12 01:19:11 EDT
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
use...

Could you also post the output of 'mii-tool eth1' ?
Comment 6 Dan Williams 2004-09-12 01:20:25 EDT
Oh, and also of 'lshal' ?

Thanks!
Dan
Comment 7 G.Wolfe Woodbury 2004-09-12 01:31:12 EDT
Created attachment 103755 [details]
lshal output from tembo machine
Comment 8 G.Wolfe Woodbury 2004-09-12 01:49:59 EDT
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
critical.

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
picture!)

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 10.11.12.2 from 
00:40:05:30:cc:8c via eth0
Sep 11 17:25:33 wolves dhcpd: DHCPACK on 10.11.12.2 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 10:56:13 EDT
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.