linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Tomas Winkler <tomasw@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	Michael Buesch <mb@bu3sch.de>,
	Luis Carlos Cobo <luisca@cozybit.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH 1/6] mac80211: allow no mac address until firmware load
Date: Mon, 28 Jul 2008 12:22:38 -0400	[thread overview]
Message-ID: <1217262158.28198.44.camel@localhost.localdomain> (raw)
In-Reply-To: <1ba2fa240807280858o4020fec8k4c287567dff177ca@mail.gmail.com>

On Mon, 2008-07-28 at 18:58 +0300, Tomas Winkler wrote:
> On Mon, Jul 28, 2008 at 6:14 PM, Dan Williams <dcbw@redhat.com> wrote:
> > On Mon, 2008-07-28 at 17:07 +0200, Johannes Berg wrote:
> >> On Mon, 2008-07-28 at 10:59 -0400, Dan Williams wrote:
> >>
> >> > > If that's really a problem, yes. 01:00:00:00:00:00 is still better
> >> > > than a pseudo random MAC, IMO. It's immediately obvious to the user
> >> > > that the MAC currently is not set.
> >> >
> >> > How about 44:44:44:44:44:44 like orinoco uses for bogus BSSID?  If we
> >> > can, let's not keep creating yet more bogus MAC addresses.
> >>
> >> Either way, the problem is that these will confuse udev if you have two
> >> at the same time, no?
> >
> > the udev script I attached from Fedora 9 already ignores devices with
> > 00:00:00::: so I don't think we'd have a problem with that.  Screw the
> > Xerox thing, all zeros is just bogus and tons of stuff treats it that
> > way already.
> 
> So this won't conflict even if you have two or more devices that
> claims zero mac address?

Well, sane udev persistent name rules should be ignoring invalid MAC
addresses, and right now they just happen to ignore 00:00:00::: already
anyway.  Apparently the one I posted also handles the MAC changing later
and does the right thing.

So if you have two cards with the same MAC, they'll still get different
netdevs, just if they are both 00:00:00::: this udev script I posted
won't try to rename them at all, so everything is fine.

If you have two cards with the same MAC that's _valid_, then stuff gets
screwed up (*cough* libertas + mesh *cough*) but that's not our problem.

Dan



  reply	other threads:[~2008-07-28 16:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-10 14:57 [PATCH 1/6] mac80211: allow no mac address until firmware load Luis Carlos Cobo
2008-07-27 15:22 ` Dan Williams
2008-07-28 13:23   ` Johannes Berg
2008-07-28 13:44     ` Michael Buesch
2008-07-28 13:56       ` Luis Carlos Cobo
2008-07-28 14:00         ` Michael Buesch
2008-07-28 14:59           ` Dan Williams
2008-07-28 15:07             ` Johannes Berg
2008-07-28 15:14               ` Dan Williams
2008-07-28 15:58                 ` Tomas Winkler
2008-07-28 16:22                   ` Dan Williams [this message]
2008-07-30 11:17                     ` Luis Carlos Cobo
2008-07-30 11:35                       ` Dan Williams
2008-07-30 14:30                         ` John W. Linville
2008-07-30 14:52                           ` Luis Carlos Cobo
2008-07-28 13:57       ` Dan Williams
2008-07-28 14:25         ` Michael Buesch
2008-07-28 14:44           ` Tomas Winkler
2008-07-28 14:49             ` Johannes Berg
2008-07-28 14:57             ` Dan Williams

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=1217262158.28198.44.camel@localhost.localdomain \
    --to=dcbw@redhat.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luisca@cozybit.com \
    --cc=mb@bu3sch.de \
    --cc=tomasw@gmail.com \
    /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).