netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Kimdon <david.kimdon@devicescape.com>
To: Jiri Benc <jbenc@suse.cz>
Cc: David Kimdon <david.kimdon@devicescape.com>,
	netdev@vger.kernel.org,
	"John W. Linville" <linville@tuxdriver.com>
Subject: Re: [patch] d80211: remove sub-interface mac address policy
Date: Thu, 21 Sep 2006 14:10:57 -0700	[thread overview]
Message-ID: <20060921211057.GA22875@devicescape.com> (raw)
In-Reply-To: <20060921200939.1cab8c1c@logostar.upir.cz>

On Thu, Sep 21, 2006 at 08:09:39PM +0200, Jiri Benc wrote:
> On Thu, 14 Sep 2006 07:33:21 -0700, David Kimdon wrote:
> > Wireless vlan interfaces need to have the same mac address as
> > other sub interfaces.  Rather than complicate the kernel here by
> > adding yet another case where uniqueness is not required, remove
> > the check on mac address uniqueness altogether.
> > 
> > We should not implement a mac address allocation policy here.  It
> > is difficult to get it right in all cases and does not belong in
> > the kernel.  It is better to leave this to be implemented as a
> > userspace policy.
> 
> I disagree. This is not about policy, this is about prevention of
> accidental violation of IEEE 802.11. The only effect of this patch would
> be forcing drivers to do that check themselves thus duplicating code.

That is fine, I don't feel strongly, I will cook up a patch that fixes
the check for vlan interfaces.

> What is the purpose of "wireless vlans"?

We use wireless vlans to isolate stations to separate multicast
domains within the same bss based on the input of a radius server.  A
stations is bound to a particular wireless vlan interface, all
stations on that wireless vlan share broadcast keys, and the wireless
vlan interface can be bridged to a particular wired vlan.

> Is it something Atheros-specific?
no, it is chip driver agnostic.

> Is it documented somewhere?  Or is it in some of IEEE 802.11
> standards and I just overlooked it? (In that case I would be more
> than happy to review the whole stack and fix it.) Could you send us
> some pointers?

Take a look at http://www.ietf.org/rfc/rfc3580.txt section 3.31.
Tunnel Attributes.  That is what we are processing at a high level to
get vlan assignment.  FWIW, we have code on its way to hostapd cvs
that uses wireless vlans which will show more details of this
particular implementation.

David

      reply	other threads:[~2006-09-21 21:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-14 14:33 [patch] d80211: remove sub-interface mac address policy David Kimdon
2006-09-21 18:09 ` Jiri Benc
2006-09-21 21:10   ` David Kimdon [this message]

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=20060921211057.GA22875@devicescape.com \
    --to=david.kimdon@devicescape.com \
    --cc=jbenc@suse.cz \
    --cc=linville@tuxdriver.com \
    --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).