RouterOS v4.5 released

Wed Jan 13, 2010 2:27 pm

What's new in 4.5:

*) fixed Nstreme issues with bridged traffic
*) ipsec - added blowfish, twofish, and camellia encryption algorithms;
*) fixed static route removing;
*) fixed DHCP client compatibility with some DHCP servers;
*) added static multi-cast route support;
*) fixed temperature monitor on RB800 and RB450G;
*) user manager - payment bug fix - now able to buy
credits without extend price specified;

Download: http://www.mikrotik.com/download/router ... .5.torrent

sambol · Wed Jan 13, 2010 4:01 pm

Just downloaded, tried to upgrade without success.

02:00:00 system,error broken package routeros-mipsle-4.5.npk
02:00:03 system,info router rebooted

RB532A.

Wed Jan 13, 2010 4:03 pm

re-download, probably download was interrupted. use torrent, it has internal error checking mechanism

mandrade · Wed Jan 13, 2010 4:06 pm

Is the NSTREME BIG BUG fixed????????????

BR

sambol · Wed Jan 13, 2010 4:11 pm

Strange... downloaded 5 times from different mirrors, every time same situation. Downloaded from torrent, works. Thanks

netrat · Wed Jan 13, 2010 4:21 pm

Has the CSPF problem been fixed? Confirmed by me and mplsguy?

http://forum.mikrotik.com/viewtopic.php?f=14&t=37501

Chupaka · Wed Jan 13, 2010 4:33 pm

huh, neither of two NetFlow 'fixes' is mentioned %)

and one of them is actually not fixed

maybe, friday would be a better day for the release?..

rzirzi · Thu Jan 14, 2010 8:37 am

Is the NSTREME BIG BUG fixed????????????
BR

Normis - is the nstreme working fine and do not disconnecting? Many people waiting for this bug improvement.

doush · Thu Jan 14, 2010 12:43 pm

What is *fixed static route removing bug ?

Please MT team give more info about it. I

mrz · Thu Jan 14, 2010 12:44 pm

What is *fixed static route removing bug ?

Please MT team give more info about it. I

http://forum.mikrotik.com/viewtopic.php ... te#p188855

Thu Jan 14, 2010 1:01 pm

Is the NSTREME BIG BUG fixed????????????
BR
Normis - is the nstreme working fine and do not disconnecting? Many people waiting for this bug improvement.

see my post here:
http://forum.mikrotik.com/viewtopic.php ... 56#p188456

if anyone has sent us a recent supout.rif file with this issue, we will try to fix it. but nobody has, ergo there is no widespread problem with nstreme. only configuration issues.

doush · Thu Jan 14, 2010 2:49 pm

What is *fixed static route removing bug ?

Please MT team give more info about it. I
http://forum.mikrotik.com/viewtopic.php ... te#p188855

I have updated to v4.5 because of a strange issue that may related to this route bug.

I see IPs in my ARP table that are not existing. I have deleted those IPs in v4.4 and removed their route. When I check Ip route, the routes are OK but in my ARP table, I still have IPs from the very same IP segment previously deleted.

When I try to ping those IPs, I get timeout all around the network. But ARPs are there on my main router.

Am I missing something ?

janisk · Thu Jan 14, 2010 3:24 pm

most probably you are receiving packets and they are MACs are registered in ARP, but your routing table does not have information where these IPs are.

dada · Thu Jan 14, 2010 4:11 pm

Is the NSTREME BIG BUG fixed????????????
BR
Normis - is the nstreme working fine and do not disconnecting? Many people waiting for this bug improvement.

After upgrade some of our NSTREME links started to disconnect too. I found out that after the upgrade the hw-retries was set to 4. After I increased it to 8 (on both ends of line) the problem disappeared (on multiple links). So I didn't thouht that there is a bug in NSTREME but that the Mikrotiks are too optimistic when they lowered the hw-retries...

roc-noc.com · Thu Jan 14, 2010 4:54 pm

Is the NSTREME BIG BUG fixed????????????
BR
Normis - is the nstreme working fine and do not disconnecting? Many people waiting for this bug improvement.
After upgrade some of our NSTREME links started to disconnect too. I found out that after the upgrade the hw-retries was set to 4. After I increased it to 8 (on both ends of line) the problem disappeared (on multiple links). So I didn't thouht that there is a bug in NSTREME but that the Mikrotiks are too optimistic when they lowered the hw-retries...

Hardware Retries was already lowered to 4 in ROS as early as version 3.18 and that didn't cause any problems. I remember this was done to fix a problem with Ubiquiti XR2 and XR5 cards disconnecting. Before that, the default was 16.

Tom

Thu Jan 14, 2010 6:03 pm

hw-retries setting for the nstreme were not used in the v3.x
Only starting with v3.x wireless-test packages the hw-retries settings were used.

Chupaka · Thu Jan 14, 2010 6:34 pm

Hardware Retries was already lowered to 4 in ROS as early as version 3.18 and that didn't cause any problems. I remember this was done to fix a problem with Ubiquiti XR2 and XR5 cards disconnecting. Before that, the default was 16.

16? now 15 is the maximum

pbr3000 · Thu Jan 14, 2010 7:26 pm

Hardware Retries was already lowered to 4 in ROS as early as version 3.18 and that didn't cause any problems. I remember this was done to fix a problem with Ubiquiti XR2 and XR5 cards disconnecting. Before that, the default was 16.

The maximum was 15, not 16.

mandrade · Fri Jan 15, 2010 2:09 am

Is the NSTREME BIG BUG fixed????????????
BR
Normis - is the nstreme working fine and do not disconnecting? Many people waiting for this bug improvement.
see my post here:
http://forum.mikrotik.com/viewtopic.php ... 56#p188456

