On Mon, Jan 24, 2011 at 11:44, Jouni Malinen <j@xxxxx> wrote: > On Sun, Jan 23, 2011 at 11:02:53PM +0200, Arik Nemtsov wrote: >> Support passing SSID and probe-response template to drivers. >> This data can be used to offload the beacon -> probe-req -> probe-resp >> process to HW. > > What is the expected driver behavior for passing the SSID as a separate > attribute vs. passing the SSID as an IE within the Probe Response > template? Is the SSID-as-attr ever used to fill in a Probe Response by > the driver/firmware? Or is the driver/firmware only allowed to use the > full Probe Response template (with DA and timestamp updated)? It would > be useful to get this documented so that it is clear for people working > with both a driver and user space applications that could use the new > interface. The SSID-as-attr not used for the probe-resp template. It is used by FW to filter out which probe-reqs should be responded to when operating with a hidden SSID. The wl12xx FW updates the timestamp and DA. I mentioned in the documentation of ieee80211_proberesp_get (and various other parts) that the DA should be set manually and that this should be used as a template (which also implies timestamp should be set). If some part is unclear can you point out a specific patch? > > We should also document the need for special Probe Request processing > for WPS and P2P and have capability flags indicating whether the driver > needs the SSID and/or Probe Response template and whether it supports > various special rules for Probe Request processing (remove P2P IE from > Probe Response template if Probe Request does not include it, do not > reply to Probe Request if there is no match for Requested Device Type, > do not reply if there is no match for P2P Device Address). hostapd (or > wpa_supplicant AP mode) would then automatically disable use of P2P > and/or WPS if the driver/firmware does not have necessary capabilities > to implement this correctly. > For WPS (without p2p), it appears the probe-resp doesn't depend on the probe-req (in hostapd code). I also explicitly made sure this scenario works since this is a good example for a use-case when the probe-response is different from the beacon. Perhaps we can start with these AP-mode only patches and expand the functionality when it is needed for p2p? It may be hard to predict what other special handling will be needed for offloading p2p probe-resps to FW (when such FW is available). Note that the current patch doesn't remove existing functionality - a driver/FW operating in p2p mode can simply choose not to use the template and just pass probe-requests up. Regards, Arik -- 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
