I’ve been doing some research around RTS / CTS.It would appear that the current size parameters of RTS/CTS are based around the older WEP encryption standard.Below are the different possible maximum frame size of a 802.11 packet, according to the encryption scheme in use :MTU + MAC Header + Encryption HeaderWEP : 2304 + 34 + 8 = 2346 bytesWPA (TKIP) : 2304 + 34 + 20 = 2358 bytesWPA2 (CCMP) : 2304 + 34 + 16 = 2354 bytesPerhaps NG should look at adjusting the RTS/CTS parameters based on the currently implemented Wi-Fi encryption.Additionally 802.11ac increases the capability to send aggregated frames sizes from 65,535 to 4,692,480 bytes (4.47 megabytes).Some of us are observing satellite instability issues when disabling RTS / CTS by setting it to 2347 particularly during video calls.Happy to discuss the above observations with NG.https://www.oreilly.com/library/view/80211ac-a-survival/9781449357702/ch03.html

Perhaps I read the underlying information incorrectly. The impression I get is that the range of 0-2347octets is part of the 802.11 specification, not a choice made by Netgear. If Packets are shorter than the limit specified, they are sent without using the RTC/CTS mechanism. If packets are larger (even really, enormously larger) then they must use the RTC/CTS mechanism. It is clearly possible for a packet encrypted with any mechanism to be shorter than the maximum, and thus qualify to be sent without waiting for RTC/CTS. As FURRYe38 notes, setting the parameter to 64 octets will mean that the vast majority of packets use the RTC/CTS mechanism. Perhaps newer encryption methods have created a reason for the 802.11 standards committee to revisit the maximum size of a packets to qualify for skipping RTS/CTS, but that does not seem to be a "Netgear issue." p.s. Thanks for the link to O-Reilly. Fascinating reading!

I usually change my CTS/RTS settings to max (2347) as soon as I get a new NG device. Then, I watch the router statistics closely for a few days/weeks to see if there are any collisions. While I have a fair number of connected devices (35), the majority of them are low traffic devices and I have never had an issue with any collisions so 2347 works fine with me. From what I've read regarding CTS/RTS settings, as long as you are not getting any collisions, 2347 (basically CTS/RTS OFF) is fine. If you start getting collisions, then you need to adjust. I have also seen on several places that with such a low value as is set by NG when their Orbi devices are delivered, that you may end up with a latency issue. I am not a user of ZOOM or other videocall type of software except on very rare occasions. I've not had any drop/reconnect, but then again, I do not have a great number of calls to refer to.

Still wonder why NG employes 64 for CTS on Orbi AX Systems. I'm using 64 for CTS and it's been working well for me. I know the norm for most other GN routers is 2347 and has been historcally for years. I was told my someone at NG is that if you have more wifi nieghors, can impact what the CTS value could be used I think.

I agree with you that setting the CTS/RTS to a lower value is irrespective of the encryption method used.The behaviour I and others are seeing when setting CTS / RTS to the maximum value is the sudden and frequent reboot of the satellite particularly during video calls from a device connected via a satellite.The 802.11ac specification supports sending very large aggregated frames.I suspect there maybe some kind of internal buffer overrun when moving data between the client and the backbone 5Ghz radios within the satellite which of course doesn’t happen if the client is connected directly to the router.I’d be interested to understand if this remains an issue if the satellite uses a wired backbone instead.Personally I’ve been largely happy with the performance / reliability of the Orbi once I had realised that changing the RTS/CTS from the default of 64 to the maximum appears to be the underlying cause of my satellite reboot issue.

I am almost dizzy trying to comprehend WiFi. (Love that O'Reilly chapter! but, OMG!!!) Switch the radio to 802.11a to send the RTS (on as many channels as are desired), get the CTS responses and then set the radio to the highest speed possible to transmit the data packet on the correct number of channels. O'Reilly makes it very clear that the RTS/CTS business was created well before 5G WiFi. Would love to know how somebody decided that 2347 was the ideal cutoff point. i.e. For a packet shorter than that, just send the damn thing and retransmit if something goes wrong. If longer, then to a RTS/CTS to get permission to hog the radio for a longer time. Where I was going was changing the RTS/CTS from 2347 to a smaller number increases the number of packets that will require RTS/CTS protocol. When it is set to 2347, than a packet of 2346 octets would ignore the RTS/CTS and just send (as would 2345, 2344, 2343... down to the smallest packet possible). Yes, there are tons of huge packets, but there may be smaller ones as well. (Think of ICMP with 32 octets, ARP broadcasts (28), or DHCP (576).) It's not clear (to me) what the default value is. To my knowledge, I have never changed mine and it is set to 2347 (on two different Orbis). Perhaps the default is 64 for the AX products, or......?? Another unknown is the setting for the 5G (and the backup 2.4G) backup WiFi channels. I am pretty confident that those advanced WiFi settings (Transmit Power, RTS/CTS) are for the user facing WiFi channels and have no effect on the backhaul channels. On the AX product, for example, there is an option to turn off 'ax' capability on the user facing channels, but I am 100% certain that ax remains on the backhaul channel.

RBR850 RTS / CTS | NETGEAR Communities

14 Replies

FURRYe38
Guru
Feb 20, 2022
Still wonder why NG employes 64 for CTS on Orbi AX Systems.

I'm using 64 for CTS and it's been working well for me. I know the norm for most other GN routers is 2347 and has been historcally for years. I was told my someone at NG is that if you have more wifi nieghors, can impact what the CTS value could be used I think.
- CrimpOn
  Guru
  Feb 20, 2022
  Perhaps I read the underlying information incorrectly. The impression I get is that the range of 0-2347octets is part of the 802.11 specification, not a choice made by Netgear. If Packets are shorter than the limit specified, they are sent without using the RTC/CTS mechanism. If packets are larger (even really, enormously larger) then they must use the RTC/CTS mechanism.
  
  It is clearly possible for a packet encrypted with any mechanism to be shorter than the maximum, and thus qualify to be sent without waiting for RTC/CTS. As FURRYe38 notes, setting the parameter to 64 octets will mean that the vast majority of packets use the RTC/CTS mechanism.
  
  Perhaps newer encryption methods have created a reason for the 802.11 standards committee to revisit the maximum size of a packets to qualify for skipping RTS/CTS, but that does not seem to be a "Netgear issue."
  
  p.s. Thanks for the link to O-Reilly. Fascinating reading!
  - rr20552
    Apprentice
    Feb 21, 2022
    I agree with you that setting the CTS/RTS to a lower value is irrespective of the encryption method used.
    
    The behaviour I and others are seeing when setting CTS / RTS to the maximum value is the sudden and frequent reboot of the satellite particularly during video calls from a device connected via a satellite.
    
    The 802.11ac specification supports sending very large aggregated frames.
    
    I suspect there maybe some kind of internal buffer overrun when moving data between the client and the backbone 5Ghz radios within the satellite which of course doesn’t happen if the client is connected directly to the router.
    
    I’d be interested to understand if this remains an issue if the satellite uses a wired backbone instead.
    
    Personally I’ve been largely happy with the performance / reliability of the Orbi once I had realised that changing the RTS/CTS from the default of 64 to the maximum appears to be the underlying cause of my satellite reboot issue.

Forum Discussion

RBR850 RTS / CTS