Always lost the wireless connection on high traffic lines !!! Very, very unstable the 3.xx series !!!!! Unusable system !!!!

We have never had V3 wireless work correctly. We installed RB333 w/RC6-10 and it always had packet loss. Replaced with RB532, same radios, pigtail and antenna and everything works fine. We've given up in V3.

We have RC10 running, 35meg both ways, nstream-dual, dual links, total of 42 miles. No issues that we can find so far..

Have run now beta on all my routerbords and ap a while.
All working great, ofc som problem here and there but find always a soulosion.
and remember its e beta. be for i did jus avaya wirless systems.
And the mikrotik systemts it 10 times more stable, and more control.
You can do what you want.

Aboute te timeoutes try and change you config.
I did use 1 moth to finde out the best conf to 333
and even more on my ap. evrey day i just change a littel thing.
and run som tests.

I don't know what is a problem but very aggravate this. Maybe some hardware problem ? But before upgrade never lost the connect. If the bridge side disable/enable interface after go again. On high traffic line (5gzh-turbo, nstreme) .
Now write some scrypt...I remeber long time ago when developed early 2.9 version have this problem. After sole it.
I to nose for hardware maybe some component on same routers.
The config asrosk/asus board celeron 3ghz. I don't like asrock/asus p5pevm....

FYI

It is a release candidate and NOT a beta.

We have RC10 running, 35meg both ways, nstream-dual, dual links, total of 42 miles. No issues that we can find so far..

Have you had random reboots? We have RB333 RC10 running with Nstreme-dual, 40MHz channels on each end, separation of 500MHz, separate antennas, all the good stuff.

The far end has both an Nstreme Dual link and a single N-streme point to point feeding off of it. It seems to reboot at least once every two days.

We're not the only one with this issue. Before I set up a watchdog requiring reboot if pings across the Nstreme dual link fail, the box would hang!!! (Suspected kernel panic)

i have very bad performance issue on Nstream dual on 333.
I changed everything from antenna to pigtails, including the radio cards, but nothing changes the bad performance.

My link is 10km and the signaal are about -59/-60, when i start to have traffic, the rates go crazy from 9mbps up tp 36mbps, with no traffic thery are at 54mbps.

Ros

We noticed a problem in wireless communication on our main 5GHz AP few days ago, but we were not sure if it was because of the upgrade from 2.9 to 3.0RC11 or weather conditions (fog and some snow).

Hardware: PC Compaq 800MHz, Ubiquiti SR5 - HyperLink 12dB omni antenna, two more 5GHz cards connected to grid antennas.

We connect to this SR5 several base stations without heavy traffic and two more with point-to-point links using other two cards. Totally 7 x 3.0RC11 stations, 3 x 2.9.x stations and one Ovislink 5GHz client bridge are usually connected to this SR5.

Pings were huge with 3.0RC11, up to 1s and with some losses also, maybe up to 10%.

I finally decided to try 2.9.50 and it worked. With approximately the same traffic, pings were normal, up to maybe 14ms and mainly 1-2ms. Other two cards with point-to-point nstreme links worked correctly, just this ap-bridge was the problem. So, there is still something with 3.0RC11 wireless.

Well done. The problem exactly. No hardware. When use RC9 on two router - nothing problem. Morning upgrade to RC11 - some hours and now disconnect. Disab/enable bridge side and work again. This palce where come this problem continiusly high traffic - over 10 mb up/down, nstrem, 5g turbo. And other, if switch off the adaptive new feature, better the ping and stable the connect. Not perfect, but better.
This is a software bug.
And the 2.4 AP too not correct. More disconnect and slowly - or must restart client -connect after upgrade.

most of you got problems after upgrading from v2.9 to v3.0 because you are using Ubiquity High power cards and most probably you had changed the tx-power. In version 3.0 we are showing correct tx-power info for most of the Ubiquity cards. Here for example is the output from the XR2 card:

v2.9: v3.0: The number in the brackets represents the value from the eeprom. In v2.9 you were changing this eeprom value, but in v3.0 you are changing the real value that it outside the brackets. We always suggest to use the default tx-power-mode, as then you would not run into such issues.

All my cards are at default tx-power value except one CM9 which is at card-rates 30 and is used for link. It seems to be true that this happends at high-power cards, I had problems mainly at three points, one XR5, one XR2, but one CM9 also. I downgraded all routers to 2.9.50.

I don't recommend you to use CM9 card at 30 - it will not work very long, it could burn down and also the performance could be bad.

It is working like this over one year

It looked broken, so I put more tx-power and it worked. If it burns out, I will just throw it away, I already don't count on it.

Always lost the wireless connection on high traffic lines !!! Very, very unstable the 3.xx series !!!!! Unusable system !!!!

Completely useless entry!

There are around 50 adjustable option for wireless in RouterOS, i will repeat myself - FIFTY. That is a lot of thing that you can play with. There are no other product in the market that gives so much options to the customer. Ether customer will be able to use them or not it is other question.

Version 2.9 and 3.0 have different sets of those options, so you can't just upgrade and compare - it is necessary to adjust the setup.

Comon guys, we should be network specialists here - instead of this nonsense it is much more better to write topic this way:

