What's new in 4.13 (2010-Nov-01 14:48):

*) added USB power reset feature;
*) added support for nv2 in wireless-nv2 package;

Torrent:
http://www.mikrotik.com/download/router ... 13.torrent

Regular download:
http://www.mikrotik.com/download.html

( No seeds at the moment )

Hey, thank you for NV2, we have to test it now

I've tried it on 5.0rc3 and it works great. I hope it's the same with 4.13.

Hmm should be interesting to see in the lab, I wonder whats *actually* changed in this version

just completed piecing together files and have a full seed running now.

I thought it is not possible to backport NV2 to 4.x, like uldis told us on this page:

http://forum.mikrotik.com/viewtopic.php ... &start=100

But it's very good you made it, 5.0 is still not stable enough.

I downloaded torrent and I don't see wireless-nv2 packages among "all_packages". Is it included just in combined packages? I would be nice to have them separated, I like to update just packages I use.

Yep, Have to say I was completely blindsided by this one as it goes against so much of what MT has said here. NV2 couldnt be back-ported and they don't add huge new features into existing production versions.

That said it will be interesting how stable nv2 is, for MT to backport it must mean they consider the protocol and features to be stable enough to introduce into their production/stable version.

Does anyone else have the mipsbe combined file? torrents got no seeds

>added USB power reset feature

Will this address the issues we have been having with USB GSM Modems?

>added USB power reset feature

Will this address the issues we have been having with USB GSM Modems?

for future RouterBOARDs, usb power reset allows you to reboot a 3G modem without rebooting the router. This will also help the modems, that can't load normally upon reboot.

Has anyone else had a chance to check out nv2? Didnt get time today to fire it up in the lab. Looking around the Beta forum a few still have issues with it but havent confirmed if they are using RC3 or not. There are a few (once again) fix's not in the change log we need

Where is the nv2 package for 4.13?

Where is the nv2 package for 4.13?

in the RouterOS big package

Where is the nv2 package for 4.13?

It is included in combined packages, but not in "all_packages".

Has anyone else had a chance to check out nv2?

I've downgraded two 5.0rc3 machines with NV2 and 4.13 is working fine up to this moment.

http://www.mikrotik.com/download/share/ ... 13_ppc.npk
http://www.mikrotik.com/download/share/ ... mipsle.npk
http://www.mikrotik.com/download/share/ ... mipsbe.npk
http://www.mikrotik.com/download/share/ ... 2_4_13.npk

normounds, will you have idea of when this "pseudobridge" mode are supported whith NV2?

regards!!

for me Ros4.13 and NV2 looks like a disaster.
I've upgraded 4 units, two x86 and two rb433ah,
one rb433 after upgrade make so much interference that
rb411 (the same location and ros4,9) drops txrate from 270-300mbps to 52-65mbps,
even if I switch wireless protocol to 802.11 or unspecified, it makes
so great impact!
another tryout was ptp link on two intel atom boards working quite
fine since 6months. after upgrade link rate is lower 112 not 150mbps earlier,
and drastically drops real bandwidth, 20/10mbps btest max udp :/
at last one Atom had a R52n card onboard, which after upgrade, loses
clients when a/n mode selected, on pure A with every wireles protocol I've tried
could connect max 4 of 9 cpe. i had to change module to new one and, get back
to 4.3 which works for me very good.
Frankly speaking I'm dissapointed. tonight getting back to 4.3.
what's up?

Have you tried to change the frequency? I had similar problems with 5.0rc3, but after I changed channel on 2.4-only-g AP, everything worked perfectly. After I downgraded this machine to 4.13, everything is still fine.

Hmm should be interesting to see in the lab, I wonder whats *actually* changed in this version

I agree, 2 versions in almost one week...

4.13 and NV2 is a disaster for me as well

perhaps i am doing something wrong?

tested with 14 clients to an AP,running NV2 on all of them. i have set the distance to 10 km as the standard 30 is too much for my scenario. also have hwretries set to 10 and adaptive noise immunity set to "client and ap" some clients drop constantly and are getting horrible speeds

Uldis: Why did you write that NV2 is supported only in version 5.x?

hung API sessions are still NOT fixed in v4.13 =)

Uldis: Why did you write that NV2 is supported only in version 5.x?

because it was supported only in 5.x until v4.13 =)

Well according to Normis is wasn't possible due to a number of v5 features being needed.

Is anyone else noticing normal wireless problems with it? My boss loaded it onto his home CPE and found his link started dropping all the time and his signal was reported as 6db worse. A downgrade to 4.10 and all is well

Here it comes - 2nd wave of users that wanna press one magical button "Upgrade my link to new wireless protocol" and expect everything to be exactly same at it was with with old protocol (1st wave was users who was not afraid testing v5.0beta, but had exactly the same misconception)

Think about protocol changes as if it is hardware change for your wireless link - you need to reconfigure, realign afterwards.

I personally so not have any link that i didn't fine-tune, to make it work or to increase its performance after upgrade.

