RouterOS version 6.49.18 has been promoted to long-term.
Before an upgrade:
Remember to make backup/export files before an upgrade and save them on another storage device;
Make sure the device will not lose power during upgrade process;
Device has enough free storage space for all RouterOS packages to be downloaded.
Both the “stable” and “long-term” channels will display that a new version is available, it is the same version.
Should you upgrade if you are already using 6.49.18 “stable”? The 6.49.18 “long-term” does not include any updates apart for a new build time, and discovery packets now use the “long-term” label.
What’s new in 6.49.18 (2025-Feb-27 17:58):
*) 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.
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.
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.
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.
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;
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.
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!
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.
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!
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!!
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.
You still forgot my #[SUP-126246]: Winbox IPv6 ND reachable time units. First reported in 6.49.10, August 2023. Cosmetic bug (Winbox and Webfig only show wrong units label “ms” instead of “s”, value specified in seconds works correctly), but introduced in 6.47.10 which itself was a long-term release.
