v6.48.5 [long-term] is released!

emils · Fri Oct 08, 2021 2:05 pm

RouterOS version 6.48.5 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.48.5 (2021-Sep-21 13:50):

Changes since 6.48.4:

*) branding - properly clean up old branding files before installing a new one;
*) crs3xx - fixed default MAC address calculation on management Ethernet for CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) gps - improved interface monitoring;
*) health - improved temperature reporting;
*) ike2 - check if TS is still valid after obtaining SPI;
*) ipsec - improved SA update by SPI;
*) netinstall - require Netinstall version to be the same or newer as "factory-software";
*) poe - update PoE firmware only on devices that supports it;
*) ppp - improved stability when receiving bogus response on modem channel;
*) qsfp - improved system stability when setting unsupported link rates;
*) sfp - added "sfp-rate-select" setting (CLI only);
*) sfp - improved SFP, SFP+, SFP28 and QSFP+ interface stability for CRS3xx and CCR2004 devices;
*) sfp28 - changed FEC auto mode to disabled;
*) w60g - limit power output when using region EU to match EN302567 on nRAY;
*) w60g - use EU region by default;
*) winbox - added "name" and "file-name" parameter when importing and exporting certificates;
*) winbox - allow setting MCS (24-31) to 4x4 Wireless interfaces;
*) winbox - do not allow to set empty "init-string" field under "System/GPS" menu;
*) winbox - do not show "GPS antenna" selection for devices without selection support;
*) winbox - show "System/Health/Settings" only on boards that have configurable values;
*) winbox - show "current-channel" column by default for CAP interfaces;
*) wireless - added U-NII-2 support for US and Canada country profiles for hAP ac lite;

For a full changelog please visit https://mikrotik.com/download/changelogs

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.

rextended · Fri Oct 08, 2021 2:42 pm

What is the last version where IPv6 on IP Cloud work?

marekm · Fri Oct 08, 2021 3:11 pm

*) w60g - limit power output when using region EU to match EN302567 on nRAY;
*) w60g - use EU region by default;

How much power and range can we lose due to these changes? Does this only affect the nRAY (which already seems weaker than LHG60)?
What does "by default" mean - change to EU after upgrade only if no region set previously, or always?
Can't afford to lose connection with remote station after upgrade.

VitohA · Fri Oct 08, 2021 3:23 pm

Updated rb4011 and ccr2004, no issues so far.

pe1chl · Fri Oct 08, 2021 3:53 pm

I still think it is a bad policy to release a new version in the stable channel and declare it the long-term version at the same time.
You should move versions to the long-term channel only after they have proven to be free of obvious issues in the stable channel for some time.
(I know that long-term, stable and testing are not referring to quality of the software, but lots of users run long-term versions because they do not want to be concerned with bugs inadvertently included in a fresh release version)

DeDMorozzzz · Fri Oct 08, 2021 4:23 pm

*) winbox - allow setting MCS (24-31) to 4x4 Wireless interfaces;

A step to AX?

mkamenjak · Fri Oct 08, 2021 5:03 pm

*) winbox - allow setting MCS (24-31) to 4x4 Wireless interfaces;

A step to AX?

More a step to AC wifi2.

Amm0 · Fri Oct 08, 2021 5:11 pm

I still think it is a bad policy to release a new version in the stable channel and declare it the long-term version at the same time.
You should move versions to the long-term channel only after they have proven to be free of obvious issues in the stable channel for some time.
(I know that long-term, stable and testing are not referring to quality of the software, but lots of users run long-term versions because they do not want to be concerned with bugs inadvertently included in a fresh release version)

Totally agreed. The fact the same version/build was previously released and run by others in field, even if short while, is what gives me confidence about "long-term". Since ROS v7.1 certainly isn't bug free, the last thing anyone needs is some unstable v6 "long-term" build.

e.g. we use PPP-based modems on some devices, so when I see stuff like "ppp - improved stability when receiving bogus response on modem channel;" - that seem like something that should be tried in the "stable" channel first...

So now have a question about what modems/RB/etc are unstable "when receiving bogus response" with PPP before this release...

iegg · Fri Oct 08, 2021 9:56 pm

Hi,
Just applied the upgrade. Why is the multicast package missing? I have to use IGMP Proxy and now it's not available.

EDIT: I had to re-download the multicast package included in all_packages.zip, then applied it and everything back to normal. If I remember right the last time I did an upgrade I did not have to upgrade the multicast package separately. Can somebody confirm? Maybe I'm wrong about that. I'm also a quite new MT user, so sorry for that.
Might also be the case that last time I upgraded via system/packages/check for updates/download and install, which might be different from downloading and applying manually.

Thanks

Joni · Fri Oct 08, 2021 9:57 pm

I still think it is a bad policy to release a new version in the stable channel and declare it the long-term version at the same time.
You should move versions to the long-term channel only after they have proven to be free of obvious issues in the stable channel for some time.
(I know that long-term, stable and testing are not referring to quality of the software, but lots of users run long-term versions because they do not want to be concerned with bugs inadvertently included in a fresh release version)

Especially since even the changelog references a non-existing long-term release in relation to changes from v6.48.4 and not the actual predecessor v6.47.10 .
https://mikrotik.com/download/changelog ... lease-tree

Even v6.48.5 doesn't have a changelog https://mikrotik.com/download/changelog ... lease-tree nor does long-term v6.47.10:

So lets see how the actual release notes for long-term v6.48.5 upgrade from v6.47.10 looks like:

What''s new in 6.48.5 (2021-Sep-21 13:50):

Changes since 6.47.10:

*) arm - added support for automatic CPU frequency stepping for IPQ4018/IPQ4019 devices;
*) arm - improved system stability;
*) arm - improved watchdog and kernel panic reporting in log after reboots on IPQ4018/IPQ4019 devices;
*) arm64 - improved reboot reason reporting in log;
*) bgp - fixed VPNV4 RD byte order;
*) bonding - improved system stability when disabling/enabling bonding ports;
*) bonding - improved system stability when disabling/enabling bonding ports;
*) bonding - added LACP monitoring;
*) branding - fixed missing branding skins if "skins" folder does not exist;
*) branding - fixed LCD logo loading from new style branding package;
*) branding - added option to upload custom files (newly generated branding package required);
*) branding - properly clean up old branding files before installing a new one;
*) branding - added option to upload custom files (newly generated branding package required);
*) bridge - added minor fixes and improvements for IGMP snooping with HW offloading;
*) bridge - added fixes and improvements for IGMP and MLD snooping;
*) bridge - added "multicast-router" monitoring value for bridge interface;
*) bridge - automatically remove extended interfaces when deleting PE device from CB;
*) bridge - correctly filter packets by L2MTU size;
*) bridge - improved bridge stability when host changes port (introduced in v6.47);
*) bridge - allow to exclude interfaces from extended ports;
*) bridge - added warning message when port is disabled by the BPDU guard;
*) bridge - added MAC and IP source addresses information for DHCP snooping log;
*) bridge - use "frame-types=admit-all" by default for extended bridge ports;
*) bridge - show "H" flag for extended bridge ports;
*) bridge - fixed "vlan-encap" setting for filter and NAT rules;
*) bridge - improved system stability when using IGMP snooping and changing bridge MAC address;
*) bridge - show error when switch do not support controlling bridge or port extension;
*) bridge - increased multicast table size to 4K entries;
*) bridge - improved BPDU guard logging;
*) bridge - fixed multicast table printing;
*) bridge - fixed local MAC address removal from host table when deleting bridge interface;
*) bridge - fixed link-local multicast forwarding when IGMP snooping and HW offloading is enabled;
*) bridge - fixed dynamic VLAN assignment when changing port to tagged VLAN member;
*) bridge - fixed dynamic VLAN assignment when changing port "frame-type" property (introduced in v6.46);
*) bridge - fixed "multicast-router" setting on bridge enable;
*) bridge - correctly remove dynamic VLAN assignment for bridge ports;
*) bridge - fixed MDB entry removal when using bridge port "fast-leave" property;
*) cap - fixed L2MTU setting from CAPsMAN;
*) capsman - use Bits instead of Bytes for "ap-tx-limit" and "client-tx-limit" parameters;
*) capsman - use proper units for "ap-tx-limit" and "client-tx-limit" parameters;
*) certificate - properly flush expired SCEP OTP entries;
*) certificate - generate CRL even when CRL URL not specified;
*) certificate - fixed CRL URL length limit;
*) certificate - fixed private key verification for CA certificate during signing process;
*) certificate - clear challenge password on renew;
*) chr - fixed VLAN tagged packet transmit on bridge for Hyper-V installations;
*) chr - fixed SSH key import on Azure;
*) chr - improved interface loading on startup on XEN;
*) chr - improved system stability when changing flow control settings on e1000;
*) cloud - improved backup generation process;
*) conntrack - automatically reduce connection tracking timeouts when table is full;
*) console - updated copyright notice;
*) console - do not clear environment values if any global variable is set;
*) console - require "write+ftp" permissions for exporting configuration to file;
*) console - require "write+ftp" permissions for exporting configuration to file;
*) console - updated copyright notice;
*) console - allow "once" parameter for bonding monitoring;
*) console - do not clear environment values if any global variable is set;
*) crs312 - fixed missing SwOS firmware on revision 2 devices;
*) crs3xx - correctly filter packets by L2MTU size;
*) crs3xx - fixed "custom-drop-packet" and "not-learned" switch stats for CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - fixed "mirror-source" property on switch port disable for CRS305, CRS326-24G-2S+, CRS328, CRS318 devices;
*) crs3xx - fixed "storm-rate" traffic limiting for switch-cpu port on CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - added initial Bridge Port Extender support;
*) crs3xx - added initial Controlling Bridge support for CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - fixed default MAC address calculation on management Ethernet for CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - fixed CDP packet forwarding for CRS305, CRS318, CRS326-24G-2S+, CRS328 devices;
*) crs3xx - added switch-cpu port VLAN filtering (switch-cpu port is now mapped with bridge interface VLAN membership when vlan-filtering is enabled);
*) crs3xx - fixed interface LEDs for QSFP+ and SFP+ interfaces on CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - added "/system swos" menu for CRS354 devices, should only be used after SwOS 2.13 release;
*) crs3xx - improved system stability when receiving large frames on CPU for CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - improved system stability when receiving large frames on CPU for CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - improved 1Gbps Ethernet port group traffic forwarding for CRS354 devices;
*) crs3xx - fixed interface LEDs for QSFP+ and SFP+ interfaces on CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - added "/system swos" menu for CRS354 devices, should only be used after SwOS 2.13 release;
*) crs3xx - fixed "switch-cpu" VLAN membership on bridge disable;
*) crs3xx - fixed unknown multicast flood to CPU when IGMP snooping is used;
*) crs3xx - improved system stability when increasing interface L2MTU for CRS318 devices;
*) crs3xx - improved LACP linking between CRS3xx series switches;
*) crs3xx - improved system stability when bonding and IGMP snooping is used (introduced in v6.48);
*) crs3xx - improved load balancing on bonding interfaces for CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - fixed port-isolation on ether37-ether48 ports for CRS354 device;
*) crs3xx - fixed packet duplication when multiple bonding interfaces are created for CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - fixed duplicate host entries when creating static switch hosts;
*) crs3xx - fixed port isolation for "switch-cpu" port for CRS305, CRS326-24G-2S+, CRS328, CRS318 devices;
*) crs3xx - fixed port isolation removal for "switch-cpu" port on CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - fixed switch "copy-to-cpu" property for CRS305, CRS318, CRS326-24G-2S+, CRS328 devices;
*) crs3xx - fixed switch "not-learned" stats for CRS305, CRS326-24G-2S+, CRS328-24P-4S+, CRS328-4C-20S-4S+, CRS318 devices;
*) crs3xx - improved system stability on CRS354 devices;
*) crs3xx - improved system stability when receiving large frames for CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices (introduced in v6.47.5);
*) crs3xx - fixed Ethernet LEDs after reboot for CRS354 devices;
*) crs3xx - fixed VLAN priority removal for CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - improved 1Gbps Ethernet port group traffic forwarding for CRS354 devices;
*) crs3xx - fixed port-isolation on bonding interfaces for CRS317, CRS309, CRS312, CRS326-24S+2Q+ and CRS354 devices;
*) crs3xx - fixed packet transmit in 5Gbps link rate for CRS312 device;
*) defconf - fixed default configuration loading on RBOmniTikPG-5HacD;
*) defconf - fixed default configuration loading on LHG R;
*) defconf - fixed default configuration loading on LHG R;
*) defconf - fixed default configuration loading on RBcAP-2nD and RBwAP-2nD;
*) defconf - improved default configuration generation on devices with non-default wireless interface names;
*) defconf - improved CAP interface bridging;
*) defconf - fixed minor typo in configuration description;
*) defconf - fixed default configuration loading on RBOmniTikPG-5HacD;
*) defconf - fixed static IP address setting in case default configuration loading fails;
*) detnet - fixed malformed dummy DHCP User Class option;
*) detnet - use MAC address from bridge interface instead of slave port;
*) dhcp - fixed link state checking for DHCP client;
*) dhcp - fixed DHCP packet forwarding to IPsec policies;
*) dhcp - fixed link state checking for DHCP client;
*) dhcpv4-server - improved "client-id" value parsing;
*) dhcpv6 server - added support for "Delegated-IPv6-Prefix" for PPP services;
*) dhcpv6-server - allow loose static binding "pool" parameter (introduced in v6.46.8);
*) dhcpv6-server - added support for "option18" and "option37" for RADIUS managed clients;
*) dhcpv6-server - make sure that calling station ID always contains DUID;
*) dhcpv6-server - fixed false missing IPv6 Pool warning for dynamic bindings;
*) dhcpv6-server - added ability to generate binding on first request;
*) discovery - added "lldp-med-net-policy-vlan" property for assigning VLAN ID;
*) discovery - use interface MAC address when sending MNDP from slave port;
*) discovery - send the same "Chassis ID" on all interfaces for LLDP packets;
*) discovery - fixed discovery when enabled only on master port;
*) discovery - fixed discovery packet sending on newly bridged port with "protocol-mode=none";
*) discovery - fixed discovery on mesh ports;
*) discovery - allow choosing which discovery protocol is used;
*) disk - fixed external EXT3 disk mounting on x86 systems;
*) dns - added IPv6 support for DoH;
*) dns - do not use type "A" for static entries with unspecified type;
*) dns - end ongoing queries when changing DoH configuration;
*) dns - fixed listening for DNS queries when only dynamic static entries exist (introduced in v6.47);
*) dns - fixed cache memory leak when resolving CNAME domains;
*) dns - fixed CNAME query when target record is not in cache;
*) dot1x - fixed "reject-vlan-id" for MAC authentication (introduced in v6.48);
*) dot1x - fixed reauthentication after server rejects a client into VLAN;
*) dot1x - fixed unicast destination EAP packet receiving when a client is running on a bridge port;
*) dot1x - accept priority tagged (VLAN 0) EAP packets on dot1x client;
*) dot1x - fixed MAC authentication fallback (introduced in v6.48);
*) dude - fixed configuration menu presence on ARM64 devices;
*) dude - fixed configuration menu presence on ARM64 devices;
*) ethernet - improved system stability when receiving large VLAN tagged packets on IPQ4018/IPQ4019 devices;
*) ethernet - improved system stability when receiving large VLAN tagged packets on IPQ4018/IPQ4019 devices;
*) ethernet - fixed cable-test for some devices (e.g. RB2011, RB951G-2HnD);
*) export - fixed RouterBOARD USB "type" parameter export;
*) fastpath - fixed IP packet receive on bridge and bonding interfaces when destination MAC address match with slave port MAC;
*) filesystem - improved long-term filesystem stability and data integrity;
*) filesystem - fixed repartition on non-first partition;
*) filesystem - fixed repartition on RB4011 series devices;
*) gps - fixed "init-channel" release when not used;
*) gps - improved interface monitoring;
*) health - improved temperature reporting;
*) health - improved temperature reporting;
*) health - fixed voltage monitor on BaseBox5 devices;
*) health - fixed voltage monitor on BaseBox5 devices;
*) health - removed unused "heater-control" and "heater-threshold" parameters;
*) health - changed PSU state parameter type to read-only;
*) hotspot - added support for captive portal advertising using DHCP (RFC7710);
*) hotspot - fixed "html-directory" parameter export;
*) hotspot - improved management service stability when receiving bogus packets;
*) hotspot - fixed special character parsing in "target" variable (CVE-2021-3014);
*) hotspot - fixed "idle-timeout" usage with RADIUS authentication;
*) hotspot - added "vlan-id" parameter support for hosts and HTML pages;
*) ike1 - fixed "my-id=address" parameter usage together with certificate authentication;
*) ike1 - fixed policy update with and without mode configuration;
*) ike1 - fixed memory leak on multiple CR payloads;
*) ike1 - rekey phase 1 as responder for Windows initiators;
*) ike1 - fixed ''rsa-signature-hybrid'' authentication method;
*) ike2 - fixed EAP MSK length validation (introduced in v6.48);
*) ike2 - added "MS-CHAP-Domain" attribute to RADIUS requests;
*) ike2 - fixed DH group negotiation with EAP;
*) ike2 - fixed phase 2 rekeying with enabled PFS (introduced in v6.48);
*) ike2 - improved stability when invalid certificate is configured (introduced in v6.48);
*) ike2 - properly register packet time after expensive CPU operations;
*) ike2 - improved EAP message integrity checking;
*) ike2 - check if TS is still valid after obtaining SPI;
*) ike2 - added "MS-CHAP-Domain" attribute to RADIUS requests;
*) ike2 - improved child SA rekeying process;
*) ike2 - fixed EAP MSK length validation;
*) ike2 - fixed too small payload parsing;
*) ike2 - added "prf-algorithm" support for phase 1;
*) ike2 - added support for IKEv2 Message Fragmentation (RFC7383);
*) ike2 - fixed initial traffic selector''s protocol and port in transport mode;
*) interface - added temperature warning and interface disable on overheat for SFP and SFP+ interfaces (CLI only);
*) interface - fixed pwr-line running state (introduced in v6.45);
*) interface - fixed pwr-line interface linking (introduced in v6.48);
*) ipsec - fixed multiple warning message display for peers;
*) ipsec - fixed SA address parameter exporting;
*) ipsec - refresh peer''s DNS only when phase 1 is down;
*) ipsec - fixed SA address parameter exporting;
*) ipsec - improved stability when processing IPv6 packets larger than interface MTU;
*) ipsec - added SHA384 hash algorithm support for phase 1;
*) ipsec - do not kill connection when peer''s "name" or "comment" is changed;
*) ipsec - fixed client certificate usage when certificate is renewed with SCEP;
*) ipsec - improved SA update by SPI;
*) ipsec - inactivate peer''s policy on disconnect;
*) ipv6 - improved system stability when parsing IPv6 options;
*) kidcontrol - allow creating static device entries without assigned user;
*) led - fixed default LED configuration for RB911-5HnD;
*) led - fixed state persistence after device reboot on NetMetal 5 ac devices;
*) leds - fixed "/system leds" menu on RBLHG-2nD;
*) lora - added additional predefined network servers;
*) lora - added additional predefined network servers;
*) lora - added option to hide CRC error messages in monitor;
*) lora - improved downlink transmission;
*) lora - fixed device going into "ERROR" state caused by FSK modulated downlinks;
*) lora - limited output power in RU region for range 868.7 MHz - 869.2 MHz according to regulations;
*) lte - added support for Alcatel IK41VE1;
*) lte - added "comment" parameter for APN profiles;
*) lte - added "age" column and "max-age" parameter to "cell-monitor" (CLI only);
*) lte - added support for Sharp 809SH;
*) lte - fixed "earfcn" to band translation for "cell-monitor";
*) lte - fixed "band" value reporting;
*) lte - fixed "earfcn" to band translation for "cell-monitor";
*) lte - increased "at+cops" reply timeout to 90 seconds;
*) m33g - added support for "/system gpio" menu (CLI only);
*) metarouter - allow creating RouterOS metarouter instances on devices with 16MB flash storage;
*) metarouter - fixed memory leak when tearing down metarouter instance;
*) netinstall    - require Netinstall version to be the same or newer as "factory-software";
*) ospf - fixed type-7 LSA translation to type-5;
*) ovpn - fixed route cache entry leak when establishing a new session;
*) ovpn - fixed route cache entry leak when establishing a new session;
*) package - do not include multiple The Dude packages in HDD installer;
*) package - added new "iot" package with Bluetooth (KNOT only) and MQTT publisher support;
*) poe - do not perform PoE firmware upgrade procedure on RB960 and OmniTik devices without PoE out;
*) poe - do not perform PoE firmware upgrade procedure on RB960 and OmniTik devices without PoE out;
*) poe - update PoE firmware only on devices that supports it;
*) ppp - added "bridge-learning" parameter support;
*) ppp - added "ipv6-routes" parameter to "secrets" menu;
*) ppp - added support for "Framed-IPv6-Route" RADIUS attribute;
*) ppp - do not fail "at-chat" command when issued on disabled PPP interface;
*) ppp - do not fail "at-chat" command when issued on disabled PPP interface;
*) ppp - improved stability when receiving bogus response on modem channel;
*) ppp - store "last-caller-id" for PPP secrets;
*) ppp - store "last-disconnect-reason" for PPP secrets;
*) profile - added "lcd" process classificator;
*) profile - improved idle process detection on x86 processors;
*) profile - improved process classification on ARM devices;
*) ptp - improved management service stability when receiving bogus packets;
*) ptp - improved management service stability when receiving bogus packets;
*) qsfp - improved system stability when setting unsupported link rates;
*) quickset - prefer 5GHz interface for WiFi scan in CPE mode;
*) quickset - added "Port Mapping" to QuickSet;
*) quickset - fixed local IP address setting on master interface;
*) quickset - prefer 5GHz interface for WiFi scan in CPE mode;
*) rb3011 - improved system stability when changing RouterBOARD settings (introduced in v6.48);
*) rb4011 - improved SFP+ port stability after boot-up;
*) rb4011 - fixed SFP+ port MTU setting after link state change;
*) rb4011 - fixed SFP+ port MTU setting after link state change;
*) rb4011 - improved SFP+ port stability after boot-up;
*) route - improved stability when connected route is modified;
*) route - improved stability when 6to4 interface is configured with disabled IPv6 package;
*) route - improved stability when connected route is modified;
*) routerboard - fixed PCIe bus reset during power-on on MMIPS devices ("/system routerboard upgrade" required);
*) routerboard - fixed "reset-button" on hAP ac;
*) routerboard - force power-down on PCIe bus during reboot on LHGR devices ("/system routerboard upgrade" required);
*) script - added error message in the logs if startup script runtime limit was exceeded;
*) sfp - added "sfp-rate-select" setting (CLI only);
*) sfp - improved cable length monitoring as defined per SFF-8472 and SFF-8636;
*) sfp - improved SFP, SFP+, SFP28 and QSFP+ interface stability for CRS3xx and CCR2004 devices;
*) sfp - improved cable length monitoring as defined per SFF-8472 and SFF-8636;
*) sfp28 - changed FEC auto mode to disabled;
*) snmp - fixed SNMP trap agent address;
*) snmp - added information from IPsec "active-peers" menu to MIKROTIK-MIB;
*) snmp - fixed value types for "dot1qPvid";
*) snmp - fixed value types for "dot1dStp";
*) snmp - added new LTE monitoring OID''s to MIKROTIK-MIB;
*) snmp - fixed "send-trap" functionality (introduced in v6.48);
*) ssh - fixed returned output saving to file when "output-to-file" parameter is used;
*) ssh - return proper error code from executed command;
*) ssh - skip interactive authentication when not running in interactive mode;
*) supout - fixed "topic" column presence in "Log" section;
*) supout - improved autosupout.rif file generation process;
*) supout - added bonding interface monitor information;
*) supout - fixed "topic" column presence in "Log" section;
*) switch - improved system stability with 98PX1012 switch chip for CCR2004-1G-12S+2XS device;
*) switch - improved system stability with 98PX1012 switch chip for CCR2004-1G-12S+2XS device;
*) switch - fixed interface toggling for devices with multiple QCA8337, Atheros8327 or RTL8367 switch chips (introduced in v6.48);
*) switch - improved resource allocation on 98PX1012 switch chip for CCR2004-1G-12S+2XS device;
*) system - improved resource allocation (improves several service stability e.g. HTTPS, PPPoE, VPN);
*) system - improved resource allocation (improves several service stability e.g. HTTPS, PPPoE, VPN);
*) system - improved stability when receiving bogus packets;
*) telnet - do not send options if connecting to non standard port;
*) telnet - fixed "routing-table" parameter usage;
*) telnet - do not send options if connecting to non standard port;
*) telnet - fixed server when run on non standard port;
*) telnet - fixed server when run on non standard port;
*) tile - fixed bridge performance degradation (introduced in v6.47);
*) tile - fixed bridge performance degradation (introduced in v6.47);
*) timezone - updated timezone information from "tzdata2020d" release;
*) tr069-client - fixed RouterOS downgrade procedure;
*) tr069-client - added branding package build time parameter;
*) tr069-client - added wireless "noise-floor" and "overall-tx-ccq" information parameters;
*) tr069-client - allow passing LTE firmware update URL as XML;
*) tr069-client - added additional wireless registration table parameters;
*) tr069-client - fixed TotalBytesReceived parameter value;
*) tr069-client - send correct "ConnectionRequestURL" when using IPv6;
*) tr069-client - added LTE model and revision parameters;
*) tr069-client - added "X_MIKROTIK_MimoRSRP" parameter for LTE RSRP value reporting;
*) tr069-client - improved management service stability when receiving bogus packets;
*) tr069-client - improved management service stability when receiving bogus packets;
*) traffic-flow - added "sys-init-time" parameter support;
*) traffic-flow - added NAT event logging support for IPFIX;
*) traffic-generator - fixed 32Gbps limitation;
*) upgrade - improved "long-term" upgrade procedure on SMIPS devices;
*) upgrade - fixed upgrade procedure on 16MB devices;
*) upgrade - improved "long-term" upgrade procedure on SMIPS devices;
*) user - fixed "skin" configuration for user groups (introduced in v6.48);
*) user-manager - do not allow creating limitation that crosses midnight;
*) user-manager - updated PayPal''s root certificate authorities;
*) w60g - use EU region by default;
*) w60g - limit power output when using region EU to match EN302567 on nRAY;
*) w60g - improved stability in low temperature environments;
*) webfig - allow hiding QuickSet mode selector;
*) webfig - properly stop background processes when switching away from QuickSet tab;
*) webfig - allow hiding and renaming inline buttons;
*) webfig - fixed default value presence when creating new entries under "IP/Kid Control";
*) webfig - allow to specify "prefix" parameter under "IPv6/ND/Prefixes" menu;
*) webfig - do not corrupt settings when starting "Wireless Sniffer";
*) webfig - do not show newly created SMB shares as invalid;
*) webfig - do not move top right menu in opposite direction when scrolling horizontally;
*) webfig - fixed new interface addition;
*) webfig - show "Interfaces" menu by default after logging in;
*) webfig - do not show "units" twice in multi list entries;
*) webfig - do not move top right menu in opposite direction when scrolling horizontally;
*) webfig - show "network-mode" for LTE modems that support it;
*) webfig - fixed "PortMapping" button (introduced in v6.48.2);
*) webfig - allow to specify "prefix" parameter under "IPv6/ND/Prefixes" menu;
*) webfig - do not corrupt settings when starting "Wireless Sniffer";
*) webfig - show "network-mode" for LTE modems that support it;
*) winbox - added missing IGMP Snooping settings to "Bridge" menu;
*) winbox - added missing MSTP settings to "Bridge" menu;
*) winbox - added support for LTE Cell Monitor;
*) winbox - allow adding bonding interface with one slave interface;
*) winbox - allow performing "USB Power Reset" on "0" bus on RBM33G;
*) winbox - do not show "network-mode" parameter for LTE interfaces that do not support it;
*) winbox - fixed "IP->Kid Control->Devices" table automatic refreshing;
*) winbox - fixed "interface" and "on-interface" parameter presence under "Bridge/Hosts" menu;
*) winbox - fixed "receive-errors" setting persistence under "Wireless/Wireless Sniffer/Settings" menu;
*) winbox - fixed "tls-version" parameter setting under "IP/Services" menu;
*) winbox - fixed minor typo in "Users" menu;
*) winbox - provide sane default values for bridge "VLAN IDs" parameter;
*) winbox - use health values reported by gauges for "System/Health" menu;
*) winbox - added "Cloud Backup" options under "Files" menu;
*) winbox - fixed health reporting on RB960, hEX and hEX S devices;
*) winbox - show "current-channel" column by default for CAP interfaces;
*) winbox - show "System/Health/Settings" only on boards that have configurable values;
*) winbox - do not show "GPS antenna" selection for devices without selection support;
*) winbox - allow setting MCS (24-31) to 4x4 Wireless interfaces;
*) winbox - added "name" and "file-name" parameter when importing and exporting certificates;
*) winbox - show "System/Health" only on boards that have health monitoring;
*) winbox - fixed "Switch" menu on RBwAPG;
*) winbox - fixed enable/disable button presence for "Bridge/Hosts" menu;
*) winbox - show "activity" column by default under "IP/Kid Control/Devices" menu;
*) winbox - show "System/Health" only on boards that have health monitoring;
*) winbox - show "LCD" only on boards that have LCD;
*) winbox - renamed IP protocol 41 to "ipv6-encap";
*) winbox - increased "target" field limit to 128 under "Queues" menu;
*) winbox - hide "Allow Roaming" parameter on LTE modems that do not support it;
*) winbox - fixed duplicate "Trusted" setting under "Interface/Bridge/Ports" menu;
*) winbox - fixed QCA-8511 switch chip type reporting under "Switch/Settings" menu;
*) winbox - fixed "reachable-time" value unit under "IPv6/ND" menu;
*) winbox - do not show empty "CPU Frequency" parameter under "System/Resources" menu;
*) winbox - added "Channel" parameter under "System/Console" menu;
*) winbox - added "interworking-profile" parameter under "Wireless" menu;
*) winbox - added support for PTP;
*) winbox - do not show "Functionality" field for LTE interface if it is not provided;
*) winbox - fixed "vid" parameter under "Bridge/Hosts" menu;
*) winbox - show "System/Health" only on boards that have health monitoring;
*) winbox - do not allow to set empty "init-string" field under "System/GPS" menu;
*) winbox - added "src-mac-address" parameter under "IP/DHCP-Server/Leases" menu;
*) winbox - do not show "network-mode" parameter for LTE interfaces that do not support it;
*) winbox - do not show empty "CPU Frequency" parameter under "System/Resources" menu;
*) winbox - fixed "reachable-time" value unit under "IPv6/ND" menu;
*) winbox - fixed QCA-8511 switch chip type reporting under "Switch/Settings" menu;
*) winbox - fixed health reporting on RB960, hEX and hEX S devices;
*) winbox - hide "Allow Roaming" parameter on LTE modems that do not support it;
*) winbox - increased "target" field limit to 128 under "Queues" menu;
*) winbox - show "LCD" only on boards that have LCD;
*) winbox - show "System/Health" only on boards that have health monitoring;
*) winbox - show "activity" column by default under "IP/Kid Control/Devices" menu;
*) wireless - added U-NII-2 support for US and Canada country profiles for mANTBox series devices;
*) wireless - improved WPS process stability;
*) wireless - added U-NII-2 support for US and Canada country profiles for hAP ac lite;
*) wireless - increased "group-key-update" maximum value to 1 day;
*) wireless - updated "indonesia5" regulatory domain information;
*) wireless - updated "no_country_set" regulatory domain information;
*) wireless - do not override MTU and ARP values from CAPsMAN with local forwarding;
*) wireless - added U-NII-2 support for US and Canada country profiles for hap ac, hAP ac^3 LTE6, Audience and Audience LTE6;
*) wireless - updated "israel" regulatory domain information;
*) wireless - renamed "macedonia" regulatory domain information to "north macedonia";
*) wireless - added U-NII-2 support for US and Canada country profiles for hAP ac^3;
*) wireless - create "connect-list" rule when address specified for "setup-repeater";
*) wireless - fixed issue with multicast traffic delivery to client devices using power-save;
*) wireless - improved iOS compatibility with HotSpot 2.0 networks;
*) wireless - fixed issue with multicast traffic delivery to client devices using power-save;
*) wireless - improved iOS compatibility with HotSpot 2.0 networks;
*) www - added "X-Frame-Options" header information to disallow website embedding in other pages;
*) www - added "X-Frame-Options" header information to disallow website embedding in other pages;