You're post would make sense if there was much to configure, NV2 gives us cell size and slot size. My concern is not that we didnt get a magic boost out of a simple upgrade my concern is the quality of builds coming out of MT lately.

4.13 installed on a CPE with the wireless package (not wireless-nv2) showed 8db decrease and instability in a link that was stable for atleast 9 months.

I agree there are alot of users around who have unrealistic views about NV2 and how it will magically make a bad link better but 4.13 is unstable and hard to test since all changes made to it aren't released in the changelog.

NV2 might be a change but upgrading a stable link to it gives you 2 extra options to play with, NV2's features are incomplete (WDS, Pseudobridge etc) and fairly untested, I cant fathom what was going thru MT's head when they decided to backport it to ROS 4 when they have publicly said a number of times it couldn't be done

I think Mikrotik are moving too fast and focusing on things that aren't needed, We went from 2.9.51 being the last to 3.30 being the last and now ROS 4 looks like is going to end around 4.15-4.20. We get multiple builds a month with incomplete change logs and MT support telling us to deploy unreleased or beta software to production sites. Get told a bug has been fixed in 4.x and its not in the change log which makes us wonder what else has been changed which leads us to having to test for weeks on end all the features to confirm they will upgrade fine, Then a week after this is done another versions out fixing some flaw in the version we just deployed.

MT should pull NV2 from ROS 4, work on getting the many bugs out of ROS 4 and keep ROS 5 in the cooker for a while, Its nowhere near RC status, ROS should be delayed untill NV2 has a full feature set and is tested more, Work on the v6 side of things and the routing issues, Release ROS 5 as a flagship and don't EOL it a year after release

I did some test last night and today with NV2 on MT 4.13. The test has been done on an inoperational, 18 km long link with plain CM9's, Hyperlink's 29dBi grids and RB433AH's on both sides, using 40 Mhz channels, in presence of high freq congestion on both sides.

I haven't had the chance to do a real-life test, but with UDP i got 72 Mbps Tx / 65 Mbps Rx, comparing to 48 / 42 Mbps without NV2. There is however a significant increase in latency which is not what I expected after reading wiki on NV2. That is the only downside I stumbled upon.

Bottom line is, this might not be the best result in this forum but it's pretty damn good as far as I can say, considering equipment and a.m. air congestion. As soon as I get to, I will try to do the same with UBNT XR5's and make a parallel to 802.11n. Will inform you on results.

Good work MT guys! Keep it up.

Regards to all!

I did some test last night and today with NV2 on MT 4.13. The test has been done on an inoperational, 18 km long link with plain CM9's, Hyperlink's 29dBi grids and RB433AH's on both sides, using 40 Mhz channels, in presence of high freq congestion on both sides.

I haven't had the chance to do a real-life test, but with UDP i got 72 Mbps Tx / 65 Mbps Rx, comparing to 48 / 42 Mbps without NV2. There is however a significant increase in latency which is not what I expected after reading wiki on NV2. That is the only downside I stumbled upon

I've found it best to test with TCP, its always more stable altho lower result and closer to what you get in the real world, UDP makes up 20-30% of our network's traffic as an ISP. When NV2 came our in ROS 5 we tested it on a 5km link and whilst we saw a 29% increase in UDP throughput we only saw a 6% increase in TCP

To Beccara: Lets not start this useless discussion "how it should be done".
Facts are simple - RouterOS (and MikroTik) is where it is now only because it is the way it is, and in global picture they way of doing things works.

Regarding wireless: if it is 802.11n to 802.11n+nv2 transition, but in most cases (my experience) someone just do 802.11a --> 802.11n+turbo channel+ additional chain+nv2 without slightest idea how to configure it properly and then report problem with simple sentence "wireless don't work"

Well v4.13 - "wireless nv2 works"

Its user's like you that put us in this mess. There's a very small group on this forum that are high end users, Users that strike the bugs that nobody else does because they dont have the numbers or design to see them. The pure MT network I run is 1000+ Routerboard covering some 5000+ km2 of useable coverage. The users like us are more likely to have been exposed to internet networking, Cisco, Juniper and very large, complex networks. We know what industry best practice with something is, We're used to the way things get done large scale.

We've been pure MT since the start so when my boss tell's me today he's concerned at MT's releases lately it's a surprise. If people dont speak up and say "Hey, Why are you doing this? It's affecting our business and is not how the rest of the world does it" then MT wont change. Its not MT bashing for the sake of it, I always try to put forward the why's and how's and say how I would fix it. I dont expect to have to run a full test harness on a point release to deploy it because there are hidden changes. I dont expect a point release to mess with features that haven't been touched. I dont expect a peice of hardware I got 15 months ago to not be upgradeable (Got a few units licensed to v4 only and just over a year old) and the biggest annoyance is support telling us not once, not twice but five times out of our last five cases to install beta or unreleased software into a production setup to fix a bug

