I noticed when one client's radio is enabled, he brings down all other 7 clients causing timeouts. I've set AP TX and Client TX limits, but it doesn't seem make much difference.

Looking at the 15 second snapshot of clients traffic, there are 215 destinations with loads of small packets.

What else can I do to limit this client from timing out rest of the clients?
I was using RB333/XR2 with v3.2 but tried 4.2 without any improvement.

Looking at the packets, they seem to be P2P connections. So I tried to limit using firewall rules below but making no dent:

With firewall rules, it doesn't seem to help at all. I've also tried Simple Queues on WiKi, but all those packets are still there in IP Traffic Accounting, and still timeout the other clients. Anyone has any suggestion?

You can do two things:

Limit his number of connections entirely - but how much data is he pushing?

The better solution is to upgrade all your CPE to 3.30 + wireless beta package and enable RTS/CTS (See this post)

I think that this will most likely solve your issue.

http://forum.mikrotik.com/viewtopic.php?f=7&t=37092

Let us know how you get on

I already commented on the above referenced post but let me do so here again.

If you are running Nstream with polling you don't need/want RTS. If you are not running Nstream than you need to use RTS. Set it ONLY on the CPE side. NOT on the AP side. You do not need to run 3.30 on the AP for it to support RTS.

You can follow the comments on the post i mentioned by watching that post.

Otherwise we have also used this to control torrenters connections.

chain=forward action=drop protocol=tcp connection-limit=150,32

This does cause issues for the customer if they are torrenting and trying to surf at the same time though.

I noticed when one client's radio is enabled, he brings down all other 7 clients causing timeouts. I've set AP TX and Client TX limits, but it doesn't seem make much difference.

Looking at the 15 second snapshot of clients traffic, there are 215 destinations with loads of small packets.

Are you sure it's legit traffic and not a virus/trojan/zombie?

What are these AP and Client TX limits you speak of?
I hope you didn't manually reduce the air rates, that will only make things worse.

You MUST do all traffic shaping on the CPE, not AP, side in this case.

The clients are UBNT 3.4, and they have "RTS Threshold" and "Fragmentation Threshold" set default. I've set RB333 "Hw. Protection Mode: rts cts" and set NS2's "RTS Threshold=512" and "Fragmentation Threshold=1173", and now I cannot access the client to make changes will have to visit him and do it onsite. What would you recommend for starting off RTS values?

Also trying connection-limit=150,32 as suggested, but don't see any dropped packets. And still timing out...

He's not xfering much data, seems more of lots of packets. Plus I have his bandwidth capped to 1M/256K from both AP side and client side.

Thanks.

You can do two things:

Limit his number of connections entirely - but how much data is he pushing?

The better solution is to upgrade all your CPE to 3.30 + wireless beta package and enable RTS/CTS (See this post)

I think that this will most likely solve your issue.

http://forum.mikrotik.com/viewtopic.php?f=7&t=37092

Let us know how you get on

If I am not mistaken the RTS/CTS is off by default.
Uncheck the off box.

This will enable the client to request to send data.
The problem you are encountering is due to the fact that this client continues to broadcast, ultimately deafening the AP to the other clients.

Are you sure it's legit traffic and not a virus/trojan/zombie?

Yes, I've even visited the client side and had them scan all the PC's. They seem to be clean. Looking at the packets, it's mostly port 80, all-p2p, and communication services such as VoIP, Messengers, etc.

What are these AP and Client TX limits you speak of?
I hope you didn't manually reduce the air rates, that will only make things worse.

mac-address=aa:bb:cc:dd:ee:ff interface=wlan1 signal-range=-120.120 authentication=yes forwarding=yes ap-tx-limit=1000000 client-tx-limit=256000 private-algo=none
private-key="" private-pre-shared-key="" management-protection-key=""

Air rates are all left to alone to defaults.

You MUST do all traffic shaping on the CPE, not AP, side in this case.

Also have at client side, on NS2 limited bandwidth to 1M/256K.

If I am not mistaken the RTS/CTS is off by default.
Uncheck the off box.

This will enable the client to request to send data.
The problem you are encountering is due to the fact that this client continues to broadcast, ultimately deafening the AP to the other clients.

With it being off, the default value for RTS 2346. What would you recommend for it's value? I tried 512 and although it's connected to the AP, it locked me out. I'm gonna have to make a visit onsite to reset it. This was prior to enabling on AP side "Hw Protection Mode=rts cts", enabling on AP side didn't allow me to access the client's radio.

