lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9a8748490711211734p2e28cfb2q666ef719c9289201@mail.gmail.com>
Date:	Thu, 22 Nov 2007 02:34:35 +0100
From:	"Jesper Juhl" <jesper.juhl@...il.com>
To:	"Michael Pyne" <michael.pyne@...mail.net>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Ayaz Abdulla" <AAbdulla@...dia.com>, jeff@...zik.org,
	netdev@...r.kernel.org, stable@...nel.org
Subject: Re: [patch 2/8] forcedeth: fix MAC address detection on network card (regression in 2.6.23)

On 22/11/2007, Michael Pyne <michael.pyne@...mail.net> wrote:
> On Wednesday 21 November 2007, Andrew Morton wrote:
> > On Wed, 21 Nov 2007 15:34:52 -0800
> >
> > "Ayaz Abdulla" <AAbdulla@...dia.com> wrote:
> > > The solution is to get the OEM to update their BIOS (instead of
> > > integrating this patch) since the MCP61 specs indicate that the MAC
> > > Address should be in correct order from BIOS.
> > >
> > > By changing the feature DEV_HAS_CORRECT_MACADDR to all MCP61 boards, it
> > > could cause it to break on other OEM systems who have implemented it
> > > correctly.
> >
> > Getting an OEM to fix their BIOS isn't always a simple thing...
> >
> > Perhaps Michael's change should be enabled by a module parameter for
> > those who happen to have the busted BIOS?
>
> I have contacted the motherboard vendor about this a couple of weeks ago per
> Ayaz's request and have received no response.  I've also upgraded to the
> latest firmware for this motherboard and the bug remains.
>
> I think it would be ideal if there were a way to detect broken MCP61's (i.e.
> those with a Gigabyte MAC ID instead of the nVidia one) and only reverse the
> MAC address then.  A module parameter would also work but then I'd need to
> remember to apply it. :)
>

Hmm, MAC address makeups are not my strong point, but are the no rules
describing the various parts of the address that could perhaps be used
to infer programatically if the address seems to be reversed or not,
and then use that detection logic for all boards that are known to
potentially have the issue?
A module parameter that overrules the automatic detection (for when it
gets it wrong) would probably also be a good idea.


-- 
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