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.44beta6 (2018-Sep-11 08:52):
Changes in this release:
!) upgrade - release channels renamed - “bugfix” to “long-term”, “current” to “stable” and “release candidate” to “testing”;
!) upgrade - “testing” release channel now can contain “beta” together with “release-candidate” versions;
*) chr - assign interface names based on underlying PCI device order on KVM;
*) crs317 - fixed packet forwarding on bonded interfaces without hardware offloading;
*) crs3xx - improved data transmission between 10G and 1G ports;
*) dhcpv4-server - fixed service becoming unresponsive after interface leaves and enters the same bridge;
*) dhcpv6-client - log only failed pool additions;
*) ethernet - fixed IPv6 packet forwarding on IPQ4018 devices;
*) hotspot - properly update dynamic “walled-garden” entries when changing “dst-host”;
*) ike2 - added option to specify certificate chain;
*) ike2 - fixed local address lookup when initiating new connection;
*) ike2 - fixed rare authentication and encryption key mismatches after rekey with PFS enabled;
*) lte - fixed DHCP relay packet forwarding when in passthrough mode;
*) lte - fixed Jaton/SQN modems preventing router from booting properly;
*) rb3011 - added IPsec hardware acceleration support;
*) routerboard - fixed memory tester reporting false errors on IPQ4018 devices (“/system routerboard upgrade” required);
*) sniffer - made “connection”, “host”, “packet” and “protocol” sections read-only;
*) switch - fixed ACL rules on IPQ4018 devices;
*) upnp - improved UPnP service stability when handling HTTP requests;
*) w60g - added “frequency-list” setting;
*) w60g - fixed interface LED status update on connection;
*) winbox - allow setting “network-mode” to “auto” under LTE interface settings;
*) wireless - removed “czech republic 5.8” regulatory domain information as it overlaps with “ETSI 5.7-5.8”;
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 expected or after crash.
!) upgrade - release channels renamed - “bugfix” to “long-term”, “current” to “stable” and “release candidate” to “testing”;
Tell me the truth, who decided that current is stable? It is bugfix that can be considered stable, while current is some bleeding-edge and sometimes even “never to use in prod” version.
Will the naming be backward aware, like cli to accept both bugfix and long-term?
And what to do with old releases (6.29) which are not aware of branches at all and consider itself as stable?
Would be very nice to see some routing (especially BGP, BGP4 SNMP MIBs, etc.) improvements for 6.44!
Also currently peering session re-connects when it’s comment is changed in Winbox. This is annoying and could be changed.
By the way, newbie here. Aside from being a MikroTik novice, I’m also a critter lover. I’m usually found at home, treating my Pomeranian, Jules, to his nylabones and watching TV with my wife. Such a simple, yet, happy life. Cheers, fellas!
So to say, MT used to down and up again PPP-interfaces when you change comment on it! It was this way some time ago, not sure for now, but this was some “bright” idea these days (and maybe today).
Would be very nice to see some wireless (especially NV2, AC) improvements for 6.44!
The bandwidth per 20Mhz channel is very small. Compared to competition…
I suspect they will release some absolutely new change in the system somewhere between 6.49 and 6.49.7, so noone will ever be able to predict that. Look at new bridge implementation introduction, some serious change that is there in current (sorry, so called stable) release but not in the bugfix, and you get the idea.
Hi Mikrotik will this release channel naming be pushed down into other releases at a later time ?
All my ansible scripts at present that upgrade 100’s of rb’s point to “bugfix” , “current” and “release candidate”
If MT is not going to release new versions in 6.42.x series, then this series does not need its own channel. If you want to downgrade your RB to some particular older version of ROS you can always download it (manually construct download URL if every other option to get DL link fails) and install.
Channels are only useful for semi-automated upgrades and for users that trust in MT decission about which version belongs to which category of stability. If you’re not one of us, then you can completely ignore channel naming and install whatever version of ROS you believe is best for yor RBs.
IPSec results appeared on the RB3011 product page as the Mikrotik guys promised, but theese values are lower than IPSec results on the 750Gr3 page. The HW crypt core is weaker in the RB3011 or there will be optimalizations in further ROS releases?
Mikrotik, please explain why you needed to rename the release channels. Also please explain what real change does this mean. Without that the renaming of current to stable is very confusing for those who came recently or do not know that the only well tested bugfix could be considered as stable in reality.
