NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
RBR850 RTS / CTS
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 m...
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.
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 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.