RouterOS is a wireless and routing platform, Take a look at the changelog for 5. There is stuff all routing changes, ROS 5 is bug fix's, SMP and NV2. NV2 will be nice when it's stable, I'm glad it works for you altho you don't go into detail about what "works", Look around the forums are full of stability problems with it. For us NV2 isnt stable and 4.11 and 4.13 (4.12 wasnt out long enough to test) have serious new bugs in them in areas that haven't been touched.

We're well aware you need to tweak things on wireless links and there is no magic "go faster" button but NV2 in ROS 4 is going to be a major pain, We cant deploy it to fix the bugs we need to fix because it's already been shown to introduce a serious new bug for us. Hopefully someone from MT reads this and takes it onboard. If you guys really feel the need to compete with UBNT because of AirMax then take the time to polish off your product a little more, rushing ROS 5 out the door with NV2 as it stands will on hurt you guys in the long run, I like your product I really do I just wish you guys would develop it better, ROS 4 is nice but its quality has gone down here. There is a reason all our CPE still run 3.30

If you have found bugs, or problems that you need fixed, please contact support. Fighting with other forum users will not help.

If you have found bugs, or problems that you need fixed, please contact support. Fighting with other forum users will not help.

We contact support quite often, As I said in my last post all recent tickets have been "Please install ROS 5.0RC 1" which is totally and utterly unacceptable in a production enviroment.

If there is one question out of the many in my posts above that I could have answered I would like a serious response as to whats cause MT to become release happy, 2.9.51 to 3.30 to 4.15ish to 5.10???

I've found it best to test with TCP, its always more stable altho lower result and closer to what you get in the real world, UDP makes up 20-30% of our network's traffic as an ISP. When NV2 came our in ROS 5 we tested it on a 5km link and whilst we saw a 29% increase in UDP throughput we only saw a 6% increase in TCP

I agree with you on TCP test part. UDP gives far from a real life traffic results. So, even before seeing your reply, I did a test on live PTP link. Here are the link specs:
- distance 23,4 km
- equipment on both sides:
- RB433AH
- R52H
- parabolic 32dBi
- 5 Ghz, 40Mhz channels + NStream

TCP test results were 54 Rx / 52 Tx - increase 31% (good for me ). However, the latency also went up by 5 - 8 ms on average 10 packets, at more or less the same load .

The fact is that the results can be very different. The difference of increases you and I got in TCP are the proof of so. Like any wireless standard, NV2 is not perfect but it does work if you are ready to pay with higher latency. On the other hand, it is a very cheap solution.

Unfortunately, at the moment I cannot compare it to 802.11n, but I'm working on that part as well. Judging by the posts in this forum, I do not expect to see acceptable results with 802.11n on longer links. First tests I did couple of months ago were a huge disappointment, so I'm not raising much of a hope about it.

Anyhow, as soon as I match NV2 against 802.11n, I'll post my findings.

Until so, regards to all!

Uldis: Why did you write that NV2 is supported only in version 5.x?

because it was supported only in 5.x until v4.13 =)


I understand it, but was told that NV2 can not be implemented in version 4.x and suddenly we have a version 4.13 with the NV2. What do you think MT team?

Can only say NV2 ROS 4.13 saved me today.

Where regular settings (nstreme) disconnects due to poor signal (I think the antenna has blown out of alignment after a
storm- going to check it tomorrow) NV2 keeps going without disconnects.

I have 3 CPE's with 1, 2 and 7 km on connected to this AP now with NV2
default settings and it performs just as good as the nstream.

The problems starts when I use NV2 on 2 r52n cards on the same RB and link on both. I guess we have to wait for synchronization feature.

RGDS

You're post would make sense if there was much to configure, NV2 gives us cell size and slot size. My concern is not that we didnt get a magic boost out of a simple upgrade my concern is the quality of builds coming out of MT lately.

4.13 installed on a CPE with the wireless package (not wireless-nv2) showed 8db decrease and instability in a link that was stable for atleast 9 months.

I agree there are alot of users around who have unrealistic views about NV2 and how it will magically make a bad link better but 4.13 is unstable and hard to test since all changes made to it aren't released in the changelog.

NV2 might be a change but upgrading a stable link to it gives you 2 extra options to play with, NV2's features are incomplete (WDS, Pseudobridge etc) and fairly untested, I cant fathom what was going thru MT's head when they decided to backport it to ROS 4 when they have publicly said a number of times it couldn't be done

I think Mikrotik are moving too fast and focusing on things that aren't needed, We went from 2.9.51 being the last to 3.30 being the last and now ROS 4 looks like is going to end around 4.15-4.20. We get multiple builds a month with incomplete change logs and MT support telling us to deploy unreleased or beta software to production sites. Get told a bug has been fixed in 4.x and its not in the change log which makes us wonder what else has been changed which leads us to having to test for weeks on end all the features to confirm they will upgrade fine, Then a week after this is done another versions out fixing some flaw in the version we just deployed.

