Number of Probe Response Retry

[pavel_semenisch]

There is a problem with the response to broadcast probe requests that contain a wildcard SSID. 

Some client implementations wait only a few ms after sending a probe request while scanning. 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 response to be retried quite often consuming even more airtime.

Therefore, the question arises. Is it possible to set a flag to not send more than 1 probe response retry to broadcast probe requests that contain a wildcard SSID?

[hyosang_choi]

I hope to add the function for the AP to respond only to requests with more than a certain signal(RSSI threshold) even if other functions are excluded.

Example, Local Probe Request Threshold (dB) on Aruba.

[neil_neil_67001]

I'd be interested to hear more of what you are seeing here. Normally a probe request to a wildcard SSID is a broadcast, and the probe response does not get an ACK - so there should be no retries.

Beamflex only applies to data frames.

A direct probe response sent to an AP will receive an ACK, and then a direct probe response, which will also receive an ACK, but you're saying that the clients do not send the ACK as they're off doing something else, so the AP has to retry the Probe Response?

I'd like to see evidence of what you're stating above - do you have frame capture to show this? 

[josef_felber]

Hi Neil
thanks for taking care.
To make clear, not the requests of the clients are retransmitted (at least not on the L2 level), but only the responses of the access points to these requests.
If you have access to support cases you can find some relevant packet traces in case ID 00527734, see e.g. "probe responses after ...pcap". There is also quite some discussion. (The case also contained a second issue with 5.5 MBit/s beacons on a ofdm-only SSID, but that has been split off). Case happend with older ZD firmware but more recent traces with newest FW show same behavior.
>>> Beamflex only applies to data frames.
I can only asume that the unusual high number of retransmits is due to Beamflex. Even if this is not the case the parameter for the retransmit number seems to be the same or similar to data packets.
>>> but you're saying that the clients do not send the ACK
I only can trace packets at the access point - not (in parallel) at the client. So I have to deduce that the client does not receive probe responses correctly due to high interference caused by hidden stations (whose probe response packets do not show up in the trace for that reason). There is also some indication that the APs do use a rather small CW window for probe responses and do not enlarge the CW window as a consequence of retransmitting. If this is actually true (timing of traces is not very precise) , I asume this is caused by the high priority of management frames. But with probe responses being responses to broadcast request this small CW window may degrade the effectiveness of the probe mechansim. Here it also plays a role that in a multi-SSID setup the order of probe responses for different SSIDs seems not to be optimized. Typically all SSIDs should be probe-responded one after another (or maybe SSIDs with high priority should be reponded first) and only then retransmit should start on all SSIDs. Actually it seems that the first SSID in the list will be retransmitted a lot of times and then the next SSID will follow. But there seems to be no clear rule on that. Looking a the traces there seems to be a timeout on probe responses to a certain request - which makes sense. However, caused by the obvious interference and by the order that SSIDs are probe-reponded it seems possible that some SSIDs are never responded within the timeout period. Judging by the traces timeout of probe responses seems to be around 50 msec. But that means that active probing is not very much faster than simply listening to beacons (which of course does not work with hidden SSIDs) but also that the shown and traced situation would cause a 50 msec full contention of one of the rare 2.4 GHz channels in a rather vast spacial region (Ruckus APs high RX sensitivity can be cumbersome...)

So for me it seems to make sense to:
- reduce number of retransmits of probe respones
- make the CW window more flexible to solve contention situations
- let start CWmin for probe responses at a higher value for requests with small RSSI
- optimize the order of probe-responses in multi-SSID setups

This could considerably improve roaming behavior, especially of VoIP clients on smart phones. We have indication, most smart phones will use broadcast probe request (SSID = blank) to search for hidden SSIDs although the devices are configured for these SSIDs (name and WPA). So a probe request of these such devices will triggger responses on all configured SSIDs. Dedicated VOIP phones typically will only probe the configured SSID so behvior is much less problematic.

One should also not forget that active probing in conjunction with MAC spoofing is an entrance door to DoS attacks. With the AP behavior described above the door will become a gateway.

Kind Regards, Josef

[neil_neil_67001]

Hi Josef - that's a lot for me to digest!

Let me have a think and get back to you. 

[josef_felber]

... thanks again - and sorry for the typos.