Bug 60024

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/