RouterOS version 6.43.8 has been released in public “stable” 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.43.8 (2018-Dec-21 07:10):
MAJOR CHANGES IN v6.43.8:
!) telnet - do not allow to set “tracefile” parameter;
Changes in this release:
*) bridge - fixed IPv6 link-local address generation when auto-mac=yes;
*) capsman - fixed “group-key-update” parameter not using correct units;
*) crs3xx - improved data transmission between 10G and 1G ports;
*) console - properly remove system note after configuration reset;
*) dhcpv4-server - fixed dynamic lease reuse after expiration;
*) dhcpv6-server - properly handle DHCP requests that include prefix hint;
*) ethernet - fixed VLAN1 forwarding on RB1100AHx4 and RB4011 devices;
*) gps - added “coordinate-format” parameter;
*) led - fixed default LED configuration for RBMetalG-52SHPacn;
*) led - fixed PWR-LINE AP ethernet led polarity (“/system routerboard upgrade” required);
*) lte - disallow setting LTE interface as passthrough target;
*) lte - fixed DHCP IP acquire (introduced in v6.43.7);
*) lte - fixed passthrough functionality when interface is removed;
*) lte - increased reported “rsrq” precision;
*) lte - reset USB when non-default slot is used;
*) package - use bundled package by default if standalone packages are installed as well;
*) resource - fixed “total-memory” reporting on ARM devices;
*) snmp - added “tx-ccq” (“mtxrWlStatTxCCQ”) and “rx-ccq” (“mtxrWlStatRxCCQ”) values;
*) switch - fixed MAC learning when disabling interfaces on devices with Atheros8327 and QCA8337 switch chips;
*) system - fixed situation when all configuration was not properly loaded on bootup;
*) timezone - fixed “Europe/Dublin” time zone;
*) upgrade - automatically uninstall standalone package if already installed in bundle;
*) webfig - do not show bogus VHT field in wireless interface advanced mode;
*) winbox - added “allow-roaming” parameter in “Interface/LTE” menu;
*) winbox - allow to change VHT rates when 5ghz-n/ac band is used;
*) winbox - renamed “Radius” to “RADIUS”;
*) winbox - show “Switch” menu on RB4011iGS+5HacQ2HnD and RB4011iGS+;
*) wireless - added new “installation” parameter to specify router’s location;
*) wireless - improved stability for 802.11ac;
*) wireless - improvements in wireless frequency selection;
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.
Would like to know as well. My RB4011 keeps disabling 5ghz WiFi after a few days (see graph). Only a reboot can bring the WiFi up again. Wondering if this has been fixed
Thank you very much for this present!
Now if I have a country set I can only use regulatory domain and default scanlist, a real pain in the a*s.
That should be in changelog!
The reported fix to performance between 1Gb and 10Gb ports on CRS3xx series devices in 6.43.8 does not fix the issue. I’ve upgraded three CRS326 devices so far today, one from 6.43.4 and two from 6.43.7, and there has been no improvement. We ran extensive tests, all of which proved that while there was a “slight” increase in performance, as soon as you start to approach 100Mb of steady traffic going from (not to) a 1Gb port to a 10Gb uplink the 326 starts to fail to pass packets and performance drops significantly below 100Mb.
We’ve actually had to drop to 1Gb SFPs for the fiber uplinks to get ANY kind of performance above 20-30Mb/sec. As a 1Gb switch, it works great. 10Gb uplink? Back to the drawing board folks…I have 8 CRS317s (three groups of rings) and a core/edge of multiple CCR1072s/1036s that is waiting for a fix to be able to deploy.
No issue on 317s – never had any. But the DOZENS of 326s that we have are pretty much boat anchors since the change to the way bridges are configured. The 226s we’ve been retiring may need to go back in service. They work – if configured the “traditional” way instead of the new method of setting up VLANS.
Love Mikrotiks. Have hundreds of them. Don’t love this bug.
No, they are waiting to be used. We deploying five new 10Gb backbones. Two of them are multiple switch RSTP rings between the three data centers, three are just ship to shore to handle backend storage for the server cluster and other high volume data such as cameras.
There are also two 1072s, two 1036s, four 1009s (w/10Gb port) waiting to cut over from the existing network.
Not that this is necessarily a “huge” network, but this is a summary of Mikrotiks deployed onsite right now. And yes, we still have several nearly ten year old RB1200s handling edge services for one of the external network connections.
Most maintenance/upgrades (as well as backups) have been automated using in-house developed databases, so other than devices that are offline at the moment, the ship looks like this:
Most of the network is on 6.43, but a lot of the crs226s have been kept back on 6.40 waiting for maintenance time to upgrade the “old style” configurations.
There are also a dozen or so HP and Netgear switches still to be decommissioned. The 1072s, 1036s and most of the 317s are in part of the network that we are upgrading from a single 10Gb ring to five distinct connections ship to shore. There are sometimes more than ten thousand active mac addresses visible during the day. The dynamic DHCP pool is multiple /16s.
It isn’t a report, is a decision.
You should use only regulatory domain in some countries, but when you face to low quality transmission and TDMA, and occupied frequencies, what else can you do?