I suggest, open another topic and there use academic/theoretic method. We haven't time follow this.
Maybe, somebody write the cool thing about. That is the forum essential. This is the real word area.
Before write something here, change more mail by support and spend many hours by new versions.

Regards

I suggest, open another topic and there use academic/theoretic method. We haven't time follow this.
Maybe, somebody write the cool thing about. That is the forum essential. This is the real word area.
Before write something here, change more mail by support and spend many hours by new versions.

Regards

what's essential? that you say "bad wireless, not work" and we understand what you mean? sorry, doesn't work for me

Ok, "blt", lets play it your way in that case my answer to you original post:

Always lost the wireless connection on high traffic lines !!! Very, very unstable the 3.xx series !!!!! Unusable system !!!!

would be:

No,no,no very good wireless - much better than 2.9. Got much more stable connections and better signal level. Very, very good new options!

Useless! Isn't it? Sorry, but topic like this can be easily created by 10-year old.

Next time add some REAL information in your topic so we can compare it to our setups and suggest you something.

I expected if I upgrade 2.9 machine to 3.0 that everything will still work. I had major problem with our central machine with just one Ubiquiti SR5 card with all default settings, no hotspot, connection tracking turned off, no firewall rules, very simple settings. If I upgrade this machine to 3.0, I don't expect problems, but I was wrong. I tried to change many parameters, but it didn't help. Other frequences didn't help either. Then I moved to 2.9.50, put all back to default and it worked fine and it is still working fine. I can't give you more prove, but I will stick with 2.9.50 for some time.

I have another machine with 3.0RC11 which does some nstreme link with disabled CSMA and this one is working good, I can't complain.

I have the random reboots with RB333 too. The only positive thing is the fast boot after the watchdog reset the board.

Normis

Count my writed support emails about this....
But now I learn live together :

interface wireless set wlan1 disabled yes
ping 0.0.0.0 count 3
interface wireless set wlan1 disabled no

And now stable work the upgraded routers.

Yes, there are many emails from you. But they are just as informative as this topic. We really need information to fix issues. "Bad wireless" is not a description. We would need a supout.rif file, a network diagram, and a complete description of the problem that you saw, and how we can repeat it. That would really help, thank you

Hi Guys,

I didnt want to start a new thread because my problem also has to do with wireless and V3 RC10 and RC11 (these are the 2 versions Im trying out on different boards).

I have noticed that the wireless interfaces are all linked together in V3 for some reason. When I disable or enable a wireless interface, the other wireless interfaces on the board disconnect clients and reconnect them. They are not part of a bridge, so I wonder why this happens. I have tested this on RC10 running on a RB233 and on RC11 running on RB333. Never had this when I was running version 2.9.x on the RB233. I just cannot decide to change a setting on one wireless interface and click apply without the other wireless interfaces disconnecting bonded clients and reconnecting them.

Is anyone else seeing this?

With RB333 ptp link (RC9 and RC11), we've seen good wireless connectivity until we we load the link with actual traffic from lots of users. When the link is loaded, the wireless connection then bounces often and immediately reconnects.

We had this same problem with RC9 on RB532. After rolling back to 2.9.49, the link stabalized and does not drop at all. On both the RB333 and RB532 running V3, we also tried toggling all of the wireless settings we could think of including, WMM, NStream, Adaptive Noise Immunity, Compression, Preamble, Hardware Retries, Disable CSMA, Framer Policy, Polling, locking data rates, and a few more. After trying every setting, we rolled it back to 2.9.49 on the RB532, the link was and is rock solid.

Currently, the RB333 with RC11 is up and stable, but when we load it with real internet traffic, the link begins to bounce again. We've also noticed that with low traffic, there are sometimes very brief intermittent losses in data transmission even though the link may not always bounce.

I hope this helps - it's very easy to reproduce, but we don't like doing it because we need to send lots of real customer traffic across this link to produce it. Let me know what else we can do to help you track this down.

medube - what about access list and connect list? do you have rules with interface=all?

cramerit - enable Nstreme, framer-limit=4000, framer-policy=best fit - it should solve the problem.

medube - what about access list and connect list? do you have rules with interface=all?

cramerit - enable Nstreme, framer-limit=4000, framer-policy=best fit - it should solve the problem.

I am not using access list and connect list, just have default authenticate on each wireless interface acting as AP so that all clients just connect to them. On the RB233, I just upgraded the OS without changing any settings and so I believe all the settings in 2.9.x should be upgraded unless something changed during the upgrade.

Just to let you know, we tried the NSTREME suggestion with framer-policy=best fit and framer-limit=4000. This did not change the problem. We also tried RC13 and we're still seeing the same results. Extremely easy for us to reproduce: simply put up a PtP with RB333 and RC9 through 13. Choose any wireless settings you like. Then load the link with about 5 to 6 Mbps of real internet traffic from multiple users. Once you do this, the link starts bouncing on and off. If we reduce the traffic load, the link will stay connected for days on end.

What other information do you need? We could send a supout.rif if that would help, but I think it's pretty self explanatory.

please send to support@mikrotik.com your support output file when you have this problem.

we have a similar problem on an AP running v3 rc13 in a ptmp conditions all running nstream, clients are on v2.9.

If the global traffic stay below 2mbps the clients are connected for days but with traffic above this limit the clients are disconnected one time each day at the same time.

I sent supout this morning.
Regrads
Ros