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.
G.Wolfe, should I mark this bug as a dupe of 132038?
Well, the error is in NM, not ifup, so it's your choice.
Created attachment 103754 [details] debugging trace of ifconfig, NM, ifconfig and mii-tool
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.
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' ?
Oh, and also of 'lshal' ? Thanks! Dan
Created attachment 103755 [details] lshal output from tembo machine
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)
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.