installing new network card in linux

[Red Squirrel]

I just added another nic to my server. How do I tell linux about it? If I do ifconfig I still see only 1 nic. Should it have apeared automaticly? or do I need to do something?

 

[xtknight]

When you type ifconfig sometimes not all of them are showing.

If your current card is eth0, try this: ifconfig eth1 up

It's possible it's just not detected. Type lspci and see if you see it.

 

[Red Squirrel]

sweet, that command could come in handy... and yep it does see it, so at least I know it detected it, as that was my fear.

ifup eth1 or ifconfig eth1 up does not work as it can't find the card, so I'm guessing something else needs to be done to register it as a nic and generate the ifcfg-eth1 file. Do I need to run modprobe? that did come up on some google searches, though I need to type the specicic device and not sure what to refer it as, tried various things.

The nic is:
00:0d.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 20)

 

[xtknight]

try

modprobe tulip

 

[Red Squirrel]

Hmm that did not give any error like device not found, so it did do something, but I still dont see eth1, and I also tried various things such as ifconfig eth1 up, service network restart, etc. anything else I need to do?

 

[xtknight]

dmesg | tail
dmesg | grep tulip
dmesg | grep DEC

Maybe one of these commands will give you some info about how the card is being detected. What distro/version/arch?

 

[Red Squirrel]

This is the entire output of dmesg: Using 2.6.15-1.2054_FC5 i686 athlon i386


[root@borg ~]# dmesg
eth0: Promiscuous mode enabled.
device eth0 entered promiscuous mode
device eth0 left promiscuous mode
bridge-eth0: disabling the bridge
bridge-eth0: down
eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
bridge-eth0: enabling the bridge
bridge-eth0: up
eth0: no IPv6 routers present
bridge-eth0: disabling the bridge
bridge-eth0: down
eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
bridge-eth0: enabling the bridge
bridge-eth0: up
eth0: no IPv6 routers present
[root@borg ~]#

 

[xtknight]

lsmod | grep tulip

Is the tulip module loaded?

00:0d.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 20)

That's the card you're trying to get detected right, not the one that's installed on eth0?

 

[Red Squirrel]

Yes thats the card. Though when I do a network restart, I get this:

Shutting down interface eth0: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0: RTNETLINK answers: File exists
Error adding address 10.1.1.10 for eth0.
[ OK ]
[root@borg network-scripts]#


Almost seems as if the new card is trying to use eth0. Could that be? But my tests do show otherwise, I typed tcpdump in ssh console (which makes it continuously output data) and the right nic LED was flashing, not the new one.

and how would I tell if the tulip module is loaded?

 

[xtknight]

lsmod | grep tulip

If that returns something it means tulip is loaded. What's the lspci of your other card by the way?

I'm not sure. I guess it could be using eth0...

Maybe this will help: http://forums.fedoraforum.org/showthread.php?t=103474

 

[Red Squirrel]

I rebooted, getting more info now:


[root@borg ~]# lsmod | grep tulip
tulip 46817 0


[root@borg ~]# dmesg | grep tulip
tulip0: EEPROM default media type Autosense.
tulip0: Index #0 - Media 10baseT (#0) described by a 21140 non-MII (0) block.
tulip0: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block.
tulip0: Index #2 - Media 10baseT-FDX (#4) described by a 21140 non-MII (0) block.
tulip0: Index #3 - Media 100baseTx-FDX (#5) described by a 21140 non-MII (0) block.
tulip0: MII transceiver #1 config 3100 status 786b advertising 01e1.



I did find this too...

eth1: VIA Rhine II at 0xd4800000, 00:05:5df:84:69, IRQ 17.


eth1 is still not showing up in ifconfig though, and that Rhine card should be eth0 not eth1.... so it looks like for some reason this new card thinks it is primary, and its causing a conflict with the existing eth0 card. ifconfig eth1 still says unknown device though.

But if worse comes to worse I'll deal with eth0 being this card and eth1 being the old one, most apps specify the interface by IP anyway.

 

