Wireless Access

I've noticed in a few packet captures that quite often stations and APs  are using the RTS/CTS mechanism. The only reason I can think of is that 'b' protection is enabled - although I am 97% sure there are no 802.11b clients about. Are there any other reasons that either the client/AP would decide to enable this mechanism? 

RTS/CTS is used to help curb the hidden node problem when a client can't hear transmissions from another client (and then collisions would occur).

Here's a good explanation:

http://arxiv.org/ftp/arxiv/papers/1003/1003.4070.pdf

Re - hidden nodes;

acknowledged - but this mechanism would need to be put on explicitly my the administrator iirc?

---

@eljay wrote:

I've noticed in a few packet captures that quite often stations and APs  are using the RTS/CTS mechanism. The only reason I can think of is that 'b' protection is enabled - although I am 97% sure there are no 802.11b clients about. Are there any other reasons that either the client/AP would decide to enable this mechanism? 

 

 

---

There are two reasons it is happening: (1) 802.11b protection is enabled on the Aruba Controller in the 802.11g radio profile (it is enabled by default) and (2) There are 802.11b clients present on the channel.  The access points and clients are sending this in response to at least one 802.11b client present.  You have the option to uncheck that parameter in the 802.11g radio profile, so that access points will not send it in response to 802.11b client on the channel.  Clients, however will continue to send RTS/CTS traffic if they observe 802.11b clients and there is nothing you can do about that.  The purpose of RTS/CTS is for 802.11g and faster traffic to alert 802.11b clients, that cannot decode their traffic, that traffic is being sent.  If you have that parameter unchecked and you have 802.11b clients that cannot decode that traffic, they will attempt to transmit when other clients are transmitting and you will have collisions that degrade their traffic, probably....  Long story short -  It was only put in here because there is an option to disable it on other WLAN infrastructures.  You should always have protection on...

OK, thanks...

I am 99% sure that there are no 'b' clients about... which is why I'm not understanding why there are lots of cts/rts packets about... However your response does fit with my understanding of how cts/rts works. 

Given that I don't support 802.11b clients - according to Airwave there have only been 2 seen on the entire site, I think I'm going to disable 802.11b protection. The impact on performance is *huge*.  I'm sure the 'b' client owners will contact the helpdesk if they're desperate for service ! :)

Please don't remove the option to disable b protection! 

eljay,

Just because you do not support 802.11b clients does not mean they are not in the area, somewhere.  Airwave only sees clients that actually associate, not clients that merely scan.  If someone brings in an 802.11b client but it does not associate, it is still seen by clients and access points, NOT airwave necessarily.  If you don't believe that you have any 802.11b devices, but there is the small possibility that someone is carrying one, why not let a time-honored mechanism used to protect those clients and your performance continue to perform?  We have observed so many users disable mechanisms that are necessary for their network to run and when it is time to troubleshoot, they are not able to actually tell us why they are disabled...  This is not a feature..  It is part of the 802.11 spec...

Again, the ability to disable this is only because other manufacturers have it, NOT because it would improve performance.

*nod* 

I see what you're saying,

The trouble is, I'm seeing CTS/RTS *everywhere*, and my gut feeling is that it's not actually required. The impact of protecting a few AP's / Clients seems to be outweighing the benefits from letting these connect successfully.  I understand that the CTS/RTS mechanism will reduce performance in an otherwise 'healthy' 802.11g network (for example) from 20Mbps effective max throughput to about 13Mbps... So, given a high density of clients, you can understand that I am keen to kill off anything which will have a detrimental impact.  

I'm wondering if I'm seeing the 802.11b protection ripple effect?

There are so many other things to worry about, like making sure the spacing and power of access points is correct and encouraging as many clients onto the 802.11a band.

If you do disable that parameter, how will you measure the effect that it has on your clients on a continuous basis?  I personally do not enable or disable anything that I cannot directly measure its effect on clients.  With that being said, this is an open forum and others can relate their experience with that parameter.

All those are being managed effectively ; ie, network is professonally designed/surveyed, etc... Band steering is on...   :)

Good question re: measuring the effect. I'd suggest that it's almost impossible to do so. You never get the same set of  variables twice outside the lab... 

hmm...

The mystery deepens...

1) No Beacons contain the Non-ERP Not Present bit sent in the ERP flags...

2) Having done a scan of lots of channels, I'm getting lots of RTS/CTS on 5GHz channels too....

After some digging and a post on Linked in I have solved this issue.

First and foremost, the behaviour observed is correct; ie the WLAN is perfroming to standards. It looks like the behaviour is simply 802.11n mixed mode protection; as illustrated in the attached screen clip taken from an AP beacon. Therefore clients transmitting at 802.11n rates need to send CTS/RTS packets to tell legacy clients to "shush". 

In the example I was looking at, the 'n' client was transmitting at 65Mbps. I do wonder whether it'd be better off just using the 54Mbps 'g' rate such that nobody need bother filling up the air with the CTS/RTS packets!

And meant to add the link to a great summary of 802.1n proteciton