Adding another NIC the one of the old got renamed

[Basher52]

How can I fix this or do I have to change alot of scripts for this?

I had eth0 as public and eth1 as internal.
When I put another one in eth1 got offline cos the mac address was different and that gotta be that the new NIC "took" it's place.

how can I fix this.

[Void Main]

This happens to me all the time. You'll probably find an entry for each of your cards in this file:

/etc/udev/rules.d/70-persistent-net.rules

In each config line there should be a mac address and a "NAME" (you probably will have eth0 and eth1). Just replace "eth0" with "eth1" in one line and do the opposite with the other line and your cards will switch names on reboot and you should be good.

[Basher52]

oh, in UDEV no wonder I didnt find it lol
this looks weird, three NICs with the same name

Code: Select all


# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# Accton Technology Corporation SMC2-1211TX (rule written by anaconda)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:10:b5:d1:07:8e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10b7:0x9050 (3c59x)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:60:08:28:3a:fa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10b7:0x9200 (3c59x)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:01:02:0a:bc:41", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10b7:0x9200 (3c59x)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:04:75:d2:79:2e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"


[Void Main]

That is weird. Make them all unique (eth0/eth1/eth2/eth3) and reboot and then see which interfaces show up in your "dmesg | grep eth" output and "/sbin/ifconfig" commands. I have seen similar entries for cards that I had previously had installed but are no longer. I'm guessing you've never had any other cards in your system though.

[Basher52]

I'll do that

I do have had other NICs in there trying to get this ethx thing changing and I can't say it's the same as I just put in, so that might be why this is then.

also with this in mind

Code: Select all

eth1      Link encap:Ethernet  HWaddr 00:04:75:D2:79:2E 
          inet addr:192.168.67.124  Bcast:192.168.67.255  Mask:255.255.255.0


it looks like it's not the last one that I just put in here.
It gotta be cos today when I started the server up again, the internal IP was back so I guess that is the NIC that was in place from the beginning.

btw, I was trying yesterday to do the H/W check manually with kudzu but that didn't exist, is this removed for the OS now?

[Void Main]

Oh, that would explain the other entries then. Every NIC you've had in there would have an entry.

[Basher52]

crap, I new this would happen.
I'm at work now and after the reboot I can't get in through ssh.

phew, i remembered that I had open up the ssh port for my work IP
this is what dmesg finds, almost the same as before the reboot
then it was only one row of '...link up, 100Mbps...' now it's two
but there is no other eth number though

Code: Select all

[root@webserver ~]# dmesg |grep eth
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
eth0: RealTek RTL8139 at 0xe8844f00, 00:10:b5:d1:07:8e, IRQ 11
eth0:  Identified 8139 chip type 'RTL-8139B'
udev: renamed network interface eth2 to eth3
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth1:  setting full-duplex.
eth0: no IPv6 routers present
eth1: no IPv6 routers present


and this is what I changed the rules file to

Code: Select all

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# Accton Technology Corporation SMC2-1211TX (rule written by anaconda)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:10:b5:d1:07:8e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10b7:0x9050 (3c59x)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:60:08:28:3a:fa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# PCI device 0x10b7:0x9200 (3c59x)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:01:02:0a:bc:41", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"

# PCI device 0x10b7:0x9200 (3c59x)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:04:75:d2:79:2e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"


I left the last one as eth1 as that showed up in ifconfig with the correct internal IP thus thinking it was the NIC that I already had in there
and this because the mac address was the same

[Void Main]

You should actually just be able to delete the lines for the ones that are no longer installed. In fact if you delete all the ones that had "eth1" it should recreate the one that really exists. I only see one MAC address in your dmesg output. Do you have any nic module aliases in your /etc/modprobe.conf or /etc/modprobe.d files? What is the output of your "/sbin/ifconfig -a"? Also, check the "HWADDR" variable in your /etc/sysconfig/network-scripts/ifcfg-eth* files and make sure the MAC address on each card matches the right config and matches what you have in the udev config.

[Basher52]

The mac address in dmesg is the eth0 thus external NIC
weird that dmesg wont show the internal NIC though

in ifconfig -a i see one extra NIX that I don't use, yet and that's eth3
so that just has to be the new one
(stupid me for not do a man on the ifconfig then I might have seen this too )

Code: Select all

eth0      Link encap:Ethernet  HWaddr 00:10:B5:D1:07:8E 
          inet addr:82.196.xxx.xxx Bcast:82.196.xxx.xxx
          Mask:255.255.254.0
          inet6 addr: fe80::210:b5ff:fed1:78e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:258664 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20137 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:20075590 (19.1 MiB)  TX bytes:15055106 (14.3 MiB)
          Interrupt:11 Base address:0x4f00

eth1      Link encap:Ethernet  HWaddr 00:04:75:D2:79:2E 
          inet addr:192.168.67.124  Bcast:192.168.67.255  Mask:255.255.255.0
          inet6 addr: fe80::204:75ff:fed2:792e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:275161 errors:0 dropped:0 overruns:1 frame:0
          TX packets:15219 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:22837839 (21.7 MiB)  TX bytes:2563007 (2.4 MiB)
          Interrupt:5 Base address:0xae80

eth3      Link encap:Ethernet  HWaddr 00:01:02:0A:BC:41 
          BROADCAST MULTICAST  MTU:1500  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:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:10 Base address:0xce00

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:184 errors:0 dropped:0 overruns:0 frame:0
          TX packets:184 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:552626 (539.6 KiB)  TX bytes:552626 (539.6 KiB)


no alias in the modprobe files.
I'll test eth3

btw, I thought the udev was supposed to be dynamic, thus deleting everything and do a probe at every boot.

[Void Main]

It is dynamic (so to speak) but with those config files you "guide" how the objects are configured when they are identified and named and how permissions are set, etc.

[Basher52]

This happens to me all the time. You'll probably find an entry for each of your cards in this file:

/etc/udev/rules.d/70-persistent-net.rules

In each config line there should be a mac address and a "NAME" (you probably will have eth0 and eth1). Just replace "eth0" with "eth1" in one line and do the opposite with the other line and your cards will switch names on reboot and you should be good.

about this '70-persistent-net.rules', why does it keep old NICs(Network Interface Card) in there?
I mean if one NIC brakes down, why keep it in there forever when it doesn't exist in anymore? do you know why they chosen this way? like the history about it.
Can't remember when but before when a new hardware appeared it asked for configuration etc and that worked perfect for NICs, just put another in and that would work perfectly, never had this kinda problem before, this had to be new for Fedora 5 or 6, can't remember.

[Void Main]

My guess is it started when they switched over to "udev" which came about with the 2.6 kernel (FC3 maybe?). It actually is nice being able to control exactly what interface a particular network card will show up as. It can bite you if you don't know about that configuration file and start switching network cards around.

[Basher52]

...It can bite you if you don't know about that configuration file and start switching network cards around.

You can say that again I still haven't noticed anything positive about it, but you said it's nice so it gotta be, hope I'll find that out in the future

Thanks for the answer

[Void Main]

...It can bite you if you don't know about that configuration file and start switching network cards around.

You can say that again :P I still haven't noticed anything positive about it, but you said it's nice so it gotta be, hope I'll find that out in the future :)

Thanks for the answer :D

I'll tell you why it's nice. In the old days if you used 2 or 3 (or 4 or 5) network cards of the same type, every time you booted it was a crapshoot which interface name they came up with. THAT isn't fun. ;)

[Basher52]

Even when you once configured them?
cos Ive been using some old 10/100 NICs from work and they all are the same type and I didn't have that problem. Once configured, they just worked.