if anyone has sent us a recent supout.rif file with this issue, we will try to fix it. but nobody has, ergo there is no widespread problem with nstreme. only configuration issues.

FACE the REALITY .The problem is : all here use MikroTik is production envirnoment, we can not maintain a problematic link in production only for MK research... we need offer a GOOD QUALITY production link, bacause this, all people with the problem has been downgraded to 3.30. My suggestion is the MK TEAM mount a link with any spec showed here in forum by many many many users with the related problem ( use search button ) and CHECK AND FIX the NSTREAM problem....

BR

Fri Jan 15, 2010 9:03 am

We have many Nstreme links installed, that are run with actual traffic and actual users. We don't have such problems, and nor does the majority of RouterOS users. We have no real support requests at this time. If you have issues, please make a proper support request, with as much details as you can give us, and we will try to replicate the problem, and solve it.

dada · Fri Jan 15, 2010 1:18 pm

hw-retries setting for the nstreme were not used in the v3.x
Only starting with v3.x wireless-test packages the hw-retries settings were used.

It explains our problems. On link which we observed the disconnect problem first we used wireless-test in 3.X. We tried to replace hardware, realign antennas, we changed TX channels, changed nstreme settings, upgraded to 3.30. Nothing helped. Then we increased hw-retries and the problem disappeared. Now there is ROS4.2 installed and it works fine...

Fri Jan 15, 2010 1:25 pm

hw-retries setting for the nstreme were not used in the v3.x
Only starting with v3.x wireless-test packages the hw-retries settings were used.
It explains our problems. On link which we observed the disconnect problem first we used wireless-test in 3.X. We tried to replace hardware, realign antennas, we changed TX channels, changed nstreme settings, upgraded to 3.30. Nothing helped. Then we increased hw-retries and the problem disappeared. Now there is ROS4.2 installed and it works fine...

That's good news! How about others, did you try this?

nik247 · Fri Jan 15, 2010 2:30 pm

Bug with netflow (not started after reboot) not fixed in ROS 4.5(x86).
8-(
from http://forum.mikrotik.com/viewtopic.php ... 63#p189063

Fri Jan 15, 2010 2:42 pm

By the way, we made one fix for Nstreme which affected Bridged traffic. Anyone with Nstreme should upgrade.

angboontiong · Fri Jan 15, 2010 3:40 pm

By the way, we made one fix for Nstreme which affected Bridged traffic. Anyone with Nstreme should upgrade.

Normis..
I found that, is i use the RB433 with the MPLS setup for the R52N.
When the CPU load up to the 40%, then there's the limitation and we not able to pass more traffic (UDP test).

Any idea RB4 series will come out with power pc processor?

angboontiong · Fri Jan 15, 2010 3:41 pm

By the way, we made one fix for Nstreme which affected Bridged traffic. Anyone with Nstreme should upgrade.

Would you mind to explain and share more detail?

Fri Jan 15, 2010 3:57 pm

I don't know anything specific, I just know that there is a fix related to bridged traffic and nstreme, and that it was forgotten in the changelog.

pbr3000 · Fri Jan 15, 2010 8:32 pm

It explains our problems. On link which we observed the disconnect problem first we used wireless-test in 3.X. We tried to replace hardware, realign antennas, we changed TX channels, changed nstreme settings, upgraded to 3.30. Nothing helped. Then we increased hw-retries and the problem disappeared. Now there is ROS4.2 installed and it works fine...

I have this problem and the v4.2 is the last nstreme stable to me too. Not using bridged, just plain routing. hw-retries are 15 in all my ptp links, but the v4.2 is the only nstreme stable in the 4.x series (to me).

staack · Sat Jan 16, 2010 9:35 pm

What's new in 4.5:

*) fixed DHCP client compatibility with some DHCP servers;

I invented many new vulgarities over this and having to deal with the cable company until finally just giving up. But I must give credit to the wrt54g w/dd-wrt that worked without issue for the past 3 months. Now my Mikrotik is back in charge of my home network. Thank you VERY much for this fix.

adrianx · Sat Jan 16, 2010 10:24 pm

Hello ,

I have several links over 50 km with RB433Ah, Xr5 , antennas with 29dB grid, nstreme enabled, Mikrotik version 4.5 and I have no problem.

rmichael · Sat Jan 16, 2010 10:54 pm

Hello ,

I have several links over 50 km with RB433Ah, Xr5 , antennas with 29dB grid, nstreme enabled, Mikrotik version 4.5 and I have no problem.

Did you have issues with previous 4.x versions? ...I just noticed that you are using 11a. One poster on this forum suggested that problem is with b/g and it might just be that your experience proves his point.

mishaM · Sat Jan 16, 2010 11:00 pm

hello

if can do so on new version in the into comment could write in Unicode ?

adrianx · Sun Jan 17, 2010 12:15 am

I upgraded from version 4.1 and had the same results

angboontiong · Sun Jan 17, 2010 7:03 pm

Normis...
Will the improvement effect on the MPLS+VPLS setting (for 11N).

BobcatGuy · Tue Jan 19, 2010 5:09 am

As mentioned earlier in this post, I had a link that kept dropping the wireless link, From a RB 532A with XR5 to a RB 333 with XR5, This was a non nstream link. The link was dropping on the 333 side, where other clients connected to the 532a AP did not, but these drops stopped after an upgrade to 4.X I do not recall the exact version, but it stopped. The one wierd thing is that the RB 333 has log entry's an entry about 1 to 2 times a day that says router rebooted without proper shutdown, or at times Kernal failure, rebooting. The board never has its power pulled, so the log entry makes no sense.