anav · Fri Oct 08, 2021 10:21 pm

so far so good on a hex as a switch, and capac. will to tile device later today.
tile updated without incidence ccr1009

infabo · Sat Oct 09, 2021 2:37 am

updated fine on RB941-2nD and RBmAPL-2nD from 6.47.10.

randomwalk · Sat Oct 09, 2021 6:11 am

Hi, I think I found what seems to be a bug in the dns, although I'm not sure what versions are affected.
(here, I ran 'nslookup' to get the actual IP addresses of www.example.com used for demonstration purposes.

# first let's add some new A and AAAA dns records for www.example.com
/ip dns static add name=www.example.com address=93.184.216.34 
/ip dns static add name=www.example.com address=2606:2800:220:1:248:1893:25c8:1946 

# and run some tests on the dns STATIC table...
/ip dns static print terse where name=www.example.com 
 0    name=www.example.com address=93.184.216.34 ttl=1d  # <---- notice this is not a 'type A' record
 1    name=www.example.com type=AAAA address=2606:2800:220:1:248:1893:25c8:1946 ttl=1d 

/ip dns static print terse where name=www.example.com type=A # <---- issue right here (no output)

/ip dns static print terse where name=www.example.com type!=A # <---- another issue here 
 0    name=www.example.com address=93.184.216.34 ttl=1d 
 1    name=www.example.com type=AAAA address=2606:2800:220:1:248:1893:25c8:1946 ttl=1d 

/ip dns static print terse where name=www.example.com type=AAAA 
 0    name=www.example.com type=AAAA address=2606:2800:220:1:248:1893:25c8:1946 ttl=1d 

/ip dns static print terse where name=www.example.com type!=AAAA 
 0    name=www.example.com address=93.184.216.34 ttl=1d 

# Now Let's verify the output of these exact same commands run on the dns CACHE table:
/ip dns cache print terse where name=www.example.com 
 0 S type=A data=93.184.216.34 name=www.example.com ttl=1d 
 1 S type=AAAA data=2606:2800:220:1:248:1893:25c8:1946 name=www.example.com ttl=1d 

/ip dns cache print terse where name=www.example.com type=A 
 0 S type=A data=93.184.216.34 name=www.example.com ttl=1d 

/ip dns cache print terse where name=www.example.com type!=A 
 0 S type=AAAA data=2606:2800:220:1:248:1893:25c8:1946 name=www.example.com ttl=1d 

/ip dns cache print terse where name=www.example.com type=AAAA 
 0 S type=AAAA data=2606:2800:220:1:248:1893:25c8:1946 name=www.example.com ttl=1d 

/ip dns cache print terse where name=www.example.com type!=AAAA 
 0 S type=A data=93.184.216.34 name=www.example.com ttl=1d 

# The output of "/ip dns static print" and "/ip dns cache print" commands is expected to be identical, but it's not.
# At the same time the output of "/ip dns cache print" seems to be correct.

So far the issue has manifested itself only during tests of a script that I'm writing, as I don't use IPv6 in production.
I'm interested to hear some feedaback on this. Thanks

birdsky · Sat Oct 09, 2021 6:37 am

- 6.48.5 was released in long term without any time spent in stable channel. This is bad long term channel management.
- 6.48.5 changelog is in respect to 6.48.4 and not in respect to 6.47.10 (which was last long term channel release). This is bad long term channel management.
- 6.48.5 auto upgrade failed on HAP AC2. The wireless package failed to run after upgrade. So, this package was released with limited testing. This is bad long term channel management.

I expect Mikrotik to do better so that we can use long term channel packages in production.

randomwalk · Sat Oct 09, 2021 7:26 am

... so I found this change not documented in Long -Term 6.48.5

What's new in 6.48 (2020-Dec-22 11:20):
*) dns - do not use type "A" for static entries with unspecified type;

...And did some more tests... Here are my findings:

adding a new record like that:

/ip dns static add name=www.example.com address=93.184.216.34

or like this:

/ip dns static add name=www.example.com address=93.184.216.34 type=A

Makes No Difference! (the outcome of both cases is identical and described in my previous post here viewtopic.php?t=179260#p884813)
___
P.S. I understand the rational, perhaps in an attempt to avoid potential incompatibilities of legacy IPv4 scripts with newer IPv6 features,
Or, is the actual reason so to make it more convenient for developers to transition to RouterOS v7 ?
but please elaborate on "do not use type "A" for static entries with unspecified type"
and then how come these two commands "/ip dns static print" and "/ip dns cache print" produce such different output?
(FYI: Just so to understand the importance here is an example: searching a single record in a table of 80K+ records returns a result 25% faster if I search in "/ip dns cache" compared to "/ip dns static")

--
PS.PS.
Honestly the output of "/ip dns cache" is the expected behaviour. And the following "feature"

*) dns - do not use type "A" for static entries with unspecified type;

is either a bug, or in a very early Alpha, (not even "Beta") stage.

PS.PS.PS.
It's an ugly bug. That also present in 6.47.10 (long term) - observed same behaviour after a downgrade.
Digging more reveals some relevant changes made as early as 6.47.3:

*) dns - hide default static entry "type" from export;

--
Fix It. (pardon my French).
Please and thank you.

Jotne · Sat Oct 09, 2021 9:25 am

So lets see how the actual release notes for long-term v6.48.5 upgrade from v6.47.10 looks like:

Nice post.

What MT should do is to make a web page where you select two different release and it will then show all changes between those two releases.
Some like to see difference between 6.48.4 to 6.48.5 other 6.47.10 and 6.48.5. Some my upgrade from 6.48.2 to 6.48.5, so then those changes should be shown.

Caci99 · Sat Oct 09, 2021 10:15 am

I think it has been already discussed a lot about the change log of long term releases. What they will put in the forum as change log is the change to the latest stable version from which the long term has derived. If one wants to see the whole change from the latest long term release you can find it in the change log archive in their web page.
What is different this time is that Mikrotik gave less than two months to last stable release 6.48.4 to pass it on the long term release. Previous releases gave more time to the preceding stable version if I recall it correctly. Maybe they didn't have much tickets from 6.48.4 or maybe they just have strengthen their testing team ( I hope ).

pe1chl · Sat Oct 09, 2021 11:17 am

What is different this time is that Mikrotik gave less than two months to last stable release 6.48.4 to pass it on the long term release. Previous releases gave more time to the preceding stable version if I recall it correctly. Maybe they didn't have much tickets from 6.48.4 or maybe they just have strengthen their testing team ( I hope ).

Well, what I find most irritating is that the stable release was 6.48.4 (and it had some known problems e.g. in DNS resolver) and now it is quickly upgraded to 6.48.5 and declared long-term.
This is no problem in the strict definition of long-term in that this will be supported all the time that 6.49 (which is now in "stable") is getting fixed, but lots of users see long-term as a reliable version that they can deploy in production without worrying about unforeseen new bugs, because it has been througly tested not only by MikroTik but also by a wide user base. But this version 6.48.5 has not been tested by the user base at all! We still need to verify that the new fixes between .4 and .5 did not do any damage.

For now I keep my routers that run long-term on version 6.47.10 until this version has received more testing. I would prefer it when the latest stable version is promoted to long-term, not a quick fixup version after that. 6.49 could have waited.

shipwreck · Sat Oct 09, 2021 12:22 pm

Did anyone find documentation about the new properties nat-events and sys-init-time in /ip traffic-flow ipfix? I didn't even find the word ipfix neither on wiki.mikrotik.com nor on help.mikrotik.com. Is wiki.mikrotik.com even updated or to be considered up-to-date still?

Jotne · Sat Oct 09, 2021 12:33 pm

Well, what I find most irritating is that the stable release was 6.48.4 (and it had some known problems e.g. in DNS resolver) and now it is quickly upgraded to 6.48.5 and declared long-term.

Changing one version from stable to longterm is nothing new, and with all changes there was bugs before, and new bugs after...
I do also see people complaining than stable changes to long term. If that is not the way to do it, how to do it then.
Hopefully it will be better with time...

6.47.8 stable -> 6.47.9 Long term
6.46.6 stable -> 6.46.7 Long term
6.45.7 stable -> 6.45.8 Long term
...

Also to people complaining that there are many bugs.

When I looked on some threads, you make very basic bugs in every new firmware...Is this normal programming? Because when I buy some crap Asus, TP-Link...it has more stable firmware, than this...

Try to compare the functionality and what they can do. The other does not even reach to knees of RouterOS in number of function compared to price.
Everyone is free to select what they like best. I do love RouterOS...💗

npeca75 · Sat Oct 09, 2021 12:55 pm

... compared to price.

wait @Jotne
from your writings, it is legal to MKT make again and again and again same mistakes because it is "only" 200 USD in compare to , lets say, Cisco or Juniper 1000 USD?

so, the expectation to bugs and features which are stable remain stable in 6.x branch is too much? because price is only 200$$$ ?
woooa
what a new approach to programming
we make it good, but because it is only 200USD we will break it again ?
come on
i hope i will find one day company like MKT where i could screw up whatever and have 1000 beta users for FREE to test what i screwed up

winap · Sat Oct 09, 2021 1:03 pm

Try to compare the functionality and what they can do. The other does not even reach to knees of RouterOS in number of function compared to price.
Everyone is free to select what they like best. I do love RouterOS...

Mikrotik has more options, yes...But only non functionality feature! Tell me...If some HW has more options, which not functions correctly...Is this really necessary to have it?
Because when some people setup it, and in new FW don't function properly ..so what the hell is it for me this function, when is not working? Because some function is ok, some not working in new version..so the functions is now ok, but other don't...so it is the same...no function, because in some hour, days it want restart! Or the SW/HW doing what it want yourself and not, what I want..And the sensors of voltage or temp is really basic function.Yes..it has sensors, but when it show fail data, what the hell is it for me?
Yes..the other manufacture company are sometimes expensiver, because we pay for advertisement for TV company. It has less functions, but not so buggy.

infabo · Sat Oct 09, 2021 1:08 pm

When you buy TPLink you may get 1 or 2 updates in the lifecycle of the device. Then it is EOL. The reason to buy "crap" from TPLink, Asus and Co. is simply: when such a device has OpenWrt support - then you get a well performing device for cheap with some futureproof opensource firmware on it.

winap · Sat Oct 09, 2021 1:34 pm

When you buy TPLink you may get 1 or 2 updates in the lifecycle of the device. Then it is EOL. The reason to buy "crap" from TPLink, Asus and Co. is simply: when such a device has OpenWrt support - then you get a well performing device for cheap with some futureproof opensource firmware on it.

Yes, but when I don't need all this functions, so it is ok for me. Mikrotik has good HW. Others no...
But when the FW is ok, I don't need updates every month, so? When the SW is buggy, the costumers see, oh look MK has FW updates every month/half. But when you look closely, the buggy FW need to updates every month, because it contains many function, which not functions correctly. So it is nice to have all of this, but why..if this function function in falf.
I only use my logic...So I repeat..It is nice to have more options, but when it function in half, it is not for me and I take some other brand, so it function correct. And OpenWrt is ok..I had on my old Asus. It was better, than original. Why? it is open..and mikrotik is closed. So is it problem, if Mikrotik want to ask for help other people to programing some parts of code? We are people and when we help each other, it will be better place for us.

infabo · Sat Oct 09, 2021 3:09 pm

@winap
All these original firmware on devices like Linksys, Asus, Tplink just suck. Always bubbly weird customer oriented webinterfaces. After years you have a whole a lot of security concerns running these devices with their many years outdated software. no, these devices suck out of the box. Openwrt - yes is great. you can't compare apples with pears.

Amm0 · Sat Oct 09, 2021 3:53 pm

Hi,
Just applied the upgrade. Why is the multicast package missing? I have to use IGMP Proxy and now it's not available.

EDIT: I had to re-download the multicast package included in all_packages.zip, then applied it and everything back to normal. If I remember right the last time I did an upgrade I did not have to upgrade the multicast package separately. Can somebody confirm? Maybe I'm wrong about that. I'm also a quite new MT user, so sorry for that.
Might also be the case that last time I upgraded via system/packages/check for updates/download and install, which might be different from downloading and applying manually.

Thanks

Just applied the upgrade. Why is the multicast package missing? I have to use IGMP Proxy and now it's not available.

EDIT: I had to re-download the multicast package included in all_packages.zip, then applied it and everything back to normal. If I remember right the last time I did an upgrade I did not have to upgrade the multicast package separately. Can somebody confirm? Maybe I'm wrong about that. I'm also a quite new MT user, so sorry for that.
Might also be the case that last time I upgraded via system/packages/check for updates/download and install, which might be different from downloading and applying manually.

Normally, they all do get upgraded/downgraded – if you had any extra packages installed. And, normally, should be complete safe to upgrade to the latest "long-term". That sound like a bug...

But I think your posting highlight why people in this thread are talk about the "poor release management", since normally a long-term build is tested in "testing" and "stable" build channel before going to long term. I swear some poor soul, like the poster above, who tried release a "testing" or "stable" version would have found the package upgrade issue before going to "long term". As noted, it's pretty fixable, just annoying and potentially missed by admin who thought doing a "long term" upgrade be pretty safe and require only basic test after...

Now, in fairness to Mikrotik, they haven't had a major release in MANY years, so imagine they're trying to align upgrades/stuff to enable smoothly moving from v6 to v7 – although seemingly gambling with a rushed "long-term" at the same time.

To the OpenWRT poster – everything has it's place - but I'd like to see someone get the features of the "multicast" package, like PIM/IGMP Proxy on OpenWRT working as easily as dragging the package (normally only once then auto-upgraded), that then work the same on dozens devices ranging from $30-1000+. If growing WISP needed add "calea" or TR-069, or developer needed some MQTT solution with OpenWRT, someone is reading a few dense man pages and messing with config files...

Caci99 · Sat Oct 09, 2021 4:30 pm

Mikrotik has more options, yes...But only non functionality feature!

That is stretching the reality by quite some lengths beyond imagination.
I do run small and big networks based on Mikrotik and hardly can recall any bug impacting the network, performance wise there are things I wish they can do better, but bugs to bring down a network? Not any I can think of.

pe1chl · Sat Oct 09, 2021 4:53 pm

Well, what I find most irritating is that the stable release was 6.48.4 (and it had some known problems e.g. in DNS resolver) and now it is quickly upgraded to 6.48.5 and declared long-term.
Changing one version from stable to longterm is nothing new, and with all changes there was bugs before, and new bugs after...
I do also see people complaining than stable changes to long term. If that is not the way to do it, how to do it then.
Hopefully it will be better with time...

I am not complaining that there are bugs or missing features, there always are.
But in general the "stable" versions become stabilized (bugfree) more and more with increased .n version and a version that has long been in the stable channel and for which you can read forum topics about known problems at some point can be trusted in places that you consider "important", i.e. where you run the long-term version.