MT should pull NV2 from ROS 4, work on getting the many bugs out of ROS 4 and keep ROS 5 in the cooker for a while, Its nowhere near RC status, ROS should be delayed untill NV2 has a full feature set and is tested more, Work on the v6 side of things and the routing issues, Release ROS 5 as a flagship and don't EOL it a year after release

I fully second all this.
It is also just history repeating. After releasing the first ´stable´ ROS3 family version we were at version 3.12 within some weeks because of all the bugs and problems around. Now "stable" means v3.30!?!
Going from 3 to 4 it looked like MT took a bit more caution in releasing the new ´stable´ version but yet again ´stable´ doesn't mean stable when we are already at version 4.13!
It looks like 5 series is going to take even more caution so I don´t think it will be ready as a real ´stable´ version until somewhere next year.

Releasing a version 4.13 to support NV2 while it has been stated several times this feature was not possible in v4 version leaves us very confused. If we then look at the issues still around in the development of the v5 family which introduce the big advertised new NV2 then I'm seriously concerned about the ´stability´ of NV2 in v4.13. Or is it now that NV2 in v4.13 suddenly works flawless ("STABLE" version according download page) while in the new ROS5 that is supposed to embrace this new protocol it is not? How very weird this is.

I personally believe MT should not put NV2 in v4.x series firmware yet until proven stable in the v5 family. That would also be more in line with their own communications and doesn't confuse us users. Or if they want to do such make it a v4.13rc before calling it "stable".

What kind of impression do we get from ´stable´ version 4.12 that is being followed up by 4.13 only two days later?
Highest order number of stable version should only be increased if newer versions in same family have been proven not to produce new problems.
So make it a 4.12rc or 4.13rc and only after some weeks after the user community didn't really produce new issues change that version into 4.13s ("s"= stable)
Most user should rely on the qualification on the website that a "stable" version is ´stable´ to some extend. Most users will update their rb's to newer 'stable' versions relatively soon. If I want to play with new ´development´ versions I will pick these and test and see how they work for me. But a new version that is sold as "stable" and brings a new feature with big promises should be able to use without too much worries fm users if indeed the version is ´stable´.

What kind of impression do we get from ´stable´ version 4.12 that is being followed up by 4.13 only two days later?
Highest order number of stable version should only be increased if newer versions in same family have been proven not to produce new problems.
So make it a 4.12rc or 4.13rc and only after some weeks after the user community didn't really produce new issues change that version into 4.13s ("s"= stable)
Most user should rely on the qualification on the website that a "stable" version is ´stable´ to some extend. Most users will update their rb's to newer 'stable' versions relatively soon. If I want to play with new ´development´ versions I will pick these and test and see how they work for me. But a new version that is sold as "stable" and brings a new feature with big promises should be able to use without too much worries fm users if indeed the version is ´stable´.

Thanks for the vote of support, your point about the stable version is very vaild and I had not thought of it from that view point. It also makes it very difficult for us to get the bug fix's we need when major changes like NV2 are introduced

And here it goes, another topic about "stable" and "unstable"

I can suggest:
1) if router is working for you with v3.30, v4.2 or v4.11 - stay with this version, ignore new releases
2) if you don't need nv2 in v4.x - don't use it.
3) have a test network in lab or on backup links, test releases there before applying to real-life environment.

What i have done here is simple, in agreement with customers is clearly written possible maintenance time (1h/day and several h on Monday night). I have backup links, where it is easy to redirect traffic to and back to main links. After i configure latest versions on them i have this 1h/day for my testing with real time traffic. best feedback come from internet cafe - at least here everyone have lag/jitter/latency monitoring tools build in inside the game (like Counter-Strike) that reports slightest problem with arriving packets.

I personally look at RouterOS from Linux (open source) perspective, and from this perspective RouterOS is on sunny side.
I can understand you frustration if you are used to heavy proprietary software with heavy price-tag and huge support system.

When was the last time you paid for linux?

I agree, if it ain't broke don't fix it but in our case things are broke and the fix's we need sit in rushed out releases. We do test in the lab and stagger deployments but at a certain point in any network you have weak links, We need to fix the routing crash's that occur with OSPF that cause full failures but we're stuck as the wireless in 4.13 is acting up (non-nv2 package) so we're stuck with a random full routing crash once or twice a week. I really dont want to spend hours testing API features because they fixed SSTP, Or wondering what OSPF is going to do since PPP AAA was changes

Please remeber the game stopping bugs we've seen that some simple QA could have fixed, We have ROS 5 RC's coming out with simple problems, RC3 fix's a bad CRC bug on powerpc did noone from MT boot RC2 up on a RB800?

I come from big iron with big support and OSS with nill, Atleast when you have an issue with OSS software you can pay to get it fixed. We spend a decent chunk of coin with MT and we've been with them since 2.9, ROS 3 is slowly becoming the "golden" age of versions, 4's got some funky bugs and now has a unstable wireless sytem put in, 5 needs to go back into the cooker for a while and it wouldn't surprise me to hear about ROS 6 sometime Q2 2011.

