Bug 60024 - Only one Ethernet board communicates
Summary: Only one Ethernet board communicates
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-19 04:48 UTC by jac
Modified: 2008-08-01 16:22 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 15:39:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output of lspci command, as requested (395 bytes, text/plain)
2002-02-27 04:58 UTC, jac
no flags Details
Output of ifconfig command (1.25 KB, text/plain)
2002-02-27 05:00 UTC, jac
no flags Details
Output of route command (408 bytes, text/plain)
2002-02-27 05:01 UTC, jac
no flags Details
Output of ping through eth0 to a working host (304 bytes, text/plain)
2002-02-27 05:02 UTC, jac
no flags Details
Output of ping through eth1 to a working host (247 bytes, text/plain)
2002-02-27 05:03 UTC, jac
no flags Details

Description jac 2002-02-19 04:48:08 UTC
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:

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.

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
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.

Comment 1 Arjan van de Ven 2002-02-19 08:40:16 UTC
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"

Comment 2 jac 2002-02-27 04:58:35 UTC
Created attachment 46741 [details]
Output of lspci command, as requested

Comment 3 jac 2002-02-27 05:00:16 UTC
Created attachment 46742 [details]
Output of ifconfig command

Comment 4 jac 2002-02-27 05:01:26 UTC
Created attachment 46743 [details]
Output of route command

Comment 5 jac 2002-02-27 05:02:47 UTC
Created attachment 46744 [details]
Output of ping through eth0 to a working host

Comment 6 jac 2002-02-27 05:03:43 UTC
Created attachment 46745 [details]
Output of ping through eth1 to a working host

Comment 7 jac 2002-02-27 05:06:24 UTC
	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.

Comment 8 Arjan van de Ven 2002-02-27 11:42:57 UTC
eth0 has an invalid boardcast address:

are these nics connected to the same hub/switch ?

Comment 9 jac 2002-02-28 14:07:04 UTC
	No.  eth0 is connected to network, 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, 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.

Comment 10 jac 2002-03-01 05:28:52 UTC
	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.

Comment 11 jac 2002-03-02 04:23:22 UTC
	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?

Comment 12 jac 2002-03-26 05:31:12 UTC
	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.

Comment 13 jac 2002-03-31 09:56:47 UTC
	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.

Comment 14 jac 2002-04-10 04:34:22 UTC
	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.

Comment 15 Bugzilla owner 2004-09-30 15:39:23 UTC
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/

Note You need to log in before you can comment on or make changes to this bug.