However, we also have seen sometimes that a bundle of backports are done from the testing version into stable and it introduced new problems. So after that, it should be run as stable channel release for some time again before it is declared long-term.

At this point in time I was not convinced that the 6.49rc2 version was stable enough to be promoted, and this of course triggered the promotion of 6.48 to long-term.
Some more testing would have been warranted.
But of course we do no auto-upgrades so we can still wait a while before upgrading the routers running the long-term version.

winap · Sat Oct 09, 2021 5:50 pm

@winap
All these original firmware on devices like Linksys, Asus, Tplink just suck. Always bubbly weird customer oriented webinterfaces. After years you have a whole a lot of security concerns running these devices with their many years outdated software. no, these devices suck out of the box. Openwrt - yes is great. you can't compare apples with pears.

Yes, OpenWrt is ok for this device and it's also for simple user and the function is good. This is problem on the both sides...TP-Link, Asus..cheap HW, but on SW sides is ok. TP-Link is dead after 2 years of using (HW problems).. Mikrotik has very good HW and the SW is buggy...Not open for open source, or different SW.
So like woman : good hardware, but the software is bad. HW is good, but I don't know, what will be in next update.

winap · Sat Oct 09, 2021 6:04 pm

That is stretching the reality by quite some lengths beyond imagination.
I do run small and big networks based on Mikrotik and hardly can recall any bug impacting the network, performance wise there are things I wish they can do better, but bugs to bring down a network? Not any I can think of.

I mean , If i reading posts on this forum, some people has problems with auto restarting, non functional internet after few days, non function sensors of voltage/temp..Non functional Jumbo frame..this are a simple mistakes and it has no deep problem in programming. This must can do every HW router...I have rb5009 and wifi, but I must waiting for better software on it, because I don't want to be a beta-tester like windows users. Some unit has only 16MB flash and if I reinstall SW every month, we know, so the bad blocks will be only decrease it.
And this is the same on Mikrotik Switch...I like new FW, because I want better SW. But this is the same on MK switch..so buggy on basic functions...

Moba · Sun Oct 10, 2021 1:14 am

Yes, OpenWrt is ok for this device and it's also for simple user and the function is good. This is problem on the both sides...TP-Link, Asus..cheap HW, but on SW sides is ok. TP-Link is dead after 2 years of using (HW problems).. Mikrotik has very good HW and the SW is buggy...Not open for open source, or different SW.
So like woman : good hardware, but the software is bad. HW is good, but I don't know, what will be in next update.

Who is forcing you to use any MikroTik products? And ASUS? Really? They buy off the shelf parts and put them in plastic boxes to meet a price point, just like MT does, but in the general consumer market. So does TP-Link. Their hardware fails and they have software issues just like every other consumer product manufacturer: Overheating SoCs, dead radios, cracking plastics due to heat, bricked hardware after updates, poor designs reaching EOL too soon, etc. Cheap? They have plastic boxes in CCR territory nowadays. And their router software is OK? How about non functional closed source spyware SQM, buggy drivers, basic kernel level QoS that was broken for years, the countless bugs fixed by Merlin and John on supported routers (I hope they donate generously to them) and the bloated mess that makes even great consumer SoCs feel sluggish. Regardless, I would still recommend ASUS for home use to family and friends who can't be bothered to learn networking or pay to have it set up properly (SOHO).

Open source SoC and switch support is not up to MT and OpenWrt is hardly an alternative to ROS. There's a reason why the latter is licensed and close source. Even market leader Cisco, who has been supporting open source for decades, has proprietary code.

Here's my friendly advice to people who can't handle any downtime/major issues: Let others do the beta testing (even on long term releases at this point).

Could you please list the bugs you're experiencing clearly, if any, instead of ranting about how bad MikroTik is in multiple posts? You'll also get more mileage for your trouble if you send your bugs reports directly to MikroTik and keep your opinions about women out of it. I agree, the bugs need to addressed... ;)

Dude2048 · Sun Oct 10, 2021 11:40 am

What Moba said, and now back on topic.

jamsden · Sun Oct 10, 2021 5:20 pm

Upgraded my devices, RB1100AHx4, CRS112-8P and mAP lite, while HapAC3 doesn’t find any update. mAP lite shows an increase in memory usage:

Screenshot 2021-10-10 at 07.57.02.png

Is it normal?

Thank you.

winap · Sun Oct 10, 2021 5:41 pm

To Moba:
Nobody, but find good HW is very hard. I don't need router with wifi, so almost every router has wifi part. I wanted strong router, but also a good software on it.
So I choosed mikrotik, but I don't know, how buggy is. I still hoping, it will be better...
If I buy router around 200USD, I also hope, the software will be usable and stable. And that's my standarts.

Moba · Mon Oct 11, 2021 1:02 am

To Moba:
Nobody, but find good HW is very hard. I don't need router with wifi, so almost every router has wifi part. I wanted strong router, but also a good software on it.
So I choosed mikrotik, but I don't know, how buggy is. I still hoping, it will be better...
If I buy router around 200USD, I also hope, the software will be usable and stable. And that's my standarts.

What is buggy? Which issues are you having? My RB4011 runs fine without reboots or anything (even with "ultra buggy" WiFi that needs a little love to setup). It ran on its own on 6.48.3 this summer for 63 days without a single problem while I was on vacation. Isn't that usable and stable? I don't use all the features, so others might have issues that I don't.

I don't have the RB5009 yet, but I assume the internal release it ships with is functional - if it isn't, you return the router. Everything v7 is otherwise beta. Unless you actually post specific problems, I'm sorry, you're trolling, and nobody here can help you.

razortas · Mon Oct 11, 2021 5:41 am

Ok so Files upgraded as expected but when i upgraded the routerboard version on two devices RB2011 access to devices was lost. Device is booting with ether boot displayed - have so far been unsucessful in factory reset and therfore cant use Netinstall iether. They both appear to be bricked.

sindy · Mon Oct 11, 2021 8:16 am

Have you tried booting into the previous version of the bootloader by pressing the reset button before applying power? See the "reset button" manual for details.

mkamenjak · Mon Oct 11, 2021 8:32 am

Ok so Files upgraded as expected but when i upgraded the routerboard version on two devices RB2011 access to devices was lost. Device is booting with ether boot displayed - have so far been unsucessful in factory reset and therfore cant use Netinstall iether. They both appear to be bricked.

I can reproduce. I have upgraded one RB 2011, routeros upgraded successfully, although it took 2min+ to upgrade. Routerboot upgrade bricked the device. It is a remote device so I can not press any reset button.
On the other hand I have 1 other RB 2011 that upgraded routerboot successfully.

karlisi · Mon Oct 11, 2021 10:18 am

Especially since even the changelog references a non-existing long-term release in relation to changes from v6.48.4 and not the actual predecessor v6.47.10 .
https://mikrotik.com/download/changelog ... lease-tree

So lets see how the actual release notes for long-term v6.48.5 upgrade from v6.47.10 looks like:

I discussed about this with Normis some time ago and he insisted Mikrotik does it properly, there shouldn't be cumulative changelogs, we should read all changelogs by ourselves. The reason is - in cumulative changelog it is impossible to see all changes if version goes from one channel to another. I.e., some feature is introduced while v.6.48 was in stable channel, then patched 3 times still in stable, then v.6.48 goes to long-term, and in cumulative changelog we will see only this new feature introduced and nothing about it's evolution from initial trough these 3 patches. This was how I understood his arguments.

Joni · Mon Oct 11, 2021 10:41 am

Especially since even the changelog references a non-existing long-term release in relation to changes from v6.48.4 and not the actual predecessor v6.47.10 .
https://mikrotik.com/download/changelog ... lease-tree

So lets see how the actual release notes for long-term v6.48.5 upgrade from v6.47.10 looks like:
I discussed about this with Normis some time ago and he insisted Mikrotik does it properly, there shouldn't be cumulative changelogs, we should read all changelogs by ourselves. The reason is - in cumulative changelog it is impossible to see all changes if version goes from one channel to another. I.e., some feature is introduced while v.6.48 was in stable channel, then patched 3 times still in stable, then v.6.48 goes to long-term, and in cumulative changelog we will see only this new feature introduced and nothing about it's evolution from initial trough these 3 patches. This was how I understood his arguments.

Post configuration (i.e. example) or it didn't happen.
Mikrotik has a lot of peculiar views they insist on being proper, diverging from de facto ways.

If v6.48 is patched 3 times it becomes v6.48.3 and it is still the same version v6.48.3 just labeled long-term (or as mikrotik seems to prefer it, incremented by one v6.48.4, i.e. reserved numbers). Technically a long-term labeled release is not cumulative for the long-term release tree, it is the next release just versioned in relation to stable. For the sake of simplification the long-term release tree doesn't know a stable tree or testing even exists. All the things new and changed between versions in long-term are all new and all changed in relation to previous version in that tree. That is even supported by long-term tree getting bug-fixes growing on post-current stable version numbers, maintaining full parity with stable tree, as seen with v6.46.6 stable becoming v6.46.7 long-term and betting bug-fixed with v6.46.8 long-term while next stable after v6.46.6 stable was v6.47.0 stable .

pe1chl · Mon Oct 11, 2021 10:54 am

I discussed about this with Normis some time ago and he insisted Mikrotik does it properly, there shouldn't be cumulative changelogs, we should read all changelogs by ourselves.

I think MikroTik should put all changelog items in a database keyed with version number where they are added and version number where they become superseded, and then provide a webpage where you can enter two version numbers and get a customized changelog between those two versions.
Channel (stable, long-term, testing) does not matter in this case.
Ideally, some items in the database would have a more detailed description, a link to documentation, or other info. You can get that by clicking somewhere in the listed changes.

This way, it is much easier to foresee the impact of a certain upgrade, and also to get info about some change without having to ask for it in the release topic.
I can understand the changelog items have to be kept to one line for brevity, but often there is a little more to explain about them.

karlisi · Mon Oct 11, 2021 11:31 am

Post configuration (i.e. example) or it didn't happen.

No time to search exact sample, but in stable channel changelogs these 'fixed (or reverting) something, introduced in some previous release' occurs quite often. Why I should trace down all these introduced-fixed-removed I don't understand but MT knows better :)

karlisi · Mon Oct 11, 2021 11:33 am

I think MikroTik should put all changelog items in a database keyed with version number where they are added and version number where they become superseded, and then provide a webpage where you can enter two version numbers and get a customized changelog between those two versions.
Channel (stable, long-term, testing) does not matter in this case.
Ideally, some items in the database would have a more detailed description, a link to documentation, or other info. You can get that by clicking somewhere in the listed changes.

Yes! I hope people from Mikrotik will read this.

karlisi · Mon Oct 11, 2021 11:36 am

Post configuration (i.e. example) or it didn't happen.
No time to search exact sample, but in stable channel changelogs these 'fixed (or reverting) something, introduced in some previous release' occurs quite often. Why I should trace down all these introduced-fixed-removed I don't understand but MT knows better :)

Perhaps this
viewtopic.php?f=21&t=150045&p=738887#p739011

resetsa · Mon Oct 11, 2021 7:40 pm

After update from 6.47.7 on CRS112-8P-4S ospf cannot work. I believe problem with forwarding multicast traffik.
Revert to 6.47.7 resolved problem.
Be carefully.
Nothing changes in testing procedure and new version = new bugs.

randomwalk · Mon Oct 11, 2021 8:17 pm

I discussed about this with Normis some time ago and he insisted Mikrotik does it properly, there shouldn't be cumulative changelogs, we should read all changelogs by ourselves.

Certainly Mikrotik has the authority to choose the best RouterOS release and upgrade cycle in the best interest of their business. At the same time I've noticed a decrease in DNS performance of up to 25% between v6.46.8 and 6.48.5 both of which were released in the "long-term channel". Moreover I am willing to accept the Mikrotik's definition of "long-term", with one caveat: the definition of "long-term channel" should be clearly communicated so users can make an informed decision.

In my book, a noticeable performance decrease should put a question mark for a "stable", and certainly not qualified for the "long-term" channel.

An acceptable solution, and perhaps the the best strategy overall (with regards to release channels, updates within channels, and changes to IPv6 DNS in particular) would be releasing the changes under optional packages. Users would then decide whether to stay with an old package, or use a new DNS package and take a performance hit. The responsibility for the outcome would be with the user. The role of Mikrotik would be to provide users with package options and facilitate their decision by keeping them informed.

The current "situation" can best summarized as: the changes are "pushed" into "long-term" channel, while users are not fully aware of what goes on. This bring us back to the same point: What is the definition of "long-term" channel?

Thanks

karina · Tue Oct 12, 2021 12:21 am

