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?

[neil_neil_67001]

Josef - I'm part of the training team, so wouldn't normally  - I only come to the forums to offer informal advice. I've read the support case, and I see that this was looked into pretty deeply by the support team. As an employee of Ruckus, I can't really add any more, as the support team have access to the engineering teams and I know would have looked into this fully for you.

Prior to joining Ruckus, I did professional services and taught AirMagnet and CWAP classes. If I take my Ruckus hat off and look at this from a purely technical perspective,  I would want to look at the issue you're actually reporting before coming to any conclusions. That would involve doing a capture using a dedicated capture tool rather than from the access point, including next to any client stations, and also to get some proper metrics into retry rates and data rates. Knowing 802.11 as I do, I do not believe that altering Cw values will have an affect, though we would need to get into a long technical debate in order see why. Usually when delivering Ruckus training, I advise to leave settings at defaults unless you a) fully understand the implications of the change you make and b) are able to thoroughly test the results of any changes.

I don't feel I can add anything here as you have had support go through this with you, and as I'm not part of the support team, anything I add would be guesswork without having the opportunity to test properly, which unfortunately I''m not in a position to offer.

I'm sorry I can't be more useful in this case.

[josef_felber]

>>> I'm sorry I can't be more useful in this case.

But then who can?

The outcome of the support case I have referenced more or less was:
"...We transmit management frames with highest priority as they are essential for maintaining/connecting clients. On the other hand, we may reduce the management frames priority after certain retransmissions (which will increase the complexity of our design) or reduce the retransmissions of management frames and we have had this discussion internally as well. This will be a major design change and so is on Engineering’s to-do list. But I don’t have a timeline on it and am not sure when we would start working on it as we will have to first spend some resources on the gain of this change overall." (Ruckus Support Engineer)

This was about one year ago. Our customers still report issues, we still see strange traces and obvoiusly other groups observe similar or even more dramatic problems.

To bring it to a point: what should I respond next time to a customer who complains about issues using certain VOIP clients with Ruckus equipment that ran ok with (much cheaper) different brand access points before?

Josef

[michael_brado]

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.

[josef_felber]

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

[michael_brado]

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