On Fri, Oct 28, 2011 at 3:34 PM, Kalle Valo <kvalo@xxxxxxxxxx> wrote: > Helmut Schaa <helmut.schaa@xxxxxxxxxxxxxx> writes: > >> The reason is the following: if you're running a mac80211 AP with multiple >> bssids, hostapd will answer to broadcast probe requests sent by STAs with >> one probe response per bssid (unicast of course). And since some clients >> stay only for a short amount of time on the scan-channel (a few ms) under >> some circumstances the probe responses aren't sent out yet before the >> scanning STA leaves the channel and thus retried till the maximum retry >> limit is reached. And these retries consume quite a lot of airtime. And to >> avoid this we just don't want to retry the probe responses in that case. > > This is all good. But doesn't it also mean that this change increases > probability that the client doesn't receive the probe response, for > example due to interference where retransmission would help, and hence > the AP isn't included in the client's scan results? Correct. The probability to find the AP during a scan is lower then with retries. However, some commercial APs (Aruba for example) do exactly this and in some cases I noticed (on a mac80211 AP with 8 BSSIDs) one scanning client took around 50ms of airtime :) Also in a multi BSS scenario the probability of finding the second, third etc. BSSID gets lower if probe responses are retried. I've got a patch for hostapd to implement the don't-wait-for-ack behavior only for broadcast probe responses that contain the wildcard ssid. But maybe it makes sense to make this a configuration option? So it is up to the user to decide about the behavior. Helmut -- 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
