Link on download page to 6.22rc is not working.
Remove this link from page if there is no 6.22rc version

Link on download page to 6.22rc is not working.
Remove this link from page if there is no 6.22rc version

sorry, fixed

*) fixed queues - could have huge latencies and smaller throughput than specified;

Link on download page to 6.22rc is not working.
Remove this link from page if there is no 6.22rc version

sorry, fixed

please fix it also in mikrotik.com Account section - it says 'Currently there is no available development version!

What's new in 6.21.1 (2014-Nov-03 15:20):

*) fixed ugprading from v5;

What's new in 6.21 (2014-Oct-30 12:34):

*) userman - fix ~Your session has been reset due to inactivity~ error;
*) timezone - updated timezone information to 2014i release;
*) wireless - fixed scanning tool crash for 802.11ac interfaces
*) wireless - fixed Nv2 kernel panic on 802.11ac interfaces
*) quickset - added vpn configuration to Wifi AP %26 Ethernet modes as well;
*) lte - changed device identification for devices which regenerate MAC address,
most likely this will loose device's configuration;
*) sstp - fixed disconnects on high traffic load;
*) ovpn client - fixed problem where ip address was not added to bridge interface in ethernet mode;
*) webfig - show properly Switch Port configuration;
*) disks - fixed support for MMC/SD cards;
*) winbox - added filtering by dscp to torch;
*) certificate - fix CRL handling in trust chain;
*) fixed 6to4 tunnels having inactive routes;
*) ipsec - fix downgrade problem to v5;
*) ipsec - disallow template-policy-group=none in peer config and set it to 'default';
*) metarouter - some metaroutes didn't have their licenses;
*) torch - possibility to filter by dscp;
*) fixed - master port on AR8327 switches that is put into bridge could sometimes not work properly;
*) fixed queues - could have huge latencies and smaller throughput than specified;
*) interfaces report last link up/down time and link down count;

Click "Check for updates" in QuickSet or Packages menu to get the new version. This time, it should also work for v5 routers, please report if your device found the new release and how the update went.

Where can you see this interfaces report last link up/down time and link down count?

This is crazy...

MT I would rather wait months for updates if you guys would test them properly!

If you need BETA testing, make a different BETA branch for the firmware!

This is crazy...

MT I would rather wait months for updates if you guys would test them properly!

If you need BETA testing, make a different BETA branch for the firmware!

This is crazy...

MT I would rather wait months for updates if you guys would test them properly!

If you need BETA testing, make a different BETA branch for the firmware!

Hey guys, let's have a simple reality check for a moment.

If you download/upgrade any new ROS and deploy it...You essentially become the "Beta" tester, eh?

So far, I don't believe that MikroTik is requiring anyone to upgrade to a newer version of the software. So if the current version is working, then probably you should leave it alone.
If you want to experiment with newer versions, that's ok but then you do it at your own risk.
Since MikroTik doesn't charge for the software, you might conclude that it is worth ever penny you paid for it.. But there are other opinions that might differ at bit.

Rule of thumb should be, to only test new ROS software on a non-essential network and give it enough time to reveal any problems. If someone deploys it on a active network, well then, you have to accept the risks.

-tp

This is an automated reply that will help you to get fastest
possible solution or reply from our support department.

Make sure you have:
1) attempted to re-set your configuration and started from the beginning, following steps in the documentation
2) the latest RouterOS version installed on the router
http://www.mikrotik.com/download.html
3) attached the supout.rif file from the router in question
http://wiki.mikrotik.com/wiki/Manual:Su ... utput_File
4) included a precise description of the problem - use network diagrams, screenshots, videos if necessary

If something from above is incomplete in your current email, please, send all additional information as a reply to this email.

This is crazy...
MT I would rather wait months for updates if you guys would test them properly!
If you need BETA testing, make a different BETA branch for the firmware!

/tool user-manager database set db-path=/user-manager1
/tool user-manager database rebuild

What's new in 6.21.1 (2014-Nov-03 15:20):

*) certificate - fix CRL handling in trust chain;

What's new in 6.21.1 (2014-Nov-03 15:20):


What's new in 6.21 (2014-Oct-30 12:34):



*) wireless - fixed Nv2 kernel panic on 802.11ac interfaces

SSTP and PPTP clients are not working! If I would update a remote router connected to my central router by VPN, I would lost it. Downgrade to 6.20 solved the problem.