[xtknight]

Weird.

So does your tulip work now but not the VIA Rhine?

ifconfig tulip0 up

What does that do? Or is the tulip card eth0?

 

[Red Squirrel]

no such device. ifconfig shows this:

eth0 Link encap:Ethernet HWaddr 00:05:5DF:84:69
inet addr:10.1.1.10 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::205:5dff:fedf:8469/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:666 errors:0 dropped:0 overruns:0 frame:0
TX packets:740 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:94330 (92.1 KiB) TX bytes:94456 (92.2 KiB)
Interrupt:17 Base address:0x4000

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

vmnet1 Link encap:Ethernet HWaddr 00:50:56:C0:00:01
inet addr:192.168.239.1 Bcast:192.168.239.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:61 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

vmnet8 Link encap:Ethernet HWaddr 00:50:56:C0:00:08
inet addr:192.168.117.1 Bcast:192.168.117.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:61 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)


The mac address is not the mac address of the new card though, but it is specified in ifcfg-eth0 so perhaps its just overriding the mac. If I do data transfer (such as a tcp dump in ssh) the new card does not blink, but the old one. So this is telling me eth0 is still the old one, but that the new one is trying to be eth0 as well. I did notice vmware wont start properly anymore, so there is some funky network issues going on now.

 

[xtknight]

This is FC5? Wow, I'm surprised it's this hard just to add a NIC. Maybe some software system component went awry. Have you tried kudzu?

For VMware do vmware-config.pl as root. If after that it still doesn't work I have no idea what's going on with the network.

 

[Red Squirrel]

kudzu does not seem to do anything, no error or anything, theres a small delay then back to the prompt. still no eth1. Is there a proceedure specificly for network cards? I tried creating a dchp ifcfg-eth1 file but theres more to it then that since it still does not reconize eth1.

 

[Red Squirrel]

I unspecified the mac in ifcfg-eth0 but in ifconfig it still shows the same mac, which also matches with the output of kudzu -p so as far as things go eth0 is still the old card, so I need to make the new card eth1. What do I do to make it happen? The card does show up when I do kudzu -p

class: NETWORK
bus: PCI
detached: 0
device: dev11160
driver: tulip
desc: "Digital Equipment Corporation DECchip 21140 [FasterNet]"
network.hwaddr: 00:00:e8:2f7:a7
vendorId: 1011
deviceId: 0009
subVendorId: 0000
subDeviceId: 0000
pciType: 1
pcidom: 0
pcibus: 0
pcidev: d
pcifn: 0
-
class: NETWORK
bus: PCI
detached: 0
device: eth0
driver: via-rhine
desc: "VIA Technologies, Inc. VT6102 [Rhine-II]"
network.hwaddr: 00:05:5df:84:69
vendorId: 1106
deviceId: 3065
subVendorId: 1186
subDeviceId: 1400
pciType: 1
pcidom: 0
pcibus: 0
pcidev: f
pcifn: 0


First entry is the new card.


[root@borg dev]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:05:5DF:84:69
inet addr:10.1.1.10 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::205:5dff:fedf:8469/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:41667 errors:0 dropped:0 overruns:0 frame:0
TX packets:95386 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3407220 (3.2 MiB) TX bytes:29772026 (28.3 MiB)
Interrupt:17 Base address:0x4000


And macs match.

Though its still odd that this broke vmware, but I'm not worried about that issue (yet) since I hope it will simply fix itself when I get eth1 to work properly. Right now if I try to start a VM it just says that there was an error, and that its the end of the message. (does not show an actual error string, same with the log - vmware server always does that though if theres a problem).

But to not get side tracked I dont care about the vmware issue now, I just want to get eth1 to show up, and I'll post another thread if vmware still wont work.

 

[Nothinman]

eth1 is still not showing up in ifconfig though, and that Rhine card should be eth0 not eth1.... so it looks like for some reason this new card thinks it is primary, and its causing a conflict with the existing eth0 card. ifconfig eth1 still says unknown device though.