I did however increase the HW retries to 14, and this may have stopped the wireless drop, where MANY other posts were saying to decrease it to 4.

Tue Jan 19, 2010 8:46 am

uldis and me have always said to increase hw retries to avoid disconnects

mandrade · Wed Jan 20, 2010 2:10 pm

By the way, we made one fix for Nstreme which affected Bridged traffic. Anyone with Nstreme should upgrade.

This FIX was in 4.5???? i use NSTREAME in bridge mode, i will test 4.5 and return.....

BR

P.S. : Now testing in a 30Km Link, i have generated screen shots and support.rif files with 3.30 before upgrade in both sides and link are up and running now. I will evaluate the link for same time, and generate screenshots and support.rif in both sides again and post all here at end of test, i hope that will be sufficient info for prove that bug is corrected or not and put an end point in this extense discussion......

mandrade · Wed Jan 20, 2010 4:40 pm

By the way, we made one fix for Nstreme which affected Bridged traffic. Anyone with Nstreme should upgrade.

This FIX was in 4.5???? i use NSTREAME in bridge mode, i will test 4.5 and return.....

BR

P.S. : Now testing in a 30Km Link, i have generated screen shots and support.rif files with 3.30 before upgrade in both sides and link are up and running now. I will evaluate the link for same time, and generate screenshots and support.rif in both sides again and post all here at end of test, i hope that will be sufficient info for prove that bug is corrected or not and put an end point in this extense discussion......

Well ,

As promissed by me, here is the screenshots of the problem that CONTINUES ... all has been sent to support@mikrotik.com with the follow message :

Hi,

Many users have related problems with NSTREAME on version 4.x of MikroTik in forum, and normis has said in forum that can not correct the problem because noone opens a ticket on support with sufficient data for analisys. In this post http://forum.mikrotik.com/viewtopic.php ... =2#p189255 he says that you have corrected a bug with NSTREME in bridge mode, i have update a link with 30Km from 3.30 to 4.5, and the problem continues. Attached is :

- supout.rif with 3.30 from bridge and client sides
- souout.rif with 4.5 from bridge and client sides
- screenshots with 3.30 AND 4.5 of the bohs sides. With 3.30 the link is UP for 32 DAYS and with 4.5 the link goes down several times...

I hope that is sufficient info for you try to slove the problem.....

BR

With VERSION 3.30 :

Version330-Bridge.JPG

Now with VERSION 4.5 :

Version45-Bridge.JPG

The support Ticket#2010012066000292

Now wait for MikroTik support answer and of course solution....

BR

rodneal · Thu Jan 21, 2010 5:25 am

OMG - this is exactly why I upgrade a piece of my network every-time an upgrade comes out - you never know what was missed in the change-log - my entire network is bridged with the routed running over the top. And nstream hasn't worked for me either and I was stuck with v3.30.

Works great now and has since I uploaded v4.5 across the network. BUT... I had a few issues with ptmp 5.8 bh links - now I know about the increase in hw retries! How do I determine the correct number to put in - the max "15"?

Thank you,
Rod

Keep on Rockin MT

pikpik · Thu Jan 21, 2010 10:24 am

I have troubles too :/ http://forum.mikrotik.com/viewtopic.php ... 09#p189909

Ozelo · Thu Jan 21, 2010 7:51 pm

In fact, we have no issues about disassociations til ROS 4.x. Now using ROS 4.x we noticed the disconnects and also we can confirm that increasing hw-retries indeed helps to avoid it, but still a bad wireless behavior (NOT performance) comparing to ROS 3.30. Now Ive experienced good improvements on wireless 802.11 b and g access points on ROS 4.5.

By increasing hw-retries you may (or may not) experience latency, but YES helps a lot to avoid disassociations. ROS 3.30 seems to be more robust and barely we see stations disconnecting. On outdoor scenarios you may wish hw-retries to be the lowest as possible, that helps on hidden nodes but it become worse when using ROS 4.x even choosing cts-to-self. Too bad for us, using connection-rate matching for QoS on access points available only on ROS 4.x. What if ROS 4.6 comes that robustness we see like 3.30 seems to be? That would be nice.

However, on point to point links we have very stable links using hw-retries @ 15, 5ghz turbo nstreme best fit 3200. We see that lowering hw-retries on ptp links drop down performance a bit, so we keep it high.

Not talking about performance, but now on ROS 4.5 we notice a different behavior on wireless and seems to be a better one on all scenarios we have nowdays. Not that "stable" as we see on 3.x, but so far so good. I wonder what changes had to be made. Isn't a rabbit called Mikrotik on wonderland?

I thought so...

rmichael · Thu Jan 21, 2010 8:32 pm

...Too bad for us, using connection-rate matching for QoS on access points available only on ROS 4.x. What if ROS 4.6 comes that robustness we see like 3.30 seems to be? That would be nice.
...

According to change log connection-rate is also in 3.30

mandrade · Thu Jan 21, 2010 8:35 pm

Hello to all,

I receive it from support :

Hello,

please lower the CPU from the 800Mhz to the 680Mhz as at 680Mhz the board
should work more stable.
About the nstreme problem, try to increase the hw-retries setting on both ap
and the client to 7, 10 or 15 and try again.
also you can try to install in v3.30 wireless-test package to see if you have
the same problems like in v4.x

Regards,
Uldis

And after my tests , here is my answer :

Hello,

Sorry by delay to return.... but i made several tests before return to you. all have been maded with 4.5 and 3.30 wireless-test package. Here is the results :