You shouldn't activate it on the AP side, only the client side.

We use 256k for RTS and 768 for frag on our Ubiquiti radios and EWMA for the alogrithim

hii

yes

You shouldn't activate it on the AP side, only the client side.

We use 256k for RTS and 768 for frag on our Ubiquiti radios and EWMA for the alogrithim

256K not 256? 256K is much higher than default 2346. Could you explain why such a high value please?

256K not 256?

I'm guessing just a typo.... Easy to do after typing 256k a thousand times a day

typo it is, my bad.

Doesn't the smaller packet size for RTS causes the client to get AP's attention more often? So do you put higher RTS Threshold and Fragmentation Threshold values for the clients with high P2P uses and lower values for rest of the clients?

Thats the point, you want the client to get the AP's attention. In a congested number you lower the number.

As much as i have experienced using Mikrotik it is only because of Virus/Trojan which sometimes go undetected. Secondly a client can bring down your entire sector if it has Torrents uploading data. If u are talking about multiple computers on the client side and quite a few use Torrents and simultaneously browsing data. there is nothing u can do. switch over to a PtP link instead of giving connection thru ur Mikrotik. Nano is an excellent client hence no issues with that. See my earlier posts, I faced similar problems but none cld give me a solution. I tried to look for reasons myself and came up with this conclusion, because so far no one cld suggest a positive working solution.

Your suggestion is a bandaid fix which doesn't address the core issue.

i would really wish the core issue addressed. I hv been using the 433ah and all my clients r getting 40 dbi + signal and they all get disturbed due to one or two clients when they come on. If those clients r blocked the whole network is fine. i put those clients on a different AP (ptp link) and now all is well.

Read the thread, implement RTS.

it can also be bad signal and ccq on the client side

that also brings down all clients connected to the same ap

it can also be bad signal and ccq on the client side
that also brings down all clients connected to the same ap

I do have one NS2 client, that has bad signal. I insisted that our service is not for him, but he just won't cancel. His average signal is usually around -80/-84 ccq 14/77%. But today, it was around -77/-81 ccq 56/91%, when the problem occurred again.

Update: Removed his NS2 from Access List, but still occurs.

Thats the point, you want the client to get the AP's attention. In a congested number you lower the number.

I tried again, of 10 clients, I lowered the two clients RTS and Frag to 512 / 1024. One client although I can ping him but I cannot access his NS2 remotely (this users uses torrents). 2nd client call me with panic unable to brows Internet, although I can ping the NS2 and ping out from it. And took awhile but was able to access it to reset the values to default.

One thing I did noticed is that during timeouts, signals is steady -59, CCQ drops to 21/17 from 77/82 and higher, TX/RX Rate is 6Mbps/4/9Mbps/4.

Is there any logic on determination of what these values would be best except for trial and error?

256 and 768.

You have to implement it in ALL the client radios otherwise it will only make things worse.

256 and 768.
You have to implement it in ALL the client radios otherwise it will only make things worse.

I've changed all NS2 and PS2 to your recommendation, just now.
I will post the result.
Thanks.

Any solution to any of this? We are experiencing this exact same scenario. We are running a mix of 3.30 Wireless test 4.2 and 4.3 on a pure mikrotik network running nstreme with polling on, and csma disabled and see no difference between them in this area. We have narrowed this down to the bandwidth limit set on the cpe rather than the amount of connections. It seems odd but when a client running p2p or otherwise hits their cap of 1300k and stays there for an extended time all other clients begin to drop off. If the client ( I have personally paid him a visit!) limits his downloader to 1000k, which is under our 1300k limit) everything begins to function normally. We tested this theory by limiting his connection to 500k. He was still able to kill the ap at full throttle, but when he limited his download to 80% or so of his cap things began working again. We have also experimented with scripts to drop number of connections, but they didn't help. How do we work around this?

It's been 2 weeks since the change to 256k for RTS and 768 for frag. During the 2 weeks, only once the problem occurred, and it was solved by shutting down one of the 4 client's PC. Noticed that PC was running bittorrent. So the RTS change didn't stop the problem from occurring.

Couple of other things I've noticed is that since the change, remote access to the client radios are much slower. And on one of the client, setting the RTS/Frag will not allow browsing out, although you can ping. Perhaps it's a problem with the radio.

