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

No RTS/CTS in the past and polling was only used when Nstream was enabled.

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_ ... S.2FCTS.29

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_ ... S.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)

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_ ... S.2FCTS.29

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

ROS AP with non-ROS clients always worked with RTS/CTS if the CLIENT REQUESTED RTS

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...

ROS AP with non-ROS clients always worked with RTS/CTS if the CLIENT REQUESTED RTS

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.

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.

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

As mentioned above, with nstream preventing the hidden node problem, there's no need to tweak the RTS/frag settings.

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?

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?

See my comment on this here.

(What is then the use of the CTS-to-itself example given here: http://wiki.mikrotik.com/wiki/Wireless_ ... S.2FCTS.29 ?)

Just use google! Or read this and this document.

4.: So, who can give me a nice guideline in which rts frame size to use?

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.

5.: Packet fragmentations. What relation does this have in respect to frame protection and frame size? Can somebody give me some explanations here?

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?

I m a little confused.

I must activate RTS/CTS on all client?

Exactly!

By the way, using the internal RouterOS sniffer tool gives me some Wi-Fi specific frames/packets, which is very good. No time to investigate further but will some day.

I m a little confused.

I must activate RTS/CTS on all client?

Exactly!

By the way, using the internal RouterOS sniffer tool gives me some Wi-Fi specific frames/packets, which is very good. No time to investigate further but will some day.

Can you help me to understand what happen in mixed scenario (some client with RTC/CTS enable and some disabled)?

The more clients have RTS enabled, the better. As I said, sniff frames off of the air and see for yourself (is done with specialized equipment). Since each manufacturer could make their device transmit crazy stuff, it depends a lot of factors, in every single case, as well as, what antennas the clients are using, what fw versions, how far are they, ....

The more clients have RTS enabled, the better. As I said, sniff frames off of the air and see for yourself (is done with specialized equipment). Since each manufacturer could make their device transmit crazy stuff, it depends a lot of factors, in every single case, as well as, what antennas the clients are using, what fw versions, how far are they, ....

Specialized equipement: ROS wireless sniff + wireshark?

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_ ... S.2FCTS.29

And then we have this:

dulik wrote:
normis wrote:
ROS AP with non-ROS clients always worked with RTS/CTS if the CLIENT REQUESTED RTS


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...

Basically we want a conclusive answer now for the AP.
I believe normis when he says it always worked.
I believe dulik when he stated is might not always be the case........

But I still don't know what is the situation after installing wireless-test on the AP!

In the normal wireless package it is not an option to enable or disable. So if Normis says it works then it I take that for granted.
But in the wireless-test we do have that option, also for AP function. By default it is all disabled. Does it now mean it is really disabled, also for AP/AP-Bridge mode, and do we switch it on when wireless-test is installed? Or can we leave all options disabled in AP mode?
Or maybe there is not even the need to install wireless-test on the AP?

Normis, a mixed client environment is very common these days and so is the hidden node. It would be nice if MT gives a better explanation in the wiki for their user base. You guys should know more than us (in general) so why not produce better understanding.... The better understanding, the more successful MT based networks, the more business for MT! Would that not make you happy!

If there are any test packages with new options, why not make a wiki section that explains what they do and how they work and under which circumstances it is best to use.

Rudy

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.

But I still don't know what is the situation after installing wireless-test on the AP!

Our test of the current wireless-test package had mixed results.
On one node (VIA EPIA with 3 CM9 miniPCI cards) we installed it yesterday and it still runs . We tried to use its new nstreme polling, which should solve the point-to-multipoint & hidden nodes problems better than RTS/CTS and it seemed to improve the links.

But: then we tried to install the same package on another node with almost the same HW (VIA EPIA but 4 CM9 miniPCI cards) and the node went crazy: 100% CPU load and all 4 wifi links were almost dead. We struggled for one hour until succeeding with remote installation of the classic wireless (stable) package.

Anyway, even when wireless-test happens to be stable in future, the nstreme polling can help only if all the AP&stations are Mikrotik.

If you have Mikrotik as AP but stations are something else (cheap boxes with RTL8186 chipset in our case), then nstreme polling is useless and you need RTS/CTS.

Mikrotik customers never asked for RTS/CTS because most of them probably have not ever heard about hidden nodes... if they have some packet loss, they always think it is just some "interference or noise"

Mikrotik might also tell them - "RTS/CTS is not that good as our nstreme polling so don't buy anything else, buy just Mikrotik for your networks!". And this would be true if the wireless-test package would be stable, but now it is not.

Solution for us? Fortunately, we have Mikrotik only on APs, and the sloppy RTS/CTS implementation in the AP mode pushes us to migrate the APs to Linux or OpenWRT, because RTS/CTS works there reliably, since ever I remember. Even the damn cheap Nanostation handles RTS/CTS correctly in all situations. Mikrotik does not!

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.

I would do this in case of an open source project like Madwifi. Even if it is quite tough job, because you need an AP with 2 stations and you need a hidden node. How to produce a hidden node on a office table? I thought about closing the AP and a node into a metal box, but letting the AP antena go through the box so the 2 other stations can hear it. But I haven't had the time to try so don't know if the metal box would really produce hidden node.

Aside of this experiment, it's impossible to sniff the interesting packets from real network with hidden nodes. Just the basic question: how to find, which nodes are hidden? And even if you find out, how to sniff packets from hidden nodes - when they are hidden ? You would have to climb on the roof where the AP is located with a notebook, but you know, the cold winter finished just 3 weeks ago here.

Moreover, in case of Mikrotik:
Doing serious testing of their products, e.g. by sniffing packets in otherwise hardly-reachable locations, is their job! I think they must have a testing network with artificially long/noisy links, hidden nodes, many various stations for compatibility tests... so: why should I turn our network useless for half an hour just to do their job?

OK, so here is my bug report:

What I have done so far was looking into Madwifi driver and OpenHAL code and here is what I found:

In Atheros, RTS/CTS is completely handled by the HW. The reason is tight timing necessary for RTS/CTS - the spaces between RTS,CTS and data packet are SIFS=10us and this could not be done in SW, because just interrupt latency on any current computer is something between 2-30us, depending on the system load. Therefore, Atheros manages RTS/CTS in HW and its SW driver must do almost nothing about it. The only thing the driver must do is enabling the RTS/CTS functionality by writing a value into a register.

(Gees, Mikrotik was not able to add "write a byte into a register" instruction in all their versions prior 3.x? Such an easy thing missing for so many years? They could just look into Madwifi to see how to implement it...)

Now when they finally enabled RTS/CTS in 3.x, the only explanation for RTS/CTS not working in 802.11b-only mode is:

If the RTS/CTS is enabled, then the only thing, which an Atheros SW driver can fuck up about RTS/CTS, is the duration field, which is carried in the 802.11 packet. If Mikrotik sets the duration to a shorter value than the necessary one and such a erroneous CTS packet is sent to a hidden node, the result is that all the stations would set their NAV vectors to the shorter value and then - because they don't hear the hidden node transmission - they would alway jump into it's transmission by their transmission and spoil it.

So in fact, the RTS/CTS would appear to work at first sight, but if the traffic on the AP increases, this bug would make it even worse. Which is what we are seeing in our network.

Please Mikrotik, spend some few hours with your code by comparing it with Madwifi to find what you are doing wrong!

Thanks a lot in the name of all hidden nodes in the Mikrotik world!

Wel dulik,

Just to comment the first part of your message, your reply serves MT, you and me right!
MT said it always worked on AP's
You said it sometimes fails
I said I believe you both.

MT is probably only testing in an environment with their own hardware which is, no surprise, routerboard! I have rb for all my AP's and 4 of them (rb500, rb433 and rb333) running wireless-test now seem not to have problems. I only don't notice any differences when I enable or disable the rts/cts in the AP. But then again, I don' have the ability to really check or test that.

You obviously work with other hardware for AP's and that might have compatibility problems.
You can't expect MT-ROS to work on all hw in the world flawless.
Even Microsoft is not able to achieve that in their industry!

R.

I only don't notice any differences when I enable or disable the rts/cts in the AP. But then again, I don' have the ability to really check or test that.

This is what we found: with wireless test, enabling RTS/CTS on our 5GHz AP with 4 clients did not improve anything. But I don't blame Mikrotik here, the clients are very far from the AP (3km) and this is absolutely outside of WiFi specification scope - WiFi was specified with propagation delay<1us in mind, and 3km is 10us - the same time as SIFS... So aside of hidden node problem, there may also be a timing problem.
We are still testing how the new nstreme polling improves the behaviour of the p2mp with long links, but it is very new thing, so sorry for not being able to tell you now.

MT is probably only testing in an environment with their own hardware which is, no surprise, routerboard!

I am sure they must be testing also on x86, because things like nstreme2 does not work reasonably on something like RB532.
You asked for the status of wireless-test and in my reply, I gave you a link to the thread in this forum where the people are reporting their success and failures when testing it. I have added our report about another failure similar to what has already been reported, proposing that wireless-test is still unstable and should not be taken as "life-saving equipment".

I have rb for all my AP's and 4 of them (rb500, rb433 and rb333) running wireless-test now seem not to have problems.

We also have RBs on almost all our APs. There are various versions of MK running of them 2.9.x-3.22), but RTS/CTS is not working on any of them if the mode is 802.11b-only and clients are 802.11b/g.

