Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Is it possible to bring up the interface manually?
ifconfig eth1 up
Do the lights activate when you plug a cable into the device?
I see a MAC address in the ifcfg-eth1 file, but that address doesn't seem to match anything in the other various information your system presents. If you look at the output of lspci, you see the serial number listed for the working NIC, which matches the MAC in ifcfg-eth0. The serial number listed in lspci for the Broadcom BCM5722 is this:
Capabilities: [160] Device Serial Number 00-00-00-fe-ff-00-00-00
Whereas the MAC listed in ifcfg-eth1 is:
HWADDR=00:10:18:59:d7:23
I did a lookup on the MAC address found in ifcfg-eth1, and it seems to recognize that address as a proper Broadcom device. The serial number listed for it comes up as a Xerox device when converted to what its corresponding MAC would be.
I don't know if those serial numbers are directly related to MAC addresses or not. I've never really looked at them and am not familiar with them. It does seem odd the other card has a MAC address that matches its serial number, whereas the BCM5722 does not.
I work on a RHEL 5.3 system that doesn't show serial numbers in the output of 'lspci -vv' such as you see. This is the output I see:
There is another NIC on that machine, that being an Intel. Both interfaces work well enough on that system.
I would remove the MAC address from ifcfg-eth1. Just comment out the line and see if that works.
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
TYPE=Ethernet
DEVICE=eth1
#HWADDR=00:10:18:59:d7:23
BOOTPROTO=dhcp
ONBOOT=yes
USERCTL=no
IPV6INIT=no
PEERDNS=yes
How did you set up the configuration for eth1? Did the system do it during installation? I'm curious as to where that MAC address came from.
I configured eth1 manually. A second card did show up in dmesg as shown above. But the probe failed. The lights activate when I plug in a cable. I cannot bring up eth1 manually. The error message said there was no such device.
I haven't got time to look into it right now, but that search indicates there is a problem. Hopefully you can find a solution in there somewhere. If you have another gigabit ethernet card from Broadcom, I would suggest installing it to see if it works. From what I saw glancing through the results of that search, there were some bad eeproms involved.
NO no no you have to read a little bit earlier:
PCI: Enabling device 0000:23:00.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:23:00.0[A] -> GSI 56 (level, low) -> IRQ 122
PCI: Setting latency timer of device 0000:23:00.0 to 64
tg3: Could not obtain valid ethernet address, aborting.
ACPI: PCI interrupt for device 0000:23:00.0 disabled <---------------------- HERE
tg3: probe of 0000:23:00.0 failed with error -22
ADDRCONF(NETDEV_UP): eth0: link is not ready
they are both being loaded. If you would edit your net config so both come up. Like I showed in my last post. Or use your favorite GUI interface and enable eth1 . What is it in red hat Yum or something and configure the card.
Quote:
ifconfig eth1 up
is the command to get it going.
or. like I said by default when you installed it only enables one card.
You have to enable it.
Quote:
# Config information for eth1:IPADDR[1]=""
NETMASK[1]=""
USE_DHCP[1]="yes" <--- you can use "no" if there is a conflict of irq at boot time.
DHCP_HOSTNAME[1]=""
they are both being loaded. If you would edit your net config so both come up. Like I showed in my last post. Or use your favorite GUI interface and enable eth1 . What is it in red hat Yum or something and configure the card. is the command to get it going.
or. like I said by default when you installed it only enables one card.
You have to enable it.
you need to configure it.
Found at the bottom of post #9:
Code:
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
TYPE=Ethernet
DEVICE=eth1
HWADDR=00:10:18:59:d7:23
BOOTPROTO=dhcp
ONBOOT=yes
USERCTL=no
IPV6INIT=no
PEERDNS=yes
sheldonbai:
As a last few suggestion on the matter, if you have not removed the card already, I was thinking that trying to change the MAC of the NIC would be worth a try.
The MAC shown there is the one that shows up in your ifcfg-eth1 configuration file. You could use another MAC address.
Looking at the kernel you are using, it doesn't appear you have done any system updates lately. You might try running a system update. I'm maintaining a RHEL 5.3 server that is current on updates.
[jcwx@mercury ~]$ uname -a
Linux mercury 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 6 14:01:18 EST 2010 i686 i686 i386 GNU/Linux
[jcwx@mercury ~]$
I'd guess your kernel is from somewhere in the range of a year ago. I've seen a number of bug reports related to the tg3 driver. My system is at release 3.96-1, so there have been some updates to the kernel module from the one you're using.
Finding another NIC is probably the easiest route to take, however. Doing a system update would be a good idea independent of whatever card you end up using.
**/etc/sysconfig/networking-scripts/ifcfg-eth1***
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
TYPE=Ethernet
DEVICE=eth1
HWADDR=00:10:18:59:d7:23
BOOTPROTO=dhcp <----------why?
ONBOOT=yes <--------why ? device trying to connect at the same time.
USERCTL=no
IPV6INIT=no
PEERDNS=yes
you are asking your system to connect to the internet on a second device AT BOOT. when it is already connected to first device. this will not happen with dhcp un-less you are trying to connect to another local net. then you will have to set it up or configure it.
The first device is set to connect at boot. the second according to scripts will be void til brought up manual or if configured to come up after the first device. How by configuring a static ip not auto dhcp.
you are asking your system to connect to the internet on a second device AT BOOT. when it is already connected to first device. this will not happen with dhcp un-less you are trying to connect to another local net. then you will have to set it up or configure it.
The first device is set to connect at boot. the second according to scripts will be void til brought up manual or if configured to come up after the first device. How by configuring a static ip not auto dhcp.
I don't see anything in this thread indicating that sheldonbai was attempting to configure the second interface as a public interface. Interfaces don't care if you're using public or private addressing schemes. Granted, only one default gateway is going to stick if one is requesting public addresses, and that is a problem that I imagine could be worked out -- but it would be a hell of a lot easier to simply shell out a few dollars for static IP addresses.
I have an OpenBSD device that I use for testing/basic routing. I set up a DHCP server on it, and commented out the line that defines the routers offered, which in this case was the default route. I then requested a lease from this system and it did just as I suspected -- there was no default route.
Even if sheldonbai was going to use two public interfaces on his system that wasn't cooperating, there is a strong possibility that with some scripting one could configure dual WANs with DHCP leases in conjunction with what is found here at the Linux Advanced Routing & Traffic Control HOWTO. It would be a definite PITA, but I don't see why it couldn't be done, either.
The point in what sheldonbai was having a problem with was the fact the interface never became active in the first place, so whether his intended configuration would work or not, it didn't matter because eth1 was never available. Even if the interface was improperly configured, it would still come up and show up in ifconfig. You don't have to have an interface configured to bring it up with 'ifconfig ethX up'.
I really have no doubt that if one were to load up a machine with 10 NICs, and tell them all simultaneously to request a DHCP lease, they would all do as told.
Last edited by devwatchdog; 03-20-2010 at 01:29 AM.
I really have no doubt that if one were to load up a machine with 10 NICs, and tell them all simultaneously to request a DHCP lease, they would all do as told.
please read my first post. In red hat they use the same as bsd /etc/rc.d/rc.inet1.conf.
as I stated.
both of his devices are loaded do to dmesg so all he has to do is ifconfig eth1 up.
or edit his /etc/rc.d/rc.inet1.conf
I like you have multiple nic's on multiple systems and the problem should have been solved by now. Unless it is a hardware failure. or the firm ware is not being loaded on the second card.
please read my first post. In red hat they use the same as bsd /etc/rc.d/rc.inet1.conf.
as I stated.
both of his devices are loaded do to dmesg so all he has to do is ifconfig eth1 up.
or edit his /etc/rc.d/rc.inet1.conf
I like you have multiple nic's on multiple systems and the problem should have been solved by now. Unless it is a hardware failure. or the firm ware is not being loaded on the second card.
On the RHEL/CentOS systems I've dealt with there are ifcfg-ethX files in /etc/sysconfig/network-scripts/, so the use of rc.inet1.conf appears to be isolated to Fedora.
I agree about if the interface can't be brought up with ifconfig, there are bigger issues.
On a side note, I looked for tg3 related firmware on a RHEL 5.3 system, and did not find anything that was mentioned in the various documentation I ran across on the web. Apparently the tg3 module will function without the firmware from Broadcom, as the firmware only adds certain functionality.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.