linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: Dan Williams <dcbw@redhat.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] mac80211: store SSID in sta_bss_list
Date: Wed, 10 Oct 2007 11:13:19 -0400	[thread overview]
Message-ID: <20071010151319.GD5962@tuxdriver.com> (raw)
In-Reply-To: <1192027003.9739.7.camel@localhost.localdomain>

On Wed, Oct 10, 2007 at 10:36:43AM -0400, Dan Williams wrote:
> On Wed, 2007-10-10 at 11:02 +0200, Johannes Berg wrote:
> > On Tue, 2007-10-09 at 19:49 -0400, John W. Linville wrote:
> > > From: John W. Linville <linville@tuxdriver.com>
> > > 
> > > Some AP equipment "in the wild" services multiple SSIDs using the
> > > same BSSID.  This patch changes the key of sta_bss_list to include
> > > the SSID as well as the BSSID and the channel so as to prevent one
> > > SSID from eclipsing another SSID with the same BSSID.
> 
> The "standard" (which is a stretch) was that only _one_ SSID can be
> broadcast in beacons, and the rest of the supported SSIDs must be
> hidden.  Is that the case?  Or is the AP you're referring to actually
> pushing out multiple beacons with different not-hidden SSIDs and the
> same BSSID?

My impression is that the standard is not particularly clear on this,
hence the variety of behaviors.  Can you cite specific wording?

My research indicates the existance of both "1 beacon, N-1 hidden"
and "N beacons" behaviors.  Either way, the sta_bss_list can be
populated not just from beacons but also from probe responses.
So even if N-1 SSIDs are hidden, we still need to be able to record
information about them.

Unfortunately I don't have any hardware that behaves in this fashion.
I discovered references to this behavior while researching the
preceding "same BSSID on different frequencies" patch.  Having become
aware of this behavior, I figured it was worth fixing at the same
time to avoid future bug reports.

Hth!

John
-- 
John W. Linville
linville@tuxdriver.com

      reply	other threads:[~2007-10-10 15:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-09 23:49 [RFC PATCH 1/2] mac80211: store channel info in sta_bss_list John W. Linville
2007-10-09 23:49 ` [RFC PATCH 2/2] mac80211: store SSID " John W. Linville
2007-10-10  9:02   ` Johannes Berg
2007-10-10 14:36     ` Dan Williams
2007-10-10 15:13       ` John W. Linville [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=20071010151319.GD5962@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=dcbw@redhat.com \
    --cc=johannes@sipsolutions.net \
    --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).