You obviously work with other hardware for AP's and that might have compatibility problems.
You can't expect MT-ROS to work on all hw in the world flawless.

My impression about Mikrotik is falling rapidly since last year.
With 3.x, they have introduced many subtle improvements, but also many bugs and the importand things are still missing.

I also think they have made a great mistake by making Routerboards with completely different HW architectures. Now, aside of x86 which is their original platform, they must support also PPC8547 (RB1000), MIPS Atheros AR7130 (RB411-433AH), Freescale Power Quick MPC8343E (RB600), PowerPC E300 (RB333), MIPS32 aca Infineon 5120 (RB133, RB532), ...

This is not just about CPUs, these are really completely different board architectures, which means - what works on RB532, does not necessarily works on RB600...etc.

If you know Linux a bit, you know how much work it is to compile and test just one stupid SW package. Now, Mikrotik must do this for so many different architectures!!

And this trend will certainly continue. Example: all the current Routerboards are useless when it comes to 802.11n, because most of the 802.11n dual-band cards mass-produced for notebooks has the Mini Card (PCI Express) form. So we are looking forward to a brand new Routerboard with Mini Card, but the same time, we are sure that the new architecture will bring a new set of problems.

If I'd be Mikrotik, I would stop developing all those different HW branches. I would concentrate on the SW and I would support only the platform which is most easy for any Linux development: x86. I would make partnership with somebody like PCEngines to get their WRAP/Alix boards for such a price that the Mikrotik licence could be included in the end-user price similar to the current Routeboards.

