On Wednesday, June 05, 2013 09:53:00 AM Johannes Berg wrote: > > When reporting probes, driver/firmware may do its best to filter out > > probes that would not be replied with probe-resp accordingly to the > > P2P rules for active device configuration. > > This I think should be more specific. "[W]ould not be replied" is > clearly one step, but in an environment where you actually want to > offload the P2P probe responses that is pretty much useless. I'd rather > say something like: > > --- > When probe response offload it supported, the device should not report > probe requests to the host that it already responded to. It must report > (and therefore not respond to) probe requests that indicate the sending > device is in active PBC mode (specifically, <...add more details...>). > It may also drop invalid or malformed probe requests or ones that would > not be replied to for other reasons. > --- > > I think this would be a reasonable tradeoff. It means that if a probe > request is actually reported, wpa_supplicant must reply to it, and we > don't have to get into the business of having to decide whether or not > it needs to respond. > > Alternatively, we could specify that the device _must_ respond if > offload is supported, and then report it. I like this alternative. Except, reporting is accordingly to the rx filter. wpa_s may be not interesting in probes at all, or want only ones with PBC. If device answer probes in firmware, this would reduce CPU wake-ups. > > However, we need to clearly specify this so that we don't get two > responses, one from the device and one from wpa_s. If there's no way to > specify this, we need to introduce a "reply already sent" flag into the > frame reporting. Said above translates to all-or-nothing approach w.r.t. responses: - If device indicate probe-resp offload, it must reply all probes, supplicant must not send probe-resp. - If device does not indicate probe-resp offload, it should never send probe-resp by itself; it should report all matching probes and supplicant will generate probe-resp. Regarding what probes to report, I'd specify relaxed requirements for the driver: - in non-offload case, driver must report all matching probes (but may just report all, and wpa_s will filter) - in offload case, must report matching probes if rx filter says so. It is not neccessary to report all probes that device replied to. I don't want to force firmware or driver to parse probes to detect PBC; if we got frame to the host, from power perspective there is no much difference who will filter it - driver or wpa_s; and wpa_s already do this parsing. For PBC - can one specify "probes with PBC" using existing rx filter mechanism? Also, I feel this explanation get large, it deserves separate comment block, it is overkill for start_p2p_find comment. Maybe do it in another patch? Thanks, Vladimir -- 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