'SXT lite5 bricked. only option was to netinstall to lower release. Figured just a one off, then second sxt bricked. Then tried the "stable" 6.49 and yet another sxt bricked. Never had an sxt die fron an update before.
Dissapointed as a couple of the fixes are useful to me. No doubt MT will patch the problem but have lost faith in the long term channel for now, :-(

The sxts were upgraded from quite old releases 6.27 was the oldest, maybe there needs to be an interim update like 6.48.4, will have a play with some sxts i have on the shelve, see if there is some pattern

As a tester I also tried 6.49 stable on a mantbox and that went well,

JJT211 · Tue Oct 12, 2021 3:21 am

I discussed about this with Normis some time ago and he insisted Mikrotik does it properly, there shouldn't be cumulative changelogs, we should read all changelogs by ourselves.

Certainly Mikrotik has the authority to choose the best RouterOS release and upgrade cycle in the best interest of their business. At the same time I've noticed a decrease in DNS performance of up to 25% between v6.46.8 and 6.48.5 both of which were released in the "long-term channel". Moreover I am willing to accept the Mikrotik's definition of "long-term", with one caveat: the definition of "long-term channel" should be clearly communicated so users can make an informed decision.

In my book, a noticeable performance decrease should put a question mark for a "stable", and certainly not qualified for the "long-term" channel.

An acceptable solution, and perhaps the the best strategy overall (with regards to release channels, updates within channels, and changes to IPv6 DNS in particular) would be releasing the changes under optional packages. Users would then decide whether to stay with an old package, or use a new DNS package and take a performance hit. The responsibility for the outcome would be with the user. The role of Mikrotik would be to provide users with package options and facilitate their decision by keeping them informed.

The current "situation" can best summarized as: the changes are "pushed" into "long-term" channel, while users are not fully aware of what goes on. This bring us back to the same point: What is the definition of "long-term" channel?

Thanks

Noticeable DNS performance decrease screams placebo and/or other network issues. You need to back up that claim with some hard data homie

JJT211 · Tue Oct 12, 2021 3:22 am

a noticeable performance decrease

"Noticeable" screams placebo and/or other issues. You need to back up that claim with some hard data homie

randomwalk · Tue Oct 12, 2021 10:07 am

You need to back up that claim with some hard data

I took some time to capture a full 1 hour video to demonstrate
the difference between 2 versions:
----------------------------------------------------------------------
total_dns_boot time_version 6.46.8___~ 1 minute
total_dns_boot time_version 6.48.5___~ 13 minutes
----------------------------------------------------------------------
single record look-up in version 6.46.8___9.5 seconds
single record look-up in version 6.48.5___13.5 seconds
----------------------------------------------------------------------

video file: ROSv6485_TroubleShoot.mp4 (210Mb)
archive: ROSv6485_TroubleShoot.rar (94Mb)
download link: https://ufile.io/3zeohstq
* pass for archive: i_Love_RouterOS_6485

0~7 min. tests running in version 6.46.8
@ ~ 7 min. version upgrade to 6.48.5
~ 7~21 waiting for RouterOS to boot
21~40 min. test running in version 6.48.5
@ ~40 min. noticed CPU throttle
@ ~43 min. downgrade back to 6.46.8
43 ~End - testing 6.46.8 again.
----------------------------------------------------------------------
Recording this took a good chunk of my family life, and I would really appreciate developers study it in detail.

HTdeagle · Tue Oct 12, 2021 10:37 am

'SXT lite5 bricked. only option was to netinstall to lower release. Figured just a one off, then second sxt bricked. Then tried the "stable" 6.49 and yet another sxt bricked. Never had an sxt die fron an update before.
Dissapointed as a couple of the fixes are useful to me. No doubt MT will patch the problem but have lost faith in the long term channel for now, :-(

The sxts were upgraded from quite old releases 6.27 was the oldest, maybe there needs to be an interim update like 6.48.4, will have a play with some sxts i have on the shelve, see if there is some pattern

As a tester I also tried 6.49 stable on a mantbox and that went well,

Same here with 4xx series.. I wrote comment above about this... Only they die when the 6.49 firmware upgrade is done.

djdrastic · Tue Oct 12, 2021 12:52 pm

Looking at the responses on here...

Yeah I ain't touching this release.
Generally only update my fleet when there's a security update on LT train after passing QC/QA testing.

spiritamokk · Tue Oct 12, 2021 7:06 pm

I'm running GRE+IPSec behind the NAT on both sides with between MikroTIK devices of a different models. IKE1 with MAIN exchange mode. All my 40 tunnels broke overnight after automated installation of long-term 6.48.5 (before that tunnels were rock solid for 4+ years). It seems that initially IPsec tunnels establish just fine, but hang on the next Phase1 (1 day in my case) . The only temporary fix for me now is to manually clear all tunnels once a day which is a pain in my arse. I can't figure out what to do and how to reconfigure it =( Can you please stop 'improving' IPSec for long-term releases until its functionality verified? Can someone help me to figure this out? I would hate to down grade so many routers

Thank you

Darryl · Tue Oct 12, 2021 8:01 pm

RB3011 6.47.10 to 6.48.5 RouterOS installed ok.
Reboot
update bootloader from 6.47.10 to 6.48.5 and Brick.

Now I just have Etherboot sitting on my LCD. Not happy -_-

randomwalk · Tue Oct 12, 2021 8:12 pm

"Noticeable" screams placebo and/or other issues. You need to back up that claim with some hard data homie

Agree that DNS may not be the root cause, and an issue may be something else. The important detail here is that the issue goes away after downgrade to 6.47.10, or 6.46.8.
I reported the same issue with v6.48. here: viewtopic.php?p=837379#p837379.

The RB450Gx4 router is ARM based IPQ4000L and I would not rule out that this change is responsible for performance drop:

What's new in 6.48 (2020-Dec-22 11:20):
*) arm - added support for automatic CPU frequency stepping for IPQ4018/IPQ4019 devices;

I did some more testing, and these are the results:

1. Upgrading from ROS 6.46.8 ---> ROS 6.48.5 (with the firmware v6.46.8) did not help.
* Changing cpu frequency from Auto to default 716Mhz did not help.
* boot time until dns is up and running ~13 min,
* single dns record lookup ~13.5s (is slower than ~9.5s in ROS 6.46.8

2. Upgrading from ROS 6.46.8 ---> ROS 6.48.5 and upgrading the firmware from 6.46.8 ---> 6.48.5 did not help.

3. Downgrading ROS from 6.48.5 ---> 6.47.10 (firmware unchanged at v6.48.5) fixed the long boot time issue.
* boot time until dns is up and running returned to normal at ~1 min,
* single dns record lookup improved to ~10.2s but still ~6% slower than ~9.5s in ROS 6.46.8

4. Downgrading ROS from 6.48.5 ---> 6.47.10 and downgrading the firmware from 6.48.5 ---> 6.47.10 slightly improves dns performance.
* boot time remained normal at ~1 min,
* single dns record lookup to improved at ~9.9s (~5% slower than ~9.5s in ROS 6.46.8 with fiirmware 6.46.8)

5. Downgrading ROS from 6.47.10 ---> 6.46.8 (firmware unchanged at v6.47.10) further improves dns perfomance.
* boot time was normal at ~1 min,
* single dns record lookup improved at ~9.5s

6. Downgrading ROS from 6.47.10 ---> 6.46.8 and downgrading the firmware from 6.47.10 ---> 6.46.8 improved dns performance a little.
* boot time remained normal at ~1 min,
* single dns record lookup ~9.3s

--------
Notes:
* Tested on the RB450Gx4
* The "Boot time until dns is fully up and running" measured with 83152 static records by intiating the router reboot and waiting until built-in DNS server became responsive.
* The dns performance was measured by searching a single record in the DNS several times. The results were then averaged. To test just run the script provided below in your terminal.
* Don't attempt to repeat the test on a router with single core cpu, or if your router has less than 512MB of RAM.
* List of static dns records used in testing is attached in the "testhosts.zip" file here https://ufile.io/61xsudp9. Use of this file is subject to terms of use contained in the file.

{
   :local x www.example.com;

   /ip dns static
      :put "adding a temorary dns record..."
      :do { add name=$x address=[:resolve server=9.9.9.9 domain-name=$x]; # add a temorary dns record
          } on-error={:put "found the existing record..."}
      :put "testing..."
      :for i from=0 to=9 do={:put [:time {find name=$x}]}; # measure the time to find it (run 10 times)

      :put "finished, removing temorary dns record..."
      remove [find name=$x]; # done testing, remove the temorary record
}

dave864 · Wed Oct 13, 2021 9:33 am

I feel the forum is taking a turn for the worse. Asking commentators to post a config or it didn't happen and other forms of proof. All is a bit harsh. Hats off to those that did apply the proof that they were telling the truth! Geez. Have some faith in people. MT forums are usually populated by professionals so their observations should be accurate.

pe1chl · Wed Oct 13, 2021 11:16 am

I think the DNS server in the router is not intended to do things like "have 83152 static records". At that time it becomes important to have good data management and search methods, and likely that wasn't a priority when developing it.
Similarly, you should not have too many complicated regexp rules. Or even query names that return a large number of records (that was finally fixed in 6.49).
It is just a toy. Intended to have a couple of local names e.g. for a server, printer and router. Not as DNS for a large company, or for holding a large blocklist.
When you have demands like that, you should probably consider running an independent DNS server, maybe in a docker container on v7 once that is released.

r00t · Wed Oct 13, 2021 3:30 pm

Even if this might be extreme use of DNS server, if boot time went from 1 minute to 13 minutes, something is clearly wrong. Also it seems that version of routerboot matters and obviously routerboot doesn't care if you run DNS or anything else... so likely other software performance is also affected. It's important to measure and benchmark each release, and not just for raw throughput or VPN performance.
Kudos to randomwalk for spending his time on this and testing this issue properly. Hopefully Mikrotik can figure out what exactly caused this...

pe1chl · Wed Oct 13, 2021 5:01 pm

Yes, something is clearly wrong, but it looks like people complain along the lines of "they should have noticed this during internal testing", and while I agree that it is a good thing to have automated testing procedures that are run before release and test for scenarios that commonly occur in the field, it may not be reasonable to expect them testing with so many DNS records (on a smallish device that is not currently sold anymore).
Undoubtedly there will be a fix for it in another release. But that is why I question the policy of throwing versions that are not field-tested into the long-term channel.

randomwalk · Wed Oct 13, 2021 10:57 pm

It is all true about regexp, and 80K+ records sure is a lot as these alone require 300MB of RAM. At the same time the dns only uses a single core, with other remaining cores available. I find the built-in dns quite a gem on its own, which, when paired with the power of RouterOS scripting provides an opportunity to try build a business case around it. I was sceptical at the idea of using routerOS for block lists, but it works. RB450Gx4 is quite effective at it, maybe because of RISC ARM , but right now it look to me that dns is rather limited by available RAM than anything else.

But I digress, dns queries are not an issue, they are fast even with such a large table. Using script to find and manage these records is slow, which by itself is not necessarily unexpected. What I didn't expect was that 13 min long boot issue which I reported in 6.48 release thread 9 month ago was still present. The purpose of my post is to raise an awareness of Mikrotik developers that releasing features affects performance, and as people mentioned thorough testing is needed. I would also add that communicating the changes is just as important.

Roman100 · Thu Oct 14, 2021 4:27 am

*) poe - update PoE firmware only on devices that supports it;

what exactly is meant by this? What is new with POE firmware? Have these bug viewtopic.php?t=179211 been fixed?

Roman100 · Thu Oct 14, 2021 2:20 pm

*) poe - update PoE firmware only on devices that supports it;
what exactly is meant by this? What is new with POE firmware? Have these bug viewtopic.php?t=179211 been fixed?

I tested it myself and NO! The problem still remains!

WARNING
all dealers I know have taken the CRS328 out of the assortment with us! All in silence and without reason! But everyone who dares to buy CRS328 to provide POE devices will pull their hair and find out the reasons themselves!

pe1chl · Thu Oct 14, 2021 4:24 pm

Do not update firmware when there is no clearly mentioned reason to do so, and certainly not when others report that it causes problems.
Firmware update is only needed rarely, certainly not after every RouterOS update.
One would wish that the separate firmware version numbering came back, and a release note for new firmware versions and under what circumstances they are required.
Ever since this was removed, it became very unclear if a firmware update is required and if it is desirable.

deadkat · Thu Oct 14, 2021 4:26 pm

I would like to chime in for all saying Etherboot on the LCD screen == bricked......no. it just means you should backup config before an upgrade. which was mentioned in the very first post on this thread and other recent ROS release announcements.

Then you get to netinstall your device and restore the export you made. definitely not a brick as that implies the device is not recoverable.

as @pe1chl mentioned, they can't test for all possible configs. they likely test the upgrade process on the default config. its literally not possible for them to even know, much less test against, every possible config that could be set on our devices.

Darryl · Thu Oct 14, 2021 9:00 pm

Bricked means the device interfaces no longer works as intended by the manufacturer. Unable to use the reset button and power cycle functions to gain access to the device means BRICKED. Going from one Long-Term (6.47.10) to the NEXT Long-Term(6.48.5) release should not equate to getting a bricked device. Someone mentioned here that trust was lost because of this release, I'm a long time MikroTik user, yeah definitely lost some trust here. I never would have thought the most stable channel would crash a device from one release to the next. But here we are.

Netinstall is what I used to De-brick my RB3011, re-apply the .backup file and we're back online. Not so great for people who are expecting to remotely manage their devices.

As for not testing this on all devices, multiple routerboard devices are now listed here as failing on the bootloader upgrade. You would think at the very least this kind of bug would have been caught somewhere else first.

I would like to chime in for all saying Etherboot on the LCD screen == bricked......no. it just means you should backup config before an upgrade. which was mentioned in the very first post on this thread and other recent ROS release announcements.

Then you get to netinstall your device and restore the export you made. definitely not a brick as that implies the device is not recoverable.

as @pe1chl mentioned, they can't test for all possible configs. they likely test the upgrade process on the default config. its literally not possible for them to even know, much less test against, every possible config that could be set on our devices.

randomwalk · Thu Oct 14, 2021 9:23 pm

Also it seems that version of routerboot matters and obviously routerboot doesn't care if you run DNS or anything else... so likely other software performance is also affected.

I would take a close look at routerboot as it lies below the radar. Let me hypothesize here for a moment: Suppose an embedded firmware engineer wants to do the right thing and improve the accuracy and reliability of temperature readout on routerboards. So the sensor polling frequency is increased. Depending on the design this may trigger the hardware interrupt and SOC has to stop doing whatever it is doing to read the sensor data via I2C bus which is horribly slow. Hence a new tax on the overall performance is introduced. And since routerboot lies below the radar for the main part no-one can measure the impact, while filed guys start reporting all kind of strange things, which cannot be explained.

Probable?.. I would say not impossible, especially when I see reports like this: https://www.prinmath.com/ham/routeros/

SolarW · Mon Oct 18, 2021 8:06 pm

       routerboard: yes
             model: 2011UiAS-2HnD
     serial-number: 4XXXXXXXXX6
     firmware-type: ar9344
  factory-firmware: 3.10
  current-firmware: 6.47.1
  upgrade-firmware: 6.47.1

System - Packages - Check For Updates - Download&Install
After downloading router hang - on display "rebooting..." while reseting power.
Have 5-6 devices with this simptoms.
Can't use netinstall - only one device local, another very remote from me...

jbl42 · Mon Oct 18, 2021 9:34 pm

I would like to chime in for all saying Etherboot on the LCD screen == bricked......no. it just means you should backup config before an upgrade. which was mentioned in the very first post on this thread and other recent ROS release announcements.

This is commonly called a softbrick, meaning it can be recovered using tools like netboot.
While a device not recoverable with the means acvailable to mere customers is called hardbricked.

Then you get to netinstall your device and restore the export you made. definitely not a brick as that implies the device is not recoverable.

I'm open to ideas on how to do this remote.

infabo · Tue Oct 19, 2021 1:12 am

How does MIkrotik test releases? I mean, lets see the academic explaination what long-term channel actually means for Mikrotik. For many people, longterm means: most battletestes. most stable. mostly bugfree. So to say a "rock solid" release. But then you realize, Mikrotik just shift over a release from stable to longterm - without any known requirements when this happens.

Mikrotik looks like not testing this particular upgrade path thoroughly (6.47.10 to 6.68.5). Academicly one should go 6.47.8 to 6.48, then 6.48.1 and so on. Until you reach 6.48.5. Going from 6.47.10 to 6.48.5 is "not intended" judging by HOW they write changelogs.

People hit the "update" button very very fast. Dont understand why! I can't see any urgent security fixes in the changelog.

deadkat · Tue Oct 19, 2021 5:54 am

I'm open to ideas on how to do this remote.

viewtopic.php?t=178450
this thread has died off but I'm hopeful it'll provide a solution in the future. in my own testing it looks like Mikrotik has not included host networking mode from docker, only nat. so its difficult for netinstall to be hosted on a mikrotik device as things stand right now. However, my current efforts are on a netinstall LXC container (probably on proxmox) that I can imagine could function in a truly remote site. but if netinstall breaks then what? OS updates and PXEboot/netinstall are both major enough operations that I would think it justifies the cost of putting a person on site if the update is really that urgent.

People hit the "update" button very very fast. Dont understand why! I can't see any urgent security fixes in the changelog.

I have a couple of devices mounted on my brother's roof and my dad's roof that are difficult for me to reach. I understand its not the same kind of difficulty that a wisp or similar will face with remote devices. But I still don't upgrade them unless I have to. They're staying at 6.47.10 for the foreseeable future, which is the last urgent bugfix I saw.

pe1chl · Tue Oct 19, 2021 10:59 am

How does MIkrotik test releases? I mean, lets see the academic explaination what long-term channel actually means for Mikrotik. For many people, longterm means: most battletestes. most stable. mostly bugfree. So to say a "rock solid" release. But then you realize, Mikrotik just shift over a release from stable to longterm - without any known requirements when this happens.

It has already been discussed above. For MikroTik, "long-term" does not really mean "maximally stable". It is more like a release with mostly long-existing features that
is only fixed when security issues or major problems surface. The "stable" version is more like the version that tracks the new features and not so critical fixes. But there is not much difference between the two. "testing" and "development" are the versions where you really see experiments and sometimes failures.
Where it goes wrong is this: at some random point in time (usually in the middle of a discussion about problems) the "testing" version 6.##beta## is promoted to "stable" version 6.## and at that time often the previous stable version 6.##.# is made the "long-term" version. But in this case, before that was done there were some "quick fixes" to the existing stable version 6.48.4 and it was made 6.48.5 and put into long-term.
Of course these quick fixes also introduced new problems. It would have been better to release 6.48.5 as stable, wait a couple of weeks (and continuing with 6.49beta fixes) and only then make this move. But of course MikroTik want to move forward and switch to version 7 asap and it was probably decided that this procedure takes too much time.

It is never (for most software, including RouterOS) a good idea to just track some release channel and immediately install updates without first reviewing release notes and comments. That gives you a general picture of what to expect, what other people are facing, etc. E.g. in the 6.49 release there apparently is a problem with the "firmware" (the BIOS+bootloader) and it is unwise to do a firmware upgrade from that release. People should have noted that when reading the topic but still there are several reports of people being locked out of remote routers after they did a firmware upgrade. It is rarely necessary to do a firmware update, and when it is (this time there apparently is a change) it is always wise to review other people's observations first. No matter if it is called "stable".

djdrastic · Tue Oct 19, 2021 1:01 pm

Thanks for the post pe1chl
Disappointing that LT is treated the way it is but it is what it is I guess though I don't get people who just smash that upgrade button for no reason.

Granted we only update when a) There is a major security fix or serious bug we are hitting in prod b) It's passed lab testing before slowly rolling out in prod
I'll have to look at the firmware thing because I'm almost certain our ansible scripts update the firmware along with the OS version as we've had issues in the past when the two don't line up. Might have to realign that strategy.

