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):
Steps to Reproduce:
1. Install and configure any Ethernet card as eth0. Bring up and test the
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.
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
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
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
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
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
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
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/