I thought that 802.11 used rts/cts and the nstreme would allow polling, but I see that it has been added in the wirelesstest package. Does that mean that it hasn’t been used in the past. Wouldn’t it be a great thing to add to every access point then if it wasn’t running before? I have searched and am finding very little info on it so far.
Tom
No RTS/CTS in the past and polling was only used when Nstream was enabled.
My first work with wireless was with Breezecom, it had rts/cts, so for some reason, I thought that is what 802.11 consisted of.
Can you think of any reason why I should upgrade everything to rts/cts right now. I have 3 locations in town with 3 sectors on each location. Wouldn’t this help with hidden node?
Tom
So, the default behaviour of ROS is to not use RTS/CTS?
OK, it’s like this:
Previously RouterOS AP always replied with CTS to those who asked RTS, but RouterOS client never asked for RTS. Ie. the support was not in the client. Then we introduced NStreme polling to solve the hidden node problem.
Right now, in the Wireless Test package, we have also included RTS support for the RouterOS client, but you have to configure it:
http://wiki.mikrotik.com/wiki/Wireless_Development#Frame_protection_support_.28RTS.2FCTS.29
I didn’t know about all those new settings.. which are the default settings of the wireless-package? cts-to-self, rts-cts, hw-fragmentation-threshold etc etc
Thanks for the wiki btw, it will help me understanding why the wireless-test package is way better than the normal one, even some stations suffer by it. (But it’s only 2% of my customers, the other 98% is simply perfect)
And what about ROS AP with many ordinary radios (not ROS) connected to it (without NStreme)?
ROS AP with non-ROS clients always worked with RTS/CTS if the CLIENT REQUESTED RTS
That’s what I wanted to know. Thanks! 
I’ve got another question now: is it possible (or, will it be possible via wireless-test) to disable RTS responses totally? I mean, even if a client sends a RTS frame, ROS won’t answer with CTS (I know this might sound crazy :p)
So why WOULDN’T I want to upgrade all my clients and turn on the rts? Sounds like a good thing to do.
Tom
The mad reason to turn off ROS RTS/CTS responses is to disable RTS/CTS at all in a network and test the effects. As a computer scientist, I enjoy doing such things. It helps me to learn more.
Of course, in a real application, I’d let RTS/CTS working as normal. But, anyway, I think disabling RTS/CTS at all could avoid NAV attacks at the cost of some collisions in your network.
Once again, I need to test and probe it in real life to make me happier. 
From what I understand, the RTS/frag settings are set on the client side. You would never set this on the AP. Also, RTS/frag settings seem to be in the realm of voodoo science… some swear by it, others never use it and do just fine. As mentioned above, with nstream preventing the hidden node problem, there’s no need to tweak the RTS/frag settings.
We have AP’s running clients with RTS/frag settings, and some without. We have seen no noticeable improvement. In some cases if the client’s RTS/frag settings are too low (256/512 or lower), it will result in poor performance for that client.
Hi,
I’m really interesting about this topic (it is a part of my studies final project). I’m trying to understand how RTS/CTS works (and I know the standart of 802.11). The problem is that the standart doesn’t define exactly the functions, just the general things, so every trademarks do it its own way.
I’m trying to see the efects of disable/enable RTS/CTS mechanism in a little network (and the hidden node problem). I tryed to disable TOTALLY rts/cts (umbral trh=2347), but in some situations still appears rts/cts frames without any sense.
Anyone knows how really works this mechanism??
NOTE: sorry about my “rude” english
Sorry, but this is not (100%) true.
Mikrotik 2.9.x on Routerboards 532 with CM9 cards in AP mode would never reply to RTS packets. We have tested this with various stations (WA2204, Ovislink 1120, …) and it never worked.
The RTS started working in Mikrotik 3.x, but: on the same HW, Mikrotik 3.1x in AP B-only mode does not send CTS. We are also suspicious that Mikrotik in AP B/G mode does not send CTS to stations using 802.11B rates, but this is very hard to track.
These bugs are very annoying, because the proper RTS/CTS implementation is very important for exterior wifi networks with many hidden nodes.
I don’t understand how could Mikrotik neglect such a fundamental feature for such a long time…
Anyone troubleshooting wireless - a method to see what is on the air - is to use a wireless sniffer that captchures all packets from air and all frames actually - analyze probably with Wireshark, and please, when you are sure, submit probles to support@mikrotik.com and supports of other manufacturers if other equipment is part of the problematic setup. Post on the forums as well, so we Know that there is a problem and know to avoid it.
Regards.
1.: “RTS/frag settings only on the client side.” Does this mean the AP’s don’t need the wireless-test package and can be left working as they are? (What is then the use of the CTS-to-itself example given here: http://wiki.mikrotik.com/wiki/Wireless_ … S.2FCTS.29 ?)
2.: “Voodoo science..” Yes, but wasn’t all this wireless info and ROS configurations voodoo to us all when we started building wireless networks from scratch? And techniques are still developing and even MT technicians learn every day new tricks I bet. Off course, some networks will benefit from some new techniques, others won’t. My network with mixed make client CPE’s and many hidden nodes will certainly benefit from it is my expectation after reading this and other forums.
3.: “With nstream preventing the hidden node problem, … etc” is nice, if you have no other manufactures units in your network. If you have then nstream is not usable. Only MT supports nstream.
4.: So, who can give me a nice guideline in which rts frame size to use? What are the factors influencing this, or been influenced by the the frame size. The bigger the faster but more change of new handshakes with the resulting overhead in newly send frames, or the smaller but lesser throughput on a link.
What influence is the link connection rate? Or the link’s/client’s bandwidth assignment.
Anybody with some general advices?
5.: Packet fragmentations. What relation does this have in respect to frame protection and frame size? Can somebody give me some explanations here?
Rudy
I took some info from the AirOS wiki:
Quote: RTS Threshold: determines the packet size of a transmission and, through the use of an access point, helps control traffic flow. The range is 0-2347bytes, or word “off”. The default value is 2347 which means that RTS is disabled.
RTS/CTS (Request to Send / Clear to Send) is the mechanism used by the 802.11 wireless networking protocol to reduce frame collisions introduced by the hidden terminal problem. RTS/CTS packet size threshold is 0-2347 bytes. If the packet size the node wants to transmit is larger than the threshold, the RTS/CTS handshake gets triggered. If the packet size is equal to or less than threshold the data frame gets sent immediately.
System uses Request to Send/Clear to Send frames for the handshake which provide collision reduction for access point with hidden stations. The stations are sending a RTS frame first while data is send only after handshake with an AP is completed. Stations respond with the CTS frame to the RTS which provides clear media for the requesting station to send the data. CTS collision control management has time interval defined during which all the other stations hold off the transmission and wait until the requesting station will finish transmission.
Fragmentation Threshold: specifies the maximum size for a packet before data is fragmented into multiple packets. The range is 256-2346 bytes, or word “off”. Setting the Fragmentation Threshold too low may result in poor network performance.
The use of fragmentation can increase the reliability of frame transmissions. Because of sending smaller frames, collisions are much less likely to occur. However lower values of the Fragmentation Threshold will result lower throughput as well. Minor or no modifications of the Fragmentation Threshold value is recommended while default setting of 2346 is optimum in most of the wireless network use cases. Un-Quote.
Here is some more usable explanations. My questions regarding the guidelines for package and frame size still stands though…
Rudy
There are many reports stating that nstreme in the point-to-multipoint network with hidden nodes only make things worse. I found only this one report saying that in Nov 2008, Mikrotik made new p2mp nstreme polling algorithm which works well in point-to-multipoint.
Unfortunatelly, there are no details about which Mikrotik version already has the new polling algorithm, maybe people from Mikrotik can tell us?
See my comment on this here.
Just use google! Or read this and this document.
Let say that the length of the RTS frame, transmitted on 1Mbit/s (802.11b) or 6Mbit/s (802.11g-only) is X micro seconds.
The length of a data frame transmitted with “RTS Threshold bytes” on higher data rates (where data rate is dependent e.g. on signal quality) is Y microseconds.
You should set RTS Threshold to such value, that Y would be much bigger than X.
Sorry for not providing the example values for X and Y, it’s very late and I should have been sleeping for 5 hours now…
And, also check this document and if you can speak Czech, then also this diploma thesis.
You would use Fragmentation as last chance for transfering data over very noisy or weak links. Because the shorter the packet is, the bigger is the probability that it would be transfered without error on a bad link.
You will not want to use fragmentation in any other case. For hidden node protection, use only RTS/CTS. Fragmentation increase the overhead = lowers the throughput of your link. Remember: each fragmented packet would need RTS which takes time - and there is always the possibility that collision will happen even on RTS packet transmission!
I m a little confused.
I must activate RTS/CTS on all client?