On Sun, Jan 23, 2011 at 10:23:10AM +0100, Johannes Berg wrote: > Not really, except that I think that by itself it's insufficient. I > might add that depending on how the probe response thing works out in > the supplicant, it might make sense to add a capability flag that makes > the driver request this behaviour, since it would also disable > multi-SSID operation on a single BSSID (if that gets ever implemented) > for example since only a single probe request can be transmitted. Yes, it would be useful to allow user space to figure out whether the driver is generating Probe Response frames on it own (without having to guess this based on never seeing Probe Request frames or something similar). > Also, P2P GO might be quite tricky with this, but I'm not exactly sure. For the most basic functionality, it need a mechanism that allows the Probe Response template to be updated during the lifetime of the BSS. However, to fully comply with the P2P spec, whatever code is taking care of processing Probe Request frames would need to be able to conditionally include the P2P IE(s) from the template based on whether the Probe Request frame included a P2P IE. In addition, it would need to be able to check the Requested Device Type against the list of device types (both local and remote) in the group to determine whether to reply to the request. -- 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
