I have copule of links with nstreme (wds). After upgrade from 3.30 to 4.1 they doesnt work properly. They disconect,connect,disconect… After downgrade to 3.30 everything work propely. Please help me.
Send supout.rif to support before and after let them look at the data..
Scott
check the hw-retries count, maybe it is too low. As in v4.x and v3.x wireless-test package uses the hw-retries count also when you have enabled the nstreme.
I am also experiencing problem with NStream in 4.1.
I have change the hw-retries, with no effect. The link works fine until you put lots of traffic through it. The CCQ starts dropping as the traffic gets more and eventually the connection gets lost.
This happens with a RB433 and RB411 each with an R52N card and running 4.1. The link works without any problems when you turn off Nstreme. This link worked fine in 4.1rc, and only gave issues after upgrading to 4.1
Any advise?
I too have had some recent issues with some links but I cannot say where the problem orginates from - whether its interference or ROS 4.1 upgrade. I have not downgraded and really don’t want to. Just wanted to mention that I have seen changed on many of my links in the past week in different areas that would perhaps support the idea of a problem in 4.1…
We use Nstream / polling / cmsa disable and no framer on all our links
Scott
The same erratic behavior here. 
Luckily, I have a visual demonstration of the problem.
I am tracking every parameter of the wireless links (client side) with MRTG (dBm, rx-rate, tx-rate, traffic, unicast packets)
There is this 5.4Ghz omni antenna acting as an AP-bridge (RB600A, Nstreme enabled, upgraded to ROS 4.1 a few days ago). The clients are 433AH RBs or 333 RBs and they are still on ROS 3.30. From the moment I upgraded the AP to 4.1 the rx-rate analysis graph shows significant changes.
The clients are still on ROS 3.30 and there are no changes on the tx-rate graphs…
This is what I noticed:
The rx-rate was 54Mbps, ALL the time, with the AP running ROS 3.30 but with 4.1 it fluctuates a lot and a great deal… Take a look:
… on the other hand, the dBm analysis shows no significant change in the same time period…:
The same scenario happens when I use the wireless-test package in the 3.2x or 3.3x RouterOSes (again, I am talking about changing the wireless package at the AP side, NOT the client side)
Regards.
Same problem here, I even tested a downgrade.
Scenario:
RB600 <> RB411 17,5km wireless link, using nstreme best fit, disable csma.
with ROS 3.30 is throughput stable at 20mbit/s
with ROS 4.2 is unstable between 13-18mbit/s
same frequencies same everything.
Did anyone find solution?
We also found NStreme under 4.2 very unstable and simply downgraded to 3.3 and it fixed it.
Well they just came out with upgrade today and it doesn’t mention anything about nstream. As far as I know a problem has not been acknowledged even though many users have reported the same findings… Hopefully some day the results will be better.
Scott
Ive been having some issues too.
Links that would run for 150++ days with nstreme on with v3.x now only will run for 6-7 days on 4.x before disassociation
or get error like not polled for too long.
Ive re-enabled CSMA to see if that helps, and changed my framer policy to best fit from exact size.
These are PtP links and I cant disable polling or I only get a fraction of speed across the link, no need for polling on a ptp link but nstreme doesnt seem to work with it disabled.
EDIT: I had to disable nstreme on all my ptp links because of unstability. running any sort of both-way bw test caused link to go very slow throughput or crap out altogether, wthout nstreme at least the link is strong minus some bandwidth.
Can someone make me happy and confirm 4.3 fixed this issue ?
For me the incompatibility is making the 4.x fw unusable until it will get fixed.
Hope MK will fix it soon.
Wish all the best
Jan
We have encountered the same problem
we have some link in nstreme and we use ubiquity and mikrotik minipci card
and rb600 and rb433ah
with 3.x version all is working correctly
with 4.x nstrem is not working correctly (ccq downgrade when we do some traffic)
the problem i very very very big for us because whe have to downgrade many of hour basestation to 3.x OS
but in some routerboard we have link in 802.11n and link in 802.a+ nstreme technology
and, if we want continue to use N technology, we need to not use nstreme (that give us when working, a very good rate)
Mikrotik, please help us .. the problem is real, tested and it is big for us
Same problem, links would fall on the CCQ to near 0% or completely disconnect and reconnect.
Its fine with 3.30.
Its about time for a MT rep to chime in again on this as we have heard nothing for some time.
You guys send some emails with info to support to might help get some quicker attention as well.
Scott
I submitted a ticket a few days ago on this thread and have had no answer of any sort. I specifically asked them to chime in.
I thought it just me with this issue - now I feel better.
v4.x is completely unusable for me - then someone said enstreme was outdated in v4.x - what??
I went back to v3.28 before I got stable connections back!!!
I really would like to have the features of v4.3 - vaporware???
A lot of people have problems with nstream and 4.x not just the small number of people on this thread. The list is much larger… Mikrotik’s consultants know about it too and they work with lots of people consulting with MT.
Scott
I have the same problem
I had two RB 133C3 and one RB 333 with nstream on.
Upgraded to v4 and the link was jumping up and down, unable to use the link.
Trying to create a supout.rif on 133C and after that it was dead so i installed a new 433
and now i can use the link between 433 and 333 wich v4 installed but the 133C link i down.
Downgraded my 333 (this link talks to the other two) to 3.30 and both links are up again. With
4.3 on 433 and 3.30 on 133C
Also tested without nstream and all versions are working, so the problem is 133C and nstream and v4
This SUX
Sten
SM7LQP
I can safely say that you are probably the only person on this thread using a 133c with 4.x and nstream on a ptp link. Problem still exists for the rest of us.
Scott
Ya, I am still stuck on 3.30 on my backhauls and my ticket went ignored.
I get a hard time from MT for trying to get a solution on here, I open a ticket like they ask, and then they ignore it.
That is the problem with open source community supported software. Oh wait, this is closed commercial software that I paid thousands of dollars for . . . .