RouterOS version 6.45.8 has been released in public “long-term” channel!
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.
What’s new in 6.45.8 (2020-Jan-23 07:19):
Changes since 6.45.7:
*) capsman - fixed background scan showing incorrect regulatory domain mismatch error (CAP upgrade required);
*) capsman - improved radar detection algorithm;
*) chr - improved stability when changing ARP modes on e1000 type adapters;
*) console - fixed “clear-history” restoring historic actions after power cycle;
*) console - removed “edit” and “set” actions from “System/History” menu;
*) console - updated copyright notice;
*) crs305 - disable optical SFP/SFP+ module Tx power after disabling SFP+ interface;
*) dhcpv4-server - improved stability when RADIUS interim update is sent;
*) dhcpv6-client - fixed timeout when doing rebind;
*) dhcpv6-client - properly update bind time when unused prefix received from the server;
*) dhcpv6-client - properly update IPv6 address on rebind;
*) dhcpv6-server - fixed logged error message when using “address-pool=static-only”;
*) dhcpv6-server - ignore prefix-hint from client’s DHCPDISCOVER if static prefix received from RADIUS;
*) health - fixed health reporting on OmniTIK 5 PoE ac;
*) ipsec - improved system stability when processing decrypted packet on unregistered interface;
*) l2tp - improved system stability when disconnecting many clients at once;
*) led - fixed default LED configuration for RBLHG-2nD and RBLHG-5HPnD;
*) lte - show SIM error when no card is present;
*) ppp - fixed connection establishment when receiving “0.0.0.0” DNS;
*) ppp - fixed minor typo in “ppp-client” monitor;
*) ppp - prioritize “remote-ipv6-prefix-pool” from PPP secret over PPP profile;
*) qsfp - do not report bogus monitoring readouts on modules without DDMI support;
*) qsfp - improved module monitoring readouts for DAC and break-out cables;
*) routerboard - added “mode-button” support for RBcAP2nD;
*) security - fixed vulnerability for routers with default password (limited to Wireless Wire), admin could login on startup with empty password before default configuration script was fully loaded;
*) ssh - fixed output printing when “command” parameter used;
*) timezone - updated time zone database to version 2019c;
*) traffic-generator - improved memory handling on CHR;
*) w60g - fixed “monitor” command on disabled interfaces;
*) winbox - automatically refresh “Packets” table when new packets are captured by “Tools/Packet Sniffer”;
*) winbox - show “LCD” menu only on boards that have LCD screen;
*) wireless - added “ETSI” regulatory domain information;
*) wireless - added “indonesia4” regulatory domain information;
*) wireless - added U-NII-2 support forRBSXTsqG-5acD, RBLHGG-5acD-XL, RBLHGG-5acD, RBLDFG-5acD, RBDiscG-5acD;
*) wireless - allow using “canada2” regulatory domain on US lock devices;
*) wireless - fixed sensor MAC address reporting in TZSP header;
*) wireless - improved compatibility by adding default installation mode and antenna gain for devices with integrated antennas;
*) wireless - improved compatibility for Switzerland wireless country profile to improve compliance with ETSI regulations;
*) wireless - improved IPQ4019, QCA9984, QCA9888 wireless interface stability;
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 router is not working as suspected or after some problem has appeared on device
Please keep this forum topic strictly related to this specific RouterOS release.
So the question is, ain’t it is a just from 6.44.6 → 6.45.8? Or this is a mistake so in fact this should be 6.44 branch, like this: 6.44.6 → 6.44.7 → 6.44.8?
This is correct. Listed here are only changes between 6.45.7 and 6.45.8. If you want to know all changes between 6.44.6 and 6.45.8, you have to go through all versions that were released in between.
long-term isn’t a different firmware branch
it’s a regular firmware (6.45.7 in our case) plus bugfixes and improvements only, without adding new functionality
This issue has been discussed previously and seems we have to discuss it again: if an user is subscribed to “long term”, then he needs to be alerted about all changes between sequential “long term” releases regardless the release cycle. If “long term” release 6.44.6 is succeeded by “long term” release 6.45.8, then change log presented to such user should contain a merged list of changes of all changes between these two versions.
Ideally change log presented to the user would be dynamically merged list of changes between currently installed ROS and the version about to be installed. I can imagine this can pose some more work with change log organization and if MT doesn’t have some change log creation system in place (and change logs need to be prepared manually), then I guess we can live without this kind of change log. However, if “long term” release includes jump in many versions, then somebody should manually merge relevant release change logs.
After all, MT wants users to believe that it’s fine to follow the release decisions by MT without micro-managing upgrades … hence the process should flow accordingly (and change log is part of the process).
BTW, upgrades involving large version jumps (e.g. from 6.40.x to current “long term” version) should be done with regard to upgrade scripts. We’ve seen many times that upgrade scripts don’t handle large differences in configuration. In this case, upgrade process should involve upgrade to interim versions which handle upgrades of config smoother. One example of such upgrade path is Firefox … if one is running too old version, upgrade doesn’t jump directly to current version, it upgrades to one (or few) interim versions …
long term, which recently experienced version jump from 6.44.6 to 6.45.7
stable, which currently stands at 6.46.2 and normally steadily runs through all “non beta” releases
testing, which actually is “beta for v6” as it is now. After certain beta version gets bugs fixed (or at least devs think so), the last one becomes “stable” release
development, which doesn’t exist all the time. Currently its “beta for v7” …
Conservative user, who doesn’t need all the new features but prefers (or requires) bug-free stability, can opt for “long term” release channel. And upon proposed/forced ROS upgrade that user would expect to see change log between “his” consecutive versions.
Yes I know that. I used wrong term, while understand the concept.
What is strange, I hardly understand how each release “marked”, say, to be long-term or not. I can’t believe it it easy to determine that this current release “seems to be super-stable so put is under long-term”. If so it looks too dangerous to believe that long-term is really-long-term so one can put it onto reouter that should won’t long time without upgrades and will not show signs of bugs/problems.
So yes, good explanation in each case of big version bump would be nice and (really) a must.
I can imagine a sysadmin that try to choose which version to put on router/switch that’ll be work remotely and without close human presence. This way the ROS may not be very current, but very stable (trust-worth), and this is what long-term should be about, right?
Have you guys checked the changelog on your routers? The 6.45.8 changelog contains of all versions between the last long-term version. We can not predict from which version a user is upgrading in a forum topic or on a website. Please stop going off topic. This is not the place to discuss how changelogs should be published! Any further off topic posts will be removed and users will be warned.
I express my question on version number bump - and this is the topic for this version, isn’t it? It you guys can not describe what you’re doing in the first message, then be prepared to see these questions. Please consider these ideas, we are your customers and someone who keep buy your devices and licenses mainly due to ROS unique place on market, and yes we need a way to determine if current (or upcoming) version to be considered as quite stable or you just name it “release” instead “beta” (you can recall versions that infamous for being non-stable even that it was called ‘release’). Read changelog on device is good (but naive) idea but there are people who prefer to do cli-based upgrade, mind it?
I just installed 6.45.8 on one router to check it and keep eye on it, the upgrade is ok so far it works nice, too.
Well, if you upgrade from 6.44.6 (previous long-term) to 6.45.8 OF COURSE it includes new functionality. It does not if you upgrade from 6.45.7 to 6.45.8.
Indeed. The question was why is that huge jump when we talk about long-term. Logics behind is an Terra Unknown for me, so some explanation would be just perfect add-on for the announcement, dont’t you think so?
17 answers and none about the release. It probably means that the release is stable indeed
All this discussion should be put in another topic guys if you are unhappy about the release channels and how are those named.
If you check from winbox the change log that appears at /system package you will see that it has all changes since 6.45. Is there a better way to alert a user about the change log?