Make sure you are running the newest Ubiquiti firmware on your clients

Make sure you are running the newest Ubiquiti firmware on your clients

Why?

Make sure you are running the newest Ubiquiti firmware on your clients

Why?

Typical forum advice and forum reply...

"Latest" firmware is, as it is supposed to be, ´better´. Why else new firmware!

At the same time, sometimes new firmware brings sometimes new bugs....

So, both advice and reply question bear 100% truth!

My advice:
If new firmware is around, try to figure out what the new or improved features are. Sometimes new firmware brings you just that correction you need.
If the correction log of manufacturer is not showing you any corrections you need, my advice is to wait some weeks to see if other users have issues with the new firmware. Then try the upgrade on a not so important unit before implementing in your network.

Since itchibahn problem is less, but still around and this discussion worthwhile for loads of readers and still some questions left to answer my input here:

I see three possible main reasons and solutions on the issue started here.

Issue: One client bringing down other CPE units on AP network.

1. P2P users without proper QoS. P2P is nowadays smart enough to ´eat´ all available bandwidth and will bring down your network if no proper QoS is performed on your network to deal with it. It might be part of itchibahn’s problem but else in this forum loads of input to be found on this subject.
2. Link quality in terms of signals, CCQ and total capacity of network. This is something important too since poor radio links can bring network down the moment some pressure (high traffic demand) is applied to the wireless network. So the basic is first to assure client has a stable and sound connection. Try to get better then 70% CCQ’s for clients as minimum. Work with connection rates of radio’s (CPE) to bring up CCQ. Even if this means the max. throughput would go down. But also here, lots of info to be found on this forum elsewhere.
3. Data transport and settings that have implementations on the reliability of delivery of data package.

This last point is more the core of this topic so a bit more ´food for thought´ here:
My network consists out of MT AP’s with a mixture of MT, Ubiquity and other vendor’s (´laptops´!) clients.

In a mixed network like this n-stream won’t work so forget about this when you have other make stuff around. N-stream works only in full MT networks and then even preferable when constant high data streams are available. It works poor on ´idle´ links.
RTS/CTS is and has always been available in AP-mode running equipments. It is basic 802.11a/b/g requirement.

On MT ´station-mode´(=client) units though only after version 3.xx (don’t know the exact number anymore)and in 2.xx ´wireless-test package´. Ubiquity has it on all their stuff and most recent laptop or usb/pcmcia etc. stuff has it too. But all disabled under normal circumstances.
RTS/CTS has to be running on ALL clients assigned to an AP. It makes hardly any sence to have only same units using it. It can actually make things worse. I have experienced that myself.
Do we really want RTS/CTS? After all, it adds some extra overhead data to the data stream and thus payload to the AP-radio receiver. And the 802.11 standard already has CSMA implemented that should do the job? The answer according some whitepapers is a big “YES”. (Read “The Impact of RTS Threshold on IEEE 802.11 MAC Protocol” ) The disadvantage of the extra payload of RTS/CTS is very little compared to the performance increase of the network. More specific, if we have the ´hidden node´ issue or lots of interferences around it will definitely improve the network performance.

How to use RTS/CTS? To enable only is not enough. It is the package size (frame size) that triggers the RTS/CTS process. Most radio OS’s have high package size triggers as default. Meaning that only in the instance the frame supersizes the set frame size the RTS/CTS gets into work. Client radio’s that are transmitting smaller data frames (like udp. Udp is used by VOIP but also by P2P if it can’t use tcp) are not sending RTS/CTS requests to the AP when the frames are smaller than the threshold size. So if there are other client radio’s that do want to send bigger frames the ones with the small package won’t get, or get low priority in the queue for, their assigned communication cycle. It is a profound ´killer´ on VOIP connections.
So we set the protection threshold for RTS/CTS as low as possible, which is for most OS 256 (bytes).
Since now practically every frame is triggering the RTS/CTS normally spoken each client, running P2P traffic or not, gets its turn on the AP radio to send and receive his data in his assigned time window.

Jwcn
Question here. Why do you suggest fragmentation threshold of 768?
Although long frames might increase link throughput between two radio’s communicating, it occupies client A-AP radio time too long so other clients have to wait. This would suggest smaller frame size.