I only don't notice any differences when I enable or disable the rts/cts in the AP. But then again, I don' have the ability to really check or test that.

This is what we found: with wireless test, enabling RTS/CTS on our 5GHz AP with 4 clients did not improve anything. But I don't blame Mikrotik here, the clients are very far from the AP (3km) and this is absolutely outside of WiFi specification scope - WiFi was specified with propagation delay<1us in mind, and 3km is 10us - the same time as SIFS... So aside of hidden node problem, there may also be a timing problem. Well, I am referring to a close quarter densily populated (antenas) environment with both ´hidden nodes´and lots of interference, even in the 5Ghz. (use of 10 different freqs. in small area with lots of concrete house blocks and low antenna's). I also have a network in the country side were clients are on average 1 to 5 km's away. I don't use rts/cts here and due the lesser interference levels I actually have much better link quality here. In my humble opinion rts/cts makes no difference if there are only a handfull clients to an AP. CSMA/CA works fine under such condition and how big is the change you have a ´hidden node´ problem if you only have 4 clients?

We are still testing how the new nstreme polling improves the behaviour of the p2mp with long links, but it is very new thing, so sorry for not being able to tell you now. Well, there is plenty info on that in this forum. The bottom line I distilled is that it is great on heavy use links and off course on a MT platform consistent network only. I run it without polling on my back hauls and it actually improved the throughput. I ran some load tests and the throughput was increased by 1 to 1,5Mb on average with nstream.

MT is probably only testing in an environment with their own hardware which is, no surprise, routerboard!

I am sure they must be testing also on x86, because things like nstreme2 does not work reasonably on something like RB532. Well, they must be. But how reliable will that be when it comes to hardware compatebility? x86 is probably the heaviest differentiated platform you can imagine! And why should RB532 not work with nstreme2? nstreme2 will do fine on it but probably the cpu just cant process the increased data flow. I have been reading several success stories in the past on this forum on the nstreme2 protocol use on 5xx boards. So if set up properly it works....

You asked for the status of wireless-test and in my reply, I gave you a link to the thread in this forum where the people are reporting their success and failures when testing it. I have added our report about another failure similar to what has already been reported, proposing that wireless-test is still unstable and should not be taken as "life-saving equipment". If MT has implemented the IEEE 802.11 MAC protocol when it comes to DCF accordingly (and I would not see why they shouldn't) then I see actually no reason why it should not work. But, time will tell, I just changed a complete AP-CPE network towards it to see how it behaves.

I have rb for all my AP's and 4 of them (rb500, rb433 and rb333) running wireless-test now seem not to have problems.

We also have RBs on almost all our APs. There are various versions of MK running of them 2.9.x-3.22), but RTS/CTS is not working on any of them if the mode is 802.11b-only and clients are 802.11b/g. I can't say nothing on that since I use the 802.11a only. But the DCF handshaking rts/cts routine should work for both the same according one of the links you gave me yourself. http://www2.tku.edu.tw/~tkjse/6-1/6-1-8.pdf

You obviously work with other hardware for AP's and that might have compatibility problems.
You can't expect MT-ROS to work on all hw in the world flawless.

My impression about Mikrotik is falling rapidly since last year.
With 3.x, they have introduced many subtle improvements, but also many bugs and the importand things are still missing. My experience is that 3.x is a great improvement in managing routers. OK, I also have been driven mad in the early versions because there were so many upgrades needed. But from a complicated and extended OS you can't expect so much different. I work with several other operating systems for PC's, domestic indoor routers, and other equipments and they all need regular sw updates. What version is the latest Linux distribution? And in which flavour you want it? Personally I think MT is not doing any worse then the industry in general. And if you look at the enormous amount of new users they made the last year you can't defend they make a poor product.

I also think they have made a great mistake by making Routerboards with completely different HW architectures. Now, aside of x86 which is their original platform, they must support also PPC8547 (RB1000), MIPS Atheros AR7130 (RB411-433AH), Freescale Power Quick MPC8343E (RB600), PowerPC E300 (RB333), MIPS32 aca Infineon 5120 (RB133, RB532), ... Same story again, which vendor works with the same hardware as 5 years ago and still goes strong? I am not saying users are always happy with choices made. But every vendor makes choices upon market expectations and hardware availability that later might prove to be wrong. But they still have to keep their bookkeepers happy and try to sell what they can of their not so popular stocks... It counts for the auto mobile, domestic house hold, or whatever industry.... why should MT do better?

This is not just about CPUs, these are really completely different board architectures, which means - what works on RB532, does not necessarily works on RB600...etc.

If you know Linux a bit, you know how much work it is to compile and test just one stupid SW package. Now, Mikrotik must do this for so many different architectures!!

And this trend will certainly continue. Example: all the current Routerboards are useless when it comes to 802.11n, because most of the 802.11n dual-band cards mass-produced for notebooks has the Mini Card (PCI Express) form. So we are looking forward to a brand new Routerboard with Mini Card, but the same time, we are sure that the new architecture will bring a new set of problems. Doesn't that count for the whole industry?