You seem to be a mascot of MT's buggy and unstable lets-add-something-new-midrelease dept

You seem to be a mascot of MT's buggy and unstable lets-add-something-new-midrelease dept

I think he is in the majority then "Feature request" is one of the most popular keyphrases here.

Hey I'm all for you guys taking request, I wish you'd take more (ipv6 wink wink nudge nudge) but why on earth would you decide to deploy nv2 backwards mid ROS 4?

Are you really that sure it was ready despite posting of issues all over here? Please roll back whatever changes you did in 4.13 to make nv2 work, We need the routing crash fix's but normal wireless is buggy now

Hey I'm all for you guys taking request, I wish you'd take more (ipv6 wink wink nudge nudge) but why on earth would you decide to deploy nv2 backwards mid ROS 4?

Are you really that sure it was ready despite posting of issues all over here? Please roll back whatever changes you did in 4.13 to make nv2 work, We need the routing crash fix's but normal wireless is buggy now

we had far more people wanting nv2 in v4 than people complaining about it now. plus there were some other reasons I can't disclose now.

So public pressure for a feature that's unstable has caused you to release it in it's unstable stable state. Tough position, But ours is now tougher as we face routing crash's that we cant fix until wireless is stable again in ROS 4. What do we do? Do I forward all client complaints to your phone number?

So public pressure for a feature that's unstable has caused you to release it in it's unstable stable state. Tough position, But ours is now tougher as we face routing crash's that we cant fix until wireless is stable again in ROS 4. What do we do? Do I forward all client complaints to your phone number?

no, main reason was a different one.

I can respect that but please answer my question, What do we do to fix routing crash's now that wireless is unstable? I'm stuck between a rock and a very ticked off boss

I can respect that but please answer my question, What do we do to fix routing crash's now that wireless is unstable? I'm stuck between a rock and a very ticked off boss

Did you actually notice that nv2 package is a separate install, completely optional, and not affecting anything unless you actually install it??

And did you see that I posted that in the few CPE it was installed in we didn't activate NV2 package and suffered from a 5-8db signal drop and EDL disconnects with the normal wireless package, Roll back to 4.10 and everything is fine

And did you see that I posted that in the few CPE it was installed in we didn't activate NV2 package and suffered from a 5-8db signal drop and EDL disconnects with the normal wireless package, Roll back to 4.10 and everything is fine

not possible

I'll be sure to pass that message onto my boss who installed 4.13 at his house and suffered from it. Something's changed in 4.13 with normal wireless. This is software Normis, nothing is impossible

Just to jump in with a warning ... It appears that MT 4.13 + NV2 npk are causing RB600 to freeze. This is not yet confirmed and 100% sure, but if you plan on putting 4.13 + NV2 on RB600, take caution.

We'll see what will be reply from MT support.

And did you see that I posted that in the few CPE it was installed in we didn't activate NV2 package and suffered from a 5-8db signal drop and EDL disconnects with the normal wireless package, Roll back to 4.10 and everything is fine

not possible

Ticket #2010110466000286

Attached are screenshots of the same CPE before and after, taken within 10min of each other

Just to jump in with a warning ... It appears that MT 4.13 + NV2 npk are causing RB600 to freeze. This is not yet confirmed and 100% sure, but if you plan on putting 4.13 + NV2 on RB600, take caution.

We'll see what will be reply from MT support.

I've got the same problem. RB600A reboots unexpectedly with 4.13 + nv2. Sent info to support.

I can respect that but please answer my question, What do we do to fix routing crash's now that wireless is unstable? I'm stuck between a rock and a very ticked off boss

Did you actually notice that nv2 package is a separate install, completely optional, and not affecting anything unless you actually install it??

Normis,

What you are exactly stating here is that without the new nv2 package the ROS4.13 package is exactly the same as the latest 4.12 (or .11)??

Why is v4.13 then put on the download site as a new version in the first place? You could also add a nv2 package on v4.12 then isn't it? This would make things so much more clear for users.

It has been written several times on this forum and by MT that it is always advisable to install latest stable version but actually you now confirm it doesn't bring any better version in 4.13! Worse, some users report that even without the new nv2 package in use something has changed, to the worse....

If nv2 package is not stable as proven in 5rc and therefore also not in ros4 why then add it in 4 series anyway? Only because the demand is there? This is crazy!
Yes, I am also waiting for a stable nv2 package because I have several AP networks where I hope this new protocol will improve things. But no, I don't want to put any release candidate versions on my network.

But now we found nv2 is attached to a "stable" 4.13 version for a moment I thought we could finally start using it!
It was only my conspicuous nature that withheld me from putting them on my network in mass. Probably saved myself a lot of problems if I read what Beccara is sharing with us.

So now I am in a position I can't even put my trust in a "stable" version anymore!

My vote would be to remove v4.13 from the website until it brings some fixing and nv2 package only to add when it is stable.
If the user community is demanding nv2 they can always try the 5rc2 (rc3?? where?) version.

And here it goes, another topic about "stable" and "unstable"

