netdev - Re: [patch 2/8] forcedeth: fix MAC address detection on network card (regression in 2.6.23)

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]

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