On Mon, 2008-03-31 at 18:04 +0300, Jouni Malinen wrote: > 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. Right. But in that case, a beacon frame we receive will update the <BSSID,""> BSS structure, not the <BSSID,actual SSID> structure because the update code will find only the former since the SSID is hidden. TheBSS structure w/o SSID won't actually be used. > 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). Right. But wouldn't that be covered by operating on different BSS structs? > > 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. Ok, I think the HT for example should be moved in front. > > 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. Right, ok. > 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. Right. Show of hands who wants to do this? :) Bill sent me a patch privately, I've asked him to post it here on the list for comments. I really don't have time right now to investigate all this. > 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). Yeah, sure. > 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. It might help if there was code in hostapd to actually do run this scenario. *hint* *hint* :) johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
