RouterOS version 6.49.18 has been released in the "v6 stable" channel!

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 6.49.18 (2025-Feb-05 12:13):

*) console - updated copyright notice;
*) fetch - improved system stability when using TFTP;
*) hotspot - properly escape all reserved URI characters;
*) radius - added "require-message-auth" option that requires "Message-Authenticator" in received Access-Accept/Challenge/Reject messages;
*) radius - include "Message-Authenticator" in any RADIUS communication messages besides accounting for all services;
*) system - added "shutdown" parameter for reset-configuration (CLI only);
*) system - fixed false log message about successful package installation;
*) system - fixed v6 to v7 upgrade from separate packages;
*) system - improved system stability;
*) system - set flash-boot mode as "boot-device" after system reset initiated by reset button ("/system routerboard upgrade" required);
*) system - set flash-boot mode as "boot-device" after system reset initiated from software;
*) user - improved authentication procedure when RADIUS is not used;
*) wireless - allow to set Canada2 country profile when locked with US lock package for CubeG device;
*) wireless - fixed antenna gain for SXT5ac device;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while a router is not working as suspected or after some problem has appeared on the device

Please keep this forum topic strictly related to this particular RouterOS release.

Nice with a 6.x update, but why is it not Long Term?
Latest Long Term 6.49.13 released 5 May 2024, and no Long Term for 7.x

I am not sure how to explain this mix of Stable and Long Term:

*) system - improved system stability;

Hey @normis and @EdPa, I bet no customer of MikroTik would be upset if you assume some compromise in bringing minimal references of what is being done on release notes.

Hey @EdPa... I'm here to make the same request I made in the v7.17 thread.
If you could provide a little more detail on what kind of improvements, I believe users will be less concerned.

why is it not Long Term?

Maybe a good idea would be if they waited about 3 weeks, and if no monstrous bugs appeared, then they could define that this same version 6.49.18, in addition to being Stable, will also become Long-Term.
As a sign of v6's end-of-life.

Thank You MikroTik Team - that you are working on 6.x ROS version. It's very important to have support for older RouterBoards, and you do. Thank You.

Publishing a new version right away as long-term would beat the purpose of the long-term. As always - if a stable version is "okay", then after a while it is re-published as long-term.

As always - if a stable version is "okay", then after a while it is re-published as long-term.

How long is "after a while"? Last long-term is 6.49.13. Previous stable was 6.49.17, released on 2024-08-07 ... which is quite a bit longer than half a year ago. Are you saying that half a year is not long enough to assess whether 6.49.17 is fit to be long-term? Or are there some bugs in it which make it unsuitable for long-term? If so, can you highlight changelog entry (for 6.49.18) which fixes the "show stopping bug"? (my impression when reading 6.49.18 change log is that only entry, which might excuse the whole ordeal, is *) system - improved system stability; ... which, as quite often with changelog entries, doesn't tell anything in particular).

And it seems that you're saying that none of versions 6.49.14-6.49.17 brought enough of improvement to replace 6.49.13 as longterm version. Me, reading changelogs, can find quite a few entries which warrant replacing 6.49.13 with newer as longterm:
6.49.14: *) smb - improved service stability when receiving bogus packets;
6.49.15: *) system - improved system stability for RBSXTsq5nD;
6.49.17: *) system - fixed an issue with duplicated package list when upgrading from separated to bundled package;
6.49.17: *) system - improved system stability for RBLDF-5nD;

Publishing a new version right away as long-term would beat the purpose of the long-term. As always - if a stable version is "okay", then after a while it is re-published as long-term.

That's because "long term" is meant to refer to an update channel rather than an individual version. Long term does not mean "old". A long term channel should be supported in the long term with bug and security fixes, but not introduce any new features. If you identify a critical issue in a long term version, you will of course release a new long time version asap. "Stable" is normally the default channel, which does get new features and, as the name implies, is stable thanks to sufficient testing. Mixing stable and long term is what defeats the purpose of having distribution channels.

Publishing a new version right away as long-term would beat the purpose of the long-term.

😍🙏🙇‍♂️

As always

In light of a history that I have been following for about 8 years (trying to understand MikroTik world, having come from hardware-based world), I say that using "as always", is pushing the limits of the interpretation of "always" a little.
But if the intention is good, I gladly accept it!

if a stable version is "okay", then after a while it is re-published as long-term.

Please do this! The v6 widows need to understand that it is time to abandon the legacy.

Not having the entire possible mass of MikroTik customers and equipments operating on v7 reduces the volume of samples and the quality of issues to be reported to developers.
In addition to reducing the workforce on the current version, where the most senior guys probably need to be moved to look at the legacy.

I prefer to stay on version 6, where I don't need to report issues in the first place.

I prefer to stay on version 6, where I don't need to report issues in the first place.

This happens because you already know which features don't work, which scenarios will cause problems when used.

When certain types of problems appear you don't even try to solve them anymore because you are already sure that those problemas are due to limitations in the RouterOS software (but knowing is not the MikroTik hardware) and you know it's not worth trying again, opting to just stack another 1036 on the CCR breakwater.

Looking like a comforted widow who has already gone through denial, anger, bargaining, depression... and is now accepting it.

• No! Not supporting multiple types and ALGs, or NAT PMP is not normal!
• No! Not supporting hardware off-load when the silicon supports it is not normal!
• No! Not supporting basic features in IPv6, Radius, or even things like RPKI is not normal!

*) wireless - fixed antenna gain for SXT5ac device;

What does that exactly mean?

Upgarded one of our core-router, a CCR1072 and it got stuck in "rebooting" (LCD).
The only option was to go on-site, remove power, re-power and it booted up (after reboot still with the old version 6.49.17).

After another Upgrade-attempt, it rebooted normally and had 6.49.18. Another reboot (firmware) was uneventful too.
But still strange, never saw such a device stuck in "rebooting"... Not long-term for me!!

*) system - fixed v6 to v7 upgrade from separate packages;

HAP AC2

uptime: 1m35s
version: 6.49.13 (long-term)
build-time: Apr/04/2024 09:57:52
factory-software: 6.44
free-memory: 80.3MiB
total-memory: 128.0MiB
cpu: ARMv7
cpu-count: 4
cpu-frequency: 488MHz
cpu-load: 1%
free-hdd-space: 2660.0KiB
total-hdd-space: 15.3MiB
write-sect-since-reboot: 956
write-sect-total: 16613822
bad-blocks: 0%
architecture-name: arm
board-name: hAP ac^2
platform: MikroTik


Didnt work
insufficent space for upgrade
I had separate package installed.

Did you try netinstall

Did you try netinstall

No point in netinstalling when trying to verify the changelog entry quoted by @Maggiore81

The question is different: does uninstalling one of packages (and thus freeing a few 100kB) allow to upgrade or not?

I usually uninstall all the packages except dhcp/system/security and then I can upgrade to v7. But When I have the combined package, we have more or less the same free space, and the system will upgrade!

Another way is to remove almost all packages the put the combined v6 package. With that I can upgrade to v7 with no issues.

When I did have problem with upgrading 6.x devices due to space problem, I did find an older RouterOS that was smaller than the one I have currently running and downgraded to it. This gave me extra space and I was able to upgrade the device.