Bug 222866 - impossible to network 2 or more servers
impossible to network 2 or more servers
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.4
i386 Linux
medium Severity urgent
: ---
: ---
Assigned To: Neil Horman
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-16 11:56 EST by klaas de zwart
Modified: 2007-11-16 20:14 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-09 15:18:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description klaas de zwart 2007-01-16 11:56:00 EST
Description of problem:
main board  Tyan S2925 Tomcat
chipset nVidia gForce Pro 3400 with MP55 Lan
after install of linux ES or WS the network card reports a MAC address of 
66:77:44:22:33:11, of course incorect, this causes problems with our 
application which requires MAC address verification, also we cannot put more 
than one server attached to the same switch because of this


Version-Release number of selected component (if applicable):
2.6.9-42 also tried kernel update to 2.6.9-44 latest one


How reproducible:
always


Steps to Reproduce:
1. install Redhat
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Neil Horman 2007-02-09 15:18:12 EST
Sorry, this is a pain of a problem.  At its root this is a BIOS problem. 
several Bios's have been released for the nVidia chipset in which the MAC
address for the ethernet interface is backwards.  A fix was issued for the
forcedeth driver which reverses and re-stores the MAC address so that its format
is correct.  Unfortunately, some bioses try to correct this already (for
instance, if you use pxe boot to install these systems, the pxe rom, may already
do this fixup).  The result is that the forcedeth driver then winds up
re-breaking the fix, which then gets recognized as a bad MAC adress, and
replaced with something clearly wrong (as you have observed above).

Theres nothing that we can really do to universally fix this but some options are:

1) Contact your vendor for a bios update to correct this problem.  This is the
most correct solution, and a quick browse to tyans website indicates two bios
updates, which seem to have some relevance to pxe booting.  If you use pxe, you
should definately investigate this.

2) Install the system without using pxe (if you are).  Install the system
locally, and that may allow the forcedeth driver to do the appropriate fixup for
you.

3) Assign an LAA to the forcedeth device on the commandline during install, and
subsequent boots.  Not a pretty solution, but it will get you moving forward
again, until you can implement (1) or (2).
Comment 2 David Miller 2007-02-09 17:58:58 EST
Perhaps the driver can be a bit smarter about reversing the ethernet address.

Each vendor has MAC address prefix(s) assigned to them, the driver could use
this to figure out whether the ethernet address is reversed already or not.

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