On Fri, Mar 24, 2006 at 11:41:14AM -0800, Jean Tourrilhes wrote: > I've seen time where people said SSID when referring to the > BSSID, so I just wanted the terminology to be without ambiguity.
Well.. It is just somewhat funny to see ESSID being used in Linux wireless discussion when most other areas are using the correct term, SSID. I would assume that wireless.h and iwconfig documentation are the main reasons for this.. ;-) > The problem of trying to keep probe response for longer period > of time is that they may no longer be valid. As you roam around, > things need to timeout/expire because they are no longer reachable. If beacon frames are received for the same BSSID, the probe responses are very likely still valid. The only thing expiring them would be configuration change in the AP.. > But, before going into deep technical discussions, we may want > to remind us what is the goal of this API. The goal is to present the > user a list of potential networks that can be used by him, in the case > he doesn't want to associate with a specific network. Not all > associations need it, it's a convenience feature for finding open > networks. It is also convenient for figuring out security policy for closed networks.. > The network that don't send beacon do so to cloak themselves, Or to support multiple SSIDs with radios that cannot use multiple BSSIDs.. > If the user know about this network via other means, he can > still associate with it by entering manually the ESSID. This would work if there is only one hidden SSID. However, if there are more than one, it may be useful to be able to scan (without associating) multiple SSIDs. This was one of the reason for adding scan parameters in WE-18. > The only thing debatable is about the current associated > network, in case it's cloaked. This network has already been > discovered (we are associated with it), therefore the user does not > really require to see it in scan results, however it would be nice for > completness. Maybe not in scan results, but the same parameters have to be available for WPA supplicant and fetching them from scan results is one convenient mechanism. In other words, proper WPA/WPA2 validation of WPA/RSN IEs requires that the Beacon/ProbeResp IEs are available for the current AP. -- Jouni Malinen PGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
