diff mbox

[2/3] hostapd: Avoid excessive probe response retries

Message ID 1320938481-23936-2-git-send-email-helmut.schaa@googlemail.com
State Accepted
Commit 9a898ee8796eb61650af9c7f4960e0c56317e1e4
Headers show

Commit Message

Helmut Schaa Nov. 10, 2011, 3:21 p.m. UTC
Some client implementations only wait a few ms after sending a probe
request while scanning. Since probe responses are always sent at a low
rate this can eat quite some airtime and it might be impossible to get
the frame out before the client leaves the channel again. If the client
leaves before all probe reponses where acked this can cause the probe
reponse to be retried quite often consuming even more airtime.

Hence, add a new noack flag to the driver's send_mlme callback that
allows hostapd to request if the driver should expect an ACK for this
frame or not.

Use the new noack-policy only for broadcast probe requests that contain
a wildcard SSID.

Signed-hostap: Helmut Schaa <helmut.schaa@googlemail.com>
---
 src/ap/beacon.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

Comments

Jouni Malinen Nov. 11, 2011, 12:43 a.m. UTC | #1
On Thu, Nov 10, 2011 at 04:21:20PM +0100, Helmut Schaa wrote:
> Use the new noack-policy only for broadcast probe requests that contain
> a wildcard SSID.

I think this is a good thing to do by default. However, the end result
could potentially make it more difficult for stations to find the AP. In
addition, the behavior here is not strictly speaking compliant with the
current standard.

Would a configuration option that could be used to disable this sound
reasonable to add with the new functionality? In other words, disable
retries by default, but allow hostapd.conf parameter to be used to
revert to previous behavior.
Helmut Schaa Nov. 11, 2011, 8:12 a.m. UTC | #2
On Fri, Nov 11, 2011 at 1:43 AM, Jouni Malinen <j@w1.fi> wrote:
> On Thu, Nov 10, 2011 at 04:21:20PM +0100, Helmut Schaa wrote:
>> Use the new noack-policy only for broadcast probe requests that contain
>> a wildcard SSID.
>
> I think this is a good thing to do by default. However, the end result
> could potentially make it more difficult for stations to find the AP. In
> addition, the behavior here is not strictly speaking compliant with the
> current standard.
>
> Would a configuration option that could be used to disable this sound
> reasonable to add with the new functionality? In other words, disable
> retries by default, but allow hostapd.conf parameter to be used to
> revert to previous behavior.

Sure. I'll respin ASAP, but that might take some time :)

Thanks,
Helmut
Jouni Malinen Nov. 19, 2011, 5:36 p.m. UTC | #3
On Thu, Nov 10, 2011 at 04:21:20PM +0100, Helmut Schaa wrote:
> Some client implementations only wait a few ms after sending a probe
> request while scanning. Since probe responses are always sent at a low
> rate this can eat quite some airtime and it might be impossible to get
> the frame out before the client leaves the channel again. If the client
> leaves before all probe reponses where acked this can cause the probe
> reponse to be retried quite often consuming even more airtime.
> 
> Hence, add a new noack flag to the driver's send_mlme callback that
> allows hostapd to request if the driver should expect an ACK for this
> frame or not.
> 
> Use the new noack-policy only for broadcast probe requests that contain
> a wildcard SSID.

Thanks, applied. We can still consider adding a configuration parameter
for this separately, but it looked fine to push this in as-is now.
Helmut Schaa Nov. 21, 2011, 7:58 a.m. UTC | #4
On Sat, Nov 19, 2011 at 6:36 PM, Jouni Malinen <j@w1.fi> wrote:
> On Thu, Nov 10, 2011 at 04:21:20PM +0100, Helmut Schaa wrote:
>> Some client implementations only wait a few ms after sending a probe
>> request while scanning. Since probe responses are always sent at a low
>> rate this can eat quite some airtime and it might be impossible to get
>> the frame out before the client leaves the channel again. If the client
>> leaves before all probe reponses where acked this can cause the probe
>> reponse to be retried quite often consuming even more airtime.
>>
>> Hence, add a new noack flag to the driver's send_mlme callback that
>> allows hostapd to request if the driver should expect an ACK for this
>> frame or not.
>>
>> Use the new noack-policy only for broadcast probe requests that contain
>> a wildcard SSID.
>
> Thanks, applied. We can still consider adding a configuration parameter
> for this separately, but it looked fine to push this in as-is now.

Ok, thanks so far, I've still got the config parameter on my TODO list.
Helmut
diff mbox

Patch

diff --git a/src/ap/beacon.c b/src/ap/beacon.c
index 6267831..7344516 100644
--- a/src/ap/beacon.c
+++ b/src/ap/beacon.c
@@ -198,6 +198,7 @@  void handle_probe_req(struct hostapd_data *hapd,
 	struct sta_info *sta = NULL;
 	size_t buflen;
 	size_t i;
+	int noack;
 
 	ie = mgmt->u.probe_req.variable;
 	if (len < IEEE80211_HDRLEN + sizeof(mgmt->u.probe_req))
@@ -407,7 +408,11 @@  void handle_probe_req(struct hostapd_data *hapd,
 		pos = hostapd_eid_p2p_manage(hapd, pos);
 #endif /* CONFIG_P2P_MANAGER */
 
-	if (hostapd_drv_send_mlme(hapd, resp, pos - (u8 *) resp, 0) < 0)
+	/* This is a broadcast probe request, apply no ack policy to avoid
+	 * excessive retries */
+	noack = !!(elems.ssid_len == 0 && is_broadcast_ether_addr(mgmt->da));
+
+	if (hostapd_drv_send_mlme(hapd, resp, pos - (u8 *) resp, noack) < 0)
 		perror("handle_probe_req: send");
 
 	os_free(resp);