slvnet · Tue Oct 19, 2021 4:03 pm

I still think it is a bad policy to release a new version in the stable channel and declare it the long-term version at the same time.
You should move versions to the long-term channel only after they have proven to be free of obvious issues in the stable channel for some time.
(I know that long-term, stable and testing are not referring to quality of the software, but lots of users run long-term versions because they do not want to be concerned with bugs inadvertently included in a fresh release version)

Yap, agree
As I can suggest for Devs... Look at "Debian way". They do versions long long years

Darryl · Tue Oct 19, 2021 4:18 pm

Are you for real with a comment like that? This is the LONG TERM channel - Mikrotik's most stable release channel. Doesn't matter the reasons for upgrading. One should expect from one release to the next that their device won't brick in this release channel. Completely unacceptable, don't go blaming the end users for the company's errors.

Thanks for the post pe1chl
Disappointing that LT is treated the way it is but it is what it is I guess though I don't get people who just smash that upgrade button for no reason.

Granted we only update when a) There is a major security fix or serious bug we are hitting in prod b) It's passed lab testing before slowly rolling out in prod
I'll have to look at the firmware thing because I'm almost certain our ansible scripts update the firmware along with the OS version as we've had issues in the past when the two don't line up. Might have to realign that strategy.

JJT211 · Tue Oct 19, 2021 5:48 pm

You need to back up that claim with some hard data

I took some time to capture a full 1 hour video to demonstrate
the difference between 2 versions:
----------------------------------------------------------------------
total_dns_boot time_version 6.46.8___~ 1 minute
total_dns_boot time_version 6.48.5___~ 13 minutes
----------------------------------------------------------------------
single record look-up in version 6.46.8___9.5 seconds
single record look-up in version 6.48.5___13.5 seconds
----------------------------------------------------------------------

video file: ROSv6485_TroubleShoot.mp4 (210Mb)
archive: ROSv6485_TroubleShoot.rar (94Mb)
download link: https://ufile.io/3zeohstq
* pass for archive: i_Love_RouterOS_6485

0~7 min. tests running in version 6.46.8
@ ~ 7 min. version upgrade to 6.48.5
~ 7~21 waiting for RouterOS to boot
21~40 min. test running in version 6.48.5
@ ~40 min. noticed CPU throttle
@ ~43 min. downgrade back to 6.46.8
43 ~End - testing 6.46.8 again.
----------------------------------------------------------------------
Recording this took a good chunk of my family life, and I would really appreciate developers study it in detail.

Now thats what im talking about! Great work!!

kirfog · Tue Oct 19, 2021 8:50 pm

Updated firmware to 6.48.5 on couple of CCR1009-8G-1S:
One is ok
One went to permanent ether boot.

onovy · Wed Oct 20, 2021 7:52 am

Upgraded from 6.47.10 these devices:

RB4011iGS+
RBD52G-5HacD2HnD
RBwAPG-5HacT2HnD
2* RBcAPGi-5acD2nD
RBmAPL-2nD
RB912R-2nD

so far so good, no etherboot problem.

I'm using:

/system routerboard settings auto-upgrade=yes

and rebooted them twice (software uprgrade + bootloader upgrade).

roe1974 · Wed Oct 20, 2021 11:43 am

Same here as in 6.49 stable:
system/health on a ltAP is still empty ;-)

mkamenjak · Wed Oct 20, 2021 1:59 pm

@normis
Is mikrotik aware of the boot problems affecting the RB2011 after a firmware upgrade to either 6.49 or 6.48.5?

veljko · Wed Oct 20, 2021 5:14 pm

Hello everyone

I have upgraded this devices
SXT G-5HPnD r2
2011UiAS-2HnD
CRS125-24G-1S-2HnD
SXTG-5HPnD-SAr2
to 6.48.5 and all devices are dead after firmware upgrade :(

@MikroTik
please fallback 6.48.5 version of RouterOS from your servers and back 6.47.10

DarkNate · Wed Oct 20, 2021 6:47 pm

/system routerboard settings auto-upgrade=yes

Upgrade, reboot, login, reboot again, you're good.

bpwl · Wed Oct 20, 2021 9:42 pm

The RB450Gx4 router is ARM based IPQ4000L and I would not rule out that this change is responsible for performance drop:

What's new in 6.48 (2020-Dec-22 11:20):
*) arm - added support for automatic CPU frequency stepping for IPQ4018/IPQ4019 devices;

I did some more testing, and these are the results:

1. Upgrading from ROS 6.46.8 ---> ROS 6.48.5 (with the firmware v6.46.8) did not help.
* Changing cpu frequency from Auto to default 716Mhz did not help.

Maybe not related, but "changing cpu frequency" was a hint to upgrade my hAP ac2 from 6.45.6 (very Stable) to 6.48.5 (LT), and to change the CPU frequency to "auto"

All devices are idle (no other load).

1. Freq dropped from 716MHz to 488MHz.
2. Power consumption at the RB260GSP remained at 155mA/3.6mW
3. Using bandwith test with "send" and "random data" loaded CPU around 50-60%, but there was no Freq stepping up, remained at 488MHz
4. Changing between "auto" (=488MHz) and 716MHz lowered the CPU load %, but gave the same performance numbers
5. Using the same bandwidth test in "receive" action made the CPU freq jump up to 896MHz, power consumption went up to 166mA. CPU load from 21% lowered to 15%.
6. Changing between "auto" and 716MHz gave some lower CPU load on auto sometimes at 896MHz. Performance numbers where slightly better with auto. 500Mbps->550Mbps)
7. Setting the freq on 488MHz gives again 500Mbps in sending (50% CPU load) , and 450 Mbps in receiving (25% CPU load)

Can we rely on this "auto CPU frequency stepping" to correctly react on CPU load?
Is it normal for the power consumption not to drop below 155mA/3.6W, when CPU freq goes from 716 to 488 MHz? (Some powerregulator base load?)

Forgot to test this before the upgrade. But very similar setups (identical devices used hAP ac2-> RB260GSP-> wAP ac) with ROS 6.45.6 gives 720Mbps in send and 570Mbps in receiving, on multiple installations, with default freq 716MHz.

kirfog · Thu Oct 21, 2021 11:26 am

I have upgraded these devices and all are dead

Mama called the doctor and the doctor said:
"No more remote firmware upgrading on the bed!"

Thu Oct 21, 2021 11:29 am

My Dad says ... always look on the bright side of upgrade

winap · Thu Oct 21, 2021 11:32 am

My Dad says ... always look on the bright side of upgrade :) :)

My mom always said, upgrade was like a box of chocolates. You never know what you're gonna get. :D

randomwalk · Thu Oct 21, 2021 9:36 pm

@Mikrotik product managers:
Here is the real problem to solve during your next product update meeting:

Suppose one itchy finger decided to tweak, improve, and add "new features" to the firmware that was not broken.
As a direct result (and within 2 weeks) of the change 10 clients who upgraded were affected and wasted 4 field hrs each on troubleshooting.

Questions:
- How many total field hours will be spent on troubleshooting & diagnostic if 100 clients were to upgrade?
- What is the total $ impact of community troubleshooting efforts if the client base is in the 1000's and each client absorbs the cost of say $50/hr ?
- Where in your list of product management priorities is the rule "If it is not broken, don't fix it" ?
- Did the proposed change add value or subtract from it ?
- How many more clients will be affected if the (Long-Term) firmware version in question remain available for download for another 3 month?

infabo · Thu Oct 21, 2021 10:48 pm

Product managers?

bpwl · Thu Oct 21, 2021 11:31 pm

But in this case, before that was done there were some "quick fixes" to the existing stable version 6.48.4 and it was made 6.48.5 and put into long-term.
Of course these quick fixes also introduced new problems. It would have been better to release 6.48.5 as stable,