If I'd be Mikrotik, I would stop developing all those different HW branches. I would concentrate on the SW and I would support only the platform which is most easy for any Linux development: x86. I would make partnership with somebody like PCEngines to get their WRAP/Alix boards for such a price that the Mikrotik licence could be included in the end-user price similar to the current Routeboards.

I bought 4 years ago two WRAP board based AP's. One failed already after some weeks. That's a 50% failure rate! (A bit unfair maybe, you can also call it bad luck. On my approx 200 rb`s I have a failure rate of less then 2% so far which is not bad. In reliability they outperform lmost other IT related hardware I purchased in the last 10 years with ease!

Oh yeah, not to be misunderstood. I am not the sales rep from MT!

Oh yeah, by the way. I think we are drifting from the topic here. Sorry.

R.

By the way, I can confirm CTS does not work when in Wi-Fi 802.11b rates and I can also confirm that in 802.11g there are more retransmits than in 802.11b even with 54,48 Mbits disabled. I also have come to believe that MikroTik Latvia should work harder! And what dulik is saying - I think he is right.


About testing: Will it be enough to sniff from the AP interface with the RouterOS sniffer tool and then analyze with Wireshark? I should try this... to see if I can see RTS and CTS frames etc.

By the way, I can confirm CTS does not work when in Wi-Fi 802.11b rates and I can also confirm that in 802.11g there are more retransmits than in 802.11b even with 54,48 Mbits disabled. I also have come to believe that MikroTik Latvia should work harder! And what dulik is saying - I think he is right.

Thanks for the confirmation!
I have already sent the bug report to the support@mikrotik.com, but did not provide any support.rif because this bug is present and all platforms, so sending support.rif files from each combination of Routeborad and RouterOS version would be waste of time.

About testing: Will it be enough to sniff from the AP interface with the RouterOS sniffer tool and then analyze with Wireshark? I should try this... to see if I can see RTS and CTS frames etc.

I have not tried this. But I have the vague impression that RouterOS sniffer works only on the ethernet MAC layer, not 802.11 MAC (ethernet frames are carried in the 802.11 frames as the data payload). The RTS/CTS belongs to the WiFi layer.

When analyzing wifi in Linux, you must switch an Atheros or Intel wifi card into "monitor mode" and then you can analyze what is happening on wifi MAC, e.g. using wireshark. Does Mikrotik supports the monitor mode on the wifi MAC layer?

But even if you succeed with analyzing the 802.11 MAC from Mikrotik, it will be very hard to find the reason of the problem, if it is really caused by wrong "duration" field in the CTS packet, you will just dont see the data packets from the hidden node, because they will be spoilt by some other station transmission.

And with the sniffer, I think you can just see the frames which are received completely.

For tracking such a bug in the air, you would need some expensive wifi analyzer, which allows to check the traffic on the physical layer (the layer under 802.11 MAC).

But Mikrotik team does not have to do this. What they have to do is check their Atheros driver code against Madwifi to check what they are doing wrong with RTS/CTS.

I think we have done all we could to point them the possible cause.

Thank you again for your support!

Oh yeah, by the way. I think we are drifting from the topic here. Sorry.

Sorry from me too, the last paragraphs from my last post are irrelevant in the thread.

By the way, I can confirm CTS does not work when in Wi-Fi 802.11b rates and I can also confirm that in 802.11g there are more retransmits than in 802.11b even with 54,48 Mbits disabled. I also have come to believe that MikroTik Latvia should work harder! And what dulik is saying - I think he is right.


About testing: Will it be enough to sniff from the AP interface with the RouterOS sniffer tool and then analyze with Wireshark? I should try this... to see if I can see RTS and CTS frames etc.

I sniffed a client in RTS/CTS mode, but I don't see this type of frames...

Note: sniff tool in wireless section, I can see beacon frames and other 802.11 frames...

I m a little confused.

I must activate RTS/CTS on all client?

I just want to add one remark to this; Yes, best is to enable hw-protection-mode=rts-cts on all clients.
BUT, ALSO set the hw-protection-threshold! the actual working of the rts-cts is triggered by this setting.

The hw-protection-threshold can be within 256-2346 value. The high value means that most frames are send without the rts-cts beeing triggered. The lowest value (256) is recommended to have rts-cts working at all times.
rts-cts creates some extra overhead on the data stream, and thus slightly lower bandwidth but the overall performance improvement would make that a very minor consideration.

The conclusion is (not mine, I red several white papers and test on the internet) is that in conditions were the ´hidden node´ issue is obvious and lots of packet losses or corruption occurs due high interferences, the enabling of rts-cts on all clients is the best strategy in boosting performance of the network.

On the AP you can leave mode untouched since AP will always answer an rts request from the client.

IMPORTANT!
Together with this I think I found a bug in the MT software as well!
The "Hw. Fragmentation Threshold" in Winbox sets actually the HW. Protection-threshold.
Thus, by setting the "hw-protection-threshold=256" you will see in winbox the "Hw. Fragmentation Threshold" jump to that value!

These settings are not the same! I took me hours before I realised that something weird was happening!

This happens on a rb500. Can anyone of you confirm this bug? If so I will report it to MT.

Rudy

I just want to add one remark to this; Yes, best is to enable hw-protection-mode=rts-cts on all clients. BUT, ALSO set the hw-protection-threshold! the actual working of the rts-cts is triggered by this setting.

Yes, this option is called "RTS Threshold" in all other WiFi devices/drivers.
(why Mikrotik always rename things to some self-invented names, when the terminology is existing and widely used for so many years? Another example: HTB "rate" vs. Mikrotik "limit-at". HTB "ceil" vs. Mikrotik "max-limit", ... many other examples can be found in all GPL packages Mikrotik uses...)

Mikrotik terminology is often confusing like this: "hw-protection" used by mikrotik for all 802.11 protocols is similar to "RTS/CTS protection" technique defined by the 802.11g standard for protecting the 802.11B-only stations transmissions against 802.11g-only stations in mixed b/g environment. So why Mikrotik uses the "protection" term also in 802.11a, where are no such problems with legacy (802.11b) devices?

Should we report their strange terminology in the "-test" packages as bugs? Is anybody aware that Mikrotik would change the terminology to more appropriate names on users request ?

IMPORTANT!
Together with this I think I found a bug in the MT software as well!
The "Hw. Fragmentation Threshold" in Winbox sets actually the HW. Protection-threshold.
Thus, by setting the "hw-protection-threshold=256" you will see in winbox the "Hw. Fragmentation Threshold" jump to that value!

These settings are not the same! I took me hours before I realised that something weird was happening!

This happens on a rb500. Can anyone of you confirm this bug? If so I will report it to MT.

Rudy

Yes, I confirm this, I have noticed this bug also on the x86 version.

OK, so here is my bug report:

I don't know if this is a result of my bug report (I have not received any feedback from Mikrotik), but look what I found in the Mikrotik 3.23 change log:

What's new in 3.23:
...
*) wireless - fix for RTS/CTS when used together with dynamic ACK timeout;

I am going to try if this solved our problem with RTS/CTS not working with the B-only APs.

If it works then all my respect goes to Mikrotik for such a quick fix!

Yes, this option is called "RTS Threshold" in all other WiFi devices/drivers.
(why Mikrotik always rename things to some self-invented names, when the terminology is existing and widely used for so many years? Another example: HTB "rate" vs. Mikrotik "limit-at". HTB "ceil" vs. Mikrotik "max-limit", ... many other examples can be found in all GPL packages Mikrotik uses...)

HTB "ceil" vs. Mikrotik "max-limit" etc

"max-limit" should be easier to remember for a wider range of people . Mikrotik seems to be aimed at a wider range of people who may have better things to do than learn the existing terminology invented by those who don't.

Should we report their strange terminology in the "-test" packages as bugs?

They should file it under "Advanced GPL-itis"

Never post the results...

Is the RTS/CTS working now? In the last versions?

Thank YOU

Yes, it works. I have it on all my AP's now. If I disable it things go bad for connected clients when there is a lot of traffic/poor connected clients.

RTS/CTS has ALWAYS been on the AP's. You don't want to change the settings on your AP's. Only enable on the Clients.

RTS/CTS has ALWAYS been on the AP's. You don't want to change the settings on your AP's. Only enable on the Clients.

Which ROS version?

thanks!

I use 3.28 to 3.30 and slowly start to upgrade units to 4.4 to.
In the 3.x you need to install wireless-test package.
In 4.0 it is in normal wireless package embedded.

R.

Incorrect. ROS has always support RTS/CTS in the AP. No need to upgrade, install wireless-test or anything else.

In fact, you don't want to change the AP settings for RTS/CTS - only enable and tweak in the CPE.

Incorrect. ROS has always support RTS/CTS in the AP. No need to upgrade, install wireless-test or anything else.

In fact, you don't want to change the AP settings for RTS/CTS - only enable and tweak in the CPE.

jwcn, we are discussing MT wireless solution. CTS will not perform unless client supported RTS.

Are you suggesting that AP w/o test package and CPE w/test package work better? With version 4.x it's a moot point since, as it was pointed out, it's v3 w/test package rolled in.

I have to agree with jwcn, it was always available in AP.
I mend to say in my earlier post I have it now enabled on all my clients. AP settings are just default.
Sorry for the confusion, it was late at night...

I'm confused, I read a lot of threads and a lot of information about RTS and CTS implementations but there is something that miss my imagination.

RTS/CTS shoud be configured in CPE only, or in CPE and AP?

I think that is I only enable it in the CPE... well, how the AP know that he has to respond a CTS when the CPE sends the RTS if he do not support that kind of handshake????!!!

I am wrong?

I have to agree with jwcn, it was always available in AP.
I mend to say in my earlier post I have it now enabled on all my clients. AP settings are just default.
Sorry for the confusion, it was late at night...

I'm getting a little confused why it's important to know that it was always available on AP when CPE was ignoring CTS until wireless test package was rolled out. Doesn't it take two to tango?

It is always in the AP and enabled. The AP should always be set at the highest values and the CPE at the lower values.

Think of it like this, for 90% of the MT users - you shouldn't screw with the TX power settings. Likewise, you shouldn't screw with RTS/CTS settings in the AP.

Enable them in the CPE only. The AP is already enabled.

In the past MT's position was RTS/CTS is not needed because in an all MT environment they assumed everyone would use Nstream. In an Nstream environment RTS/CTS is not needed (polling) However, as many use third party CPE devices MT built the functionality of RTS/CTS into the AP's. That way, if you are in a non-MT CPE or Mixed-CPE environment you can utilize RTS/CTS.

Stop beating this to death.

Bottom Line: ENABLE RTS/CTS in CPE ONLY. DON'T SCREW WITH THE RTS/CTS SETTINGS IN THE AP!!!!

I have to agree with jwcn, it was always available in AP.
I mend to say in my earlier post I have it now enabled on all my clients. AP settings are just default.
Sorry for the confusion, it was late at night...

I'm getting a little confused why it's important to know that it was always available on AP when CPE was ignoring CTS until wireless test package was rolled out. Doesn't it take two to tango?

The AP has to support RTS/CTS by default just because if one connect a non MT CPE to the AP it will not probably work - because the CPE will use RTS/CTS probably. If the AP has RTS/CTS disabled (i.e. it doesn't respond to RTS requests with appropriate CTS) the CPE (which is sending the RTS and is waiting for CTS) will not work. It saved Mikrotik company many support calls, IMHO.

We switched all our CPEs to wireless-test just after we discovered that it supports RTS/CTS. Many strange problems with througput disappeared after it. Now we are upgrading to 4.X - because its wireless package support the RTS/CTS feature and it is much safely have the support in standard wireless package (no inactive wlan interface after upgrade to higher ROS when you forgot to disable the wireless-test package)

Sorry to revive this 'beaten to death' subject...
So I get it, only enable rts/cts on clients.
But what value for HW protection threshold is optimum? 2346(default on UBNT devices)? But with MTU at 1500, would any packet ever reach that size? (Permission to flame me for ignorance is granted) The 'default' when enabling it is 0, does that mean it is always enabled, or never? Assuming all AP & clients are on ROS 4.5
While I've got you here now, can someone explain where frame-lifetime would be of any use or need tweaking?

Ekkas

Sorry to revive this 'beaten to death' subject...
So I get it, only enable rts/cts on clients.
But what value for HW protection threshold is optimum? 2346(default on UBNT devices)? But with MTU at 1500, would any packet ever reach that size? (Permission to flame me for ignorance is granted) The 'default' when enabling it is 0, does that mean it is always enabled, or never? Assuming all AP & clients are on ROS 4.5
While I've got you here now, can someone explain where frame-lifetime would be of any use or need tweaking?

Ekkas

The HW protection threshold defines a packet size which is allowed to sent without asking for the permission to sent. It means packets shorter than the limit are sent immediately by the client station. Larger ones has to use RTS and wait for CTS. So if you use 2346byte limit it is the same as dissabling the RTS/CTS on the client. In our network we use 512 bytes as the limit.

The 0 in threshold shoul mean any packet has to use RTS/CTS before it is being sent. At least there is nothing about special other meaning of zero threshold in:
http://wiki.mikrotik.com/wiki/Wireless

IMHO it is not wise to want to use RTS/CTS for very small packets...

So...leave the AP RTS/CTS alone. This is how our AP is set at present. If I click on the Hardware Frag Threshold drop down it shows 256 (default) but I have not applied that, just left it like you see here.
Is this correct? Everything else looks fine?
Thanks

So...leave the AP RTS/CTS alone. This is how our AP is set at present. If I click on the Hardware Frag Threshold drop down it shows 256 (default) but I have not applied that, just left it like you see here.
Is this correct? Everything else looks fine?
Thanks

The HW. Fragmentation Threshold has nothing to do with RTS/CTS. It should affect the maximum wireless frame size (http://wiki.mikrotik.com/wiki/Manual:Interface/Wireless). If you enable it (it means define a value between 256-3000) the MT will divide large frames into sequence of smaller ones (max size defined by hw. frag threshold). If you have this option disabled IMHO the size of the frames is in most cases defined by wireless interface MTU (1500 bytes by default) - the IP system will not generate larger packets or will fragment larger ones.

I just have to put in my two cents here.........

I am a WISP with long range clients. I have several Mikrotik APs with around 100 (+/- 80 clients) where all of the clients are hidden from each other. AKA - no client can hear another client talking to the AP.

What I have found works best for APs in my network is the following:

All client APs are set to use RTS/CTS with a hardware-protection-threshold set at 32
- note 100% of nearly 1,000 clients system wide all use RTS/CTS and the RTS threshold is set at 32. Any client wanting to send anything bigger than 32 must use RTS first and wait for a CTS from the AP.

My APs do have hardware-protection-mode set to NONE.
note - do not even try using "cts to self" or "rts cts" on an AP like my load/distance because it will kill the throughput for everybody.

edit - add another note--- APs set to not use RTS/CTS will still respond to clients asking for a RTS by sending the requesting client a CTS. When a CTS is sent to a client, all clients on the AP stop transmitting which gives the client a clear and clean channel to send data to the AP (the client does not get stepped on). Without this RTS/CTS setup in place - there can be a ton of clients all transmitting at the same time and then nothing makes it to the AP from clients or from clients to the AP.

RTS/CTS does slow down the network - but - if you have a serious hidden node problem (where clients on your AP can not hear other clients on your AP) and you have more than 20ish clients, then give this a try.

I have played around with RTS/CTS settings for more than 5 years on large WISP networks and this is the only thing I have found that really works.
FYI - I have about 100 APs which range from customer connection counts from 30 to 150+ clients each

Tom Jones - a WISP up here in North Idaho

I just have to put in my two cents here.........

I am a WISP with long range clients. I have several Mikrotik APs with around 100 (+/- 80 clients) where all of the clients are hidden from each other. AKA - no client can hear another client talking to the AP.

What I have found works best for APs in my network is the following:

All client APs are set to use RTS/CTS with a hardware-protection-threshold set at 32
- note 100% of nearly 1,000 clients system wide all use RTS/CTS and the RTS threshold is set at 32. Any client wanting to send anything bigger than 32 must use RTS first and wait for a CTS from the AP.

My APs do have hardware-protection-mode set to NONE.
note - do not even try using "cts to self" or "rts cts" on an AP like my load/distance because it will kill the throughput for everybody.

edit - add another note--- APs set to not use RTS/CTS will still respond to clients asking for a RTS by sending the requesting client a CTS. When a CTS is sent to a client, all clients on the AP stop transmitting which gives the client a clear and clean channel to send data to the AP (the client does not get stepped on). Without this RTS/CTS setup in place - there can be a ton of clients all transmitting at the same time and then nothing makes it to the AP from clients or from clients to the AP.

RTS/CTS does slow down the network - but - if you have a serious hidden node problem (where clients on your AP can not hear other clients on your AP) and you have more than 20ish clients, then give this a try.

I have played around with RTS/CTS settings for more than 5 years on large WISP networks and this is the only thing I have found that really works.
FYI - I have about 100 APs which range from customer connection counts from 30 to 150+ clients each

Tom Jones - a WISP up here in North Idaho

I didnt make good experience using RTS/CTS. Used it on ROS4.5 and things are
getting worse. One client managed to reduce the performance of the whole
network to a minimum. Disabling RTS/CTS on this client made things better.
May be an implementation problem or an older atheros card who did not behave
well.

re:I didnt make good experience using RTS/CTS. Used it on ROS4.5 and things are
getting worse. One client managed to reduce the performance of the whole
network to a minimum. Disabling RTS/CTS on this client made things better.
May be an implementation problem or an older atheros card who did not behave
well.

Questions:
#1 Was the AP congested
#2 Were there 20+ish clients
#3 Was RTS/CTS turned off in the AP
#4 Were all clients set to use RTS/CTS with a small frame size to trigger a RTS request from each client
#5 Was the RTS/CTS threshold set to a low number on all clients (I use 32)

If #1 is no and#2 is less than 20 - then using RTS/CTS could actually slow down the network because the additional client timing delays to send RTS to the AP and receive back a CTS from the AP could actually take longer than just letting RED take care of the congestion. However - if you have more than 20ish clients then client RTS/CTS may actually be faster than RED

If #3 is if no/off - An AP should never be set for RTS/CTS. It just takes up a bunch of air time for the AP to send a RTS and wait for a CTS back from a client - never use RTS/CTS on an AP.
If the AP is set for CTS-to-Self - this will also slow down the network. With this setting in an AP, the AP is forced to send out a CTS at the highest rate that all clients can listen to. If you have a B connection to your AP, then the AP is forced to send a CTS at 1 or 2 or 5.5 or 11 meg rates. So if you have an AP with a client at a 54 meg connection and a B client with a 1 meg connection, your AP is forced to send a CTS at 1 meg rate for every client it talks to. This slows down the throughput for the entire network.

#4 - If using RTS/CTS in your client radios - all clients must use RTS/CTS. If you have a mix of some clients using RTS/CTS and some clients not using RTS/CTS then you are giving a poteintial unfair advantage for clients not using RTS/CTS to talk to the AP.
Example - An AP has 100 clients. 99 of the clients are set to use RTS/CTS and one client does not have RTS/CTS enabled. If this one non RTS/CTS client is trying to upload a large amount of data, then it will be stepping on the 99 other clients which must ask RTS and wait for CTS from the AP. When a client steps on another client then both clients loose there data they are sending/receiving and it takes some retries and more air time to correct the problem. If this happens in a congested network then you only add more congestion to the allready congested network.

#5 - small client RTS/CTS threshold settings are important. If a clinet has a large RTS/CTS threshold then the clients may have the ability to start talking to the AP without first sending a RTS and waiting for a CTS from the AP. So, in a congested network which uses RTS/CTS, a single client with a large RTS/CTS threshold can again cause collisions and add more congestion to an already congested network.

NOTE - in my opinion - RTS/CTS should only be used on larger networks with congestion and hidden nodes. Also if you use RTS/CTS it needs to be every client and not just some clients.

Well done TomjNorthIdaho your post is very informative

re:I didnt make good experience using RTS/CTS. Used it on ROS4.5 and things are
getting worse. One client managed to reduce the performance of the whole
network to a minimum. Disabling RTS/CTS on this client made things better.
May be an implementation problem or an older atheros card who did not behave
well.

Questions:
#1 Was the AP congested
#2 Were there 20+ish clients
#3 Was RTS/CTS turned off in the AP
#4 Were all clients set to use RTS/CTS with a small frame size to trigger a RTS request from each client
#5 Was the RTS/CTS threshold set to a low number on all clients (I use 32)

If #1 is no and#2 is less than 20 - then using RTS/CTS could actually slow down the network because the additional client timing delays to send RTS to the AP and receive back a CTS from the AP could actually take longer than just letting RED take care of the congestion. However - if you have more than 20ish clients then client RTS/CTS may actually be faster than RED

If #3 is if no/off - An AP should never be set for RTS/CTS. It just takes up a bunch of air time for the AP to send a RTS and wait for a CTS back from a client - never use RTS/CTS on an AP.
If the AP is set for CTS-to-Self - this will also slow down the network. With this setting in an AP, the AP is forced to send out a CTS at the highest rate that all clients can listen to. If you have a B connection to your AP, then the AP is forced to send a CTS at 1 or 2 or 5.5 or 11 meg rates. So if you have an AP with a client at a 54 meg connection and a B client with a 1 meg connection, your AP is forced to send a CTS at 1 meg rate for every client it talks to. This slows down the throughput for the entire network.

#4 - If using RTS/CTS in your client radios - all clients must use RTS/CTS. If you have a mix of some clients using RTS/CTS and some clients not using RTS/CTS then you are giving a poteintial unfair advantage for clients not using RTS/CTS to talk to the AP.
Example - An AP has 100 clients. 99 of the clients are set to use RTS/CTS and one client does not have RTS/CTS enabled. If this one non RTS/CTS client is trying to upload a large amount of data, then it will be stepping on the 99 other clients which must ask RTS and wait for CTS from the AP. When a client steps on another client then both clients loose there data they are sending/receiving and it takes some retries and more air time to correct the problem. If this happens in a congested network then you only add more congestion to the allready congested network.

#5 - small client RTS/CTS threshold settings are important. If a clinet has a large RTS/CTS threshold then the clients may have the ability to start talking to the AP without first sending a RTS and waiting for a CTS from the AP. So, in a congested network which uses RTS/CTS, a single client with a large RTS/CTS threshold can again cause collisions and add more congestion to an already congested network.

NOTE - in my opinion - RTS/CTS should only be used on larger networks with congestion and hidden nodes. Also if you use RTS/CTS it needs to be every client and not just some clients.

The ap was congested. All Clients had Big latency.
Disabling the offending client solved problem. Disabling rts/cts on this
Cpe solved problem. All cpes had rts/cts enabled. Ap had rts/cts disabled.

Your complete right with your setup. But I saw it failing. My theory is that there
was a problem with ros 4.5 or the older atheros card. I could not verify this as
i cant see what they are exactly doing on air.

im caught in the hidden node problem,having 20+clients in coverage of 1.5 km
using tplink 501g as cpe, got collision by some clients.
sing 433 ah 5.6 router os in bts
By last post in the forum,
i came to know.
1.To enable rts/cts nothing to change ap end settings.
2.Enable rts setting on all Client CPE's
but, i want know how do select the value of rts/cts mentioned in cpe.
may i use same value on all cpe's means which value is preferrable..?
if different values between cpe's means how do i select it ..?
help me solve the hidden node issue

im caught in the hidden node problem,having 20+clients in coverage of 1.5 km
using tplink 501g as cpe, got collision by some clients.
sing 433 ah 5.6 router os in bts
By last post in the forum,
i came to know.
1.To enable rts/cts nothing to change ap end settings.
2.Enable rts setting on all Client CPE's
but, i want know how do select the value of rts/cts mentioned in cpe.
may i use same value on all cpe's means which value is preferrable..?
if different values between cpe's means how do i select it ..?
help me solve the hidden node issue

You considered using nstreme or nv2?

im caught in the hidden node problem,having 20+clients in coverage of 1.5 km
using tplink 501g as cpe, got collision by some clients.
sing 433 ah 5.6 router os in bts
By last post in the forum,
i came to know.
1.To enable rts/cts nothing to change ap end settings.
2.Enable rts setting on all Client CPE's
but, i want know how do select the value of rts/cts mentioned in cpe.
may i use same value on all cpe's means which value is preferrable..?
if different values between cpe's means how do i select it ..?
help me solve the hidden node issue

You considered using nstreme or nv2?

no nstream or nv2
i used basic 802.11 b/g/n protocol

Hi ...

I guess 32 is used 'cause it is the smalest TCP-IP packet we have so this force CPEs to wait for AP CTS.

I'm a bit confused anyway, because I thought RTS/CTS belongs to 802.11B or 802.11B/G.

So ... what about 802.11A or if 802.11G only is selected - and - if we do not use "default" data rates but configured ones?

Setting RTS/CTS on CPEs which are A modes (or locked to G mode) have the expected effect?

Regards;

Sorry to necro this thread, but I have looked everywhere else for an answer, have come up with zip, and given that this thread has the most relevant discussion of this subject vs. any other past thread, it seems appropriate to put it here.

The collective wisdom out there seems to agree that RTS threshold is only set on the client, and that APs by spec and by design just respond to every one of those with CTS. You don't "enable" RTS/CTS on an AP because all APs have CTS support enabled...it's required. Thus, the hw-protection-mode and hw-protection-threshold options are not applicable to mode "ap bridge", just to "station".

Okay, if that's truly the case, then why did CAPsMAN introduce those options in v2? CAPsMAN is only applicable to APs...you can't configure a CAP to be a "station". So why are those options there if they have no applicability to APs?

Can someone please clarify this for me?

Thanks,

-- Nathan

Nathan, I guess that as these settings exist on standalone ap (even if we actually don't use/need them) they had been ported to (ap mode) capsman (?)