v6.42.9 [long-term] is released!

RouterOS version 6.42.9 has been released in public “long-term” 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.42.9 (2018-Sep-27 05:19):

Important note!!! Backup before upgrade!
RouterOS v6.41 and above contains new bridge implementation that supports hardware offloading (hw-offload).
This update will convert all interface “master-port” configuration into new bridge configuration, and eliminate “master-port” option as such.
Bridge will handle all Layer2 forwarding and the use of switch-chip (hw-offload) will be automatically turned on based on appropriate conditions.
The rest of RouterOS Switch specific configuration remains untouched in usual menus.
Please, note that downgrading below RouterOS v6.41 will not restore “master-port” configuration, so use backups to restore configuration on downgrade.

*) bridge - ignore tagged BPDUs when bridge VLAN filtering is used;
*) bridge - improved packet handling when hardware offloading is being disabled;
*) crs317 - fixed packet forwarding on bonded interfaces without hardware offloading;
*) crs326/crs328 - fixed packet forwarding when port changes states with IGMP Snooping enabled;
*) defconf - properly clear global variables when generating default configuration after RouterOS upgrade;
*) dns - fixed DNS cache service becoming unresponsive when active Hotspot server is present on the router (introduced in 6.42);
*) filesystem - fixed NAND memory going into read-only mode (requires “factory-firmware” >= 3.41.1 and “current-firmware” >= 6.43);
*) health - added missing parameters from export;
*) health - fixed voltage measurements for RB493G devices;
*) hotspot - properly update dynamic “walled-garden” entries when changing “dst-host”;
*) ike2 - fixed rare authentication and encryption key mismatches after rekey with PFS enabled;
*) ike2 - improved subsequent phase 2 initialization when no child exist;
*) ipsec - improved invalid policy handling when a valid policy is uninstalled;
*) ipsec - improved stability when using IPsec with disabled route cache;
*) led - added “dark-mode” functionality for wsAP ac lite, RB951Ui-2nD, hAP, hAP ac lite and LtAP mini devices;
*) lte - fixed LTE interface not working properly after reboot on RBSXTLTE3-7;
*) lte - fixed LTE registration in 2G/3G mode;
*) netwatch - limit to read, write, test and reboot policies for Netwatch script execution;
*) ospf - improved link-local LSA flooding;
*) ospf - improved stability when originating LSAs with OSPFv3;
*) routerboard - fixed memory tester reporting false errors on IPQ4018 devices (“/system routerboard upgrade” required);
*) routerboard - show “boot-os” option only on devices that have such feature;
*) routerboot - fixed RouterOS booting on devices with particular NAND memory;
*) sniffer - made “connection”, “host”, “packet” and “protocol” sections read-only;
*) supout - added “files” section to supout file;
*) upgrade - fixed RouterOS upgrade process from RouterOS v5 on PowerPC;
*) upnp - improved UPnP service stability when handling HTTP requests;
*) userman - fixed “shared-secret” parameter requiring “sensitive” policy;
*) w60g - added “frequency-list” setting;
*) w60g - fixed interface LED status update on connection;
*) w60g - fixed random disconnects;
*) w60g - general stability and performance improvements;
*) webfig - fixed time interval settings not applied properly under “IP/Kid Control/Kids” menu;
*) webfig - fixed www service becoming unresponsive;
*) winbox - show “System/RouterBOARD/Mode Button” on devices that has such feature;
*) wireless - accept only valid path for sniffer output file parameter;
*) wireless - fixed “/interface wireless sniffer packet print follow” output;

What’s new in 6.42.8 (2018-Sep-21 13:30):

(factory only release)

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 concrete RouterOS release.