They did it in the past. 6.45.6 is a super stable version, the LT made out of that 6.45.8 was problematic. (viewtopic.php?t=156825&#p782153)

This are just more incidents waiting to happen as people upgrade. Dragging my feet on upgrading as much as I can, and trying to find the "real stable" versions arround.
6.45.6 is superb, 6.45.9 has fixed the 6.45.8 issues. But I had to wait till 6.47.10 to find another next "real stable" version for production.

Eager to learn about other "real stable" versions. But lost trust in LT.

Darryl · Fri Oct 22, 2021 3:42 pm

Certainly not in the long-term channel. I've already paid mikrotik for the hardware. I come here in this release channel to actually make it work like advertised.

There may be an opportunity for MT here to provide paid access (subscription or per-release) to some kind of ultra-stable channel with security bugfixes only for those who really can't risk running unproven releases.
I can certainly think of a bunch of devices worth paying to keep running safe and secure releases, even if they have to forgo feature updates for years.

winap · Fri Oct 22, 2021 7:41 pm

What???
Why must people pay for firmware? There is no way...
MK MUST make good software, because people pay for hardware and software in it!!
There is only MK problems, so they can't make a good software, maybe they are lazy or don't have motivation, I don't know..
if the people know, how really work MK, they also know, how to programme it!! Only use logic...
If I made a problematic car and you buy from me that crap, you will be some trouble, with riding, or breaking..you give me extra money to solve my problems??
This is my problems, when I something produce..No this is for dump people, to pay for another people twice time..

Cray · Fri Oct 22, 2021 11:03 pm

There is one major L2TP/IPSec regression in 6.48.x that has not yet been fixed in 6.48.5 (or anything newer):

Using ROS 6.48.x, 6.49.x, 7.x and configuring IPSec peers with DNS name as remote address (not using fixed remote IP) the L2TP/IPSec connectivity stops working because any DNS addressed IPSec remote peer gets matched as peer for the incoming L2TP/IPSec connection instead of automatically generated L2TP peer.

This causes L2TP/IPSec shared secret validation to fail for L2TP clients.

If configuring all peers to use fixed IP addresses, the L2TP connections start matching to the dynamically generated L2TP peer + shared secret again.

Earlier long-term release ROS 6.47.10 is not affected by this issue and mixing DNS addressed remote IPSec peers with L2TP/IPSec server works there as expected.

Issue has been reported to Mikrotik as ticket# SUP-63883

pe1chl · Sat Oct 23, 2021 11:48 am

There is one major L2TP/IPSec regression in 6.48.x that has not yet been fixed in 6.48.5 (or anything newer):

Using ROS 6.48.x, 6.49.x, 7.x and configuring IPSec peers with DNS name as remote address (not using fixed remote IP) the L2TP/IPSec connectivity stops working because any DNS addressed IPSec remote peer gets matched as peer for the incoming L2TP/IPSec connection instead of automatically generated L2TP peer.

I cannot reproduce that here in 6.49. I presume this is visible in the /ip ipsec listings as a blank IP instead of the resolved IP in the remote address columns, but
that is not what I observe here. I have two different L2TP/IPsec client interfaces both with remote as a DNS name, but they both result in fully qualified IPsec peers, with the server entry still having the wildcard spec.
Maybe you were testing back-and-forth between two routers? That never really worked, I think.

bratislav · Sat Oct 23, 2021 2:03 pm

Although it may not be the usual subject for a new firmware release since this particular release is obviously plagued with some outstanding bugs we may state our opinion on what should be called a long-therm release...
Since we already have stable and long-term branches in addition to testing and development I don't think adding yet another ultra-stable-extra-long-term-super-cala-fragilistic-expialidocious branch would help per se, payed or not. And as far as I can say there is no software/firmware out there that any company would provide a guaranty of any kind or for any purpose, especially not a contractual guarantee...
IMHO MikroTIk should rethink the current release policy, firmware version should not be considered a long-term just because there is a newer release supposedly ready, it should be the version that is purged of and than tested for some specified time for all known bugs. And there is also a nonsensical decision of rebranding the boot loader with every release of RouterOS so users cannot track what version they actually have and are unaware of what changes have been made under the hood... And especially MiktoTik should not just quietly push new and isufficiently tested boot loader into the long-term release as it seems happened here...
As for something beyond basic support such as firmware updates I think that some form of payed MikroTik support would be appreciated by some but that shouldn't mean that really stable firmware should be a privilege of paying customers only, under payed support contract MikroTik could do some kind of remote monitoring, support calls and priority fixes of some new outstanding bugs for example.

Certainly not in the long-term channel. I've already paid mikrotik for the hardware. I come here in this release channel to actually make it work like advertised.
I was thinking more another tier beyond the existing long-term channel - it would take MT extra work to back-port security patches and perform additional testing to an ultra-stable channel (and ultra-stable-candidate channel?) as well as provide a degree of contractural guarantee in the additional purchase, so that may warrant additional charges to cover that expense. There's no reason someone couldn't either remain on a given older version (without security fixes) or track the relatively more dynamic Long Term and Stable channels. You bought the hardware with either the existing channel arrangement or an even smaller set of channels, so adding one more paid tier wouldn't lose you anything you don't already have.
However, this is off-topic here so I'll drop it now.

anuser · Sun Oct 24, 2021 12:24 am

Upgrade from 6.48.4 to 6.49 => Clients do not get IP address via DHCP over the EoIP tunnel
Downgrade to 6.48.5 => Clients do not get IP address via DHCP over the EoIP tunnel
Downgrade to 6.48.4 => Clients receive an IP address again.

=> RB750GR3 on both sites.

sirbryan · Sun Oct 24, 2021 7:11 pm

Upgraded a Cube 60 from 6.48.1 to 6.48.5 and the config changed from CPE to AP, requiring a truck roll to determine what happened and to reprogram it. Fortunately upgrading the wAP 60 on the other side to 6.49 didn't break anything. (Upgraded the CPE while I was there to 6.49 as well.)

Certainly not Long Term or stable. I can only imagine what would have happened if I ran the update through the whole network at once.

starlingus · Mon Oct 25, 2021 3:12 pm

Is anyone from MikroTik checking this forum topic? There always was a vivid discussion with MikroTik Support representatives (emils and others) working towards found issues solutions. I have not seen any response from MikroTik here yet (no offence to all forum gurus and other contributors here).

Jotne · Mon Oct 25, 2021 6:48 pm

They always read the forum, but for support problem, email then at support@mikrotik.com and you will get a ticket number and they will reply.

infabo · Sun Oct 31, 2021 12:20 am

niceeee error on /export. Hung for 5mins and then some spooky error message.

[if@tv-cpe] > /export
# oct/30/2021 23:10:20 by RouterOS 6.48.5
# software id = foo
#
# model = RB941-2nD
# serial number = bar
/interface bridge
add name=bridge1
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-onlyn channel-width=20/40mhz-XX \
    country=austria disabled=no frequency=auto installation=indoor mode=\
    station-bridge ssid=jupiter wireless-protocol=802.11
/interface list
add name=WAN
add name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa-psk,wpa2-psk disable-pmkid=\
    yes group-ciphers=tkip,aes-ccm mode=dynamic-keys supplicant-identity=\
    MikroTik unicast-ciphers=tkip,aes-ccm wpa-pre-shared-key=baz \
    wpa2-pre-shared-key=baz
/user group
set full skin=tv-cpe
/interface bridge filter
add action=drop chain=input dst-port=68 in-interface=!wlan1 ip-protocol=udp \
    mac-protocol=ip
/interface bridge port
add bridge=bridge1 interface=wlan1
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/interface list member
add interface=wlan1 list=WAN
add list=LAN
add interface=ether1 list=LAN
add interface=ether2 list=LAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
/ip dhcp-client
add disabled=no interface=bridge1
/ip ssh
set strong-crypto=yes
/system clock
set time-zone-name=Europe/Vienna
#error exporting /system identity
#interrupted

mth · Mon Nov 01, 2021 2:06 pm

Updating two NetMetal 5 from 6.44 to 6.48.5 were okay. but when I update bootloader the device start to flip flop on ether1, so I had to bring them down netinstall to 6.47.10 and everything seems okay then! I do not recommend anyone to install this long-term version!

hngjared · Tue Nov 02, 2021 4:13 pm

Updating two NetMetal 5 from 6.44 to 6.48.5 were okay. but when I update bootloader the device start to flip flop on ether1, so I had to bring them down netinstall to 6.47.10 and everything seems okay then! I do not recommend anyone to install this long-term version!

I've had the same problem on 3 devices. Port flapping, bringing down device. Worst ROS "long-term" update I've ever tried. Stay away from this version!

n3xus · Wed Nov 03, 2021 10:19 am

Can confirm. bricked numerous devices after bootloader update with this "long-term". Recovered with netinstall. STAY AWAY from this release

infabo · Wed Nov 03, 2021 10:37 am

What I do not understand: why does MT not revoke this release or at least speak out an official warning? Instead they are silent and people keep bricking their devices? It is quite a month out now - there should be enough information collected to pin down: which platforms are affected by the firmware issues? And how to resolve. 1 month without hotfix.

zdiv · Thu Nov 04, 2021 1:49 pm

upgraded multiple devices to 6.48.5 and 6.49 to test.
in 9 out of 10 cases got them bricked after firmware upgrade.
only NetInstall helps afterwards.

tested on
rb2011
rb911 hpnd
rb912
rb hex
ccr 1009
ccr 1036
rb 1100ahx4

I can only imagine horror of people having scripts for auto upgrade.

eworm · Thu Nov 04, 2021 2:16 pm

Wondering why I have not seen it on a single device... Possibly this does not happen with split packages (vs. bundle)?

osc86 · Thu Nov 04, 2021 3:33 pm

I have updated 10 hap ac2s and a few hap lites, and didn't have this problem with any of them. I'm using split packages on all of them.
I don't use bundle package anymore with 16MB flash devices.

pe1chl · Thu Nov 04, 2021 5:10 pm

I have updated 10 hap ac2s and a few hap lites, and didn't have this problem with any of them. I'm using split packages on all of them.
I don't use bundle package anymore with 16MB flash devices.

I use split packages as well but still on my hAP ac2 with only 4 packages for use as a wireless AP it fails to install RouterOS v7 "due to lack of space" :-(
Now I need to find if my install is somehow corrupted and uses too much space, or if this update will not work and requires netinstall for some other reason.

             free-memory: 77.8MiB
             total-memory: 128.0MiB
           free-hdd-space: 2656.0KiB
          total-hdd-space: 15.3MiB

Uploading OK, reboot and then it is back in v6 with an error message indicating lack of space...
I think selling devices with 16MB flash never was a really good idea...

eworm · Thu Nov 04, 2021 5:34 pm

Uploading OK, reboot and then it is back in v6 with an error message indicating lack of space...

Have a look at my topic about upgade path from split packages.

amojak · Thu Nov 04, 2021 6:51 pm

I still think it is a bad policy to release a new version in the stable channel and declare it the long-term version at the same time.
You should move versions to the long-term channel only after they have proven to be free of obvious issues in the stable channel for some time.
(I know that long-term, stable and testing are not referring to quality of the software, but lots of users run long-term versions because they do not want to be concerned with bugs inadvertently included in a fresh release version)

100% this.. I have been asking for this since way before there was a Long term channel. There needs to be a known stable channel where the last version that has been in the field some time with no instabilities or show stopping issues is kept. Only incrementing when the next actual stable version is detected.

Also that version needs to have the log show any bugs or niggles found with it since its release with what newer release addresses it so people know what to expect.

It is called traceability.

Bill

amojak · Thu Nov 04, 2021 6:56 pm

They always read the forum, but for support problem, email then at support@mikrotik.com and you will get a ticket number and they will reply.

Surprised? Nothing has really changed since when we first got an RB532 and RB112 with Ros 2 , except they now reserve being rude to you in private and ignore you on the forum perhaps?

amojak · Thu Nov 04, 2021 6:59 pm

Ok so Files upgraded as expected but when i upgraded the routerboard version on two devices RB2011 access to devices was lost. Device is booting with ether boot displayed - have so far been unsucessful in factory reset and therfore cant use Netinstall iether. They both appear to be bricked.

welcome to the world of bricked unrecoverable routers, got a stack of em here now..

jimmer · Fri Nov 05, 2021 2:40 am

What I do not understand: why does MT not revoke this release or at least speak out an official warning? Instead they are silent and people keep bricking their devices? It is quite a month out now - there should be enough information collected to pin down: which platforms are affected by the firmware issues? And how to resolve. 1 month without hotfix.

Agreed, Pretty poor form when the 7.1rc5 firmware is more reliable than the supposedly Long Term and Stable bootcode..

I have gotten to the point where I am reluctant to upgrade my units because I cant afford to have vendor provided code put the router into a state that requires manual intervention and recovery, we shouldn't be having this issue this far along, I'd prefer to wait longer for Mikrotik to properly test a release than be in this position again :(

Kind Regards,
Jim.

Jotne · Fri Nov 05, 2021 9:38 am

Surprised? Nothing has really changed since when we first got an RB532 and RB112 with Ros 2 , except they now reserve being rude to you in private and ignore you on the forum perhaps?

This it not what I have seen from MT. They always tries to help out if you ask polite for help.

Fri Nov 05, 2021 10:10 am

The issue with unavailable devices after 2nd reboot has been reproduced and it seems to be related when upgrading from 6.41.4 (or older) RouterOS/RouterBOOT versions. Our apologies for the caused issues, the fix will be included in upcoming releases.

So anyone using older than 6.42 RouterOS or RouterBOOT versions, please first upgrade RouterOS and RouterBOOT to 6.48.4 or 6.47.10, and only then use the latest version.

amojak · Fri Nov 05, 2021 12:48 pm

hi,

Do you have the ability to stop customers from upgrading the brick way? If not then withdrawing the release sounds a damn good idea as it is now over a month down the road.

Unless you can instruct distributors to accept free returns/swaps of bricked hardware for swap for the duration?

It is not a "caused issue", it is turning your hardware useless, this is more than just an issue.

Where are the warnings in CAPS on the update firmware notes as stage 1?

Screenshot from 2021-11-05 10-45-32.png

Screenshot from 2021-11-05 10-46-01.png

Speeding up your response to this maybe a good idea as i doubt your distributors/resellers will be happy with the returns and angry customers.

Thanks

The issue with unavailable devices after 2nd reboot has been reproduced and it seems to be related when upgrading from 6.41.4 (or older) RouterOS/RouterBOOT versions. Our apologies for the caused issues, the fix will be included in upcoming releases.

So anyone using older than 6.42 RouterOS or RouterBOOT versions, please first upgrade RouterOS and RouterBOOT to 6.48.4 or 6.47.10, and only then use the latest version.

mducharme · Fri Nov 05, 2021 2:18 pm

Unless you can instruct distributors to accept free returns/swaps of bricked hardware for swap for the duration?

Can’t you just netinstall the device to recover it? Others were reporting that that was working.

owsugde · Fri Nov 05, 2021 4:22 pm

Updated an edge router at a client from 6.47.10 to 6.48.5, didn't show back up in VPNs (1 OVPN, 2 L2TP). Assuming it's crashed or worse. Have a backup, but not quite up to date... Building is closed for the weekend, will still drive there (40min) and try my luck through the admin WLANs.

That's what you get from updating sort of in a hurry on a Friday afternoon, I guess. Never had an issue remotely like this on the long-term branch though.

pe1chl · Fri Nov 05, 2021 4:29 pm

Updated an edge router at a client from 6.47.10 to 6.48.5, didn't show back up in VPNs (1 OVPN, 2 L2TP). Assuming it's crashed or worse. Have a backup, but not quite up to date... Building is closed for the weekend, will still drive there (40min) and try my luck through the admin WLANs.

That's what you get from updating sort of in a hurry on a Friday afternoon, I guess. Never had an issue remotely like this on the long-term branch though.

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;

Ehman · Sat Nov 06, 2021 2:49 pm

this version is a disaster....

I've update my 750GL (bad blocks 0.0% FYI) ....so today with this firmware after it had v6.44.6 on and it completely bricked the thing...I always stick with the long-term releases
and after I re-loaded v6.48.5 on with netinstall it worked briefly and went dead again... looks like the device went into a continuous loop??!?! ...it went haywire!
I netinstall routeros-mipsbe-6.47.9 ... I know that version works!!! already have it running on my routers without issues.....

Thank God it wasn't one of my live routers!!! and therefor a DEV router!!!

and netinstall also gave me issues on my win7 machine ......error on the screen is......."bind() failed: An attempt was made to access a socket in a way forbidden by its access permissions (10013)"
run as administrator didnt work either....

I had to pull out a XP laptop for netinstall mission

and dont get me wrong... I'm not new Mikrotik!! been using Mikrotik since v4.12 and own many routers running... but today I'm not having a good day with Mikrotik and I've had days like this ages ago with Mikrotik bugs...

avoid v6.48.5 by all cost!!!!

mducharme · Sat Nov 06, 2021 2:57 pm

this version is a disaster....

If you see the thread for 6.49 (which has the same issues), MikroTik found that this issue only happens when you are upgrading from a device that has a very old RouterBOOT firmware (6.41.4 or older). If the RouterBOOT firmware is newer than 6.41.4 it *should* upgrade without issue.

owsugde · Sat Nov 06, 2021 3:02 pm

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;

That would have helped me 0% here because the device got inacessible remotely. It still was responsive through the local net, though. All the bridges and ports failed to load after update reboot, so all the adresses and routes were of course inactive. I had seen that once before, at around 6.43 or so on current branch. Another reboot actually fixed it and the routerboot luckily also didn't break, but I still downgraded to 6.47.10 to be safe. Also enabled ping watchdog, which might have caught this, but I generally try to avoid on big hotspot edge routers.

Also, backuping everything at every update becomes impractical quite quickly when updating hundreds of small devices. On an important edge router it might be sensible to do (again, wouldn't have helped me here), but I don't believe anyone really backups ALL their damn wAPs before doing every single update, on long-term branch no less.

r00t · Sat Nov 06, 2021 3:41 pm

Long-term branch should NOT have these problems... one would expect long-term to be exactly the same as stable that's maybe 1-2 releases behind and proven to be stable without any reported issues. But that's not the case, long-term is older version where some fixes and features are backported and added, so it may happen to be even worse than current stable.
To make things even worse, Mikrotik completely fails to put up any warnings even if there are known serious issues with the release. Now that they know what's causing the problem, I would have expected big warning at the top of this thread, maybe also on the download page. But no, this is Mikrotik... everything is fine, people are still flooding forum with new threads about bricked devices, but who cares...

pe1chl · Sat Nov 06, 2021 4:00 pm

Also, backuping everything at every update becomes impractical quite quickly when updating hundreds of small devices.

When you have hundreds of devices you should arrange for a backup mechanism that runs regularly (depending on the frequency of your config changes) and that you can easily kick off as part of your upgrade procedure.

Ehman · Sat Nov 06, 2021 6:31 pm

bugs inadvertently included in a fresh release version)

I've never had any issues with long-term released until today!! I would expect this from beta's but NOT from long-term releases... long-term is like legacy releases kinda to me

Ehman · Sat Nov 06, 2021 6:34 pm

this version is a disaster....
If you see the thread for 6.49 (which has the same issues), MikroTik found that this issue only happens when you are upgrading from a device that has a very old RouterBOOT firmware (6.41.4 or older). If the RouterBOOT firmware is newer than 6.41.4 it *should* upgrade without issue.

Well v6.48.5 is a mess... I was on 6.44.6 and went to 6.48.5

Ehman · Sat Nov 06, 2021 6:44 pm

Long-term branch should NOT have these problems... one would expect long-term to be exactly the same as stable that's maybe 1-2 releases behind and proven to be stable without any reported issues. But that's not the case, long-term is older version where some fixes and features are backported and added, so it may happen to be even worse than current stable.
To make things even worse, Mikrotik completely fails to put up any warnings even if there are known serious issues with the release. Now that they know what's causing the problem, I would have expected big warning at the top of this thread, maybe also on the download page. But no, this is Mikrotik... everything is fine, people are still flooding forum with new threads about bricked devices, but who cares...

Long-term branch should NOT have these problems

Exactly

ageees ago!!, I've once updated my rb1100ahx2 remotely over my internal network and bricked my router, and that was my main router that was connecting all my AAA servers and managed all my connections and I was sitting 200+ km away... yea.. I had to go reload an older version back weeks later cant remember if it was done with a console cable or not, was messedup!!!

So long-term releases is supposed to be bug free and solid!

honzam · Sat Nov 06, 2021 10:25 pm

The biggest mistake of Mikrotik in recent times. Stop downloading 6.48.5 when you know about the error. How much damage still needs to be done?

Vlad2 · Sun Nov 07, 2021 2:16 am

The issue with unavailable devices after 2nd reboot has been reproduced and it seems to be related when upgrading from 6.41.4 (or older) RouterOS/RouterBOOT versions. Our apologies for the caused issues, the fix will be included in upcoming releases.
So anyone using older than 6.42 RouterOS or RouterBOOT versions, please first upgrade RouterOS and RouterBOOT to 6.48.4 or 6.47.10, and only then use the latest version.

I agree with some colleagues, if there is an error, it has been identified, then it is urgent:
1) revoke 6.48.5 (remove the firmware file itself from publicity) (it is impossible for devices to be updated)
2) urgently make a correction and release 6.48.5.1, since the Long-Term market segment = these are important commercial routers. (especially since you have already done such fixes)
3) warn on the website / in the shell that there may be problems when installing 6.48.5. Because not everyone reads forums and so on. Although it is more correct, part 1 is to revoke the update that the router turns into a BRICK and make a correct Corrected update.

ALL this is financial and image losses, creating a shadow of the unprofessionalism of the IT industry.

(sorry for the translation, it's done automatically)

winap · Sun Nov 07, 2021 1:50 pm

ALL this is financial and image losses, creating a shadow of the unprofessionalism of the IT industry.

If I want make a good SW, I must testing a very long time to sell good SW without bugs ..But Mikrotik doesn't care about trouble of people..
It they has a stupid boss and they must relase FW every month, it's clear...
Mikrotik has buggy FW's but too many options of setup :D Too many, but functional of 70%.
Maybe if some people from Mikrotik have sympathy with costumers, they also know, so they must testing longer, because they want to minimalise problems with their product and save time to solve it on costumers site..So Mikrotik throws responsibility on costumers and who cares, so they have a problems..So make downgrade and that's it.
Who cares of some people must drive 200km to company, when something happend and reflashe it..
Please Mikrotik, have a heart with people, thank you.

Jotne · Sun Nov 07, 2021 4:44 pm

Have the same problem.
RB951Ui-2HnD 6.47.10 —> 6.48.5, 6.40.7 —> 6.48.5 same problem: no boot after 2nd reboot. Hap AC lite, RB751 — no problem

Ref post above 6.41.4 (or older) gives problem when upgrading to 6.48.5. 6.47.10 should work, post a support case to MT

Ehman · Mon Nov 08, 2021 11:40 am

where is the people from Mikrotik in this forum!?!

eddieb · Mon Nov 08, 2021 11:56 am

this is a user forum, mikrotik support is support@mikrotik.com

Ehman · Mon Nov 08, 2021 12:03 pm

this is a user forum, mikrotik support is support@mikrotik.com

Very funny

Chupaka · Mon Nov 08, 2021 12:43 pm

where is the people from Mikrotik in this forum!?!

Here, for example: viewtopic.php?p=889344#p889344

Ehman · Mon Nov 08, 2021 12:47 pm

where is the people from Mikrotik in this forum!?!
Here, for example: viewtopic.php?p=889344#p889344

thank you

Ehman · Mon Nov 08, 2021 12:58 pm

I agree with some colleagues, if there is an error, it has been identified, then it is urgent:
1) revoke 6.48.5 (remove the firmware file itself from publicity) (it is impossible for devices to be updated)
2) urgently make a correction and release 6.48.5.1, since the Long-Term market segment = these are important commercial routers. (especially since you have already done such fixes)
3) warn on the website / in the shell that there may be problems when installing 6.48.5. Because not everyone reads forums and so on. Although it is more correct, part 1 is to revoke the update that the router turns into a BRICK and make a correct Corrected update.

