linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn@mork.no>
To: David Laight <David.Laight@ACULAB.COM>
Cc: Kristian Evensen <kristian.evensen@gmail.com>,
	"linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] rndis_host: Set random MAC for ZTE MF910
Date: Fri, 15 Jul 2016 19:42:28 +0200	[thread overview]
Message-ID: <877fcmlrwb.fsf@miraculix.mork.no> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F4F921C@AcuExch.aculab.com> (David Laight's message of "Fri, 15 Jul 2016 16:42:02 +0000")

David Laight <David.Laight@ACULAB.COM> writes:
> From: Bjørn Mork
>> Sent: 13 July 2016 23:23
> ...
>> Or how about the more generic?:
>> 
>>         if (bp[0] & 0x02)
>>    		eth_hw_addr_random(net);
>> 	else
>> 		ether_addr_copy(net->dev_addr, bp);
>> 
>> That would catch similar screwups from other vendors too.
>
> Not really, that disables 'locally administered' addresses.

... when the 'locally administered' addresses comes from firmeare, yes.
That was the idea.  We are better off using our own random locally
administered address if some vendor has been cheap/stupid enough to
program that into firmware.

The aminstrator is of course still free to set any address, 'locally
administered' or whatever.  This is not the question here.

> If a vendor has used the same address on lots of cards it could easily
> be a 'real' address.

Sure.  We cannot easily detect that.  The only way is to keep a
blacklist of such  'real' addresses, the way Kristian initially
proposed.

But I thought that we could simplify this particular screwup since the
address in question had the local bit set, and catch every other similar
abuse at the same time. If you get the local bit from formware, then you
know for sure that there is something wrong.

> Not only that, there certainly used to be manufacturers that used 'locally
> administered' addresses on all their cards (as well as those that used unallocated
> address blocks).

Sure. But is there any reason to care about those addresses?

> Not to mention the bit-revered addresses....

Listing all the ways vendors have screwed is going to be a long and
rather boring thread ;)


Bjørn

  reply	other threads:[~2016-07-15 17:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-13 16:39 [PATCH] rndis_host: Set random MAC for ZTE MF910 Kristian Evensen
2016-07-13 22:23 ` Bjørn Mork
2016-07-14  7:54   ` Kristian Evensen
2016-07-14  8:01     ` Kristian Evensen
2016-07-15 16:42   ` David Laight
2016-07-15 17:42     ` Bjørn Mork [this message]
2016-07-17  3:02       ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877fcmlrwb.fsf@miraculix.mork.no \
    --to=bjorn@mork.no \
    --cc=David.Laight@ACULAB.COM \
    --cc=kristian.evensen@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).