True, and it will come back until things improve.

I can suggest:
1) if router is working for you with v3.30, v4.2 or v4.11 - stay with this version, ignore new releases

Humanity rode horses to go from A to B. Worked for years...
The whole idea of newer OS is that it brings new functionality, better management and improved capacity while old problems are fixed. Stating to stick with the working OS is like asking to sit tight on the horse and ignore the fact the rest of the world moves forward....

2) if you don't need nv2 in v4.x - don't use it.

Imho everybody is looking for better links to their clients and more clients per tower. In the end we all need the best the ROS can offer.

3) have a test network in lab or on backup links, test releases there before applying to real-life environment.

You only have to read all that has been written on the ´n´ protocol from cheering lads that had links running at incredible speeds only to find out in real live these promised were hard to achieve. Off course every sensible user puts a new OS on a non production unit but that doesn't give much guarantees about what happens in the real production environment. The only ´real lab´ is the real world![/quote]

I can understand you frustration if you are used to heavy proprietary software with heavy price-tag and huge support system.

This statement makes no sense. Most of us are new with MT so never used to work with other systems and the once that did came to MT because their old proprietary software running equipment lacked support or capacity. MT is still a good OS and support is not bad. Better then many ´big´ names in the industry. But that doesn't mean improvement can't be wished...

bug voltage monitor ROS 4.13 on RB/433UAH

28 v fixed when the source is 14.4 v

IDC

Everywhere is getting full of TDMA noise from the other manufacturer. This is affecting the CSMA based systems.

IMHO, thats the reason they have implemented it for v4 too.

1) if router is working for you with v3.30, v4.2 or v4.11 - stay with this version, ignore new releases

currently used v4.1/v4.2 has TrafficFlow bug (it suddenly stops exporting), and somewhere around v4.6 MT fix that and broke API session logout (so we have +1000 hung sessions per day) - what version should we use, is we want both things working?..

Dont bring you logic here We're in the same boat with the OSPF bug causing full routing crash's. Macgaiver doesn't seem to be able to tell the difference between "crying" and constructive criticism, He's quite happy to roll over and accept the path we're heading down with ROS

logic ended when I installed v5.0rc3 on my production router without testing - just because only v5 could recognize the hardware (including NIC) of new Intel SR1630HGP server... SR1530HGH being working flawlessly with v3 for a few years =)

You're a brave man! It is kind of understandable that a new gen platform would require updated drivers, introducing them into ROS 4 could cause stability problems

actually, the only non-'Unknown' hardware in v4 on that platform was USB keyboard... =) so, additional driver for 'everything' is new kernel - that's what we have in v5

Dont bring you logic here We're in the same boat with the OSPF bug causing full routing crash's. Macgaiver doesn't seem to be able to tell the difference between "crying" and constructive criticism, He's quite happy to roll over and accept the path we're heading down with ROS

This is a good example, why i have hard time see something "constructive" here. (double karma decrease, and making things personal)

Back to topic:
If you do some research in forum you will see that every time MT rolled out fast,unexpected version it was for 1 of two reasons:
1) in some degree it was necessary for new boards (ether for production, or some missing feature support, or fix in BIOS or software)
2) show-stopper bug that need to be fixed as soon as possible

and together with this:

we had far more people wanting nv2 in v4 than people complaining about it now. plus there were some other reasons I can't disclose now.

I think there are very good reasons why nv2 is in v4, i as far as i can see it we have just enough time to check it and get it into shape that is working for us before MUM Europe.

guys, stop fighting!

as I said, nobody is forcing any new packages on you. ignore the package, and everything will be the same. no other files were changed, the package is completely separate.

bug voltage monitor ROS 4.13 on RB/433UAH

28 v fixed when the source is 14.4 v

IDC

Detailed described in http://forum.mikrotik.com/viewtopic.php?f=2&t=46413

guys, stop fighting!

as I said, nobody is forcing any new packages on you. ignore the package, and everything will be the same. no other files were changed, the package is completely separate.

I see you've ignored the bit where I showed you 4.13 normal wireless is worse than 4.10 wireless

Dont bring you logic here We're in the same boat with the OSPF bug causing full routing crash's. Macgaiver doesn't seem to be able to tell the difference between "crying" and constructive criticism, He's quite happy to roll over and accept the path we're heading down with ROS

This is a good example, why i have hard time see something "constructive" here. (double karma decrease, and making things personal)

So you dont see the posts where I asked for specific things in IPv6 or in here where I asked why nv2 has been backported after MT have said it wasn't possible, Or where I asked for more complete change logs to assist us in version testing etc etc. Double karma decrease because all you tell those who speak up about improving things is that its the way it is and to shut up.

I've reported normal wireless faults, someone reported lockup's on RB600's, another has problems with voltage reporting. For a release where only NV2 was added with USB feature aswell it seems that things other than these 2 items have issues now, A sign something changed somewhere else.

