Red Hat Bugzilla – Bug 60024
Only one Ethernet board communicates
Last modified: 2008-08-01 12:22:52 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.14-5.0 i486) Description of problem: If more than one Ethernet board is installed and configured, only the first to be configured will send or receive packets. A second board appears to configure normally, and gives normal output from ifconfig or a ping from the host where the board is installed. But pinging any other host gives a "host unreachable" message, and pinging the interface from another host also gives "host unreachable". tcpdump running on another host shows no activity when the second interface is brought up, not even arp packets. If arp entries are put in by hand, pings from either end time out, and the second interface doesn't respond to external pings. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install and configure any Ethernet card as eth0. Bring up and test the interface. 2. Install an Ethernet card of either the same type or a different type as eth1. Bring up the interface. Read the status with ifconfig; it looks normal. Read the routing table with route; both boards have routes to their respective nets. Ping the interface's address from the same host; a response is received. 3. Attempt to reach another host on the net connected to eth1, or communicate with the interface from another host. Observe the net with tcpdump. The interface neither transmits packets nor responds to arriving packets. Actual Results: No more than one Ethernet board sends and receives packets. Expected Results: The host should operate dual-homed. Additional info: Dual Ethernet boards worked out-of-the-box on RH 6.0, and has never worked on 6.2, 7.0, or 7.2. Board types tested are ISA NE-2000 clones and PCI 3C9095B Combo. It doesn't matter which type is installed first, eth0 always works and eth1 never works. It doesn't matter whether static addressing or DHCP is used. It doesn't matter whether eth0 is up or down; eth1 never communicates. It doesn't matter whether the platform is a 486 or a Pentium. Kernel is stock RH from CD-ROM. OS is installed with no firewall, to eliminate that as a possible cause. Searched Customization Guide -- no clues found. Read through kernel config files in /usr/src/linux; didn't see anything that appeared to relate to dual-homed hosts or using multiple network interfaces. Once a simple dual-homed host works, the next objective is to set up an iptables firewall/router.
Ok, since my home firewall box has 2 different nics as well, I know it ought to work in principle. So, question: Can you attach the following 1) Output of "lspci" 2) Output of "ifconfig" 3) Output of "route -n"
Created attachment 46741 [details] Output of lspci command, as requested
Created attachment 46742 [details] Output of ifconfig command
Created attachment 46743 [details] Output of route command
Created attachment 46744 [details] Output of ping through eth0 to a working host
Created attachment 46745 [details] Output of ping through eth1 to a working host
The requested command outputs are attached as text files. I also included the outputs of pings using the two Ethernet boards. Sorry it took so long to get this back to you. There was a rush on at work.
eth0 has an invalid boardcast address: 255.255.255.255 are these nics connected to the same hub/switch ?
No. eth0 is connected to network 192.168.254.0, and gets its IP address, broadcast address, and everything else from a Siemens 2614 firewall. This works OK, in spite of the odd broadcast address. That's just the way the 2614 wants it. eth1 is manually configured, and connected to network 192.168.203.0, which has other manually configured hosts on it, which talk to each other. The broadcast address oddity is probably a red herring. I had the same problems earlier, when I configured both network boards manually, connecting them to different nets where all hosts had static addresses. Either board will communicate, if it's the first board to be configured after RH 6.2 or 7.2 is installed from CD-ROM. Using ifconfig to set the IP address manually, whatever board is working will communicate with any net it's plugged into. But the second board to be configured, regardless of which type of board it is, never communicates with anything.
If it would help you investigate the bug, I think I could contrive to give you root access to the dual-homed Linux box and leave it powered up. I could configure the 2614 to expose the Linux box to the Internet, then set up a Siemens 2601 on the other network. The 2601 does little but present a simple web page. This has negligible security downside for me, because there is nothing on the Linux box except a pristine RH 7.2 installation and some config files that didn't succeed in getting dual-homing to work. Once the fix is documented, I can just re-install from CD-ROM and wipe out any residue of third-party cracking.
This is a shot in the dark, but could the behavior be related to default settings in /proc? If so, what settings might be involved, and what config files might control them?
New clue. According to the 3C905B Combo board's manual, the board auto-detects which port is connected to the network. Under RH 6.0, it does. But under RH 7.2, the board always attempts to communicate on the 10BaseT port, regardless of which port is actually connected to the network. In this case, the 10Base2 port is plugged in. If a cable is plugged into the 3C905B's 10BaseT port, and the jumper-configured NE-2000 is connected to a 10Base2 network, the Pentium successfully operated as a dual-homed host under RH 7.2. No method was found to get the 3C905B board to use the 10Base2 port under RH 7.2. The command ifconfig eth0 media 10base2 produced the error message SIOCSIFMAP: Operation not supported and editing /etc/sysconfig/network-scripts/ifcfg-eth0 to include the line MEDIA=10base2 had no effect. Each test in this set was done with the network cables connected before the computer was powered-up. So it looks as though the 3C59x driver has a bug that was not present in earlier revisions: it overrides the media autodetection, and doesn't offer a manual override to undo the default override.
Solid clue. Installed Libranet Linux 2.0 on the same hardware. This is a Linux 2.4.16 based on Debian. As with RH 7.2, the 3C905B communicated on the 10BaseT port, ignoring the type of network actually connected. But the command modprobe 3c59x xcvr=0 sent after the interface was already up switched it to the 10Base2 port. A ping to the host at the other end worked. So it appears that recent versions of the driver set the transceiver type explicitly, preventing the board from detecting the media as it should. Can't reproduce this yet. The entire network configuration disappeared after a reboot, probably because of inexperience with Libranet.
The problem of overriding the media auto-detection appears to be specific to the Linux 2.4 3c59x driver. Media auto-detection worked correctly with PCI Tulip and ISA PNP NE-2000 boards under Libranet 2.2 (Linux 2.4.16). Can't test further with the 3C905B for now, because one of the parameters used with a modprobe command during testing apparently overwrote a nonvolatile config bit; it doesn't talk under any OS now.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/