- 3.30 wireless-test package in same configuration show the problem to me....
- CPU clock does not affect the problem, 680 or 800 nothing change the results of the next tests....
- hw-retries in 7 minimize but not slove the problem BUT hw-retries in 10 or 15 the link becomes stable again in 4.5 and in 3.30 wireless-test package

Conclusion to me : The solution is increse hw-retries to 10 or 15 slove the case
Suggestion : If possible in the upgrade process MK can verify and correct if necessary the hw-retries problem.....

BR

butche · Mon Jan 25, 2010 4:41 am

Conclusion to me : The solution is increse hw-retries to 10 or 15 slove the case
Suggestion : If possible in the upgrade process MK can verify and correct if necessary the hw-retries problem.....

My question to Mikrotik is this: If increasing the hw retries is a fix, then WHY is this only a problem with 4.x? I have a link running with 3.30 (not wireless-test), RB433AH, R52H boards. NO PROBLEM with this link. I just checked. HW-Retries is set to 6 right now. Max Station count is set at 4 (it is currently point to point link, but this WAS a point to multi point ap). Link runs an average of 12-15Mbps in traffic. Upgrade to 4.2, 4.3, 4.4 and 4.5 (I have tried them ALL), and the link will no reliably move more than 1-2Mbps of traffic. Usually, it's under 1M. I would like SOME explanation of WHY the suggested fix is required and what has changed in the software to make it necessary. I understand from Uldis in this thread that hw-retries setting was not used in 3.x unless wireless-test was used, so that may be the answer I am seeking. SIGH...

rmichael · Mon Jan 25, 2010 6:35 am

normis said, on few occasions, that v3.30 + wireless test == v4.x

Back in v3.x there were two groups of satisfied users - one for whom test package worked best and for others regular package did fine. Now that there's one choice those who did not use test package are FUBAR so it seems.

Mon Jan 25, 2010 8:42 am

hw-retries default setting changed both in wireless-test and in v4 (which uses the same wireless test now as default package). this was changed because of reports of high latency on certain wireless links (this was a popular topic before wireless-test had this change).

there is a cost to low latency - higher possibility of disconnect. balance the hw-retries setting so, that you have both a stable link, and one with low latency.

this setting is individual, and can be perfected only with experimentation. imagine it as the next step after link alignment.

so again - in v3 non-test the default was a higher value. this lead to bad latency in some cases. we decreased the default hw-retries value in test package. this lead to a better latency. it turns out, it leads also to more disconnects. if that's your case - increase the hw retries value

pikpik · Mon Jan 25, 2010 10:04 am

vpls + nstreme on 4.5 works fine
eoip or wds + nstreme = disconnects

Muqatil · Mon Jan 25, 2010 11:30 am

hw-retries default setting changed both in wireless-test and in v4 (which uses the same wireless test now as default package). this was changed because of reports of high latency on certain wireless links (this was a popular topic before wireless-test had this change).

there is a cost to low latency - higher possibility of disconnect. balance the hw-retries setting so, that you have both a stable link, and one with low latency.

this setting is individual, and can be perfected only with experimentation. imagine it as the next step after link alignment.

so again - in v3 non-test the default was a higher value. this lead to bad latency in some cases. we decreased the default hw-retries value in test package. this lead to a better latency. it turns out, it leads also to more disconnects. if that's your case - increase the hw retries value

As i was trying to point out, in 3.30 wireless test the 4 hw-retries were working fine, why would be 4.5 unstable with 4 hw-retries?
Anyway, i did a reset-configuration after the upgrade and it works fine even with 4 hw-retries... There must be something else different from 3.x version that makes 4.x unstable.
I'm an happy user of 4.5 version now.

mandrade · Mon Jan 25, 2010 3:41 pm

Conclusion to me : The solution is increse hw-retries to 10 or 15 slove the case
Suggestion : If possible in the upgrade process MK can verify and correct if necessary the hw-retries problem.....
My question to Mikrotik is this: If increasing the hw retries is a fix, then WHY is this only a problem with 4.x? I have a link running with 3.30 (not wireless-test), RB433AH, R52H boards. NO PROBLEM with this link. I just checked. HW-Retries is set to 6 right now. Max Station count is set at 4 (it is currently point to point link, but this WAS a point to multi point ap). Link runs an average of 12-15Mbps in traffic. Upgrade to 4.2, 4.3, 4.4 and 4.5 (I have tried them ALL), and the link will no reliably move more than 1-2Mbps of traffic. Usually, it's under 1M. I would like SOME explanation of WHY the suggested fix is required and what has changed in the software to make it necessary. I understand from Uldis in this thread that hw-retries setting was not used in 3.x unless wireless-test was used, so that may be the answer I am seeking. SIGH...

Here is an official explanation direct from support :

Hello,

in older RouterOS versions (v3.x) the hw-retries setting was ignored for the
nstreme links. Only when we introduced the wireless-test package and v4.x this
setting also started to apply for the nstreme links.
Each case is different and the client should tune hw-retries for this
individual case differently.

Regards,
Uldis

BR

phendry · Mon Jan 25, 2010 10:30 pm

Still seeing same issue with .11n with 4.5

AP is RB411AH with SR71-15 and client is RB411 with R52N. Link is running in 5GHz-only-N with NStreme/Polling enabled. Noise floor -118 with -60/-62 signal, 100/100 CCQ and both AP and client set to 15 for Hw Retries. Rate is happy idle at 65Mbps/65Mbps (not running 40MHz).

If I run bandwidth test to client from AP, the RF drops.
If I run bandwidth test to AP from client, the RF drops.

If I set AP to 5GHz (i.e. no .11n), I get full bandwidth as expected without any drops.

