linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jouni Malinen <j@w1.fi>
To: Chaoxing Lin <clin@3eti.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: Help: Guidance on "AP/VLAN" mode
Date: Fri, 22 Oct 2010 21:27:24 +0300	[thread overview]
Message-ID: <20101022182724.GA9896@jm.kir.nu> (raw)
In-Reply-To: <0E78D47E19ECA44893BC64D10E0D130E014FA568@efjrocmx01.EFJDFW.local>

On Fri, Oct 22, 2010 at 01:43:07PM -0400, Chaoxing Lin wrote:
> CLIN: I saw that dynamic-VLAN section. And did not quite understand how
> to setup. Is there any further documentation on dynamica-VLAN?

I don't know, but Google search for the configuration field names in
hostapd.conf will likely give you some hits (no guarantees of usefulness
of those, though).

> Must the interface in /etc/hostapd.vlan be type of __ap_vlan? Or it can
> be any AP interface specified in "bss=xxx" in multi-BSSID case?

You should not create them manually; hostapd will create these for you..
Sure, the type will be NL80211_IFTYPE_AP_VLAN, but you should not need
to know that ;-).

> CLIN: Getting VLAN ID from Radius server means all VLANs must use 802.1x
> way for authentication.

No, it doesn't. But the only other option is to use station MAC address
to VLAN ID mapping, so yes, this has some limitations.

> 1. Most of the time multi-BSSID is superior to multi-SSID. But
> multi-BSSID uses multiple MAC addresses and each radio actually has only
> reserved one MAC address. Meaning, all other MAC addresses used are
> actually reserved by other radio/Ethernet adapter, etc. When product
> like this goes on market, it's bound to have MAC address conflict,
> unless vendor reserves enough MAC for its product. It's kind of a waste
> to reserve 32 (in my case) MAC addresses per radio since most of the
> time multi-BSSID won't be used in SOHO. 

There are costs involved with it, but then again, so there are with
multi-SSID.. I would just refuse to depend on multi-SSID myself because
of interop issues and limitations on what kind of security policies can
be used between the networks sharing the same BSSID.

You can get pretty good results with use of locally administered
addresses, but sure, there is always a possibility of conflict, even if
very unlikely with good address allocation strategy.

> 2. The other thing regarding hostapd dynamic VLAN is that it creates a
> bridge for each VLAN and tag is only added at a certain interface e.g.
> "vlan_tagged_interface=eth0". There are a few problems with this design.

> 	a. One bridge for each VLAN overloads system unnecessarily. It
> means that all protocols over bridge have to run multiple copies, one
> per bridge. This is expensive for embedded devices.

Keep in mind that CONFIG_FULL_DYNAMIC_VLAN is optional functionality..
If you don't want it, don't enable it.

> 	b. In case there multiple interfaces need vlan tag, does hostapd
> allow me to put multiple interfaces in "vlan_tagged_interface=xxx"
> option? Even if it allows that, it's still inconvenient if the interface
> list is dynamic. My current product has one bridge which encloses 
> one Ethernet port, 
> AP/VLAN interface, 
> and multiple(dynamic, auto detect by proprietary app) WDS interfaces. 

I would assume that you can simulate something similar by providing a
some scripts for managing how the interfaces get linked together and not
using hostapd to manage the VLAN interfaces at all.

> Only AP/VLAN interface adds/removes/checks VLAN tag per SSID, while all
> other interfaces in the bridge pass packet as is (In other words, they
> behave as VLAN trunk ports). Eventually, it's up to the VLAN switch
> attached at the Ethernet port to distribute packet per VLAN rules. It
> seems hard for me to use current (mac80211, hostapd, iw, etc) to achieve
> what I need.

I'm not sure whether I would fully agree with that, but sure, it may not
currently provide everything you need. Anyway, it should be possible to
extend this as needed..
 
-- 
Jouni Malinen                                            PGP id EFC895FA

      reply	other threads:[~2010-10-22 18:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-21 15:54 Help: Guidance on "AP/VLAN" mode Chaoxing
2010-10-22 11:45 ` Help: Guidance on &quot;AP/VLAN&quot; mode jpo234
2010-10-25  8:50   ` Johannes Berg
2010-10-22 15:27 ` Help: Guidance on "AP/VLAN" mode Jouni Malinen
2010-10-22 17:43   ` Chaoxing Lin
2010-10-22 18:27     ` Jouni Malinen [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=20101022182724.GA9896@jm.kir.nu \
    --to=j@w1.fi \
    --cc=clin@3eti.com \
    --cc=linux-wireless@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).