Almost each update is causing some troubles. I agree - it is crazy.

lte - changed device identification for devices which regenerate MAC address,
most likely this will loose device's configuration;

more detailes please

Warning!

I just upgrade two CCR1036 to 6.21.1 from v6.20 and lost access to routers. They keep rebooting at each couple of seconds and never go back.
Only netinstall could solve the problem (after hours with consumer complaints).
You guys do not testing before releasing to the public?
Email to support is on the way.

PS: No problem on ppc and mipsbe.
Edit: There is one bonding interface one each router.

Hi Guys !

Bug the Netmetal922 AC Device on ros6.19 and 6.20 ! fw3.17

I change the wireless interface protocol mode to nv2 the device power led dont work anymore(interface settings change to default, and reboot the device, working fine the power led again). The power led work fine if boot the device, if booted the ros not work.

Regards
Krisztian

Warning!

I just upgrade RB2011UAS-2HnD to 6.21.1 from v6.19 and my router CPU used 100%.
and I turn off all ether Port(ether3 Port is Console) but, Nothing had changed.

I sent a rif file to the mikrotik support email and I waiting for a reply.
Please do sufficient test, before the release.

Where can you see this interfaces report last link up/down time and link down count?

in Terminal, '/interface print detail'

These releases and more specifically, releases full of bugs are seriously becoming rather tiresome right about now...

Warning!

I just upgrade RB2011UAS-2HnD to 6.21.1 from v6.19 and my router CPU used 100%.
and I turn off all ether Port(ether3 Port is Console) but, Nothing had changed.

I sent a rif file to the mikrotik support email and I waiting for a reply.
Please do sufficient test, before the release.

Same issue here on a 750GL, DNS maxes cpu , DNS tab shows no DNS servers defined. Everything was fine after reboot, DNS servers showed back again.

These releases and more specifically, releases full of bugs are seriously becoming rather tiresome right about now...

The bios version from the affected CCR's was 3.18. After upgrade to 3.19 I did a reinstall to 6.21.1 at top from 6.20 using the same configuration and there are no problems right now. Looks like v6.21.1 don't play well with bios 3.18.
But the Mikrotik team should not have tested it? I have open tickets for another bugs too.
Looks like the best approach is maintain a lab to test the new versions, even the "stable" ones.

After doing a download from the Web UI and upgrade and reboot, surprised to find no DHCP items on the IP menu in winbox UI or anywhere else as far as I can tell. Still working through the Terminal as AFAK, but I think I'll back down to 6.20 for now.

Michael

Warning!

I just upgrade RB2011UAS-2HnD to 6.21.1 from v6.19 and my router CPU used 100%.
and I turn off all ether Port(ether3 Port is Console) but, Nothing had changed.

I sent a rif file to the mikrotik support email and I waiting for a reply.
Please do sufficient test, before the release.

Same issue here on a 750GL, DNS maxes cpu , DNS tab shows no DNS servers defined. Everything was fine after reboot, DNS servers showed back again.

Still cannot go lower than 6dB TX Power on RB922UAGS-5HPacD so have to stay on 6.19 where it is possible to go to 0. Will you guys fix it? Or nobody else having the problem?

Because you can't use FQDN with main mode. You need aggressive mode.

We have tested CCR routers in many combinations of RouterOS and firmware. We have not noticed any issues in this particular combination of OS/firmware. Please contact our support department with clear description of what the problem was and send supout files from your devices which were affected by this combination. We will gladly take a look if your specific configuration might cause some problems.

in Terminal, '/interface print detail'

I can not see any details regarding report last link up/down time and link down count when i try to go by terminal with /interface print.
Is there something else to do?

[admin@router] > interface print detail where name=sfp1
Flags: D - dynamic, X - disabled, R - running, S - slave 
 0  R  name="sfp1" default-name="sfp1" type="ether" mtu=1500 actual-mtu=1500 
       l2mtu=1590 max-l2mtu=10226 mac-address=00:00:00:00:00:01 fast-path=yes 
       last-link-up-time=nov/05/2014 13:12:29 link-downs=0 
[admin@router] > 

Also downgrading downgrading does not work. Device just reeboting but after still have ros 2.21.1

Also downgrading downgrading does not work. Device just reeboting but after still have ros 2.21.1

and what's in Log? what exactly you do to downgrade?

*) fixed 6to4 tunnels having inactive routes;

ros code