You offer your ideas on whats stable and why to update and ignore those who have faults like Traffic Flow + API where any ROS 4 version results in you having atleast one of the bugs but you need both or with us needing the routing fix but now wireless is bung.

guys, stop fighting!

as I said, nobody is forcing any new packages on you. ignore the package, and everything will be the same. no other files were changed, the package is completely separate.

I see you've ignored the bit where I showed you 4.13 normal wireless is worse than 4.10 wireless

It's simply not true. There are zero changes there. Maybe a bald eagle sat on your antenna during the upgrade, and made the antenna tilt down. He flew away when you downgraded

Eagle would have had to have been there 3 times over 4 days for 10min-45min each time.

Respond to the ticket, I'll give you remote access to it to upgrade and downgrade all you like, Its there, There is an issue. Stable link in terms of equipment and environment, Test's done close together to avoid thermal/time of day issues.

You can reproduce it simply

Also we don't have bald eagles in New Zealand

I agree completely with Beccara - I have tried every version and beta since 3.30 and not a single one managed the RF as effectively.
We had this same problem 3-4 years ago - at that time I had NOT identified a version that was stable. It sucked! Lost lots of customers!
Now we have v3.30 for everything but 900mhz and some legacy RB boards and some legacy cards which all run great on v3.28.
I have been consistently logging my issues on this forum as have quite a few others. We are not the occasional banger with a few systems in place but run full growth oriented mature networks that support a myriad of systems and services in the field.
The only reason we continue to log here is we really like MT - BUT - if this is not taken serious then we have to make decisions that allow us to continue to build our platforms and not argue over semantics.
The fact that we are already being forced to test other platforms in the field - beyond acquiring a working knowledge of other tech - means we are being forced to make these decisions.
I really enjoy working with RB and MT. I want to keep it that way!
Rod

Dont bring you logic here We're in the same boat with the OSPF bug causing full routing crash's.

Known problems that caused OSPF to crash are fixed and these fixes were backported to v4.13. If you still have OSPF crashes with v4.13 then you have to contact support with new supout files. Have you previously contacted support about OSPF problems, can you give a ticket number?

I can confirm that, running rc02 full bgp, 22 bgp peers , ospf e running flawless dispite a thousand of rx drops a day.

huh... funny... interval between messages is 23 minutes...

no other files were changed, the package is completely separate.

Known problems that caused OSPF to crash are fixed and these fixes were backported to v4.13.

so, who's right?

Something has changed and you guys wont even respond to the ticket about it, I've given you screen shots of the change and if i have to i will take a video showing no bald eagles on the CPE during the upgrade.

While no configuration of source code may have changed between v4.12 and v4.13 in the wireless package, there are definitely changes to the md5 and sha1 checksums of files related to wireless inside RouterOS. It may be, that the build system changed "something" while building the new version.

