On Fri, 2011-01-21 at 20:01 +0200, Arik Nemtsov wrote: > On Thu, Jan 20, 2011 at 22:52, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > > As I also just commented on the corresponding hostapd patch, I'm not > > sure this is sufficient. If this is necessary for probe response > > offloading, I'm tempted to say that we should be honest about it and let > > userspace determine the entire probe response (which will contain the > > correct SSID) since it can be different from the beacon which presumably > > you're now using to generate probe responses. > > > > Well the SSID is still needed in its pure form (i.e. not bundled up > inside some skb). Technically you can easily parse it out but I agree. > You're talking about adding another set_probe_resp() callback from > hostapd. That makes sense. I'll look into it. > > In the meanwhile are there any comments for this portion? 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. Also, P2P GO might be quite tricky with this, but I'm not exactly sure. johannes -- 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