/interface 6to4
add local-address=213.211.xx.xx mtu=1480 name=6to4
/ipv6 address
add address=2002:d5d3:xxxx::1/16 advertise=no interface=6to4
add address=2002:d5d3:xxxx:80::1 interface=internal
/ipv6 route
add distance=1 dst-address=2000::/3 gateway=::192.88.99.1%6to4

ros code

0   S  dst-address=2000::/3 gateway=::192.88.99.1%6to4 
        gateway-status=::192.88.99.1%6to4 unreachable distance=1 scope=30 
        target-scope=10 

 1 ADC  dst-address=2002::/16 gateway=6to4 gateway-status=6to4 unreachable 
        distance=0 scope=10 

 2 ADC  dst-address=2002:d5d3:xxxx:80::/64 gateway=internal
        gateway-status=internal reachable distance=0 scope=10

Still cannot go lower than 6dB TX Power on RB922UAGS-5HPacD so have to stay on 6.19 where it is possible to go to 0. Will you guys fix it? Or nobody else having the problem?

In older RouterOS version the the 6db tx-power offset was not taken into the account. This problem is now fixed in latest RouterOS releases where it uses the correct tx-power value. Since the offset is 6db you can't get lower as you can't specify in the cards eeprom lower value than 0.

On my RB1100AHx2 I got 40-60% unclassified CPU usage after upgrade (in idle).
Downgrade to 6.20 brings it down to 0 - 0.2%.

On other single core Atheros based boards, everything seems fine (750GL, 951G, Omnitik, CRS-125).

CCR1009-8G-1S-1S+
firmware 3.13

