On Tue, Apr 01, 2008 at 03:16:13PM +0200, Johannes Berg wrote: > 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. The Beacon frames would probably need to update all <BSSID,*> entries for the fields that we decide need to be updated based on Beacons, not just the <BSSID,"">... Alternatively, we could change the BSS table to have just one entry for each BSSID and a list of SSID entries for each BSSID (with SSID, WPA/RSN IE, Privacy flag, etc. from ProbeResp). This would be internal to kernel, though, and the scan result would likely need to continue showing these as separate "BSSes" even though they have the same BSSID. > > 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? It is next to impossible to figure out which SSID the Beacon frame is based on in multi-SSID configuration and as such, it is difficult to say which BSS structure would be updated.. I think there has to be support for selective update of information based on Beacon frames, but there are multiple ways of implementing this. > > 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* :) Yeah.. Well, the problem is that no one has asked (as far as I know) for this for a real world use case after multi-BSS support was added. Sure, this would be nice for testing purposes, but the changes needed for multi-SSID support are somewhat complex and would not only require quite a bit of work now, but also make long term maintenance take more effort.. I'm not completely against doing this, but this is not exactly on top of my to-do list ;-). -- 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
