Skip to main content

15 Messages

 • 

320 Points

Wed, Oct 26, 2016 10:19 AM

Acknowledged

0

Number of Probe Response Retry

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?

Responses

Brand User

Former Employee

 • 

2.6K Messages

 • 

44.8K Points

4 years ago

No, there is no such flag.

15 Messages

 • 

320 Points

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

4 Messages

 • 

102 Points

3 years ago

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.

7 Messages

 • 

120 Points

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

388 Messages

 • 

5.9K Points

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.

27 Messages

 • 

470 Points

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? 

7 Messages

 • 

120 Points

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

27 Messages

 • 

470 Points

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

Let me have a think and get back to you. 

Brand User

Former Employee

 • 

2.6K Messages

 • 

44.8K Points

3 years ago

Thanks for sharing your detailed analysis Josef.  Most of the 802.11 standards are set and I understand the support engineer, who was repeating what product marketing must have told them.

What I find most interesting in your observations, is about the SSID order and probe responsing the 1st one multiple times and not the deepest WLAN(s).  If you can show this to our engineers with a trace, I'd ask your support engineer to file a bug.  That will have more immediate effect than a feature request.

Meanwhile, it might be helpful if your VoIP WLAN was the first SSID.

7 Messages

 • 

120 Points

Hi Michael,

thanks for commenting.
>>> If you can show this to our engineers with a trace
Can you provide an upload link or an email address?

Josef
Brand User

Former Employee

 • 

2.6K Messages

 • 

44.8K Points

You'd need to please open a ticket, if you don't have one open already?
https://support.ruckuswireless.com/contact-us

7 Messages

 • 

120 Points

The old case had been closed. I have opened a new one with new and very recent traces. You are welcome to have an eye on the progress of this new case (00789474).
By the way, how can I change the order of SSIDs on access points? Please see also the case - there is something even more strange about the order of SSIDs appearing in the probe responses. Must be some 'hidden' parameter other than the plain list order that is relevant.
Josef