On Sun, Mar 30, 2008 at 10:33:19AM +0200, Johannes Berg wrote:
> After having two bug reports about the BSS list/probe_resp variable in
> mac80211 and a very detailed analysis of the problem from Bill Moss, I
> think I've understood the problem now but I'm not sure how to proceed
> because I do not understand the reason for "Do not allow beacons to
> override data from probe responses".
The main (and only) reason for this is support for multi-SSID
configurations (hidden SSID and/or multiple SSIDs with the same BSSID,
but with different security parameters). Only the Probe Response frames
are guaranteed to include correct information for <BSSID,SSID> pair in
these cases and because of that, Beacon frames are not allowed to update
things like SSID or WPA/RSN IE.
> The question, however, is: why are beacons not allowed to override probe
> response information? That is, why does this piece of code exist:
>
> if (sdata->vif.type != IEEE80211_IF_TYPE_IBSS &&
> bss->probe_resp && beacon) {
> /* STA mode:
> * Do not allow beacon to override data from Probe Response. */
> ieee80211_rx_bss_put(dev, bss);
> return;
> }
This controls which BSS info fields are updated based on both Beacon and
Probe Response frames and which are updated only based on Probe Response
frames.
One example of information that should not be overridden by Beacon
frames is WPA and RSN IE since these could differ based on the SSID in
multi-SSID configurations. An example of information that must be
updated from every Beacon frame would be ERP IE. Finally, there are also
more complex cases, like the Capability Information, which should
probably be handled separately for each subfield (e.g., Privacy could be
per-SSID and Short Slot Time for every SSID of the BSSID).
> Bill Moss reports that removing this piece of code (and then the
> probe_resp variable completely since it'll be write-only) fixes the
> problem, and it's obvious why.
I don't think that this would be the correct fix for this issue.
> The only thing I'm not sure about is whether that will introduce
> regressions because probe responses can contain better information than
> beacons. The only reason I can find for this would be an AP that has
> multiple SSIDs with different security settings on each and announces
> those only in the probe responses (and otherwise uses a hidden SSID),
> but we only handle that now, much later than the code there that was
> already present.
I'm not sure whether the current code is correct for all information
from Beacon/ProbeResp (i.e., some parts might need to be moved to be
before/after this check), but changes to WPA/RSN IE are after this
return-on-Beacon for a reason and removing that check would break some
multi-SSID networks.
> However, that actually seems to have another bug, if you have such an AP
> will you find two BSSes, one with a hidden and one with a visible SSID?
That is by design.
> Any hints about this code or the desired behaviour would be greatly
> appreciated.
I think that we will need to evaluate whether the current implementation
is updating all pieces of information in correct place and still
maintain possibility of not using Beacon frames to update some fields.
There might be cases where the old information from ProbeResp should
expire (though, if we are still associated with that BSSID,SSID pair, we
should use Probe Request to update this information instead of just
blindly throughing it away).
Any information that has to be same for all SSIDs in multi-SSID (single
BSSID) configuration can be updated based on Beacon frames since the
SSIDs for a specific SSID would not contain any different information
for these parts. However, fields that can be configured per-SSID, must
be handled separately in order to be able to support multi-SSID
configuration with different security policies per SSID. This would
mainly included Privacy flag in the capability field and security
related IEs (WPA IE, RSN IE), but there may be something else that would
benefit of similar handling.
--
Jouni Malinen PGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
