From: Johannes Berg <johannes@sipsolutions.net>
To: Dmitry Tarnyagin <abi.dmitryt@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH v3] cfg80211: merge in beacon ies of hidden bss.
Date: Fri, 04 Nov 2011 17:48:50 +0100 [thread overview]
Message-ID: <1320425330.3969.115.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <CAMG6FYhbX+zKRw823RmPzwXqVzP7c+5W8pAaR4DGsOm0qnZGpA@mail.gmail.com> (sfid-20111104_171212_230697_F4323BFB)
On Fri, 2011-11-04 at 17:12 +0100, Dmitry Tarnyagin wrote:
> The problem with PSM when a hidden SSID was used was originally
> reported by Juuso Oikarinen.
>
> - When generally scanning, the AP is getting a bss entry with
> a zero SSID.
And maybe one with the probe reply too, if you do a scan with the SSID,
but anyway.
> - When associationg, a probe-req is sent to the AP with the SSID,
associating :-)
> and as a result a probe-responseis received with the hidden
probe-response is
> SSID in place. As a consequence, a second bss entry is created
> for the AP, now with the real SSID.
> - After association, mac80211 executes ieee80211_recalc_ps(),
> but does not switch to powersave because the beacon-ies are missing.
>
> As result, the STA does not ever enter PSM.
>
> The patch merges in beacon ies of hidden bss from beacon to the probe
> response, creating a consistant set of ies in place.
consistent
> Patch is depended on "cfg80211: fix cmp_ies" made by Johannes.
Thanks. This looks fine to me.
> + /* sort by length first, then by contents */
> + if (ie1[1] != ie2[1])
> + return ie2[1] - ie1[1];
> +
> + /* zeroed SSID ie is another indication of a hidden bss */
> + for (i = 0; i < ie2[1]; i++)
> + if (ie2[i + 2])
> + return -1;
The "return -1" here seems to be correct, but tricky -- maybe it
warrants a comment?
(I'm also thinking that maybe hashing the SSID into the tree was a bad
idea?)
One thing just occurred to me: This patch doesn't make the problem go
away, it just makes it less likely. Consider this: you ask to connect to
an AP with hidden SSID without scanning first. The scan for this AP
happens so quickly that you don't receive a beacon at all, you only
receive a probe response because the scan falls between two beacons.
In that case, the BSS entry will never be updated to get beacon IEs, so
you will still never enter powersave, because the beacon IEs weren't
present when the BSS entry was created.
You can probably reproduce that case easily by using a large beacon
interval, say 1 second.
To fix this, we need to address the TODO item.
johannes
next prev parent reply other threads:[~2011-11-04 16:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-04 16:12 [PATCH v3] cfg80211: merge in beacon ies of hidden bss Dmitry Tarnyagin
2011-11-04 16:48 ` Johannes Berg [this message]
2011-11-04 16:50 ` Johannes Berg
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=1320425330.3969.115.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=abi.dmitryt@gmail.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