Re: Network Up, Then Down with 9.2 -- more info
![](https://seccdn.libravatar.org/avatar/afdd4637d0bd85b0e27c99a530531087.jpg?s=120&d=mm&r=g)
On Sat, Jan 15, 2005 at 09:28:55AM -0800, Michael Nelson wrote:
My system (upgraded this week from 9.1 to 9.2) has suddenly started acting strange about bringing up my eth0 interface. It uses the 3c59x driver. I noticed that after a complete boot into runlevel 5, the eth0 interface has no ip address.
Clarification... it has no IPV4 IP address. It *will* have an IPV6 address, even though I have specified "USE_IPV6="no" in /etc/sysconfig/network/config. At the end of booting into runlevel 2, 3, or 5, ifconfig shows: # ifconfig eth0 Link encap:Ethernet HWaddr 00:50:DA:25:86:46 inet6 addr: fe80::250:daff:fe25:8646/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:580 (580.0 b) Interrupt:11 Base address:0xb800 lo Link encap:Local Loopback inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Notice that eth0 is actually UP and RUNNING, it just has no ipv4 ip address. The routing table is correspondingly empty.
If I then run "rcnetwork restart", it brings up the interface properly with the correct IP and netmask.
# ifconfig eth0 Link encap:Ethernet HWaddr 00:50:DA:25:86:46 inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:31 errors:0 dropped:0 overruns:0 frame:0 TX packets:45 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8813 (8.6 Kb) TX bytes:3949 (3.8 Kb) Interrupt:11 Base address:0xb800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:76 errors:0 dropped:0 overruns:0 frame:0 TX packets:76 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:8117 (7.9 Kb) TX bytes:8117 (7.9 Kb) Note that the proper ipv4 address is there now, and the ipv6 addresses are gone from both eth0 and lo. The routing table is now correct: # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default router 0.0.0.0 UG 0 0 0 eth0
I rebooted into runlevel 2 in order to simplify things, and I can see the network script say that eth0 has ip address 192.168.0.2 with appropriate netmask. But at the end of the boot into runlevel 2, if I check with ifconfig, eth0 now has no ip address.
...no IPV4 ip address, I should have said.
I tried rebooting and going into single user mode and then manually running each of the scripts (in order) in /etc/rc.d/rc2.d. The network script again brings up eth0 with the correct IP and netmask, and at the end of running all the scripts the network is properly configured and running fine.
Even after that, I can "init s" and then "init 2", and at the end of init 2 the interface will now be properly brought up. Once it have brought it up with rcnetwork restart I can bring it up and down at will, and it will come up and down properly even when changing runlevels.
So I am kind of flummoxed as to why it doesn't finish a normal boot into level 2 or 3 or 5 with the interface having the proper IP and netmask, but it will be OK if I run "rcnetwork restart".
Here is an excerpt from the /var/log/boot.msg file:
Setting up network interfaces: lo lo IP address: 127.0.0.1/8 done eth0 device: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) eth0 configuration: eth-id-00:50:da:25:86:46 eth0 IP address: 192.168.0.2/24 doneSetting up service network . . . . . . . . . . . . . . . .done <notice>exit status of (network) is (0)
Nothing in the boot.msg file or /var/log/messages shows anything after that regarding eth0 losing its configuration.
I tried using yast to remove the entire config for the interface, then rebooted, then used yast again to set up the interface. After rebooting again, same deal. I have been troubleshooting this for hours on end, and it still fails to set up eth0 properly during a normal boot.
![](https://seccdn.libravatar.org/avatar/696255f62c3cefe5d517f913058b70bc.jpg?s=120&d=mm&r=g)
On Sun, 2005-01-16 at 07:49 -0800, Michael Nelson wrote: <big snip> Hi Michael, My 9.2 system supports concurrent IPv4 and IPv6 addressing. Here's what I see: eth0 Link encap:Ethernet HWaddr 00:D0:09:C4:53:22 inet addr:192.168.1.47 Bcast:255.255.255.255 Mask:255.255.255.0 inet6 addr: fe80::2d0:9ff:fec4:5322/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1786 errors:0 dropped:0 overruns:0 frame:0 TX packets:1946 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:654721 (639.3 Kb) TX bytes:178434 (174.2 Kb) Interrupt:11 Base address:0xd400 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:872 errors:0 dropped:0 overruns:0 frame:0 TX packets:872 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:231156 (225.7 Kb) TX bytes:231156 (225.7 Kb) Compared to my experience, your system appears to be 'toggling' between the two addressing schemes, adopting either one or the other but not both. Which scheme "wins" depends upon the sequence of routines used to initialize the hardware and establish the network connection. Now, I'm just a regular Linux user and not a networking 'guru' -- so I apologize if my reply is too simplistic -- but in these kinds of situations, I usually check my work to see if I've inadvertently set two competing (contending) configuration settings somewhere -- creating the effect that the last relevant part to run just happens to "win" the contest. In my experience, this is usually the result of a typo or because I've misinterpreted a cryptic config file argument. (Think "no no" = "yes" except when both items 343z and z434 are set to "yes yes" in which case the default should be "maybe" but not in leap years or on the fifth Tuesday of any month ending in "r" :-P] When I can't deduce where such mistakes are buried, I then resort to brute force, i.e. removing the misbehaving components and reinstalling them from scratch (i.e. from the "factory defaults") -- usually after taking a long breather -- and then taking specific care thereafter not to repeat any typos or errors in logic. Keep the faith -- you're obviously _very_ close. I hope the encouragement, if not a precisely on-target technical solution, might be of some help. regards, - Carl
![](https://seccdn.libravatar.org/avatar/afdd4637d0bd85b0e27c99a530531087.jpg?s=120&d=mm&r=g)
On Sun, Jan 16, 2005 at 01:06:08PM -0500, Carl E. Hartung wrote:
My 9.2 system supports concurrent IPv4 and IPv6 addressing.
Yep, so does mine. The problem is solved, see my previous post for the solution. Thanks for your suggestions though! Michael -- San Francisco, CA
participants (2)
-
Carl E. Hartung
-
Michael Nelson