public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Michael Buesch <mb@bu3sch.de>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	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 09:57:45 -0400	[thread overview]
Message-ID: <1217253465.28198.20.camel@localhost.localdomain> (raw)
In-Reply-To: <200807281544.33509.mb@bu3sch.de>

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

On Mon, 2008-07-28 at 15:44 +0200, Michael Buesch wrote:
> On Monday 28 July 2008 15:23:53 Johannes Berg wrote:
> > On Sun, 2008-07-27 at 11:22 -0400, Dan Williams wrote:
> > > On Thu, 2008-07-10 at 16:57 +0200, Luis Carlos Cobo wrote:
> > > > Originally by Johannes Berg. This patch adds support for devices that do not
> > > > report their MAC address until the firmware is loaded. While the address is not
> > > > known, a multicast on is used.
> > > 
> > > Johannes, thoughts on this?  Is there a better way to do it for devices
> > > that don't know their MAC address until firmware load?
> > 
> > I actually wrote this patch, but largely I don't care. It seemed that
> > having unique MAC addresses would screw up less with udev, but maybe we
> > can just leave it zeroed until we know?
> 
> Well, I think that really is pretty weird and it is confusing to the
> user to see that pseudo random MAC that changes suddenly when the device is
> initialized. For the human user (so everybody but me), it would be better
> to have the MAC all-zeros until the firmware loaded. So it would be obvious
> that the MAC is not set, yet. I think userspace
> tools should just be fixed, if they have problems with that.

Agreed.

> (What are the udev problems, btw?)

People seem to want persistent device names.  Since the kernel doesn't
provide stable device/bus enumeration, there are udev hacks (see
attached from Fedora 9) that read the MAC address of the card on
hot-plug and then assign it to a cached device name so that every time I
plug in my Netgear MA401 it gets "eth2".

Same thing as putting UUIDs on partitions and in /etc/fstab to make sure
your internal SATA drive is always sda no matter what USB stuff you plug
in.

The question is, when the MAC address gets updated, whether udev will
recognize that change and re-name the device to the cached value.

Dan

[-- Attachment #2: 75-persistent-net-generator.rules --]
[-- Type: text/plain, Size: 2403 bytes --]

# do not edit this file, it will be overwritten on update

# these rules generate rules for persistent network device naming
#
# variables used to communicate:
#   MATCHADDR             MAC address used for the match
#   MATCHID               bus_id used for the match
#   MATCHDRV              driver name used for the match
#   MATCHIFTYPE           interface type match
#   COMMENT               comment to add to the generated rule
#   INTERFACE_NAME        requested name supplied by external tool
#   INTERFACE_NEW         new interface name returned by rule writer

ACTION!="add", GOTO="persistent_net_generator_end"
SUBSYSTEM!="net", GOTO="persistent_net_generator_end"

# ignore the interface if a name has already been set
NAME=="?*", GOTO="persistent_net_generator_end"

# device name whitelist
KERNEL!="eth*|ath*|wlan*[0-9]|msh*|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end"

# ignore Xen virtual interfaces
SUBSYSTEMS=="xen", GOTO="persistent_net_generator_end"

# read MAC address
ENV{MATCHADDR}="$attr{address}"

# match interface type
ENV{MATCHIFTYPE}="$attr{type}"

# do not use "locally administered" MAC address
ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""

# do not use empty address
ENV{MATCHADDR}=="00:00:00:00:00:00", ENV{MATCHADDR}=""

# build comment line for generated rule:
SUBSYSTEMS=="pci", ENV{COMMENT}="PCI device $attr{vendor}:$attr{device} ($driver)"
SUBSYSTEMS=="usb", ENV{COMMENT}="USB device 0x$attr{idVendor}:0x$attr{idProduct} ($driver)"
SUBSYSTEMS=="pcmcia", ENV{COMMENT}="PCMCIA device $attr{card_id}:$attr{manf_id} ($driver)"
SUBSYSTEMS=="ieee1394", ENV{COMMENT}="Firewire device $attr{host_id})"

# ibmveth likes to use "locally administered" MAC addresses
DRIVERS=="ibmveth", ENV{MATCHADDR}="$attr{address}", ENV{COMMENT}="ibmveth ($id)"

# S/390 uses id matches only, do not use MAC address match
SUBSYSTEMS=="ccwgroup", ENV{COMMENT}="S/390 $driver device at $id", ENV{MATCHID}="$id", ENV{MATCHDRV}="$driver", ENV{MATCHADDR}=""

# see if we got enough data to create a rule
ENV{MATCHADDR}=="", ENV{MATCHID}=="", ENV{INTERFACE_NAME}=="", GOTO="persistent_net_generator_end"

# default comment
ENV{COMMENT}=="", ENV{COMMENT}="net device ($attr{driver})"

# write rule
DRIVERS=="?*", IMPORT{program}="write_net_rules"

# rename interface if needed
ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"

LABEL="persistent_net_generator_end"


  parent reply	other threads:[~2008-07-28 14:00 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
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 [this message]
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=1217253465.28198.20.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 \
    /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