It may also be that this may be the cause of many changes with effect RouterOS at each release.
Example: Mikrotik changes something in source (and it's a good change). Then they run a build system to "re-compile" the whole system again. During this process the build system includes the intended change, but may introduce another (unknown to the programmers) change. The only way to test for this would be to create some kind of testing suite to run each compile against.

Just worth noting. I do think users have valid points. Something may have changed unknowingly. This issue (of unknown changes, and user discrepancy), should be investigated further.

Doing some tests with NV2 Package in 4.13.

With NV2-Package I see a signal loss of 5-6db even without using nv2.

I see strange behavior when using a dualpol Antenna on one side
and a single pol Antenna on the other. The dualpol side has to
enable both chains for receiving and the right chain for sending.
When selecting only the right chain for send and receive I get no
connection. This happens with and without NV2 Package.

At the end of the day Normis / MRZ / Mikrotik staff - RouterOS is your baby and you can do with it whatever you like - and without having to explain yourself to us - the user.

You do so at your own risk however.

RouterOS will only ever exist so long as there are (serious) people out there prepared to pay for, and use it (in serious quantities). And those people will only ever exist if RouterOS is reliable AND people have confidence in it.

Historically - RouterOS has been brilliant - I own the network beccara talked about earlier (1000+ clients, 90+ Broadcast sites, all MT and all RB products)- which should give some indication as to my commitment. However more recently its not the buggy releases thats been the issue (Beta is beta, dont run it and you wont have problems, i get that).

Its the lack of support - we suffer from serious OSPF crashes since running 4.x (we need 4.x to support N cards, so no going back to 3) and 4.13 DOES cause wireless issues for us. We're not lieing or making it up. We're not n00bs. We're not idiots either. If MT isn't prepared to take us seriously and resolve our issue what do we do? We have to go else where, and this will be repeater for many other SERIOUS RouterOS users.

So MT - take a piece of free advice and listen to your (serious) users - we're the ones you're building RouterOS for, after all.

mtcw

*edit*

I want to throw in here, i dont really care about NV2 right now. Yes more throughput and better latency will rock and i do want it - but we need the basics to be stable first. Its no good being able to do 100mbit over wireless if routing crashes twice a day and our users leave our service due to unreliability - then we have no money and stop buying RB / RouterOS.

Well said, Belyivulk.

I will chime in that I'm also having wireless issues with 4.13 which are not Nv2 related. Downgrades to 4.11 'fixed' this.

I also had an OSPF issue last night with a router after updating to 4.13. It actually seemed as if the Ethernet interface was physically flapping. OSPF routes kept flapping along with the interfaces's main IP. The 4.13 router was on an Ethernet broadcast domain with two other ROS 4.11 routers, and 5 Cisco routers…all of which run OSPF. Again a downgrade to 4.11 was the 'solution' to this problem.

Unfortunately I do not have sup-outs to submit to MikroTik regarding these problems. I'll try setting up a test lab to mirror this production config and send MT the sup-outs from those. I'm certain I'll be able to reproduce the issue.

Hey Blake,

Thats exactly what we see with OSPF - running 4.10 on an RB800 to a 3com Managed switch.

Mikrotik have acknowledged to us that they can see the OSPF crashes - but to date nothing has been done about it (first reported around May / June this year).

>added USB power reset feature

Will this address the issues we have been having with USB GSM Modems?

for future RouterBOARDs, usb power reset allows you to reboot a 3G modem without rebooting the router. This will also help the modems, that can't load normally upon reboot.

Are you saying that RB's like the RB-411U will not benefit from this feature it is rather important. If not what RB's will support this please could you supply a list that would be able to support 3G modems?

Thx

Hi!

There are interesting phenomena at us.
There is a centre what restarts.
There is a centre what forgets the user's radio.
A radio turns off - allows and a little one works onto time.

Very annoying things. Users they complain.

Looking forward to trying nv2. Unfortunately the nv2 wireless package in 4.13 causes PPPoE sessions on 2.4GHz interface to randomly disconnect, so reluctantly had to downgrade wireless package without testing on 5GHz interface.

Shame as I wanted to see if TDMA would improive our PtMP performance.

I'm having problems with NV2 as well, not so much the new firmware (4.13) but whenever I change from Nstreme to NV2 the connection lasts for all of 30 seconds and then the radios stop passing data all-together. The wireless connections are NOT dropping, but it's acting like there is a network loop or something. I've enabled RSTP, but that doesn't seem to help.

I've already started a thread regarding it, but I'm getting very little feedback.

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

>added USB power reset feature

Will this address the issues we have been having with USB GSM Modems?

for future RouterBOARDs, usb power reset allows you to reboot a 3G modem without rebooting the router. This will also help the modems, that can't load normally upon reboot.

Are you saying that RB's like the RB-411U will not benefit from this feature it is rather important. If not what RB's will support this please could you supply a list that would be able to support 3G modems?

Thx

I am looking for more information here too. We will probably tear out our 411U's that are in service with USB modems shortly (within days) because of this very issue with "invalid" or recreated usb ports with an ever increasing PPPx numbering each reboot. We are using ZTE and Sierra modems, and have tried all ROS versions 4.6-5.0b3, done Netinstalls, reset-configs etc, but the behavior is the same when it comes to the USB GSM modems. Its worth mentioning that ROS x86 on a PC clone board does not seem to suffer this USB bug, at least not in our testing environment.

So, to be clear, this USB power reset feature wont work on any of the current line of RB's with USB ports Normis?

USBpower reset will work only with some yet-unreleased products. RB411U will have no benefit

hello everybody, look at this something is wrong here. the 4.13 no is good version for my rb433ah. power supply is 12 volts and winbox shows 24Volts , the frequency is also displayed wrong.

We are seeing exactly the same issues as Beccara in 4.13 standard wireless package.

One of our RB433AH has 2x R52s with approx 15 clients on each using 802.11b/g. About a week since the upgrade one interface suddenly has only 4 clients able to connect. Changed to standard wireless package - no improvement. After hours of hassle we finally downgraded to 4.11 and everyone reconnected no problem.

There is certainly something different about how 4.13 handles standard wireless package - if Normis insists nothing has changed then I dreadthis being carried over into future releases.

As someone once told me you have to pick your battles wisely, After a support ticket and letting them login to a unit and my boss pulling his hair out at his own CPE going haywire we dropped it with MT, They wont budge on it and testing to 5.0rc4 showed the change reversed so hopfully 4.14 or 5.0 wont continue to have the same problem.

Perhaps if there is a change/issue MT wont admit to it because of its nature

Just to jump in with a warning ... It appears that MT 4.13 + NV2 npk are causing RB600 to freeze. This is not yet confirmed and 100% sure, but if you plan on putting 4.13 + NV2 on RB600, take caution.

We'll see what will be reply from MT support.

Yes, i can confirm freezing of rb600. This is from 4.10 yet, but without using nv2. Just using standard 5ghz card and higher usage of ethernet ports. It is very dissapointing. So much money and no stability. And watchdog doesnt help me ... Ping packet is passing through , but rb600 rebooting of watchdog timer (using same watchdog address ...). Shit you repairing that bug/s. Its your enthusiast/s device ...