After uprade to 6.21.1 reboots several times during the day without any messeges in log`s

Great release guys. Are you even tried to test this befor releasing?

So does that mean with 6dB tx power the real output is also 6dB? If yes the maximum antenna gain connected legally to this device could only be 24dB in my country where 1W EIRP (30dBm) is allowed? Or what does this offset really mean?

And is this valid only for AC boards or also older N boards?

Thanks

Profiler permanently shows 'DNS' CPU usage over 80% and DNS resolver stops resolving after few hours.

So does that mean with 6dB tx power the real output is also 6dB? If yes the maximum antenna gain connected legally to this device could only be 24dB in my country where 1W EIRP (30dBm) is allowed? Or what does this offset really mean?

And is this valid only for AC boards or also older N boards?

Thanks

my measurement says that the real card output is about 2.0-2.5dBm on each connector when set to 6dBm (ROS 6.20). The offset is only for new wireless chipsets I think.

On my RB1100AHx2 I got 40-60% unclassified CPU usage after upgrade (in idle).
Downgrade to 6.20 brings it down to 0 - 0.2%.

Warning!

I just upgrade RB2011UAS-2HnD to 6.21.1 from v6.19 and my router CPU used 100%.
and I turn off all ether Port(ether3 Port is Console) but, Nothing had changed.

I sent a rif file to the mikrotik support email and I waiting for a reply.
Please do sufficient test, before the release.

I upgraded our routers (all either 6.19 or 6.20).. worked fine but 3/4 of our omnitiks lost their wireless card configuration. When booting the wlan1 is gone and wlan2 now apears (there's only 1 wireless card in an omnitik) but is disabled and set to defaults. I restored from backup's but this is the only glitch I've had in 5 years of upgrading routerboards. My advice is if you are upgrading an omnitik, backup your wireless config and check anywhere (routing, IP's, etc) where the interface is listed.

On my RB1100AHx2 I got 40-60% unclassified CPU usage after upgrade (in idle).
Downgrade to 6.20 brings it down to 0 - 0.2%.

I have same problem with 6.21.1 and RB2011UAS-2HnD.
After reboot all is ok, but after few hours unclassified CPU usage increases to 100% and performance of the router decreasing with packet loss.

Hey guys, let's have a simple reality check for a moment.

If you download/upgrade any new ROS and deploy it...You essentially become the "Beta" tester, eh?

So far, I don't believe that MikroTik is requiring anyone to upgrade to a newer version of the software. So if the current version is working, then probably you should leave it alone.
If you want to experiment with newer versions, that's ok but then you do it at your own risk.
Since MikroTik doesn't charge for the software, you might conclude that it is worth ever penny you paid for it.. But there are other opinions that might differ at bit.

Rule of thumb should be, to only test new ROS software on a non-essential network and give it enough time to reveal any problems. If someone deploys it on a active network, well then, you have to accept the risks.

-tp

Actually MT should only allow new releases with permanent version number ready in their download (for auto upgrade) section when they are approved by many clients and at least are around for a month or so. Any other version, no matter how good they think it is, should be not considered to be 'definite and final stable version' before its really proven in 99% of the cases it works.....

Since version 6.21.1 I get random reboots with my RB1100AHx2. Had to downgrade to 6.20 again.

Since version 6.21.1 I get random reboots with my RB1100AHx2. Had to downgrade to 6.20 again.

Same here. Mikrotik staff must be surprised again.

Our RB 1100 AHX2 hangs completly after 4 or 5 days
Dont't install 6.21.1

This forum also has automatic translation, see the button in bottom right corner.

This forum also has automatic translation, see the button in bottom right corner.

Только в одну сторону, а загружать вас мелкими проблемами нехотелось бы, да и диву дашь, когда видишь перевод написанного, технический язык - сложнее перевести автопереводчику, поэтому и предлагаю подфорумы языковые.

I realize this is off topic... But Normis, please hear my thoughts.

This is crazy with the bugs being introduced. I too am experiencing random reboots on 1100 hardware, as well as CCR. No "custom" scripting or complicated configurations. No userman, no hotspot, etc.

I don't have the time/ability to make supout files and send them and track progress etc.
-- I AM NOT A BETA TESTER --

There is a serious problem with your release methods for new firmware, and it needs to be addressed/organized better.

Right now it feels like your developers are guessing trying to patch bugs and release firmware in a hurry, and thus introducing more/bigger bugs. There needs to be a proper Alpha, Beta, Stable firmware flow, and right now there isn't.

My advice
====================
1) Introduce a PROPER firmware flow. ALPHA = v7 BETA = v6 STABLE =v5
2) Make ALPHA/BETA the same as Ubnt does. Only certain people who have accepted/approved can access the BETA files. Everyone else only sees STABLE.
3) NOTHING gets released to STABLE until completely cleared for at least a couple months.

This is a normal flow for any software company (That knows what they are doing anyway).
However Mikrotik has introduced one BIG FATAL mistake that breaks this...
-- You have produced hardware, that depends on BETA firmware!! -- (CCR, CRS, some 2011, etc that NEED v6)
THIS IS A BIG BIG BIG NO NO NO NO NO!!!!!!!!!!!!!

I don't want CCR in my hands when it can only run BETA firmware!
I don't want CRS in my hands when it can only run BETA firmware!

I want you to MARK your new firmware as BETA, so people understand the most recent is NOT THE BEST!
I want you to STOP producing new hardware that requires BETA firmware to operate! Make it work on the STABLE firmware first, or don't produce/release it!
This was your absolute biggest mistake. v5 was stable, and is stable, and works nearly flawlessly for what it promises, but I can't run it on everything, otherwise I WOULD!

This is very frustrating Normis, Mikrotik is the only company that does software development that I have ever seen work in such a backwards fashion. Again, even Ubnt can get this right. (And that is not a nice thing to say, because they can't get a lot of things right)

when you have such a situation, make supout.rif, then downgrade. shouldn't take more than 30 seconds to make the file.

when you have such a situation, make supout.rif, then downgrade. shouldn't take more than 30 seconds to make the file.

please, has at least one of you contacted support about this? we can't fix it, if we can't see the problem

I realize this is off topic... But Normis, please hear my thoughts.

This is crazy with the bugs being introduced. I too am experiencing random reboots on 1100 hardware, as well as CCR. No "custom" scripting or complicated configurations. No userman, no hotspot, etc.

I don't have the time/ability to make supout files and send them and track progress etc.
-- I AM NOT A BETA TESTER --

There is a serious problem with your release methods for new firmware, and it needs to be addressed/organized better.

Right now it feels like your developers are guessing trying to patch bugs and release firmware in a hurry, and thus introducing more/bigger bugs. There needs to be a proper Alpha, Beta, Stable firmware flow, and right now there isn't.

My advice
====================
1) Introduce a PROPER firmware flow. ALPHA = v7 BETA = v6 STABLE =v5
2) Make ALPHA/BETA the same as Ubnt does. Only certain people who have accepted/approved can access the BETA files. Everyone else only sees STABLE.
3) NOTHING gets released to STABLE until completely cleared for at least a couple months.

This is a normal flow for any software company (That knows what they are doing anyway).
However Mikrotik has introduced one BIG FATAL mistake that breaks this...
-- You have produced hardware, that depends on BETA firmware!! -- (CCR, CRS, some 2011, etc that NEED v6)
THIS IS A BIG BIG BIG NO NO NO NO NO!!!!!!!!!!!!!

I don't want CCR in my hands when it can only run BETA firmware!
I don't want CRS in my hands when it can only run BETA firmware!

I want you to MARK your new firmware as BETA, so people understand the most recent is NOT THE BEST!
I want you to STOP producing new hardware that requires BETA firmware to operate! Make it work on the STABLE firmware first, or don't produce/release it!
This was your absolute biggest mistake. v5 was stable, and is stable, and works nearly flawlessly for what it promises, but I can't run it on everything, otherwise I WOULD!

This is very frustrating Normis, Mikrotik is the only company that does software development that I have ever seen work in such a backwards fashion. Again, even Ubnt can get this right. (And that is not a nice thing to say, because they can't get a lot of things right)

I realize this is off topic... But Normis, please hear my thoughts.

This is crazy with the bugs being introduced. I too am experiencing random reboots on 1100 hardware, as well as CCR. No "custom" scripting or complicated configurations. No userman, no hotspot, etc.

I don't have the time/ability to make supout files and send them and track progress etc.
-- I AM NOT A BETA TESTER --

There is a serious problem with your release methods for new firmware, and it needs to be addressed/organized better.

Right now it feels like your developers are guessing trying to patch bugs and release firmware in a hurry, and thus introducing more/bigger bugs. There needs to be a proper Alpha, Beta, Stable firmware flow, and right now there isn't.

My advice
====================
1) Introduce a PROPER firmware flow. ALPHA = v7 BETA = v6 STABLE =v5
2) Make ALPHA/BETA the same as Ubnt does. Only certain people who have accepted/approved can access the BETA files. Everyone else only sees STABLE.
3) NOTHING gets released to STABLE until completely cleared for at least a couple months.

This is a normal flow for any software company (That knows what they are doing anyway).
However Mikrotik has introduced one BIG FATAL mistake that breaks this...
-- You have produced hardware, that depends on BETA firmware!! -- (CCR, CRS, some 2011, etc that NEED v6)
THIS IS A BIG BIG BIG NO NO NO NO NO!!!!!!!!!!!!!

I don't want CCR in my hands when it can only run BETA firmware!
I don't want CRS in my hands when it can only run BETA firmware!

I want you to MARK your new firmware as BETA, so people understand the most recent is NOT THE BEST!
I want you to STOP producing new hardware that requires BETA firmware to operate! Make it work on the STABLE firmware first, or don't produce/release it!
This was your absolute biggest mistake. v5 was stable, and is stable, and works nearly flawlessly for what it promises, but I can't run it on everything, otherwise I WOULD!

This is very frustrating Normis, Mikrotik is the only company that does software development that I have ever seen work in such a backwards fashion. Again, even Ubnt can get this right. (And that is not a nice thing to say, because they can't get a lot of things right)

+1
Agreed 100%.

Normis?

Clearly you can see I'm not the only one who thinks this.

There is a real problem that needs to be solved with MT's methods of releasing firmware.

MT also needs to absolutely STOP releasing hardware that is dependent on BETA level firmware (v6 is BETA, don't even try calling it stable). This really screwed a lot of users! If I could run my CCR on v5, I would gladly do it.

People in our market need our products to WORK without stopping. Performance is "nice" but not the major issue. When the routers are rebooting and jamming etc... They are one thing = GARBAGE!

I have worked with many vendors, as well as software developers. I have *NEVER* seen such an unorganized disaster as Mikrotik's firmware methods. You guys need to clean up your procedures, and have proper ALPHA/BETA/STABLE groups. This way the people who want to play with BETA can do it and are aware of it, and the ones who want to use stable can stick with stable and not worry.

Right now you don't even have stable (6 is not stable, please never never call it stable, it is not stable. It is untested guessing.).

6 needs to be frozen feature-wise, and stabilized. Nothing else added or changed. Make your NV2 changes and improvements etc on v7 or something else.

Sorry I am just echoing the same thing I said before, but it is simple common sense, and I don't understand why Mikrotik can't see the current system is unacceptable.

please, has at least one of you contacted support about this? we can't fix it, if we can't see the problem