Is it possible that Hw Retries for none Mikrotik .11n cards isn't working properly?

Mike_CT · Tue Jan 26, 2010 3:58 pm

I warn all to be very careful when upgrading, as I agree there are issues.

I have a small network with just 5 highsites or core routers as I call them. RB600 x 2 and RB433AH x 3.

Some R5H links, some R52 and one with R52-CM9. Not tried N yet.

Well for 2 days after the upgrade, many disconnects on my backhaul links, nstreme, 5Ghz. Not too many issues with sector APs for clients, they are ok.

Hw-retries helped a little, went from 4 to 7 or 8. But what helped most was to reset config on each wlan and rebuild, rebooted. That seems to have resolved the issue. No latency is about 2ms on all links, no drops for last 24hrs.

I think the CM9 was having an issue on the one link. R5H seems no problems.

My first post...hope this helps someone.

Mike

DolceVii · Tue Jan 26, 2010 4:51 pm

after upgrade from 4.4 to 4.5
1. when upgrade from 4.4 to 4.5 reboot ok but after 2min disconnect and need to unplug PoE to work..
2. rb600a don't work after 3-4 hours, need to unplug PoE to work again... Fw2.20
downgrade to 4.4 and the problem still there!

rb192 don't work. Fw2.18

DolceVii · Wed Jan 27, 2010 6:52 pm

Problem resolved! Ros 4.5 works!!! on rb600a

DolceVii · Sat Jan 30, 2010 6:08 pm

rb192 kernel not found!!
make netinstall but now software ID change and my lience don't work..

Mon Feb 01, 2010 9:40 am

RouterBOARD SoftID can't change. Did you reinstall using latest netinstall and latest RouterOS v4.5?

Write to support with your Serial number and new SoftID.

Mon Feb 01, 2010 3:38 pm

Testing 4.5 on clients on one segment.
AP: RB500/3.30 wireless-test with Omni R52/11a/20MHz
Mixed RB133C3 and RB411 no nstreme/RTS CTS.
Clients doing NAT, DHCP Server on internal,
DHCP client on external interface. All R52.
Removed all unneccesary packets.

Looks promising so far. I see RB133C running
smoother on 4.5 than on 3.30.

GREG3f · Fri Feb 05, 2010 2:34 pm

Normis says 3.30 test package = 4.x for Nstream

Are there new test packages with fixes ?

What's new in 4.5:
*) fixed Nstreme issues with bridged traffic

I have a bridged network and am running wireless test. It would be nice to have any Nstream fixes for my 3.30 boards.

Also getting most new RB411 with a 3.31 OS... is there a different wireless test package?

Fri Feb 05, 2010 2:37 pm

new test packages will be available with v5 beta, whenever that is going to be released

GREG3f · Fri Feb 05, 2010 4:16 pm

Then is it safe to say, the best practice is to run 3.30/3.31 without test package or run 4.5 or higher? Or is 3.30 OK to use with wireless test on a bridged network?

If so, what is the procedure to remove 3.30 test package from CPEs without loosing wireless configuration?

Mon Feb 08, 2010 8:17 am

Instead of doing that, I would recommend you to upgrade to v4.5. your settings will be kept.

vk7zms · Tue Feb 16, 2010 6:33 am

As with MANY previous posts on this and other threads, we are experience widespread and uncontrollable wireless disconnects since upgrading to ROS4.5. We have tried many things to rectify the situation, including resetting the wlan interfaces and reconfiguring etc. In some case increasing hw-retries setting improved situation, but overall the move to 4.5 has been disastrous for us.

Initially we upgraded some test links and found an AWESOME decrease in latency - very happy with that. after extensive testing of these links we rolled 4.5 out to about two thirds of or network (just over 300 MT devices). While a lot of links worked better (lower latency), others become unusable due to constant (10-20 second) disconnects.

There appears to be no set pattern - some are base station to cpe links where some of the clients connect as normal and some drop in and out constantly. others are back haul links that will stay up as long as the traffic load is low, and drop out whenever traffic builds up. I have tried to see if it was one particular hardware platform that was having the issue, but i appears to be happening across all router board devices we have installed (RB600, 600A, 532, 532a, 411, 411a, 411r, 133, 133a, 112 and x86).

Dual nstreme links are also now experiencing high levels of drop outs to the extent that most of our main production backhauls are unusable. fortunately we have plenty of redundant links and only a few customers are offline completely. almost ALL however are on a reduced service.

Following this thread, i see constant reference from mt support saying that 4.5 issues are isolated cases, this is most definitely NOT the case. it IS widespread among anything running ROS4.5

Anyone who has any other fixes other than increasing hw-retries, or resetting the wlan interfaces, I would be very grateful to hear from you

Kind Regards Murray Suthwell

Tue Feb 16, 2010 9:23 am

If you have followed the forum threads, as you say, then you will see that all issues were solved with wireless settings reset and hw-retries increase

npero · Tue Feb 16, 2010 9:47 am

I upgrade two of my Mikrotik box from 3.30 to 4.5 with couple nstreme links.

One link have constantly disconnect data lost change hardware retries and now working better that 3.30 more stable better uptime, but other link with nstreme has been perfectly stable in 3.30 uptime on link usualy more that 20 day now disconnect every five to six hours with extensive data lost try to change hardware retries but not help.

On other box also have long link 25km with not very good signal upgrading to 4.5 chage hardware retires give much stable link with less extensive data lost but on some box link with very good signal and distance about 1km in 3.30 uptime more that 10 days now disconnected every day one or more time.

Other side on boot link are 3.30 aslo I will try to upgrade maybe help.