I highly agree with this post....

r00t · Mon Nov 08, 2021 3:44 pm

From v7.1rc6 changelog:
*) system - improved system stability if device is upgraded from RouterOS and/or RouterBOOT v6.41.4 or older;

Now why they choose to release v7 instead of quick fix for long-term... ?!!
Every day this long-term release is still available with no warnings or any sort of mitigation of the problem is bad.

eworm · Mon Nov 08, 2021 3:54 pm

Now why they choose to release v7 instead of quick fix for long-term... ?!!

Because they make what makes sense: Changes are tested in development and/or testing channel, the changes are cherry-picked to stable and long-term then.

r00t · Mon Nov 08, 2021 5:53 pm

Well, if it's going to take a week before long-term is fixed, just pull the release. At least for affected architectures. Just disable download and update within ROS.

Jotne · Mon Nov 08, 2021 10:21 pm

Well, if it's going to take a week before long-term is fixed, just pull the release. At least for affected architectures. Just disable download and update within ROS.

I dont see the problem.
First 6.41.4 is very old, so some one has missed out many many version.
Second, I do not auto upgrade, and always read the forum and wait some weeks before upgrade.

But I do agree that this should have not show up in fist place.

Ehman · Tue Nov 09, 2021 10:09 am

Well, if it's going to take a week before long-term is fixed, just pull the release. At least for affected architectures. Just disable download and update within ROS.
I dont see the problem.
First 6.41.4 is very old, so some one has missed out many many version.
Second, I do not auto upgrade, and always read the forum and wait some weeks before upgrade.

But I do agree that this should have not show up in fist place.

Remember... I was on v6.44.6 when I went to v6.48.5 when my router got bricked! ....v6.44.6 is not that ancient old...

karlisi · Tue Nov 09, 2021 10:25 am

I dont see the problem.
First 6.41.4 is very old, so some one has missed out many many version.

You are right about this, only partially. In such case changelog should start with "warning, if you upgrade from versions older than..."

starlingus · Tue Nov 09, 2021 12:24 pm

This is "Long-term" (LT) channel release, the most stable the highest quality one. It is meant to be used for production environment as the level of quality verification is significantly higher that for other channels. The price of using LT is that it takes time to get new release.

Therefor (based on statement above) I would expect way more interaction with MikroTik support representatives in this thread. It should be mainly MikroTik interest to make sure LT bits does not suffer from any major issues and if they do, these issues are resolved in no time, and the progress on known issues is well and frequently communicated (at least in this thread I suppose). Please do not be passive and do not let ruin MikroTik brand for such a easy-to-fix reason.

One more comment... these discussions about release notes diffs between two LT releases occurs in each LT release thread. Please consider implementing full changelist (without need for assembling information from stable build changelog to stable build change log). It could help to have these threads focused on LT release quality instead of reopening discussions about the same again.

I am big MikroTik fan using your devices also in production a lot. So I feel it is my duty to be vocal about this.

mysz0n · Wed Nov 10, 2021 11:53 am

I just updated three mANTBox 15S,
From version 6.47.9, two of them went into bootloop. One started without a problem. Thanks mikrotik for screwing up this morning and upsetting the customers.
Does anyone test this before going public?

pe1chl · Wed Nov 10, 2021 12:32 pm

Does anyone test this before going public?

Does anyone read the forum before updating customer's equipment?

infabo · Wed Nov 10, 2021 1:19 pm

I do not want to defend a yolo update policy, but: why should it be mandatory to read the FORUM before upgrading a device? One could assume that a release - out for a whole month already - is a safe harbor.

mysz0n · Wed Nov 10, 2021 2:11 pm

[/quote]
Does anyone read the forum before updating customer's equipment?
[/quote]

Are you kidding? Should I read 150 forum entries before I install the officially released version of the software? is it beta or long-term ??

DragonQ · Wed Nov 10, 2021 2:57 pm

So lets see how the actual release notes for long-term v6.48.5 upgrade from v6.47.10 looks like:
Nice post.

What MT should do is to make a web page where you select two different release and it will then show all changes between those two releases.
Some like to see difference between 6.48.4 to 6.48.5 other 6.47.10 and 6.48.5. Some my upgrade from 6.48.2 to 6.48.5, so then those changes should be shown.

That would be ideal but in reality would be an absolute nightmare to maintain. e.g. if there was a bug introduced in 6.48.2 that was fixed in 6.48.5 it shouldn't be mentioned at all in a 6.47.10 to 6.48.5 changelog.

r00t · Wed Nov 10, 2021 3:59 pm

Are you kidding? Should I read 150 forum entries before I install the officially released version of the software? is it beta or long-term ??

Sadly answer is Yes, you have to if you have any Mikrotik hardware in your network, otherwise you are risking downtime, bricked devices and more.
Waiting a week can be considered minimum practice, but testing everything in lab or test setup first is just as important.
Long term? Stable? Beta? There is really no difference, no branch can be trusted.

In the past, I would just say this is the price you pay for cheap Mikrotik devices, as they were much cheaper then other vendors.
But with Audience and RB4011 it's not $50 hardware anymore and software quality and release testing seems to have got even worse...

pe1chl · Wed Nov 10, 2021 4:14 pm

Are you kidding? Should I read 150 forum entries before I install the officially released version of the software? is it beta or long-term ??

It depends on what you want. You can choose to live the risky life and just install what is released, or you can decide to first read other people's experience with the software and then decide if you want to install it, or want to wait for the next release.
When it is your own home router and you have some way to restore it (e.g. have kept older versions on a computer), by all means just go for it and most of the time you will be allright.
When you are operating a business network with equipment at customers, in any case do some update on a representative device you keep in the office where you can run tests before deploying it to customers.
And when you have half an hour of time to spare, read the forum. Or be prepared to spend a multiple of that half an hour later on recovering customer's devices, and handle their complaints.

rextended · Wed Nov 10, 2021 4:17 pm

(duplicate)

pe1chl · Wed Nov 10, 2021 4:24 pm

That would be ideal but in reality would be an absolute nightmare to maintain. e.g. if there was a bug introduced in 6.48.2 that was fixed in 6.48.5 it shouldn't be mentioned at all in a 6.47.10 to 6.48.5 changelog.

I think it would be possible (I have written this in other topics as well) to put all changelog lines in a database where for every line there are some keyfields like what release this pertains to, what release negates this change (initially empty, can later be filled), what release the problem was introduced in, what models it pertains to, maybe some other things.
And, for each changelog line some optional field with room for further explanations, links to documentation, etc.
Then it should be relatively easy to maintain, probably from MikroTik point of view even easier than a textfile with some lines, as that has to be gathered from different sources at the time of release, while the database could be filled at the time each change is committed.

The website as described would present the changelog for the version range selected. The starting topic of the release has a link to the proper version range.
And when read on the website, each line that has further information has a link to that information, so we can easily see further information instead of having to ask for it here in the release topic (this is especially true for the testing and development versions).

rextended · Wed Nov 10, 2021 4:39 pm

If the problem is really the RouterBOOT 6.41.4 or older (if someone do not know the differencies between RouterBOOT and RouterOS is better to shut up)
negligence on MikroTik staff can be advised, BUT, is worst the negligence on the users,
because the latest "bug free" BIOS is (actually) 6.43.7, and all the users than install just RouterOS without upgrade also the BIOS to actual RouterOS version,
is like install newer processor on motherboard without FIRST upgrade the BIOS with one that support new processor.

Or like convert Windows 10 (64) from MBR to GPT without first upgrade the BIOS with one EFI capable version...

r00t · Wed Nov 10, 2021 5:47 pm

rextended:
Sorry, but no. First your analogy is wrong because with BIOS etc. you know beforehand you have to update it for CPU/GPT to work. If there was a warning on top of this release changelog saying "You need routerboot version X, update it beforehand" it would be OK. But there isn't...

Also it's very common to have old stock or backup hardware that's been sitting in storage for a while, with old version, you just pick up when you need it, try to load latest version... and you are stuck in a boot loop. Again with no warning this is going to happen, unless you read forum and this thread.

And last is simply "don't touch what's not broken", especially with Mikrotik where there is certain risk that updating to latest and newest version will break something, even if it's long-term release. If device is perfectly stable with some version of Routerboot and ROS, but then there's some feature I need from long-term, I only update absolute minimum that's required for this new feature to work, limiting amount of new stuff that may cause issues. Again if there was a warning saying this version requires newer Routerboot, I would have known to update it... or maybe just decide it's not worth it.

starlingus · Thu Nov 11, 2021 12:01 pm

don't touch what's not broken

In this world full of serious vulnerabilities this approach is not possible anymore, unless you do not care about security and you do not mind to sacrifice your device for some botnet like "Meris" https://blog.mikrotik.com/security/meris-botnet.html. And this is the Sophie's Choice ... struggle with potential buggy upgrade or stay unprotected. Even if you have your own staging environment and you test new MikroTik builds before production deployment you can get into situation where new bits are not usable and old ones are vulnerable or having any other serious issue. Here is why I blame MikroTik for lausy cooperation with customers. The silence from MikroTik side in this thread as an example.

Ehman · Fri Nov 12, 2021 12:57 pm

I've emailed support@mikrotik.com and explained them my story and told them to read this forum... after some emails I'm happy with this last email from them...

Hello,

Suggested stable versions for upgrade are > 6.44.4, 6.46.6, 6.48.4, 6.49.

We will check and fix issues with upgrading in the next versions of ROS.

Best regards,

Oskars K.

So lets see if they deliver...

rextended · Fri Nov 12, 2021 2:53 pm

I suggest you to progress 6.44.6, 6.46.8, 6.47.10, 6.48.5
Upgrade at least on 6.47.10 also the BIOS (RouterBOOT), that is the problem on 6.48.5 (and 6.49).
Ignore 6.45.x (6.45.9)
6.49 is not a long-term release

rextended · Fri Nov 12, 2021 3:03 pm

Download on PC the 7.1rc6 based on right platform used on your routerboard,
open routeros-7.1rc6-xxxxxx.npk with 7-ZIP (or similar),
go to /etc/ and extract the xxxxx-7.1rc6.fwf based on firmware type that have your routerboard.
put the file inside the root folder on winbox
go to system / routerboard, on "Upgrade Firmware" must appear 7.1rc6, Upgrade the RouterBOOT / Current Firmware.
on settings temporarly disable auto upgrade
Reboot.
On winbox go to system / packages / "Check for Updates" / etc. as usual.

Do all at your own risk, and test on laboratory before do anything.

Ehman · Fri Nov 12, 2021 8:32 pm

I suggest you to progress 6.44.6, 6.46.8, 6.47.10, 6.48.5

soooo inconvenient and messedup I'd say... its like saying, if you want win10, you need to install windows 95 first and then upgrade and upgrade and upgrade until you reach win10

mkx · Fri Nov 12, 2021 9:49 pm

I suggest you to progress 6.44.6, 6.46.8, 6.47.10, 6.48.5
soooo inconvenient and messedup I'd say... its like saying, if you want win10, you need to install windows 95 first and then upgrade and upgrade and upgrade until you reach win10

No, it's the case where you have windows 95 running and you want to get to windows 11 without touching running config. Or you can bite the bullet and format disk and install windows 11 directly (netinstall newest version of ROS).

hecatae · Fri Nov 12, 2021 10:50 pm

Managed to downgrade a rb941-2nd from 7.1rc6 to 6.48.5 successfully using the tik app on my android.

JJT211 · Sat Nov 13, 2021 4:39 pm

I feel the forum is taking a turn for the worse. Asking commentators to post a config or it didn't happen and other forms of proof. All is a bit harsh. Hats off to those that did apply the proof that they were telling the truth! Geez. Have some faith in people. MT forums are usually populated by professionals so their observations should be accurate.

Its not that we need proof....it's that we need hard data to confirm, troubleshoot and ultimately to fix. Someone just complaining that xyz doesnt work solves nothing. A vast majority of the people here work professionally in IT, we should do better.

prawira · Sun Nov 21, 2021 2:22 am

Dear Emils,

I got problem with the dude with 6.48.5 long-term on arm / RB4011.
the dude server itself ok, but the number client that be able to connect to the dude server is limited only one. the #2 connection got an error connection close.
when downgraded into 6.47.10, the number of client connected is not limited to 1.
is there any new setting on 6.48.5 that limit the number of the dude client connection ?

thank you

jovaf32128 · Fri Nov 26, 2021 5:32 pm

Mikrotik 4011 was good on 6.47.10, but after 6.48.5 update i got message “no policy found/generated” for IKE2 connection continuously every day or every second day. 6.49 same thing. Reverted to 6.47.10 - no problem.
Server 4011. Client 1100AHx4, it’s version does not matter (tried 6.47.10, 6.48.5, 6.49) - problem depends only of server firmware.

Emils ask me for the supout, but I can not provide. May be anyone has similar problem?

freemannnn · Sun Nov 28, 2021 9:50 pm

today 12 pieces of rb951 used as caps (upgraded to 6.48.5 before 10 days) soft-bricked after the second reboot happened by power outage. i netinstalled all of them and they are back to business.

mjezierski · Mon Nov 29, 2021 5:12 pm

today 12 pieces of rb951 (upgraded to 6.48.5 before 10 days) used as caps soft-bricked after the second reboot happened by power outage. i netinstalled all of them and they are back to business.

I experienced the same thing with 18 RB953GS-5HnT-RP - All required a netinstall after upgrading and 2nd reboot seemingly wiped out the NAND storage. Error on serial terminal was "Kernel Not Found". Luckily in this case I was wiping the config and redeploying with a different configuration anyway.

Amm0 · Tue Nov 30, 2021 1:21 am

today 12 pieces of rb951 (upgraded to 6.48.5 before 10 days) used as caps soft-bricked after the second reboot happened by power outage. i netinstalled all of them and they are back to business.
I experienced the same thing with 18 RB953GS-5HnT-RP -

curious if the original ROS version was particular older (eg not the previous long-term) - i’ve seen weirdness when going making big leaps in firmware?

The 2nd reboot is likely when the firmware auto-upgrade kicking in - so the 2nd reboot is a curious detail here.

freemannnn · Tue Nov 30, 2021 9:36 am

I experienced the same thing with 18 RB953GS-5HnT-RP -
curious if the original ROS version was particular older (eg not the previous long-term) - i’ve seen weirdness when going making big leaps in firmware?

The 2nd reboot is likely when the firmware auto-upgrade kicking in - so the 2nd reboot is a curious detail here.

the version the rb951ui-2hnd they had was ROS 6.43.16
i never use firmware auto-upgrade.

emils · Tue Dec 07, 2021 12:38 pm

New version 6.48.6 has been released in long-term RouterOS channel:

viewtopic.php?t=180989