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?

[michael_brado]

No, there is no such flag.

[pavel_semenisch]

Hi Michael,
I know that there is no such feature, I was told about it in technical support.
I noted my message as an idea, because it is worth considering as a future request.
I captured the radio interface traffic from the street access points.
63.6% of all traffic is the probe response packets. 54.9% of all traffic - probe responce retry packages to broadcast probe requests that contain a wildcard SSID.
It's horrible. And by and large, these packages are meaningless

[jim_ambrose_dmt]

I am capturing the same thing. When the client sends out a wildcard probe request my wireshark capture files shows dozens and dozens of probe response retries.

[josef_felber]

Hi,
we are observing the same issue and I think it is a severe degradation of performance. In an medium to dense access point environment we get a rising number of complaints regarding VoWLAN clients when roaming in hidden SSIDs and multi-SSID setups. The issue is especially related to "smart" phone clients as those seem to be programmed for SSID-broadcast probe request in case of hidden SSIDs. With Ruckus access points which are obviously programmed for beam steering even at that early stage when responding to probe request (which are MAC broadcasts) an avalanche of probe reports and retransmits is triggered. Most of these will not be received by the probing client as the avalanche will cause high interference in an (unavoidable) hidden station scenario. And many probe responses come from access points far to distant to have enough SNR at the clients (phones may be smart, but their antenna are weak). And last but not least it seems that the access point is first re-transmitting the first configured SSID a lot of times, then the second ... and so on. At the end it may happen that not a single probe reponse for the relevant VOIP SSID has been transmitted before there is a general response timeout. So it seems to be a good idea to make the VOIP SSID the first in the access points list, but that is not easy to achieve.
We have reports from customers that used the same smart phones for VOIP with Ubiquity hardware without roaming issues and then getting into trouble by upgrading to Ruckus.
I stongly believe there is an rather simple solution to improving the probing behaviour of Ruckus access points dramatically:
1. Reduce re-transmit number to onyl a few (2-3) for probe responses (and other messages to broadcast requests)
2. In multi-SSID send transmit and re-transmits in a round (the SSID list) robin manner.
3. Use a starting CWMin value depending on request RSSI to make responses from distant access points less prioritized than from close ones.
Kind Regards, Josef