Seem to me longer link with nstreme work better in 4.5 and more stable that 3.30 but shorter disconnect.Also on all link I have little better result in UDP bandwidth test.

I don't try to reset interfaces for now.

Any idea what I can do with this before very stable link and how disconnect couple time of day ?

Tue Feb 16, 2010 9:48 am

To help you more specifically we would need to see your supout.rif file. Make the file at the time when disconnect recently happened.

npero · Tue Feb 16, 2010 9:54 am

Disconnected happen couple time of day don't have any particular rule, strange thing is longer link where I disconnect every couple days how working much stable but shorter have this problem before upgrade on one shorter link have up time 30 days.

Now I creating supout.rif from both upgraded box and send to you maybe help.

Tue Feb 16, 2010 10:01 am

vk7zms you talk about latency change. this is exactly what Hwframes change does in v4. We changed the Hwframes default setting to improve latency on good links, this however, affected not so good links, bringing more disconnects. In that case, you have to increase HWretries setting again

Summarize

on bad links:

v3.30 has high hwframes setting and has better stability but worse latency
v4.x has low hwframes setting and has better latency and worse stability

so change this setting according to your situation

vk7zms · Tue Feb 16, 2010 10:28 am

If you have followed the forum threads, as you say, then you will see that all issues were solved with wireless settings reset and hw-retries increase

Normis - if you had read my post, you would have seen that i HAVE TRIED THIS.

I have problematic links set to hw-retries=15. I have done the "reset to defaults" thing, but still have problems on lots of links (more than 20).

Tue Feb 16, 2010 10:30 am

and you say that those links were rock solid before upgrade? sounds impossible

phendry · Tue Feb 16, 2010 11:23 am

can you confirm if you are using NStreme on these links and if so what settings you're using? We had disco problem with exact size but moving to best-fit resulted in no disconnects.

vk7zms · Tue Feb 16, 2010 1:05 pm

Yes - we use Nstreme on all links (or dual nstreme). On our nstreme links we have been running with dynamic size and framer limit 3200

eivind · Tue Feb 16, 2010 10:40 pm

ROS 4.3 Problem?
Lost IP connection between RB411/433 and wlan interface on a clientantenna in use. This has happend on another antenna too.
wlan interface can be configured, but connecting the interface to an IP-address is not possible (station mode). The interface text under IP-Address settings "wlan1" is i coursive.
I tried a lot to find a solution with no luck (including upgrade to OS v. 4.5), and I finally downgraded OS to v. 3.30. Now it's working fine.

Is there someone else who have seen this and maybe have a solution within OS 4.5??

vk7zms · Tue Feb 16, 2010 11:01 pm

yes - had the same problem - but only once out of several hundred upgrades - after upgrade could not reach cpe via ip address or ping it from the base station - wireless re-associated, so just deleted the ip address and re-added it via mac-telnet and it all worked fine again.

vk7zms · Wed Feb 17, 2010 2:04 am

Rolled back a couple of links to 3.30 - now stable and working as normal

in process of rolling back ALL base stations to 3.30

4.5 has many nice features and I look forward to being able to install a stable 4.x version in the near future

missinlnk · Wed Feb 17, 2010 7:15 pm

If you have followed the forum threads, as you say, then you will see that all issues were solved with wireless settings reset and hw-retries increase
Normis - if you had read my post, you would have seen that i HAVE TRIED THIS.

I have problematic links set to hw-retries=15. I have done the "reset to defaults" thing, but still have problems on lots of links (more than 20).

Some of our customers have found that just setting the hw-retries back to 15 doesn't fix their problems. They actually had to custom pick a number for each link to get their links to stabilize at a good latency with minimal/no disconnects. So far that number has usually ended up around 7-10, but there is enough variance in setups and environments that it could be just about anywhere in-between 4 and 15.

You should be able to make rough adjustments (try 7 and then 10 or 11) to get close. In those two numbers you should find a setting that gets you closer to a good link. At that point you can try adjusting up or down 1 to find the best number.

Scott

vk7zms · Wed Feb 17, 2010 11:45 pm

Thanks for the reply Scott - but there must be something other than hw-reties that affects link stability in 4.5. A lot of the links were so unstable it was impossible to connect to CPE and make any changes. I had technicians at several of our bigger customers changing settings while I changed the base station settings. We tried everything we could find on the forums before making first post - hence my frustration at being to "change hw-retries settings and it will be fixed" (especially after I detailed that we had done this in my first post).

We have rolled all base stations back to 3.30 - finished doing this about six hours ago, and haven't had a single customer on the phone with a problem since.

I was VERY impressed with the reduced latency on some links and really want to re-install it as soon as the stability issue is resolved - even if this turns out to be a configuration issue (other than hw-retries and resetting card settings).

The other reason we had to roll back is many links were not stable enough to connect and upload a script to the CPE to reset the wlan settings and turn the card back on after reset etc, so a site visit to each customer would have been needed. Hopefully this need to reset wlans to defaults will be addressed in the next version of ROS so it is possible to upgrade without taking customers off air for extended periods of time.

SapieH · Thu Feb 18, 2010 9:40 am

Hi phendry

We have done some tests using 5GHz-only-N. As far as I know you can not use N-streme in conjunction with -only-N.
Up to 8km link we have reletevely stabe performence using R52N both ends. We then set up a 29km link and experienced exactly the same problem as you describe. As soon as you load the link the quality deteriorates and the link collapses.
What is interestesting is that we are also testing a Ubiquity rocket on a 22km link which also uses N protocol and have had stunning results - 95Mbps throughput, full duplex and quality is excelent.