Just running 'ifconfig' will only show up interfaces, have you looked through the output of 'ifconfig -a' yet? And there is no such thing as a primary or secondary NIC to the kernel, the names they get (eth0, eth1, etc) are completely arbitrary and in this case are determined by the order the modules were loaded. If you want to make sure the same NIC gets the same name you'll need to figure out how Fedora wants you to do that, I know Debian and Ubuntu use udev rules for that.

class: NETWORK
bus: PCI
detached: 0
device: dev11160
driver: tulip
desc: "Digital Equipment Corporation DECchip 21140 [FasterNet]"

If this output is right it looks like the NIC is called dev11160 instead of eth1.

 

[Red Squirrel]

hmm good call

[root@borg dev]# ifconfig -a
dev11160 Link encap:Ethernet HWaddr 00:00:E8:2F7:A7
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:16 Base address:0x2000

eth0 Link encap:Ethernet HWaddr 00:05:5DF:84:69
inet addr:10.1.1.10 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::205:5dff:fedf:8469/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:42945 errors:0 dropped:0 overruns:0 frame:0
TX packets:97028 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3542184 (3.3 MiB) TX bytes:30744022 (29.3 MiB)
Interrupt:17 Base address:0x4000

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

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 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)

vmnet1 Link encap:Ethernet HWaddr 00:50:56:C0:00:01
inet addr:192.168.239.1 Bcast:192.168.239.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:73 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

vmnet8 Link encap:Ethernet HWaddr 00:50:56:C0:00:08
inet addr:192.168.117.1 Bcast:192.168.117.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:73 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
ifconf
[root@borg dev]#


I see it. Is it normal for it to be called that? Seems kind of odd. Figured they would always be called eth0, eth1, etc. Other then that the nic does seem to be working now. I set a static IP for it, I ran a tcp dump on it strictly, pinged it from my windows box and it got the packets.

Is it possible to rename it to eth1? Not a huge issue, would just be easier that way.

 

[Nothinman]

I see it. Is it normal for it to be called that? Seems kind of odd. Figured they would always be called eth0, eth1, etc

No it's not normal, but technically they can be called pretty much anything you want. I remember reading about this a while back but I don't remember the real cause or the fix.

Is it possible to rename it to eth1? Not a huge issue, would just be easier that way.

Sure, as I said Debian and Ubuntu both use udev rules for that but I have no idea how FC wants you to do it.

 

[daveqb]

Solaris uses names similiar to the type of NIC, like Realtek is rtl0 or something like that.

I think sticking to the eth0....eth9... etc make it easier to find, but to each (distro) there own.

 

[Red Squirrel]

Odd, I rebooted, and it got renamed to eth1.... this is scary. Somehow it broke one of my VMs but thats a whole seperate issue.

To think, this nic install would of been brainless under windows.

 

[n0cmonkey]

Originally posted by: RedSquirrel
Odd, I rebooted, and it got renamed to eth1.... this is scary. Somehow it broke one of my VMs but thats a whole seperate issue.

To think, this nic install would of been brainless under windows.

Unless you have a Linksys Etherfast card and no driver disk... Each rev of the card uses different drivers, and you don't know which version you have unless you take it out of the machine...

 

[Nothinman]

Odd, I rebooted, and it got renamed to eth1.... this is scary. Somehow it broke one of my VMs but thats a whole seperate issue.

I really doubt it broke your VMs unless you had their network tied to the old device name for some reason. And as I said, figure out how FC does static network device names or just use udev since I know that FC uses udev.

To think, this nic install would of been brainless under windows.

And as long as you stick with that attitude you'll never become any good with Linux.

 

[Red Squirrel]

Turns out the VM issue was a permission issue that decided to pop up. During this process I rebooted several times so the permissions probably got changed for some reason after the last reboot so I never noticed till now that it could not boot up. And udev is not a valid command as I tried it.

 

[Nothinman]

And udev is not a valid command as I tried it.

No it's not, it's a daemon and a handful of support utils. The daemon that manages your /dev directory.