But small frame size do increase the payload since each data package that is broken in two will have now its own header data before it is put on the link and will thus increase the payload on that specific load. At the same time, both end cpu’s have to work now to break the package (tx sice) and add the header while then the other end have to erase the extra data and glue the packages together again. The more data package that are ´broken´-up the more data actually has to flow over the link and the harder the cpu’s have to work. On congested AP’s with too small of package threshold settings this slows down the network performance.
If we consider that most network use MTU of 1500 it will mean radio’s with your setting break up almost all data packages so you must see an increase on payload of the link and cpu time of both cpu’s. To me it looks you are ´killing the aid worker´.
We don’t want to set the fragmentation threshold to low because that will do more harm than good. I have been given the advice to use 1500 since that is the data package size in most instances (MTU).

But since you never know if things can be improved, my questions: Wwhat is your argument to set fragmentation threshold to 768?

Last item I would like to discuss is best settings in P2P and P2MP links for Hw. Retries, Frame Lifetime, Disconnect Timeouts and On Fail Retry Time.
I have been digging and reading in and have a pretty much established setting modulus for each type of link and depending station or bridge mode radio but would like to discuss this with others before I start preparing a nice tutorial on the WiKi. (The MT info on the WiKi is just not enough.) Shall we start a new topic on this?

R.

Mike over at UBNT suggested the frag level of 768 - beyond that I have no idea.

I can tell you by default, the Alvarion VL line which uses a modified Alvarion chipset uses 10 for the HW retrans settings.

My opinion;

MT states: (http://wiki.mikrotik.com/wiki/Wireless# ... S.2FCTS.29)
Quote:
* hw-fragmentation-threshold (integer 256..3000 | disabled;) : Specifies maximum fragment size in bytes when transmitted over wireless medium. 802.11 standard packet (MSDU in 802.11 terminology) fragmentation allows packets to be fragmented before transmitting over wireless medium to increase probability of successful transmission (only fragments that did not transmit correctly are retransmitted). Note that transmission of fragmented packet is less efficient than transmitting un-fragmented packet because of protocol overhead and increased resource usage at both - transmitting and receiving party.
Un-Quote


If your Alvarion now fragments all data in portions of 10bytes and put some header on it of some bytes (I don't know how much but will be in the same range) this would mean you basically double the data to be transported over the link.
At the same time the router recieving the data package first has to break the package up and add the headers before he send it to the next hop over the wireless link
The receiving end now had to debug all the frames back to its original package size.
You can imagine that takes quit some processor time to on both ends.

So although these small setting on a very poor link (other wise retrans not needed) might improve the data delivery over such poor link, the sheer bulk of extra data to be transported reduces that (already poor- ) links capacity in Alvarion's case by 50%

This is what UBNT writes in their manual:

Quote:
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 the guideline is "NOT to small", If not needed leave default 2346

2346 is 1500mtu dataframe + all possible header add ons for encryption, TOS etc.
If you are not using that, 1500 is therefore a good suggestion.


Personally I have not a high impression of the skills of Mike from ubnt. He actually wonders in a topic why someone would use RTS/CTS and fragmentation threshold at all...
That shows of little knowledge of real world networks. RTS/CTS almost always improves network performance.
He also advised me in the past re settings of my nano`s which didn't help me at all. You won't find me a lot there any more...


So, if your link suffers from lots of package losses it is better to enhance the link anyway physical possible instead of reducing the thresholds to very low numbers.

Its like an icy road full with loaded auto buses that have to transport a certain amount of passengers in a certain time to reach their destinations in time. Now and then a bus slips and get lost so not everybody will make it.

I don't think we will save a lot of passengers in the end by having them all using their own little Volkswagen with a trailer on their tow bar (extra headers) to do the same.... probably more passengers won´t make it in time in the end, even when the ice is gone. So what did we win here?

I have used 1000 for some months and upon advice of a experienced member of this forum changed that into 1500 but to be hones have not seen noticeable differences in data deliveries in general.
Maybe in certain specific links that suffer higher package losses then the average it might be a suggestion to test with some lower settings. But since you basically also have to set the lower frame size on the AP the good links are now suffering from higher date payloads. On heavy used networks this would decrease overall performance of the AP-clients network.

My suggestion would be to use 1500 for most links that have no extra WEP, WPA or TOS headers on the data packages. If you do then you have to increase the size a bit to cope with the extra.

R.

Well, with the 256/768 combo we are pushing 5megs/512k without any packet loss to clients on 5mhz channels.

It seems to work well for us, I haven't tried tweaking any further.