Does this upgrade include the fix for the CCR-1072’s that keep crashing when trying to run them at 1200Mhz ? (http://forum.mikrotik.com/t/ccr1072-watchdog-reboot/109522/1)

Did support@ tell you it should be fixed in this version? I can’t see any signs of this in the topic. Also, this topic is for problems introduced in this version, not for some old problems — they should have separate topics.

This is a bad move! Now users of 6.40.x versions cannot install updates anymore.
We need full support of hw-accelerated VLAN switching in the new bridge at some locations before versions >6.40 can be used.

Will monitor this thread . I understand the reasoning for the new bridge implemenation but I find some of the things still a bit alien to be honest and there still seems to be cases where there isn’t 1:1 feature parity over the old way of doing things.

Have a boatload of 2011’s that act as shaping L2 bridges that I will have to swing over and config scripts that need to be rewritten.

What is unknown string string “bugfix”? :slight_smile: Where string “long term”?
1.png

After downgrading from 6.43.2 to 6.42.9 mikrotik ddns don’t work. On router DDNS service ip address is valid. But any device don’t connect to router because ip address is old. Note from mikrotik Wiki:
"Note: Since RouterOS v6.43 your device will use cloud2.mikrotik.com to communicate with the MikroTik’s Cloud server. Older versions will use cloud.mikrotik.com to communicate with the MikroTik’s Cloud server. "
If cloud2.mikrotik.com remember old ip address, how disable my old ip from cloud2.mikrotik.com and enable my new ip from cloud.mikrotik.com?

You have to disable DDNS service on v6.43 before downgrading for it to work on older versions.

Thank you :slight_smile: But i don`t disable ddns service. I must upgrading to 6.43.2, disabling ddns and downgrading to 6.42.9 again? Or is there an easier way?

Yes, that is correct. If you jump between versions older than 6.43 and 6.43 or newer, then you must disable IP/Cloud DDNS feature first and re-enable it back after upgrade/downgrade.

!) cloud - reworked “/ip cloud ddns-enabled” implementation (suggested to disable service and re-enable after installation process);

All VLAN related features are available in newer versions. they have been available since 6.41

An exception is with CRS3xx series switches, they did not certain switching features in 6.40.x yet so they were only added in 6.42 and 6.43

No features were removed, only one feature was renamed and that is the “master-port” that had various limitations, now it is replaced with a simple bridge configuration. Nothing else is changed regarding to VLAN configuration. You simply have to replace every configuration line that involves the master-port with a bridge, or better - let RouterOS convert your configuration when upgrading, it will automatically replace the master-port with a bridge. All VLAN switching configuration for non-CRS3xx is still under /interface ethernet switch. You should check this guide:
https://wiki.mikrotik.com/wiki/Manual:Basic_VLAN_switching
Here you can see that VLANs (for non-CRS3xx) are still configured under /interface ethernet switch menu, master-port is replaced with a bridge, that is it.

In addition with 6.41 you now have the ability to filter VLANs on devices that do not support VLAN switching or do not have a built-in switch chip in a way that does not violates IEEE 802.1W and will be compatible with other switches in your network.


Can you please share more details which configuration you are not able to use since 6.41?

The warning about master-port configurations being updated to the new bridge configuration should really be repeated in the release notes now this version has changed track from current/stable to bugfix/long-term - people who have been using the bugfix branch may be unaware of the change introduced back in 6.41

Thanks, we have added the bridge migration warning back for this release.

But when an existing configuration with master-port with VLAN subinterfaces on the master-port is converted to a single bridge with VLAN subinterfaces on the bridge and VLAN filtering, the result is that it is no longer hw-accelerated.
(on routers like RB2011 and RB750)
Is that ever going to be fixed? Or do you recommend keeping the switch configuration and not use the bridge VLAN filtering?

This is simply not true, at least not on RB951G. In old config, you had VLAN filtering configured explicitly in /interface ethernet switch, then a master port and vlan interfaces on that master port. Change from 6.40 to 6.42 converts master port to bridge, all the rest (VLAN filtering on switch chip and vlan interfaces now hanging off the bridge) remain the same. Switching is still done in hardware as it used to be. If something was not possible due to switch chip limitations, it still isn’t possible … not in the old manner nor HW-offloaded in the new manner.

With ROS > 6.40 it is possible to use “new” bridge vlan-filtering, but it is not mandatory to do it.
New way lacks HW offload support for non-trivial tasks, but it allows things to be done which were not possible previously on some devices due to lack of support in hardware.

So if there are no any master-ports in my 6.40.9 setup, then upgrade to 6.42.9 should not cause any problems?

Generally, it should not cause problems at all :slight_smile:

Well, when you switch on VLAN FIltering, Hw. Offload switches off. So, you say it’s just cosmetic error, and everything is still hardware-accelerated?

I converted an RB2011 router which had VLAN switching to a bridge according to https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#Bridge_VLAN_Filtering and it lost the hw-accel while many other routers which had switching but no VLAN had hw-accel after that.
So apparently the bridge only can do hw-accel without VLAN, which is weird because the hardware clearly can do it (this was only on ports 1-5 on that RB2011).

@Chupaka and @pe1chl: the way 6.40 config is converted, there’s no sign of bridge vlan-filtering. Bridge acts as a dummy (VLAN unaware) switch. VLAN filtering is done by switch chip in hardware.
Its only after you start configuring VLANs on bridge (transforming it to VLAN-aware switch) when yiu loose HW offloading.

Replaced running v6.43.2 on RB1100Hx2, hAP and a few wAP AC and cAP without any major problems. Had some issues with detect-internet enabled interface and dhcp-client. I removed the interface from the interface list and recreated the dhcp client and got it working.