Ofcourse we had to put rb433 on eather end to do the testing as Ubiquity's setup and features suck! Oh how i wish Mikrotik could deliver this performance as I want to stick to Mikrotik only on my network.

rpingar · Thu Feb 18, 2010 9:44 am

our experience about 4.5 and Nstreme is a better performace at a cost of some random disconnects aof the links.
The disconnects of the ptp links with signal at -60 happen also with HWreties at 15

Links that before running stable for more then 365days (also with wireless-test and 3.x) now have random disconnects daily.

the disconenct reason is "extensive data loss".

Regards
Ros

vk7zms · Thu Feb 18, 2010 1:38 pm

We have many Nstreme links installed, that are run with actual traffic and actual users. We don't have such problems, and nor does the majority of RouterOS users. We have no real support requests at this time. If you have issues, please make a proper support request, with as much details as you can give us, and we will try to replicate the problem, and solve it.

How many more users need to post with the same symptoms before someone from MT acknowledges there is actually a problem?

Thu Feb 18, 2010 1:40 pm

When will you finally email support

? Or are you afraid of something ?

vk7zms · Fri Feb 19, 2010 12:34 am

When will you finally email support ? Or are you afraid of something ?

please see copy of email sent to support@mikrotik.com.au 16/2/2010 bellow - still no reply - not even a ticket number.

when I send an email to support@mikrotik.com.au with a license key issue, Sergejs replies promptly. Perhaps you are just ignoring 4.5 disconnect requests so you can protend it is not an issue ???

Hi, Since upgrading some of our devices to ROS 4.5 we have experienced high levels of link failures across our network

symptoms are

1-frequent disconnects (staying connected for less than 20 seconds before dropout)
2-link drops as soon as data is passed across it (even significant ping stream)

please find attached a suppout.rif from one of our base stations - the most problematic link on this base station is from wlan4-howrah-SR5. There is only one cpe connected to this interface, so I have chosen it as an example of our problems.

as per suggestions on the forums I have reset configurations on wlan interfaces at the base station and cpe and reconfigured.

I have tried a number of different hw-retries settings

I have tried using different bands 5Ghz, 5Ghz-10mhz, 5Ghz-5mhz

I have tried with nstreme on and off

Your assistance would be greatly appreciated

fewi · Fri Feb 19, 2010 12:49 am

Just to check - mikrotik.com.au as you say in your post, or mikrotik.com? mikrotik.com.au exists but is a distributor, and not Mikrotik itself.

vk7zms · Fri Feb 19, 2010 1:36 am

my bad - added the .au as I typed it in this morning - very tired from working all night rolling back to 3.30

checked sent email - properties below

From: "Murray Southwell" <murray@staff.tasmanet.com.au>
To: "MikroTik Support [Maris]" <support@mikrotik.com>
Cc: "Joel Harris - Tasmanet" <joel@tasmanet.com.au>
Subject: wireless disconnects
Date: Tue, 16 Feb 2010 14:42:04 +1100
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0028_01CAAF16.351A5560"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049

Fri Feb 19, 2010 9:24 am

That mail was answered 3 days ago, check your email filters

vk7zms · Sat Feb 20, 2010 1:30 pm

That mail was answered 3 days ago, check your email filters

sounds impossible - i received other email from support@mikrotik.com - just nothing in relation to this issue - not even a ticket number. perhaps you would be so good as to post it here?

Xymox · Sun Feb 21, 2010 1:10 pm

minor issue..

If you disable Discovery Interfaces, they reactivate on reboot. You also cannot remove them "Not Implemented"..

In short there is no way to disable this and have it stay disabled.

vk7zms · Tue Feb 23, 2010 6:27 am

That mail was answered 3 days ago, check your email filters

sounds impossible - i received other email from support@mikrotik.com - just nothing in relation to this issue - not even a ticket number. perhaps you would be so good as to post it here?

Bump - still waiting Normis

Tue Feb 23, 2010 8:04 am

last mail to MikroTik from you is:

Hi Sergejs - serial number is 206D01FD177C

Software ID is ZF9H-ZCV2

Kind Regards, Murray Southwell

and Sergejs immediately replied:

Hello Murray,

There is no any information on our account server for CF purchase ZF9H-ZCV2.
Do you have an e-mail or invoice about the license purchase?

Regards,
Sergejs

there has been no further email from you

previously, to your other ticket, there was also an immediate reply:

Created:
02/16/2010 16:06:09
Hello,

Increase the hw-retries count for that wireless card.
Try to set the nstreme framer-policy to none.
check the log file form the client device what is says when it disconnects.

Regards,
Uldis

you have also not replied to this email.

there are no unreplied emails from you

vk7zms · Tue Feb 23, 2010 8:18 am

That mail was answered 3 days ago, check your email filters

Interesting how you can claim to have answered my email 3 days ago, and now you can't find it.......

I will forward another copy of the original to support

Tue Feb 23, 2010 8:21 am

I just posted the mails above, you can't even see those ????

Tue Feb 23, 2010 8:27 am

AGAIN:

From:
"MikroTik Support [Uldis]" <support@mikrotik.com>
To:
"Murray Southwell" <murray@staff.tasmanet.com.au>
Cc:
"Joel Harris - Tasmanet" <joel@tasmanet.com.au>
Subject:
Re: [Ticket#2010021666000093] wireless disconnects
Created:
02/16/2010 16:06:09
Hello,

Increase the hw-retries count for that wireless card.
Try to set the nstreme framer-policy to none.
check the log file form the client device what is says when it disconnects.

Regards,
Uldis

pikpik · Tue Feb 23, 2010 1:52 pm

NSTREME:

status: connected-to-ess
band: 5ghz-11n
frequency: 5600MHz
tx-rate: "78.0Mbps-HT"
rx-rate: "65.0Mbps-HT"
ssid: "router-lv"
bssid: 00:1D:0F:XX:XX:XX
radio-name: "001D0FXXXXXX"
signal-strength: -48dBm tx-signal-strength: -50dBm

rx-ccq: 43%
p-throughput: 64789
overall-tx-ccq: 90%
authenticated-clients: 1
wds-link: no
nstreme: yes
polling: yes
csma-disabled: no
framing-mode: none
routeros-version: "4.5"
last-ip: 192.168.1.220
802.1x-port-enabled: yes
compression: no
wmm-enabled: yes
current-tx-powers: 6Mbps:17(17/20),9Mbps:17(17/20),12Mbps:17(17/20),18Mbps:17(17/20),24Mbps:17(17/20),36Mbps:17(17/20),48Mbps:17(17/20),54Mbps:17(17/20),HT20-0:17(17/20),
HT20-1:17(17/20),HT20-2:17(17/20),HT20-3:17(17/20),HT20-4:17(17/20),HT20-5:17(17/20),HT20-6:17(17/20),HT20-7:17(17/20),HT40-0:17(17/20),HT40-1:17(17/20),
HT40-2:17(17/20),HT40-3:17(17/20),HT40-4:17(17/20),HT40-5:17(17/20),HT40-6:17(17/20),HT40-7:17(17/20)
notify-external-fdb: no

without:

status: connected-to-ess
band: 5ghz-11n
frequency: 5600MHz
tx-rate: "270.0Mbps-HT"
rx-rate: "270.0Mbps-HT"
ssid: "router-lv"
bssid: 00:1D:0F:BB:8C:66
radio-name: "001D0FBB8C66"
signal-strength: -51dBm
tx-signal-strength: -54dBm
noise-floor: -114dBm
signal-to-noise: 63dB
tx-ccq: 99%
rx-ccq: 97%
p-throughput: 149425
overall-tx-ccq: 99%
authenticated-clients: 1
current-ack-timeout: 30
wds-link: no
nstreme: no
framing-mode: none
routeros-version: "4.5"
last-ip: 192.168.1.220
802.1x-port-enabled: yes
compression: no
wmm-enabled: yes
current-tx-powers: 6Mbps:17(17/20),9Mbps:17(17/20),12Mbps:17(17/20),18Mbps:17(17/20),24Mbps:17(17/20),36Mbps:17(17/20),48Mbps:17(17/20),54Mbps:17(17/20),HT20-0:17(17/20),
HT20-1:17(17/20),HT20-2:17(17/20),HT20-3:17(17/20),HT20-4:17(17/20),HT20-5:17(17/20),HT20-6:17(17/20),HT20-7:17(17/20),HT40-0:17(17/20),HT40-1:17(17/20),
HT40-2:17(17/20),HT40-3:17(17/20),HT40-4:17(17/20),HT40-5:17(17/20),HT40-6:17(17/20),HT40-7:17(17/20)
notify-external-fdb: no

config (2 sites the same):

name="to_kosciol" mtu=1500 mac-address=00:1D:0F:XX:XX:XX arp=enabled disable-running-check=no interface-type=Atheros 11N radio-name="001D0FXXXXXX" mode=station
ssid="router-lv" area="" frequency-mode=manual-txpower country=poland antenna-gain=0 frequency=5600 band=5ghz-onlyn scan-list=default rate-set=configured
supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps supported-rates-a/g=6Mbps,54Mbps basic-rates-b=1Mbps basic-rates-a/g=54Mbps max-station-count=2007 ack-timeout=dynamic
tx-power=17 tx-power-mode=all-rates-fixed periodic-calibration=disabled periodic-calibration-interval=60 dfs-mode=none wds-mode=disabled wds-default-bridge=none
wds-default-cost=100 wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0
default-client-tx-limit=0 proprietary-extensions=post-2.9.25 wmm-support=disabled hide-ssid=no security-profile=default disconnect-timeout=3s on-fail-retry-time=100ms
preamble-mode=short compression=no allow-sharedkey=no station-bridge-clone-mac=00:00:00:00:00:00 ht-ampdu-priorities=0,1,2,3,4,5,6,7 ht-guard-interval=long
ht-extension-channel=below-control ht-supported-mcs=mcs-0,mcs-7,mcs-10,mcs-11,mcs-12,mcs-13,mcs-14,mcs-15 ht-basic-mcs=mcs-0 ht-txchains=0,1 ht-rxchains=0,1
ht-amsdu-limit=8192 ht-amsdu-threshold=8192 hw-retries=15 frame-lifetime=0 adaptive-noise-immunity=client-mode hw-fragmentation-threshold=disabled hw-protection-mode=none
hw-protection-threshold=0

best-fit or none, same result

Alessio Garavano · Thu Apr 15, 2010 8:35 pm

Hi friend from australia... try "station-pseudobridge" rather than "station-wds"...

I upgrade a backbone with 10 RBs to 5.0b1 using bridge without rstp and putted this bridge like a port in a mesh interface and have the same issue... 20 seconds pings OK, 20 seconds timeouts... constantly... changing the radios in station-wds to station-pseudobridge the problem was solved...

Good luck and regards!

alldine · Tue Nov 16, 2010 10:33 pm

i have the same problem with several links even after upgrade to 4.11 and 4.13 from 3.30 throughput between 44000 & 52000 ccq tx/rx 94 to 100 % every few howers disconnected with encryption or without , changing Hw.retries ,disconnect timeout, on fail retry time can work for 12 h or 18 h no problem or disconnect after 6 h no standards for