eth0 now eth1 WTF? Network woes....The saga....[Long]
Mates, I have built a new box for the house, and it is testing my understanding of Linux. It is also testing logic. I know I'm aging, but I have ruled out Alzheimer's. Here is the scoop. When I first installed SuSE 10, the network would come up and it used eth0: Simply /etc/sysconfig/network/ifcfg-eth-id-00:4c:69:6e:75:79 would bring up the Linksys card as eth0. This is how it worked. Then on a subsequent reboot the network doesn't come up. I mean loopback is fine, but the NIC fails to load and the error is "unable to load mandatory services.." Yes, I understand the mandatory devices loading and /etc/sysconfig/network/config. On reboot, the network fails. dmesg says it is now trying to load eth1? Ok, cp ifcfg-eth-id-00:4c:69:6e:75:79 ifcfg-eth1 rcnetwork restart -- presto! it comes up. So then I leave both ifcfg-eth-id-00:4c:69:6e:75:79 and ifcfg-eth1 in /etc/sysconfig/network. Some subsequent reboots work some fail. Latest reboot, network fails, /var/log/boot.omsg says it is now looking for: doneWaiting for mandatory devices: eth-id-00:4c:69:6e:75:79 19 Initializing random number generatordone <notice>startproc: execve (/sbin/resmgrd) [ /sbin/resmgrd ], [ CONSOLE=/dev/console ROOTFS_FSTYPE=reiserfs TERM=linux SHELL=/bin/sh ROOTFS_FSCK=0 LC_ALL=POSIX INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=160 PATH=/sbin:/usr/sbin:/bin:/usr/bin:/lib/klibc/bin vga=0x31a RUNLEVEL=3 PWD=/ SPLASHCFG= PREVLEVEL=N LINES=64 HOME=/ SHLVL=2 splash=0 SPLASH=no ROOTFS_BLKDEV=/dev/hda2 _=/sbin/startproc DAEMON=/sbin/resmgrd ] Starting resource managerdone 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 0 eth-id-00:4c:69:6e:75:79 No interface found failedSetting up service network . . . . . . . . . . . . . . . .failed I only have 1 NIC? What is going on? OK, next go round it complains that it is now looking for another hardware address for eth1 - no changes to the system... It is looking for the NIC at 00:04:5a:87:c8:43. WTF? OK, easy enough: cp eth-id-00:4c:69:6e:75:79 eth-id-00:04:5a:87:c8:43; rm eth-id-00:4c:69:6e:75:79. rcnetwok restart -- it works! Reboot. I understand that the pci bus and the order that devices are activated and their addresses are dynamic. But where do I stop the randomness?? doneWaiting for mandatory devices: eth-id-00:04:5a:87:c8:43 19 17 eth1 device: Linksys NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) eth1 configuration: eth-id-00:04:5a:87:c8:43 eth1 IP address: 192.168.6.16/24 doneSetting up service network . . . . . . . . . . . . . . . .done OK, great -- for now. Obviously, I can't have a server that when it goes down, it comes up and the network (for whatever reason) is "guessing" at the hw address for the NIC. What in the heck is going on? So the questions: (1) why is my system now wanting to load the NIC as eth1 instead of eth0? (2) how in the heck is the hardware address changing? (I set the kernel parameters noapic and nolapic in grub to try and cure it -- no joy) I have read all the discussion on eth0, eth1 -- I know it doesn't matter what binding the system makes, but I just want to find a way to have my NIC come up each time in case I'm 1000 miles away when the power exhausts the UPC. Do I go to a straight ifcfg-eth0 and ifcfg-eth1 setup in /etc/network/sysconfig? Do I put both eth-id-00:4c:69:6e:75:79 and eth-id-00:04:5a:87:c8:43 in there (seems like a lame Band-Aid approach) What is the best way to solve this conundrum??? -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
On Monday 23 January 2006 12:06 am, david rankin wrote:
Do I go to a straight ifcfg-eth0 and ifcfg-eth1 setup in /etc/network/sysconfig? Do I put both eth-id-00:4c:69:6e:75:79 and eth-id-00:04:5a:87:c8:43 in there (seems like a lame Band-Aid approach)
What is the best way to solve this conundrum???
When it is working and not working what does ifconfig say? Two things I would try. 1st, make sure there is only one nic setup in Yast. 2nd, I would swap out the nic.. Might have a flakey card. Since it's a new machine, is it possible there is an onboard nic and a card installed as well? Richard
On Sunday 22 January 2006 21:38, Richard Atcheson wrote:
On Monday 23 January 2006 12:06 am, david rankin wrote:
Do I go to a straight ifcfg-eth0 and ifcfg-eth1 setup in /etc/network/sysconfig? Do I put both eth-id-00:4c:69:6e:75:79 and eth-id-00:04:5a:87:c8:43 in there (seems like a lame Band-Aid approach)
What is the best way to solve this conundrum???
When it is working and not working what does ifconfig say?
Two things I would try. 1st, make sure there is only one nic setup in Yast. 2nd, I would swap out the nic.. Might have a flakey card.
Since it's a new machine, is it possible there is an onboard nic and a card installed as well?
Richard Somehow your software thinks there are more than one nics. Double check that your motherboard does not have a second nic. if you find one, disable it in the cmos setup. When there is just one, suse stops being confused. That has been my experience with 10.0. 9.3 had the problem as well, but once set in Yast it could handle it. What happened to the days when one could assign eth0, eth1 and so one to particular cards I don't know. d.
From:
On Sunday 22 January 2006 21:38, Richard Atcheson wrote:
On Monday 23 January 2006 12:06 am, david rankin wrote:
Do I go to a straight ifcfg-eth0 and ifcfg-eth1 setup in /etc/network/sysconfig? Do I put both eth-id-00:4c:69:6e:75:79 and eth-id-00:04:5a:87:c8:43 in there (seems like a lame Band-Aid approach)
What is the best way to solve this conundrum???
When it is working and not working what does ifconfig say?
Two things I would try. 1st, make sure there is only one nic setup in Yast. 2nd, I would swap out the nic.. Might have a flakey card.
Since it's a new machine, is it possible there is an onboard nic and a card installed as well?
Richard Somehow your software thinks there are more than one nics. Double check that your motherboard does not have a second nic. if you find one, disable it in the cmos setup. When there is just one, suse stops being confused. That has been my experience with 10.0. 9.3 had the problem as well, but once set in Yast it could handle it. What happened to the days when one could assign eth0, eth1 and so one to particular cards I don't know. d.
Guys, when I said it was a new box, I misspoke. It is new to my home, but it is the same box that worked flawlessly for the past 5 years at work as a server running mandrake 7.2. Nothing has changed and there is only one NIC. Yast only sees 1 NIC. Ifconfig shows: nemesis:/home/david # ifconfig eth1 Link encap:Ethernet HWaddr 00:04:5A:87:C8:43 inet addr:192.168.6.16 Bcast:192.168.6.255 Mask:255.255.255.0 inet6 addr: fe80::204:5aff:fe87:c843/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5399 errors:0 dropped:0 overruns:0 frame:0 TX packets:3781 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:555501 (542.4 Kb) TX bytes:703613 (687.1 Kb) Interrupt:11 Base address:0xec00 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:3191 errors:0 dropped:0 overruns:0 frame:0 TX packets:3191 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:239728 (234.1 Kb) TX bytes:239728 (234.1 Kb) It is as if eth0 just dissapeared into oblivion.. Any more guesses?? Maybe the PCI bus is randomly loading the card in a different order some times?? -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
On Mon, 2006-01-23 at 16:10 -0600, david rankin wrote:
From:
Guys, when I said it was a new box, I misspoke. It is new to my home, but it is the same box that worked flawlessly for the past 5 years at work as a server running mandrake 7.2. Nothing has changed and there is only one NIC. Yast only sees 1 NIC. Ifconfig shows:
ifconfig will only show configured interfaces (ones with an active driver). Use dmesg to show all recognised hardware, even ones without a driver. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-01-23 at 17:28 -0500, Ken Schneider wrote:
ifconfig will only show configured interfaces (ones with an active driver). Use dmesg to show all recognised hardware, even ones without a driver.
Or run hwinfo or the hardware info thing in Yast. I wonder - wild, but wild guess - if that ethernet card doesn't have a MAC, or it get erased, and something creates a new MAC for it. Is that possible? - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD1W2TtTMYHG2NR9URAuVAAJwNTGbyfgdSbLr15QnTFeJI3x4kmQCfZwNE hPqJByCkc9kB2xDakknFplw= =R3Lx -----END PGP SIGNATURE-----
----- Original Message -----
From: "Ken Schneider"
On Mon, 2006-01-23 at 16:10 -0600, david rankin wrote:
From:
Guys, when I said it was a new box, I misspoke. It is new to my home, but it is the same box that worked flawlessly for the past 5 years at work as a server running mandrake 7.2. Nothing has changed and there is only one NIC. Yast only sees 1 NIC. Ifconfig shows: ifconfig will only show configured interfaces (ones with an active driver). Use dmesg to show all recognised hardware, even ones without a driver.
This is strange. What is the eth0 ADMtek from dmesg below? Linux Tulip driver version 1.1.13-NAPI (May 11, 2002) ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI Interrupt 0000:00:0f.0[A] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11 tulip0: MII transceiver #1 config 1000 status 786d advertising 05e1. eth0: ADMtek Comet rev 17 at 0001ec00, 00:04:5A:87:C8:43, IRQ 11. NET: Registered protocol family 10 Disabled Privacy Extensions on device c036b920(lo) IPv6 over IPv4 tunneling driver ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] ACPI: Sleep Button (CM) [SLPB] 0000:00:0f.0: tulip_stop_rxtx() failed eth1: Setting full-duplex based on MII#1 link partner capability of 45e1. -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
From: "Ken Schneider"
On Mon, 2006-01-23 at 16:10 -0600, david rankin wrote:
From:
Guys, when I said it was a new box, I misspoke. It is new to my home, but it is the same box that worked flawlessly for the past 5 years at work as a server running mandrake 7.2. Nothing has changed and there is only one NIC. Yast only sees 1 NIC. Ifconfig shows: ifconfig will only show configured interfaces (ones with an active driver). Use dmesg to show all recognised hardware, even ones without a driver.
Here is the information from YAST hardware info if it sheds any light on the situation. I'm not smart enough to know what it is trying to tell me... 33: udi = '/org/freedesktop/Hal/devices/net_00_04_5a_87_c8_43' info.udi = '/org/freedesktop/Hal/devices/net_00_04_5a_87_c8_43' linux.subsystem = 'net' linux.hotplug_type = 2 (0x2) net.80203.mac_address = 18698717251ull (0x45a87c843ull) info.product = 'Networking Interface' net.interface_up = true net.arp_proto_hw_id = 1 (0x1) net.linux.ifindex = 2 (0x2) net.address = '00:04:5a:87:c8:43' net.interface = 'eth1' net.physical_device = '/org/freedesktop/Hal/devices/pci_1317_985' info.capabilities = { 'net', 'net.80203' } info.category = 'net.80203' info.parent = '/org/freedesktop/Hal/devices/pci_1317_985' linux.sysfs_path = '/sys/class/net/eth1' 34: udi = '/org/freedesktop/Hal/devices/pci_1317_985' info.udi = '/org/freedesktop/Hal/devices/pci_1317_985' linux.subsystem = 'pci' linux.hotplug_type = 1 (0x1) pci.subsys_product = 'Unknown (0x0574)' pci.subsys_vendor = 'Linksys' info.product = 'NC100 Network Everywhere Fast Ethernet 10/100' pci.product = 'NC100 Network Everywhere Fast Ethernet 10/100' info.vendor = 'Linksys' pci.vendor = 'Linksys' pci.device_protocol = 0 (0x0) pci.device_subclass = 0 (0x0) pci.device_class = 2 (0x2) pci.subsys_vendor_id = 4887 (0x1317) pci.subsys_product_id = 1396 (0x574) pci.vendor_id = 4887 (0x1317) pci.product_id = 2437 (0x985) info.linux.driver = 'tulip' pci.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:0f.0' info.parent = '/org/freedesktop/Hal/devices/computer' info.bus = 'pci' linux.sysfs_path_device = '/sys/devices/pci0000:00/0000:00:0f.0' linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:0f.0' -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
sniiip....
Guys, when I said it was a new box, I misspoke. It is new to my home, but it is the same box that worked flawlessly for the past 5 years at work as a server running mandrake 7.2. Nothing has changed and there is only one NIC. Yast only sees 1 NIC.
as a last sanity check on the number of cards, what does your bios show?
david rankin wrote:
When I first installed SuSE 10, the network would come up and it used eth0:
Simply /etc/sysconfig/network/ifcfg-eth-id-00:4c:69:6e:75:79
You're listing two different MAC-addresses in your posting: 00:4c:69:6e:75:79 and 00:04:5a:87:c8:43 That would seem to imply you've got two NICs. However, the first address isn't valid - the first 3 bytes are not registered at the IEEE (you can look them up at standards.ieee.org) - whereas the 2nd MAC is a Linksys address. I don't what the story is with the first address, but try googling for it, and you get a number of direct hits. http://www.google.ch/search?hl=en&q=00%3A4c%3A69%3A6e%3A75%3A79 And for a MAC address that is supposedly universally unique, I wouldn't expect an awful lot of hits in google. /Per Jessen, Zürich (-4.38 °C) -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
----- Original Message -----
From: "Per Jessen"
david rankin wrote:
When I first installed SuSE 10, the network would come up and it used eth0:
Simply /etc/sysconfig/network/ifcfg-eth-id-00:4c:69:6e:75:79
You're listing two different MAC-addresses in your posting:
00:4c:69:6e:75:79 and 00:04:5a:87:c8:43
That would seem to imply you've got two NICs. However, the first address isn't valid - the first 3 bytes are not registered at the IEEE (you can look them up at standards.ieee.org) - whereas the 2nd MAC is a Linksys address.
I don't what the story is with the first address, but try googling for it, and you get a number of direct hits.
http://www.google.ch/search?hl=en&q=00%3A4c%3A69%3A6e%3A75%3A79
And for a MAC address that is supposedly universally unique, I wouldn't expect an awful lot of hits in google.
Now that is really really strange! There are 372 posts out there on 00:4c:69:6e:75:79. How in the world can that happen? Is there anything that could cause SuSE to report the wrong mac address? Hmm... -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
are you using vmware ?
On 1/24/06, david rankin
----- Original Message ----- From: "Per Jessen"
david rankin wrote:
When I first installed SuSE 10, the network would come up and it used eth0:
Simply /etc/sysconfig/network/ifcfg-eth-id-00:4c:69:6e:75:79
You're listing two different MAC-addresses in your posting:
00:4c:69:6e:75:79 and 00:04:5a:87:c8:43
That would seem to imply you've got two NICs. However, the first address isn't valid - the first 3 bytes are not registered at the IEEE (you can look them up at standards.ieee.org) - whereas the 2nd MAC is a Linksys address.
I don't what the story is with the first address, but try googling for it, and you get a number of direct hits.
http://www.google.ch/search?hl=en&q=00%3A4c%3A69%3A6e%3A75%3A79
And for a MAC address that is supposedly universally unique, I wouldn't expect an awful lot of hits in google.
Now that is really really strange! There are 372 posts out there on 00:4c:69:6e:75:79. How in the world can that happen? Is there anything that could cause SuSE to report the wrong mac address? Hmm...
-- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-- Regards -RP- ___________________________ If computers were made in heaven, would they be perfect? ___________________________
----- Original Message -----
From: "RutePoint"
are you using vmware ?
Nope, this is simply a SuSE 10 box that serves as mass storage, dial in, webserver and mail. -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-01-23 at 16:19 -0600, david rankin wrote:
And for a MAC address that is supposedly universally unique, I wouldn't expect an awful lot of hits in google.
Now that is really really strange! There are 372 posts out there on 00:4c:69:6e:75:79. How in the world can that happen? Is there anything that could cause SuSE to report the wrong mac address? Hmm...
Can it be created, programmed somehow, on the fly? If the number can be programmed, it can also be erased, perhaps by accident. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD1W6HtTMYHG2NR9URAjHqAJwKGTy0Qa4b1zglli+iAIULSNoe/QCeOFbQ w0AP5lY67300tA6ZIHydc9A= =tIfz -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Monday 2006-01-23 at 16:19 -0600, david rankin wrote:
And for a MAC address that is supposedly universally unique, I wouldn't expect an awful lot of hits in google.
Now that is really really strange! There are 372 posts out there on 00:4c:69:6e:75:79. How in the world can that happen? Is there anything that could cause SuSE to report the wrong mac address? Hmm...
Can it be created, programmed somehow, on the fly?
If the number can be programmed, it can also be erased, perhaps by accident.
- -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76
iD8DBQFD1W6HtTMYHG2NR9URAjHqAJwKGTy0Qa4b1zglli+iAIULSNoe/QCeOFbQ w0AP5lY67300tA6ZIHydc9A= =tIfz -----END PGP SIGNATURE----- -- If you're not confused, you're not trying hard enough. -- Please note - Due to the intense volume of spam, we have installed site-wide spam filters at catherders.com. If email from you bounces,
"supposedly" is the correct word. I once had 2 duplicate mac addresses on the same lan - manufacturer screwed up. I suppose if it could happen once it could happen twice. Mike- On Tue, 24 Jan 2006 01:02:13 +0100 (CET), you wrote: try non-HTML, non-encoded, non-attachments,
On Mon, 2006-01-23 at 00:06 -0600, david rankin wrote:
Mates,
I have built a new box for the house, and it is testing my understanding of Linux. It is also testing logic. I know I'm aging, but I have ruled out Alzheimer's. Here is the scoop.
When I first installed SuSE 10, the network would come up and it used eth0:
Simply /etc/sysconfig/network/ifcfg-eth-id-00:4c:69:6e:75:79 would bring up the Linksys card as eth0. This is how it worked.
Then on a subsequent reboot the network doesn't come up. I mean loopback is fine, but the NIC fails to load and the error is "unable to load mandatory services.." Yes, I understand the mandatory devices loading and /etc/sysconfig/network/config.
On reboot, the network fails. dmesg says it is now trying to load eth1? Ok, cp ifcfg-eth-id-00:4c:69:6e:75:79 ifcfg-eth1 rcnetwork restart -- presto! it comes up. So then I leave both ifcfg-eth-id-00:4c:69:6e:75:79 and ifcfg-eth1 in /etc/sysconfig/network. Some subsequent reboots work some fail.
Latest reboot, network fails, /var/log/boot.omsg says it is now looking for:
I had the same problem; I have 2 NIC's. Previously, one could decide which NIC MAC goes to which device. Since SuSE 9.3 it has changed, in that the OS picks the MAC and device no. at random. I solved the problem by editing in etc/sysconfig/network/ directory (you will have to change it every time YaST reconfigures new NICS). The problem was solved by an answer by the info from Michael Cox in Dec. 2005: "Find the file named ifcfg-eth-id-mac address of the particular nic. Edit the contents to assign the ipaddress you want to the particular NIC with that MAC address. Repeat for the rest of your NICs" Cheers :-) Al
Al Active wrote:
which NIC MAC goes to which device. Since SuSE 9.3 it has changed, in that the OS picks the MAC and device no. at random.
AFACT, in SUSE 10.0 the default is now to use persistent names. Check your /etc/sysconfig/network/config - # # Forces all interfaces eth* ath* wlan* and ra* to be persistent # via udev. # See /usr/share/doc/package/sysconfig/README.Persistent_Interface_Names # for details. # FORCE_PERSISTENT_NAMES=yes Also have a look at: /usr/share/doc/packages/sysconfig/README.Persistent_Interface_Names /Per Jessen, Zürich (-4.25 °C) -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
someone else wrote and sent me the link sometime ago but i forgot the url
but here is a snip of the text that person wrote:
I'm told that this problem only shows up under certain circumstances and
that it's not specific to SuSE 9.3. I don't know - I've only ever
s een it on SuSE 9.3, but hey... Anyway, For
the archives, here's the finished workaround for using shorewall with SuSE
9.3 I've been told abo ut another approach,
but frankly, this works - so I don't plan to fix it.
Put the following in /etc/rc.d/S07shorewall, right after start) and before
exec /sbin/shorewall -f start
(Alternatively, you can put it in S05network, as the next to the last line
in case $action='START')
(Mind the word wrap - there are blank lines between each command)
echo "Stabilizing eth interface names" >/var/log/ifaceinit
echo -n "Stabilizing eth interface names"
echo "Before------------------------------" >>/var/log/ifaceinit
/sbin/ifconfig >>/var/log/ifaceinit
/sbin/ifconfig eth0 down >>/var/log/ifaceinit 2>>/var/log/ifaceinit
/sbin/ifconfig eth1 down >>/var/log/ifaceinit 2>>/var/log/ifaceinit
'# remember to insert YOUR MAC ADDRESSES - these are mine!
/sbin/nameif foo0 00:40:05:7A:E0:84 >> /var/log/ifaceinit
2>>/var/log/ifaceinit
/sbin/nameif foo1 00:09:5B:BD:A5:98 >> /var/log/ifaceinit
2>>/var/log/ifaceinit
/sbin/nameif eth0 00:40:05:7A:E0:84 >> /var/log/ifaceinit 2>>
/var/log/ifaceinit
/sbin/nameif eth1 00:09:5B:BD:A5:98 >> /var/log/ifaceinit 2>>
/var/log/ifaceinit
/sbin/ifconfig eth0 up >>/var/log/ifaceinit 2>>/var/log/ifaceinit
/sbin/ifconfig eth1 up >>/var/log/ifaceinit 2>>/var/log/ifaceinit
echo "After----------------------------" >>/var/log/ifaceinit
/sbin/ifconfig>>/var/log/ifaceinit
'# assumes eth0 is your external interface - if it isn't, change this line!
route add default eth0
'# put this here just to make me happy
echo " - OK"
sleep 10
-RP- (salo -23c)
On 1/23/06, Per Jessen
Al Active wrote:
which NIC MAC goes to which device. Since SuSE 9.3 it has changed, in that the OS picks the MAC and device no. at random.
AFACT, in SUSE 10.0 the default is now to use persistent names. Check your /etc/sysconfig/network/config -
# # Forces all interfaces eth* ath* wlan* and ra* to be persistent # via udev. # See /usr/share/doc/package/sysconfig/README.Persistent_Interface_Names # for details. # FORCE_PERSISTENT_NAMES=yes
Also have a look at:
/usr/share/doc/packages/sysconfig/README.Persistent_Interface_Names
/Per Jessen, Zürich (-4.25 °C)
-- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-- Regards -RP- ___________________________ If computers were made in heaven, would they be perfect? ___________________________
Mates,
I have built a new box for the house, and it is testing my understanding of Linux. It is also testing logic. I know I'm aging, but I have ruled out Alzheimer's. Here is the scoop.
When I first installed SuSE 10, the network would come up and it used eth0:
Simply /etc/sysconfig/network/ifcfg-eth-id-00:4c:69:6e:75:79 would bring up the Linksys card as eth0. This is how it worked.
Then on a subsequent reboot the network doesn't come up. I mean loopback is fine, but the NIC fails to load and the error is "unable to load mandatory services.." Yes, I understand the mandatory devices loading and /etc/sysconfig/network/config.
On reboot, the network fails. dmesg says it is now trying to load eth1? Ok, cp ifcfg-eth-id-00:4c:69:6e:75:79 ifcfg-eth1 rcnetwork restart -- presto! it comes up. So then I leave both ifcfg-eth-id-00:4c:69:6e:75:79 and ifcfg-eth1 in /etc/sysconfig/network. Some subsequent reboots work some fail.
Latest reboot, network fails, /var/log/boot.omsg says it is now looking for:
doneWaiting for mandatory devices: eth-id-00:4c:69:6e:75:79 19 Initializing random number generatordone <notice>startproc: execve (/sbin/resmgrd) [ /sbin/resmgrd ], [ CONSOLE=/dev/console ROOTFS_FSTYPE=reiserfs TERM=linux SHELL=/bin/sh ROOTFS_FSCK=0 LC_ALL=POSIX INIT_VERSION=sysvinit-2.85 REDIRECT=/dev/tty1 COLUMNS=160 PATH=/sbin:/usr/sbin:/bin:/usr/bin:/lib/klibc/bin vga=0x31a RUNLEVEL=3 PWD=/ SPLASHCFG= PREVLEVEL=N LINES=64 HOME=/ SHLVL=2 splash=0 SPLASH=no ROOTFS_BLKDEV=/dev/hda2 _=/sbin/startproc DAEMON=/sbin/resmgrd ] Starting resource managerdone 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 0 eth-id-00:4c:69:6e:75:79 No interface found failedSetting up service network . . . . . . . . . . . . . . . .failed
I only have 1 NIC? What is going on?
OK, next go round it complains that it is now looking for another hardware address for eth1 - no changes to the system... It is looking for the NIC at 00:04:5a:87:c8:43. WTF? OK, easy enough: cp eth-id-00:4c:69:6e:75:79 eth-id-00:04:5a:87:c8:43; rm eth-id-00:4c:69:6e:75:79. rcnetwok restart -- it works! Reboot. I understand that the pci bus and the order that devices are activated and their addresses are dynamic. But where do I stop the randomness??
doneWaiting for mandatory devices: eth-id-00:04:5a:87:c8:43 19 17 eth1 device: Linksys NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) eth1 configuration: eth-id-00:04:5a:87:c8:43 eth1 IP address: 192.168.6.16/24 doneSetting up service network . . . . . . . . . . . . . . . .done
OK, great -- for now.
Obviously, I can't have a server that when it goes down, it comes up and the network (for whatever reason) is "guessing" at the hw address for the NIC. What in the heck is going on? So the questions:
(1) why is my system now wanting to load the NIC as eth1 instead of eth0? (2) how in the heck is the hardware address changing? (I set the kernel parameters noapic and nolapic in grub to try and cure it -- no joy)
I have read all the discussion on eth0, eth1 -- I know it doesn't matter what binding the system makes, but I just want to find a way to have my NIC come up each time in case I'm 1000 miles away when the power exhausts the UPC.
Do I go to a straight ifcfg-eth0 and ifcfg-eth1 setup in /etc/network/sysconfig? Do I put both eth-id-00:4c:69:6e:75:79 and eth-id-00:04:5a:87:c8:43 in there (seems like a lame Band-Aid approach)
What is the best way to solve this conundrum???
-- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com -- -- If you're not confused, you're not trying hard enough. -- Please note - Due to the intense volume of spam, we have installed site-wide spam filters at catherders.com. If email from you bounces,
Welcome to the ranks of the damned. SuSE changed the way that eth devices are assigned interface names in version 9.3 and it has since turned into a religous issue. I maintain that it's the stupidest move since 640K, but whenever I say so I'm maligned. There are two solutions to the problem. Here's the one that I use- http://www.catherders.com/tikiwiki-1.9.1/tiki-read_article.php?articleId=36 If you don't use shorewall, put it in boot.localnet google will help you find the other method, I don't have a link handy. Mike- On Mon, 23 Jan 2006 00:06:28 -0600, you wrote: try non-HTML, non-encoded, non-attachments,
Mates: I think I've found the cause and the cure -- but not the answer.
OK, next go round it complains that it is now looking for another hardware address for eth1 - no changes to the system... It is looking for the NIC at 00:04:5a:87:c8:43. WTF? OK, easy enough: cp eth-id-00:4c:69:6e:75:79 eth-id-00:04:5a:87:c8:43; rm eth-id-00:4c:69:6e:75:79. rcnetwok restart -- it works! Reboot. I understand that the pci bus and the order that devices are activated and their addresses are dynamic. But where do I stop the randomness??
The problem seems to be in /etc/udev/rules.d/30-net_persistent_names.rules. The question [bug] is how in the heck duplicate entries got created in the first place. Something in SuSE setup must have created the first entry. Of course, the hardware address is wrong, but for some reason it is there. As noted, this must be a popular MAC address given the 372 references to it on Google. Also, it must have worked following installation since Yast and online update were able to connect during set up. # This rules are autogenerated from /sbin/rename_netiface. But you can modify # them, but make sure that you don't use an interface name twice. Also add such # interface name rules only in this rules file. Otherwise rename_netiface will # create wrong rules for new interfaces. # It is safe to delete a rule, as long as you did not disable automatic rule # generation. Only if all interfaces get a rule the renaming will work # flawlessly. See also /etc/udev/rules.d/31-net_create_names.rules. # # Read /usr/share/doc/packages/sysconfig/README.Persistent_Interface_Names for # further information. # # Use only a-z, A-Z and 0-9 for interface names! # SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:4c:69:6e:75:79", IMPORT="/sbin/rename_netiface %k eth0" SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:04:5a:87:c8:43", IMPORT="/sbin/rename_netiface %k eth1" Then on subsequent reboot, the network failed because there is no NIC that corresponds to eth-id-00:4c:69:6e:75:79. Also, due to the multiple entries in /etc/udev/rules.d/30-net_persistent_names.rules above, eth0 would fail and the NIC with the real MAC address of 00:04:5a:87:c8:43 would load as eth1. This caused no end of WTFs? Reading the list, I know I'm not the only poor sucker that has pulled his hair out over this problem. The problem seems to be that somewhere during initial setup, if Yast can't guess the right driver or MAC for the NIC, it makes one up that will work. Then it leaves the guessed at MAC and device in the above file. This is a big problem. I'll leave it to the Gurus to figure out who?, what?, where?, when?, how? and why? this happens and how? to fix it. Thanks for all that replied. If you have lost eth0 and don't know why you can't get it back, I'll bet that it is for the same reason. -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
dunno whether you are ware but if your hardware has bluetooth support,
but bluetooth as well has mac addresses so the address could be comming
from there
On 1/25/06, david rankin
Mates:
I think I've found the cause and the cure -- but not the answer.
OK, next go round it complains that it is now looking for another
hardware
address for eth1 - no changes to the system... It is looking for the NIC at 00:04:5a:87:c8:43. WTF? OK, easy enough: cp eth-id-00:4c:69:6e:75:79 eth-id-00:04:5a:87:c8:43; rm eth-id-00:4c:69:6e:75:79. rcnetwok restart -- it works! Reboot. I understand that the pci bus and the order that devices are activated and their addresses are dynamic. But where do I stop the randomness??
The problem seems to be in /etc/udev/rules.d/30-net_persistent_names.rules. The question [bug] is how in the heck duplicate entries got created in the first place. Something in SuSE setup must have created the first entry. Of course, the hardware address is wrong, but for some reason it is there. As noted, this must be a popular MAC address given the 372 references to it on Google. Also, it must have worked following installation since Yast and online update were able to connect during set up.
# This rules are autogenerated from /sbin/rename_netiface. But you can modify # them, but make sure that you don't use an interface name twice. Also add such # interface name rules only in this rules file. Otherwise rename_netiface will # create wrong rules for new interfaces. # It is safe to delete a rule, as long as you did not disable automatic rule # generation. Only if all interfaces get a rule the renaming will work # flawlessly. See also /etc/udev/rules.d/31-net_create_names.rules. # # Read /usr/share/doc/packages/sysconfig/README.Persistent_Interface_Names for # further information. # # Use only a-z, A-Z and 0-9 for interface names! # SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:4c:69:6e:75:79", IMPORT="/sbin/rename_netiface %k eth0" SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:04:5a:87:c8:43", IMPORT="/sbin/rename_netiface %k eth1"
Then on subsequent reboot, the network failed because there is no NIC that corresponds to eth-id-00:4c:69:6e:75:79. Also, due to the multiple entries in /etc/udev/rules.d/30-net_persistent_names.rules above, eth0 would fail and the NIC with the real MAC address of 00:04:5a:87:c8:43 would load as eth1. This caused no end of WTFs?
Reading the list, I know I'm not the only poor sucker that has pulled his hair out over this problem. The problem seems to be that somewhere during initial setup, if Yast can't guess the right driver or MAC for the NIC, it makes one up that will work. Then it leaves the guessed at MAC and device in the above file. This is a big problem. I'll leave it to the Gurus to figure out who?, what?, where?, when?, how? and why? this happens and how? to fix it.
Thanks for all that replied. If you have lost eth0 and don't know why you can't get it back, I'll bet that it is for the same reason.
-- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-- Regards -RP- ___________________________ If computers were made in heaven, would they be perfect? ___________________________
From: "RutePoint"
dunno whether you are ware but if your hardware has bluetooth support, but bluetooth as well has mac addresses so the address could be comming from there
Nope, no bluetooth. This is a 5 year old Abit KT7 board with a 5 year only Linksys NIC. Was Bluetooth even around in '01? -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
david rankin wrote:
Nope, no bluetooth. This is a 5 year old Abit KT7 board with a 5 year only Linksys NIC. Was Bluetooth even around in '01?
Barely. The Bluetooth SIG was formed in 1999. I suspect actual Bluetooth products would have been pretty rare in '01. http://en.wikipedia.org/wiki/Bluetooth /Per Jessen, Zürich (-0.82 °C) -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
david rankin wrote:
The problem seems to be in /etc/udev/rules.d/30-net_persistent_names.rules. The question [bug] is how in the heck duplicate entries got created in the first place.
Yep, I would report that to Novell - bugzilla.novell.com. Especially given that some apparently bogus MAC-address is found and entered.
Something in SuSE setup must have created the first entry. Of course, the hardware address is wrong, but for some reason it is there. As noted, this must be a popular MAC address given the 372 references to it on Google.
And as "a popular MAC address" is clearly oxymoronic, it's gotta be a bug. Maybe someone decided to conjure up a "hidden" MAC-address for some or other purpose, and it got lose?
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:4c:69:6e:75:79", IMPORT="/sbin/rename_netiface %k eth0" SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:04:5a:87:c8:43", IMPORT="/sbin/rename_netiface %k eth1"
I would just edit this file so you're left with: SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:04:5a:87:c8:43", IMPORT="/sbin/rename_netiface %k eth0" I still don't understand why an 'eth1' is even mentioned during startup, but ...
Reading the list, I know I'm not the only poor sucker that has pulled his hair out over this problem. The problem seems to be that somewhere during initial setup, if Yast can't guess the right driver or MAC for the NIC, it makes one up that will work.
Something like that - but I don't think it's YaST, given how often that particular MAC address is referenced on various mailing-lists. /Per Jessen, Zürich (-5.75 °C) -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
Per Jessen wrote:
david rankin wrote:
The problem seems to be in /etc/udev/rules.d/30-net_persistent_names.rules. The question [bug] is how in the heck duplicate entries got created in the first place.
Yep, I would report that to Novell - bugzilla.novell.com. Especially given that some apparently bogus MAC-address is found and entered.
I did some more googling, and I'm beginning to think 00:4c:69:6e:75:79 is somehow a default MAC-address created/assigned by the tulip driver when it cannot find a MAC-address on the device itself. Yep, I've just now had a look at the tulip driver - the 00:4c:69:6e:75:79 is exactly that, a fake MAC-address: tulip_core.c: char last_phys_addr[6] = {0x00, 'L', 'i', 'n', 'u', 'x'}; When no EEPROM is found, the MAC-address is setup as the above. ('L'=0x4C, 'i'=0x69, 'n'=0x6e, ... etc). I could suspect this whole thing to be caused by a faulty NIC that sometimes reports a MAC-address, and sometimes doesn't. At install-time, it didn't and you ended up with 00:4c:69:6e:75:79 = "Linux". Sometime later the NIC did come up with a MAC-address, and YaST can't help but conclude you've got two NICs. /Per Jessen, Zürich (-5.32 °C) -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
some nic cards facilitate the changing of mac addresses, maybe this is the
case and the nic driver is "faulty" ??
On 1/25/06, Per Jessen
Per Jessen wrote:
david rankin wrote:
The problem seems to be in /etc/udev/rules.d/30-net_persistent_names.rules. The question [bug] is how in the heck duplicate entries got created in the first place.
Yep, I would report that to Novell - bugzilla.novell.com. Especially given that some apparently bogus MAC-address is found and entered.
I did some more googling, and I'm beginning to think 00:4c:69:6e:75:79 is somehow a default MAC-address created/assigned by the tulip driver when it cannot find a MAC-address on the device itself.
Yep, I've just now had a look at the tulip driver - the 00:4c:69:6e:75:79 is exactly that, a fake MAC-address:
tulip_core.c:
char last_phys_addr[6] = {0x00, 'L', 'i', 'n', 'u', 'x'};
When no EEPROM is found, the MAC-address is setup as the above. ('L'=0x4C, 'i'=0x69, 'n'=0x6e, ... etc).
I could suspect this whole thing to be caused by a faulty NIC that sometimes reports a MAC-address, and sometimes doesn't. At install-time, it didn't and you ended up with 00:4c:69:6e:75:79 = "Linux". Sometime later the NIC did come up with a MAC-address, and YaST can't help but conclude you've got two NICs.
/Per Jessen, Zürich (-5.32 °C)
-- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-- Regards -RP- ___________________________ If computers were made in heaven, would they be perfect? ___________________________
RutePoint wrote:
Per Jessen wrote:
I could suspect this whole thing to be caused by a faulty NIC that sometimes reports a MAC-address, and sometimes doesn't. At install-time, it didn't and you ended up with 00:4c:69:6e:75:79 = "Linux". Sometime later the NIC did come up with a MAC-address, and YaST can't help but conclude you've got two NICs.
some nic cards facilitate the changing of mac addresses, maybe this is the case and the nic driver is "faulty" ??
I guess it's possible, but given the maturity of the tulip driver, I'd blaim the card first and the driver second. Still, a fake MAC-address = "Linux" is a bit odd - I wonder if it's the norm in NIC drivers, in which case YaST ought to know about it. /Per Jessen, Zürich (-1.13 °C) -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
From: "Per Jessen"
Per Jessen wrote:
david rankin wrote:
The problem seems to be in /etc/udev/rules.d/30-net_persistent_names.rules. The question [bug] is how in the heck duplicate entries got created in the first place.
Yep, I would report that to Novell - bugzilla.novell.com. Especially given that some apparently bogus MAC-address is found and entered.
I did some more googling, and I'm beginning to think 00:4c:69:6e:75:79 is somehow a default MAC-address created/assigned by the tulip driver when it cannot find a MAC-address on the device itself.
Yep, I've just now had a look at the tulip driver - the 00:4c:69:6e:75:79 is exactly that, a fake MAC-address:
tulip_core.c:
char last_phys_addr[6] = {0x00, 'L', 'i', 'n', 'u', 'x'};
When no EEPROM is found, the MAC-address is setup as the above. ('L'=0x4C, 'i'=0x69, 'n'=0x6e, ... etc).
I could suspect this whole thing to be caused by a faulty NIC that sometimes reports a MAC-address, and sometimes doesn't. At install-time, it didn't and you ended up with 00:4c:69:6e:75:79 = "Linux". Sometime later the NIC did come up with a MAC-address, and YaST can't help but conclude you've got two NICs.
Per, This is the most plausable explanation I can think of. But what it doesn't explain (or what I'm definately not smart enough to understand) is how on initial boot the system was able to use the 'fake' MAC address for online update, etc.. It could be the card itself getting flakey, but I don't think so. It seems more likely that there is something in the install process that causes Yast to pull the default MAC instead of the MAC from the card. Oh, well, at least I have learned quite a bit more about device and interface initialization by this exercise. -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
david rankin wrote:
This is the most plausable explanation I can think of. But what it doesn't explain (or what I'm definately not smart enough to understand) is how on initial boot the system was able to use the 'fake' MAC address for online update, etc..
Actually that should be perfectly possible. I don't think there's anything that'll check the validity of a MAC-address, so as long as it's unique on the physical network, it'll work fine.
It could be the card itself getting flakey, but I don't think so. It seems more likely that there is something in the install process that causes Yast to pull the default MAC instead of the MAC from the card.
I don't think YaST is to blaim. The default MAC is supplied by the tulip driver when it cannot read the EEPROM. This does sound a bit like what someone else suggested - a programmable MAC-address.
Oh, well, at least I have learned quite a bit more about device and interface initialization by this exercise.
That's the best bit of tinkering with this - all this good stuff you pick up along the way. :-) Did you get it to work, by the way? /Per Jessen, Zürich (0.00 °C) -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
From: "Per Jessen"
david rankin wrote:
Oh, well, at least I have learned quite a bit more about device and interface initialization by this exercise.
That's the best bit of tinkering with this - all this good stuff you pick up along the way. :-) Did you get it to work, by the way?
Yes, It works like a champ. I removed: SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:4c:69:6e:75:79", IMPORT="/sbin/rename_netiface %k eth0" and then I changed: SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:04:5a:87:c8:43", IMPORT="/sbin/rename_netiface %k eth1" to: SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:04:5a:87:c8:43", IMPORT="/sbin/rename_netiface %k eth0" Now the network comes up as expected every time. I also submitted it to bubzilla and the concensus is that it is too rare to fix. Basically, just edit /etc/udev/rules.d/30-net_persistent_names.rules manually to remove the offending entry. I like that solution, and that is what I figured, but it just took me three days to find /etc/udev/rules.d/30-net_persistent_names.rules.
/Per Jessen, Zürich (0.00 °C)
Glad to see you are enjoying a heat wave ; -) Thanks again for your help! -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
On Tue, 24 Jan 2006 20:11:14 -0600, david rankin wrote:
The problem seems to be in /etc/udev/rules.d/30-net_persistent_names.rules.
Please report it at https://bugzilla.novell.com in order for SUSE to take notice. Philipp
participants (10)
-
Al Active
-
Carlos E. R.
-
david rankin
-
kanenas@hawaii.rr.com
-
Ken Schneider
-
Michael W Cocke
-
Per Jessen
-
Philipp Thomas
-
Richard Atcheson
-
RutePoint