RouterOS version 7.18rc has been released on the "v7 testing" 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 the upgrade process;
3) Device has enough free storage space to download all RouterOS packages.

What's new in 7.18rc2 (2025-Feb-21 12:50):

*) cloud - added "Back To Home Files" feature (additional fixes);
*) dhcpv6-relay - added option to create routes for bindings passing through relay (additional fixes);
*) disk - do not allow adding device in raid when major settings mismatch in superblock and config;
*) disk - fixed removing device from raid while resyncing;
*) ethernet - fixed issue with default-names for RB4011, RB1100Dx4, RB800 devices (additional fixes);
*) ethernet - fixed link-down on startup for ARM64 devices (introduced in v7.16);
*) l3hw - added initial HW offloading for VXLAN on compatible switches (additional fixes);
*) lte - added initial eSIM management support (additional fixes);
*) lte - fix R11e-4G modem initialization (introduced in v7.18beta4);
*) lte - fixed cases where the MBIM dialer could get stuck;
*) lte - fixed interface recovery in mixed multiapn setup for MBIM modems (additional fixes);
*) lte - improved initialization for external USB modems;
*) ptp - improved system stability;
*) qos-hw - fixed wred-threshold (introduced in v7.18beta2);
*) ssh - improved channel resumption after rekey and eof handling;
*) wifi-qcom - prevent AP from transmitting broadcast data unencrypted during authentication of first client;
*) winbox - added missing options under "System/Disk" menu (additional fixes);

What's new in 7.18rc1 (2025-Feb-18 08:57):

*) cloud - added "Back To Home Files" feature (additional fixes);
*) console - renamed "back-to-home-users" to "back-to-home-user";
*) disk - allow to set only type=raid devices as raid-master;
*) disk - cleanup raid members mountpoint, improve default name of file base block-device;
*) disk - do not allow configuring empty slot as raid member;
*) disk - fixed setting up dependent devices when file-based block-device becomes available;
*) disk - improved stability;
*) disk - mount multi-device btrfs filesystems more reliably at startup;
*) disk - set non-empty fs label when formatting by default;
*) file - improved handling of filesystems with many files (additional fixes);
*) l3hw - added initial HW offloading for VXLAN on compatible switches (additional fixes);
*) log - added CEF format support for remote logging (additional fixes);
*) lte - fixed interface recovery in mixed multiapn setup for MBIM modems;
*) lte - improved automatic link recovery and modem redial functions;
*) lte - reduce modem initialization time for R11e-LTE-US;
*) lte - reduced SIM slot switchover time for modems with AT control channel (except R11e-LTE) (additional fixes);
*) poe-out - fixed PoE-out not working on first boot after upgrade for CRS354 (introduced in v7.18beta2);
*) rose-storage - fixes for btrfs server;
*) smb - fixes for SMB server;
*) winbox - added "Reset Alert" button under "IP/DHCP Server/Alerts" menu;
*) winbox - added missing options under "System/Disk" menu;
*) winbox - do not show LTE "Antenna Scan" button on devices that do not support it;

Other changes since v7.17:

*) 60ghz - improved system stability;
*) bgp - fixed certain affinity options not working properly;
*) bgp - improved system stability when printing BGP advertisements;
*) bgp - make NO_ADVERTISE, NO_EXPORT, NO_PEER communities work;
*) bond - added transmit hash policies for encapsulated traffic;
*) bridge - added MLAG heartbeat property;
*) bridge - avoid duplicate VLAN entries with dynamic wifi VLANs;
*) bridge - do not reset MLAG peer port on heartbeat timeout (log warning instead);
*) bridge - fixed endless MAC update loop (introduced in v7.17);
*) bridge - fixed missing S flag on interface configuration changes;
*) bridge - improved stability when using MLAG with MSTP (introduced in v7.17);
*) bridge - improvements to MLAG host table updates;
*) bridge - process more DHCP message types (decline, NAK, inform);
*) bridge - removed controller-bridge (CB) and port-extender (PE) support;
*) bridge - show VXLAN remote-ip in host table;
*) btest - allow limiting access to server by IP address;
*) certificate - fixed localized text conversion to UTF-8 on certificate creation;
*) chr - fixed limited upgrades for expired instances;
*) chr/x86 - added network driver for Huawei SP570/580 NIC;
*) chr/x86 - fixed error message on bootup;
*) chr/x86 - fixed GRE issues with ice network driver;
*) chr/x86 - Realtek r8169 updated driver;
*) cloud,bth - use in-interface matcher for masquerade rule;
*) console - added dsv.remap to :serialize command to unpack array of maps from print as-value (additional fixes);
*) console - added file-name parameter to :serialize;
*) console - allow ISO timezone format in :totime command;
*) console - allow tab as dsv delimiter;
*) console - allow to toggle script error logging with "/console settings log-script-errors";
*) console - do not autocomplete arguments when match is both exact and ambiguous;
*) console - do not show numbering in print follow;
*) console - fixed "get" and "proplist" for certain settings;
*) console - fixed issue where ping command displays two lines at the same time;
*) console - fixed issue with disappearing global variable;
*) console - implement scriptable safe-mode commands and safe-mode handler;
*) console - improved hints;
*) console - log errors within scripts to the system log;
*) console - make non-pseudo terminals work with imports;
*) console - put !empty sentence when API query returns nothing;
*) container - add default registry-url=https://lscr.io;
*) container - allow HTTP redirects when accessing container registry;
*) container - allow specifying registry using remote-image property;
*) container - improved image arch choice;
*) container - use parent directory of container root-dir for unpack by default, so that container layer files are downloaded directly on target disk;
*) defconf - added IPv6 FastTrack configuration;
*) device-mode - do not allow changing CPU frequency if "routerboard" is not allowed by device mode (introduced in v7.17);
*) device-mode - fixed feature and mode update via power-reset on PPC devices;
*) dhcpv4-client - allow selecting to which routing tables add default route (additional fixes);
*) dhcpv4-client - fixed default option export output;
*) dhcpv4-server - fixed "active-mac-address" update when client has changed MAC address;
*) dhcpv4-server - fixed framed-route removal;
*) dhcpv4-server - fixed lease assigning when server address is not bind to server interface (introduced in v7.17);
*) dhcpv6-client - added "validate-server-duid" option;
*) dhcpv6-client - allow specifying custom DUID;
*) dhcpv6-client - do not run script on prefix renewal;
*) dhcpv6-relay - add routes for bindings passing through relay;
*) dhcpv6-server - respond to client in case of RADIUS reject;
*) discovery - advertise IPv6 capabilities based on "Disable IPv6" global setting;
*) discovery - improved stability during configuration changes;
*) discovery - report actual PSE power-pair with LLDP;
*) discovery - use power-via-mdi-short LLDP TLV only on pse-type1 802.3af;
*) disk - add disk trim command (/disk format-drive diskx file-system=trim);
*) disk - allow to add swap space without container package;
*) disk - fix detecting disks on virtual machines;
*) disk - fixed showing free space on tmpfs (introduced in v7.17);
*) disk - improved system stability when SMB interface list is used (introduced in v7.17);
*) dns - do not show warning messages for DNS static entries when they are not needed;
*) ethernet - fixed issue with default-names for RB4011 and RB1100Dx4 devices;
*) ethernet - improved link speed reporting on 2.5G-baseT and 10Gbase-T ports;
*) fetch - added "http-max-redirect-count" parameter, allows to follow redirects;
*) fetch - do not require "content-length" or "transfer-encoding" for HTTP;
*) fetch - fixed IPv6 handling in URL (introduced in v7.18beta2);
*) file - added "recursive" and "relative" parameters to "/file/print" for use in conjunction with "path" parameter;
*) file - allow printing specific directories via path parameter;
*) file - fixed missing meta information from special files such as packages (introduced in v7.18beta2);
*) file - hide store directories, such as container (introduced in v7.18beta2);
*) firewall - allow in-interface/in-bridge-port/in-bridge matching in postrouting chains;
*) firewall - fixed incorrectly inverted hotspot value configuration;
*) firewall - increased maximum connection tracking entry count based on device total RAM size;
*) hotspot - fixed an issue where extra "flash/" is added to html-directory for devices with flash folders (introduced in v7.17);
*) igmp-proxy - fixed multicast routing after upstream interface flaps (introduced in v7.17);
*) iot - added new "iot-bt-extra" package for ARM, ARM64 which enables use of USB Bluetooth adapters (LE 4.0+);
*) iot - improvements to LoRa logging and stability;
*) iot - limited MQTT payload size to 32 KB;
*) ip - added support for /31 address;
*) ippool - added pool usage statistics;
*) ipsec - added hardware acceleration support for hEX refresh (additional fixes);
*) ipsec - fixed chacha20 poly1305 proposal;
*) ipsec - fixed installed SAs update process when SAs are removed;
*) ipv6 - added ability to disable dynamic IPv6 LL address generation on non-VPN interfaces;
*) ipv6 - added FastTrack support;
*) ipv6 - added routing FastPath support (enabled by default) (additional fixes);
*) ipv6 - added support for neighbor removal and static entries;
*) ipv6 - fixed configuration loss due to conflicting settings after upgrade (introduced in v7.17);
*) l2tp - added IPv6 FastPath support;
*) l3hw - added neigh-dump-retries property;
*) l3hw - fixed /32 (IPv6 /128) route offloading when using interface as gateway;
*) l3hw - fixed partial route offloading for 98DX224S, 98DX226S, 98DX3236 switches;
*) l3hw - respect interface specifier (%) when matching a gateway;
*) log - added option to select TCP or UDP for remote logging;
*) lte - added at-chat support for EC21EU;
*) lte - added basic support for Quectel RG255C-GL modem in "at+qcfg="usbnet",0" USB composition;
*) lte - added confirmation-code parameter for eSIM provisioning;
*) lte - added initial eSIM management support (additional fixes);
*) lte - fixed Huawei ME909s-120 support;
*) lte - fixed missing 5G info for "/interface lte print" command;
*) lte - fixed missing IPv6 prefix advertisement on renamed LTE interfaces;
*) lte - fixed prolonged reboots on Chateau 5G ax;
*) lte - fixed R11eL-EC200A-EU modem RAT mode selection (introduced in v7.18beta2);
*) lte - fixed SIM slot initialization with multi-APN setups;
*) lte - lte monitor, show CQI when modem reports it as 0 - undetectable, no RX/down-link resource block assigned to modem by provider;
*) lte - R11eL-EC200A-EU fixed online firmware upgrade and added support for firmware update from local file;
*) lte - R11eL-EC200A-EU improved failed connection handling and recovery;
*) lte - removed nonexistent CQI reading for EC200A-EU modem;
*) net - added initial support for automatic multicast tunneling (AMT) interface (additional fixes);
*) netinstall - try to re-create socket if link status changes;
*) netinstall-cli - fixed DHCP magic cookie;
*) ospf - fixed DN bit not being set;
*) ospfv3 - fixed ignored metric for intra-area routes;
*) ovpn - added requirement for server name when exporting configuration;
*) ovpn - disable hardware accelerator for GCM on Alpine CPUs (introduced in v7.17);
*) ovpn-client - added 1000 character limit for password;
*) pimsm - fixed incorrect neighbor entry when using lo interface;
*) poe-out - added "power-pair" info to poe-out monitor (CLI only);
*) poe-out - added console hints;
*) poe-out - added new modes "forced-on-a" and "forced-on-bt", where old "forced-on" mean "forced-on-bt" (CLI only);
*) poe-out - fixed invalid poe-in status detection for RB5009 (introduced in v7.18beta2);
*) poe-out - upgraded firmware for 802.3at/bt PSE controlled boards (the update will cause brief power interruption to PoE-out interfaces);
*) port - improved handling of USB device plug/unplug events;
*) ppc - fixed HW encryption (introduced in v7.17);
*) ppp - add support for configuration of upload/download queue types in profile;
*) ppp - added support for random UDP source ports;
*) ppp - fixed setting loss when adding new ppp-client interface for BG77 modem from CLI;
*) ppp - properly cleanup failed inactive sessions on pppoe-server;
*) ptp - do not send packets on STP blocked ports;
*) qos-hw - fixed global buffer limits for 98CX8410 switch;
*) queue - improved system stability when many simple queues are added (introduced in v7.17);
*) queue - improved system stability;
*) queue - prevent CAKE bandwidth config from potentially causing lost connectivity to a device;
*) resolver - fixed static FQDN resolving (introduced in v7.17);
*) rip - fixed visibility of added key-chains in interface-template;
*) rose-storage - add btrfs filesystem add-device/remove-device/replace-device/replace-cancel commands to add/remove/replace disks to/from a live filesystem;
*) rose-storage - add btrfs filesystem balance-start/cancel commands;
*) rose-storage - add btrfs filesystem scrub-start, scrub-cancel commands (CLI only);
*) rose-storage - add btrfs transfers, supports send/receive into/from file for transferring subvolumes across btrfs filesystems;
*) rose-storage - add support to add/remove btrfs subvolumes/snapshots;
*) rose-storage - added support for advanced btrfs features: multi-disk support, subvolumes, snapshots, subvolume send/receive, data/metadata profiles, compression, etc;
*) rose-storage - allow to separately mount any btrfs subvolumes;
*) rose-storage - update rsync to 3.4.1;
*) rose-storage,ssh - support btrfs send/receive over ssh;
*) route - added /ip/route/check tool;
*) route - added subnet length validation on route add;
*) route - do not use disabled addresses when selecting routing id;
*) route - fixed busy loops (route lockups);
*) route - fixed incorrect H flag usage;
*) route - improved stability when polling static routes via SNMP;
*) route - properly resolve imported BGP VPN routes;
*) routerboot - disable packet switching during etherboot for hEX refresh ("/system routerboard upgrade" required);
*) routerboot - improved stability for IPQ8072 ("/system routerboard upgrade" required);
*) routing-filter - improved stability when using large address lists (>5000);
*) routing-filter - improved usage of quotes in filter rules;
*) sfp - fixed missing "1G-baseX" supported rate for NetMetal ac2 and hEX S devices;
*) sfp - improved linking with certain QSFP modules on CRS354 devices;
*) sfp - improved system stability with some GPON modules for CCR2004 and CCR2116 devices (additional fixes);
*) sfp,qsfp - improved initialization and linking;
*) smb - fixed connection issues with clients using older SMB versions (introduced in v7.17);
*) smb - improved system stability;
*) snmp - added "mtxrAlarmSocketStatus" OID to MIKROTIK-MIB;
*) snmp - added disk serial number through description field;
*) snmp - sort disk list and assign correct disk types;
*) supout - added IPv6 settings section;
*) supout - added per CPU load information;
*) switch - allow entering IPv6 netmask for switch rules (CLI only);
*) switch - fixed dynamic switch rules created by dot1x server (introduced in v7.17);
*) switch - fixed issues with inactive hardware-offloaded bond ports;
*) switch - improved egress-rate on QSFP28 ports;
*) switch - improved system stability for CRS304 switch;
*) switch - improvements to certain switch operations (port disable, shaper and switch initialization) (additional fixes);
*) system - added option to list and install available packages (after using "check-for-updates");
*) system - do not allow to install multiple wireless driver packages at the same time;
*) system - do not cause unnecessary sector writes on check-for-updates;
*) system - enable "ipv6" package on RouterOS v6 downgrade if IPv6 is enabled;
*) system - fixed a potential memory leak that occurred when resetting states after an error;
*) system - force time to be at least at package build time minus 1d;
*) system - improved HTTPS speed;
*) system - improved stability on busy systems;
*) system,arm - automatically increase boot part size on upgrade or netinstall (fixed upgrade failed due to a lack of space on kernel disk/partition);
*) tile - improved system stability;
*) traceroute - added "too many hops" error when max-hops are reached;
*) traceroute - limit max-hops maximum value to 255;
*) user - improved authentication procedure when RADIUS is not used;
*) vxlan - added disable option for VTEPs;
*) vxlan - added IPv6 FastPath support;
*) vxlan - added option to dynamically bridge interface and port settings (hw, pvid);
*) vxlan - added TTL property;
*) vxlan - changed default port to 4789;
*) vxlan - fixed unset for "group" and "interface" properties;
*) vxlan - replaced the "inherit" with "auto" option for dont-fragment property (new default);
*) webfig - added confirmation when quitting in Safe Mode;
*) webfig - do not reload form when failed to create new object;
*) webfig - fixed "TCP Flags" property when inverted flags are set in console;
*) webfig - fixed datetime setting under certain menus;
*) webfig - fixed displaying passwords;
*) webfig - fixed Switch/Ports menu not showing correctly;
*) webfig - hide certificate information in IP Services menu when not applicable;
*) webfig - remember expand/fold state;
*) wifi - added max-clients parameter;
*) wifi - avoid excessive re-transmission of SA Query action frames;
*) wifi - fix issue which made it possible for multiple concurrent WPA3 authentications to interfere with each other;
*) wifi - implement steering parameters to delay probe responses to clients in the 2.4GHz band;
*) wifi - log a warning when a client requests power save mode during association as this may prevent successful connection establishment;
*) wifi - re-word the "can't find PMKSA" log message to "no cached PMK";
*) wifi - try to authenticate client as non-FT client if it provides incomplete set of FT parameters;
*) wifi-qcom - fix reporting of radio minimum antenna gain for hAP ax^2;
*) wifi-qcom - fixed potentially lowered throughput for station interfaces if channel.width property is set (introduced in v7.18beta2);
*) winbox - added "Copy to Provisioning" button under "WiFi/Radios" menu;
*) winbox - added "Last Logged In/Out" and "Times Matched" properties under "WiFi/Access List" menu;
*) winbox - added L3HW Advanced and Monitor;
*) winbox - added TCP settings under "Tools/Traffic Generator/Packet Templates" menu;
*) winbox - do not show 0 Tx/Rx rate under "WiFi/Registration" menu when values are not known;
*) winbox - fixed locked input fields when creating new certificate template;
*) winbox - fixed usb power-reset bus selection for RB924iR-2nD-BT5&BG77 (introduced in v7.18beta2);
*) winbox - show LTE "CA Band" field only when CA info is available;
*) winbox - show warning messages for static DNS entries;
*) x86 - fixed "unsupported speed" warning (additional fixes);

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, please send a supout file from your router to support@mikrotik.com. File must be generated while a router is not working as suspected or after some problem has appeared on the device

Please keep this forum topic strictly related to this particular RouterOS release.

Thanks for the improvements.

Heads-up - breaking changes for management and monitoring:
*) console - put !empty sentence when API query returns nothing;

*) poe-out - added new modes "forced-on-a" and "forced-on-bt", where old "forced-on" mean "forced-on-bt" (CLI only);

Does this mean that Mode A is going to be possible now or in future?

*) dhcpv6-relay - add routes for bindings passing through relay;

i'd really appreciate an option to disable this for both relay and server (unless one already exists and i couldn't find it) -- when using DHCPv6 for IA_NA, there's often no need to add these routes and they clog up the routing table.

Thanks for the RC release.
But what I have mention in the beta channel that should be fixes has been fixed. Like the duplicate name in logs

*) bond - added transmit hash policies for encapsulated traffic;

Nice feature, too bad MPLS isn't on the list of supported protocols.

*) poe-out - added new modes "forced-on-a" and "forced-on-bt", where old "forced-on" mean "forced-on-bt" (CLI only);

Does this mean that Mode A is going to be possible now or in future?

Only for PSE devices that support 4-pair powering
Documentation was just updated: https://help.mikrotik.com/docs/spaces/R ... rtSettings

Heads-up - breaking changes for management and monitoring:
*) console - put !empty sentence when API query returns nothing;

It's still not in docs, which is annoying since we're now at "rc". IMO docs should be done by a "release candidate" (i.e. theoretically shippable). And developing an API client requires accurate docs. I mean it's not entirely clear if it's only if you use .query or any get...

God only knows how many other API clients in the bowels of ISPs networks that are going to run into this one.

No mention of CVE-2024-54772 fixing?

It was published on cve.org on 2025-02-11.

And the first time it was mentioned here on the forum was in 2025-02-13:

https://www.cve.org/CVERecord?id=CVE-2024-54772

No mention of CVE-2024-54772 fixing?

It was published on cve.org on 2025-02-11.

And the first time it was mentioned here on the forum was in 2025-02-13:

https://www.cve.org/CVERecord?id=CVE-2024-54772

This repo contains the exploit for CVE-2024-54772 which can enumerate valid usernames in Mikrotik routers running RouterOS v6.43 through v7.17.2. The patch is present in v6.49.18 and it will be available in branch v7.18 but it's now still under testing (as v7.18beta2) and will be released in the near future. Please, check the following link for RouterOS change log


It might not be mentioned in release notes but seems patch already incorporated into 7.18b2 onwards.

already RC state ... ? it's fast...

No mention of CVE-2024-54772 fixing?

It was published on cve.org on 2025-02-11.

And the first time it was mentioned here on the forum was in 2025-02-13:

https://www.cve.org/CVERecord?id=CVE-2024-54772

on the 6.X release they mentioned that this line means the CVE has been fixed.
Its also present on the RC here.
Still a bit confusing since they dont mention the CVE itself

*) user - improved authentication procedure when RADIUS is not used;

Here:
viewtopic.php?t=214751
viewtopic.php?t=214751#p1127084

skindesigner solution still not working...

Why there no way to disable the quickset menu everywhere... ?

Please check SUP-172615.

Mikrotik is one of the best company doing this Stuff...

I need to check again, but at first glance it seems 7.18rc1 broke my 6to4 tunnel

EDIT: yep, back to 7.18beta6 and 6to4 tunnel is working ok.

*) console - renamed "back-to-home-users" to "back-to-home-user";

I get y'all use the singular form in commands. But if you were going to rename it "back-to-home-shares" or something that reflect the are the Nth users that some "shared" the VPN in your app. Anyway, how back-to-home was reflected in CLI is weird.

IMO, the first BTH user should move to under the "back-to-home-user" so all the BTH "users" are in one place.

Hi MT,
from this road map,
https://help.mikrotik.com/docs/spaces/R ... l+Overview

any ETA or which version 6vpe & 6PE will be implemented?


thx

Please send supout file to support@mikrotik.com (or files, if both end-points are RouterOS) - it is working just fine for me between two RouterOS powered devices running 7.18rc1.

I need to check again, but at first glance it seems 7.18rc1 broke my 6to4 tunnel

EDIT: yep, back to 7.18beta6 and 6to4 tunnel is working ok.

We will look into this, but the route service crashes that you are experienced were also there on your router in v7.16, so they are not introduced in v7.18.

Please check SUP-172615.

Heads-up - breaking changes for management and monitoring:
*) console - put !empty sentence when API query returns nothing;

It's still not in docs, which is annoying since we're now at "rc". IMO docs should be done by a "release candidate" (i.e. theoretically shippable). And developing an API client requires accurate docs. I mean it's not entirely clear if it's only if you use .query or any get...

And why was this change even made?? Only in response to some customer who does not understand that an empty response could be returned on a query?

We will look into this, but the route service crashes that you are experienced were also there on your router in v7.16, so they are not introduced in v7.18.

It is clear that in 7.16 some breakage was introduced in the routing... and now we cannot assume that it will ever be fixed?
I presume the window for BGP fixes in 7.18 has again been closed now that we are in rc?
Is "routing" still a priority for MikroTik or do we now only get fixes and additions for stuff like "storage"?

In RC phase usually you see in changelog "(additional fixes)" or bugfixes for bugs introduced in beta only.

*) l3hw - added initial HW offloading for VXLAN on compatible switches (additional fixes)

Anyone looked at this one yet? Performance? Also, I recall this was added on one of the 17.x versions, is this now in 17.2?

Subject: Bug Report Regarding SIP Timeout Configuration in MikroTik RouterOS

Dear MikroTik Support Team,

I am writing to formally report an issue encountered in MikroTik RouterOS related to SIP timeout settings.

When configuring the SIP timeout to 20 minutes, as per the request of our SIP/VoIP operator, the system unexpectedly reduces the TCP/UDP timeout for the same port number. This behavior was neither requested nor intended and is causing conflicts and premature timeouts in other network connections utilizing the same port.

The SIP timeout setting should only increase the connection timeout if the existing timeout in conntrack is lower. It should not override or reduce existing timeout values, as this leads to unintended network disruptions.

We kindly request that this matter be investigated and addressed promptly, as it is impacting network stability. If this is an intended system behavior, we would appreciate detailed clarification on the reasoning behind it and any possible workarounds to prevent unintended consequences.

Thank you for your attention to this issue. We look forward to your response and guidance.

Best regards,

It is clear that in 7.16 some breakage was introduced in the routing... and now we cannot assume that it will ever be fixed?I presume the window for BGP fixes in 7.18 has again been closed now that we are in rc? Is "routing" still a priority for MikroTik or do we now only get fixes and additions for stuff like "storage"?

Yeah, it’s pretty baffling that something as fundamental as routing still isn’t fixed, despite everyone knowing about the issues. At this point, when and why it broke matters less than the fact that it’s still not resolved.

What about adding ":copy" and ":move" commands to copy and move files? You are working on improving file management, but don't have this basic functionality, it's VERY strange.

Mikrotik team, please solve the problems regarding the network and leave features like storage, container and SMB which are completely unnecessary in routers and switches and can only cause instability. I don't know what's going on, but this is network equipment, not servers.

What about adding ":copy" and ":move" commands to copy and move files? You are working on improving file management, but don't have this basic functionality, it's VERY strange.

You can "move" files by setting their names. 😉

I think there is no clean way to copy, though.

@merkkg

... enumerate valid usernames in Mikrotik routers ...

"enumerate" is a bit of over exaggerated

on all the device with R11e-4G sim failure and downgrade to 7.17.2 all working fine, in Iran TD-LTE only support 42 which is not existing in any new card except 5g or million devices has issue, Please do provide the firmware update for R11e-4G and support it till new card release if there will be one.

Thanks
Parham

Mikrotik team, please solve the problems regarding the network and leave features like storage, container and SMB which are completely unnecessary in routers and switches and can only cause instability. I don't know what's going on, but this is network equipment, not servers.

If you don't like/need them, just don't use them, what the problem? I'm 100% sure, there are different developer teams for network features/storage features and they don't affect each other productivity.

You can "move" files by setting their names. 😉

I think there is no clean way to copy, though.

Yeah, my bad, thanks for pointing to this. But I mostly need "copy" to transfer between RAM and SMB and making backups.

Hi,

Kernel failure in previous boot while upgrading from 7.17.2 to 7.18rc1 on CCR2004-1G-12S+2XS.

I send autosupout.rif to support...

Mikrotik team, please solve the problems regarding the network and leave features like storage, container and SMB which are completely unnecessary in routers and switches and can only cause instability. I don't know what's going on, but this is network equipment, not servers.

If you don't like/need them, just don't use them, what the problem? I'm 100% sure, there are different developer teams for network features/storage features and they don't affect each other productivity.

You can "move" files by setting their names. 😉

I think there is no clean way to copy, though.

Yeah, my bad, thanks for pointing to this. But I mostly need "copy" to transfer between RAM and SMB and making backups.

+1, I couldn't agree more. I use those features, and I am happy with the functionalities they provide...

If you don't like/need them, just don't use them, what the problem? I'm 100% sure, there are different developer teams for network features/storage features and they don't affect each other productivity.

Well, the problem is that the network developer team fouled up the routing in 7.16 and now in 7.18rc1 it still has not been fixed.
I have a ticket open since August 2024 and there basically is no progress.
Sometimes I fear the routing developer team has been reduced to zero members.
(in the early days of v7 it was the same, many many versions the wellknown BGP problems were not addressed at all)

In that case one might expect that "routing" gets more priority than "nice features for the home user", but sadly it isn't the case.

+1, I couldn't agree more. I use those features, and I am happy with the functionalities they provide...

I use BGP routing, and I am sad it no longer works reliably (as it did in v6 and for some time in v7, I would say between 7.10 and 7.15).

+1, I couldn't agree more. I use those features, and I am happy with the functionalities they provide...

I use BGP routing, and I am sad it no longer works reliably (as it did in v6 and for some time in v7, I would say between 7.10 and 7.15).

Our production network is on 7.13, and absolute zero issues with BGP. Some 1.9M routes hapily routing

Our production network is on 7.13, and absolute zero issues with BGP. Some 1.9M routes hapily routing

Don't upgrade past 7.15!
We had to do that for other reasons, we use BGP internally on a small network, not for internet routing.
But it now fails to perform is basic task: keeping alternative routes in the table and re-select them when a tunnel is down, and also quick response when tunnels come up.

Mikrotik team, please solve the problems regarding the network and leave features like storage, container and SMB which are completely unnecessary in routers and switches and can only cause instability. I don't know what's going on, but this is network equipment, not servers.

I agree with You 1000%
Routers should be routers. Let servers be servers...

Mikrotik team, please solve the problems regarding the network and leave features like storage, container and SMB which are completely unnecessary in routers and switches and can only cause instability. I don't know what's going on, but this is network equipment, not servers.

I agree with You 1000%
Routers should be routers. Let servers be servers...

We all know what's coming next: one of MT staffers telling us (again) that routing development team is separate from "goodies" development team. And that development pace of one team does not affect development pace of the other team.

While this might be true it's still royal PITA to see core functionality of ROS stagnate at some (partially) defunct state while other functionalities (about which some users do care and are enthusiastic while majority of users don't give a s**t) are getting somewhere. I'm pretty sure that many users would understand about complexity (and time demanding) of fixing routing functions ... if MT would publish some (semi)concrete plans about when things are going to be fixed. And then also stick to those plans.

All the new stuff is suffixed by "(additional fixes);". So you get an idea where development effort goes into. Fixing bugs is one of the most time consuming tasks you have as developer. Writing new features is fast. Fixing bugs is consuming all your time.

Mikrotik team, please solve the problems regarding the network and leave features like storage, container and SMB which are completely unnecessary in routers and switches and can only cause instability. I don't know what's going on, but this is network equipment, not servers.

I agree with You 1000%
Routers should be routers. Let servers be servers...

I've to second that. I wish MT would focus mainly on the core functionality of their devices, routing and switching in a first instance, and treat this with the highest priority in terms of stability and bug fixing. Once the core functionality is considered to be working and stable (I'm not saying it has to be absolutely free of bugs, but there shouldn't be any major/severe bugs), only then other functions should be added, tested and further improved or extended with the help & contribution of the community.

It makes the impression that there is attempt to concur with DD-WRT, which is rather a sad development to be honest.

We all know what's coming next: one of MT staffers telling us (again) that routing development team is separate from "goodies" development team. And that development pace of one team does not affect development pace of the other team.

I've already said about it, though I'm not a staffer. But it seems, that some people don't understand this...

Please send supout file to support@mikrotik.com (or files, if both end-points are RouterOS) - it is working just fine for me between two RouterOS powered devices running 7.18rc1.

I need to check again, but at first glance it seems 7.18rc1 broke my 6to4 tunnel
EDIT: yep, back to 7.18beta6 and 6to4 tunnel is working ok.

An RB4011 (7.18rc1) on my side <-6to4 tunnel-> HE tunnel broker (Frankfurt, DE 216.66.80.30 node) on the other side.
Was working fine on 7.17.x and also 7.18 untill beta6 (version I went back to).

P.S. I'm sorry, I can't provide supout in this case (I would need to redact/remove 50% of the config before submitting). BUT the config is just basic 6to4 tunnel, a WORKING config until yesterday.

Reading the tea leaves, it seems as though there are other products that have been in the pipeline for a while that are going to leverage these features in ways that our existing RB- and CCR-whatevers may not. And likely in different directions/verticals than most forum posters are used to.

That said, I too wish that BGP and other core networking functionality seemed to garner as much internal attention.

(One could surmise that the networking codebases are significantly more difficult to work on than implementing existing Linux solutions, hence the appearance that the "goodies" are getting more attention. It doesn't take much to add GUI knobs and levers for BTRFS, for example, but chasing down BGP oddities that only a few people are reporting is quite seriously the proverbial needle in the haystack. Messaging like "we've heard you and we're looking for the problem" goes a long way in this regard.)

(One could surmise that the networking codebases are significantly more difficult to work on than implementing existing Linux solutions, hence the appearance that the "goodies" are getting more attention. It doesn't take much to add GUI knobs and levers for BTRFS, for example, but chasing down BGP oddities that only a few people are reporting is quite seriously the proverbial needle in the haystack.

Adding a GUI and knobs and levers to something like FRR, or Bird which is readily available and stable in linux, doesn't take a lot either :)

Messaging like "we've heard you and we're looking for the problem" goes a long way in this regard.)

I agree with this, if there was a list of known issues that they are working on (even if they cant give a timeline) it would be super helpful.

While this might be true it's still royal PITA to see core functionality of ROS stagnate at some (partially) defunct state while other functionalities (about which some users do care and are enthusiastic while majority of users don't give a s**t) are getting somewhere.

Yes, what is so bad about it is that around version 7.10 things were working fine again, after having been broken or incomplete in the early v7 releases, I already started recommending people to upgrade from v6.49 to v7.10 where before I recommended v6 for stable operation, then that was OK until 7.15.x and in 7.16 it was broken again.
I would think that once the developers got a signal that there were problems, they would be able to check what was changed in 7.16 and how that could affect the operation, and maybe even rollback the changes.
Instead, we got 7.17 and now we will get 7.18 all with the same problems still present.
And as users we do not have the option to remain on 7.15 for routing and update other features to newer releases that provide useful changes and fixes...

So not quite sure here whether it is, or isn't hardware offloaded :-)

(One could surmise that the networking codebases are significantly more difficult to work on than implementing existing Linux solutions, hence the appearance that the "goodies" are getting more attention. It doesn't take much to add GUI knobs and levers for BTRFS, for example, but chasing down BGP oddities that only a few people are reporting is quite seriously the proverbial needle in the haystack.

Adding a GUI and knobs and levers to something like FRR, or Bird which is readily available and stable in linux, doesn't take a lot either :)

That would be awesome! Like the good old v2.9.x days with Quagga! :D

An RB4011 (7.18rc1) on my side <-6to4 tunnel-> HE tunnel broker (Frankfurt, DE 216.66.80.30 node) on the other side.
Was working fine on 7.17.x and also 7.18 untill beta6 (version I went back to).

P.S. I'm sorry, I can't provide supout in this case (I would need to redact/remove 50% of the config before submitting). BUT the config is just basic 6to4 tunnel, a WORKING config until yesterday.

No problems with 6to4 tunnels on my CHRs with rc1 (but not HE).

Our production network is on 7.13, and absolute zero issues with BGP. Some 1.9M routes hapily routing

Don't upgrade past 7.15!
We had to do that for other reasons, we use BGP internally on a small network, not for internet routing.
But it now fails to perform is basic task: keeping alternative routes in the table and re-select them when a tunnel is down, and also quick response when tunnels come up.

good to know...

Mikrotik team, please solve the problems regarding the network and leave features like storage, container and SMB which are completely unnecessary in routers and switches and can only cause instability. I don't know what's going on, but this is network equipment, not servers.

I agree with You 1000%
Routers should be routers. Let servers be servers...

no sense on a market completly saturated...
MikroTik ADN is network, why spend so time to storage when network features is becoming unstable...

MikroTik ADN is network, why spend so time to storage when network features is becoming unstable...

I agree... lot of not really oriented network routers/switching/firewall features, but since this release, when seeing ipv6 fast tracking, i can say it's a great thing.

*) cloud - added "Back To Home Files" feature (additional fixes);

I'd like to request a YouTube video on this feature.

Any details on this?

So not quite sure here whether it is, or isn't hardware offloaded :-)

Those two are not the same thing. "Hardware Offload" is a setting that you can turn on or off to tell RouterOS whether you want hardware offloading to be enabled if possible. And Hw. Offload is the actual status whether Hardware offloading is currently supported by the hardware and actively working.

In the Bridge -> Ports table they are two separate columns (you can toggle their visibility). Hw. Offload also corresponds to the "H" flag of the entry.

An RB4011 (7.18rc1) on my side <-6to4 tunnel-> HE tunnel broker (Frankfurt, DE 216.66.80.30 node) on the other side.
Was working fine on 7.17.x and also 7.18 untill beta6 (version I went back to).

No problems with 6to4 tunnels on my CHRs with rc1 (but not HE).

Thanks for your feedback; I've tried again to upgrade to 7.18rc1 (on 2nd partition for quick restore) and .. now it works (no config changes have been made).
There is something I'm missing for sure.. but for now let's hope it's a stable state.

*) ovpn - disable hardware accelerator for GCM on Alpine CPUs (introduced in v7.17);

I suppose this is why using GCM on a CCR2004 with 7.17.2 I get a lot of "AEAD Decrypt error: cipher final failed"?

Disk editor window has become very overloaded with tons of unneeded fields and flags and now looks like a garbage container...

For example, tmpfs or smb disk types definitely don't need temperature statistics, power cycles, power up time and I think many other fields, because they simply don't have such parameters. And they don't need raid/nvme/iscsi and other non-related flags.
BTW, statistics is absolutely empty. At least, for smb and tmpfs, not sure about other types.

Please, leave only those fields and flags that are related to current disk type!
.

MikroTik ADN is network, why spend so time to storage when network features is becoming unstable...

I agree... lot of not really oriented network routers/switching/firewall features, but since this release, when seeing ipv6 fast tracking, i can say it's a great thing.

What the point MT selling CCR with the best network chip inside and people buy it for SMB?
I think people choose to buy CCR for complex network/ routing /mpls purposes to support their business and put their hope with MT hardware. But to see all of this, its very frustrating.


Thx

Any real improvements in 60 Ghz?

For all you storage haters:

https://youtu.be/g1wpIIfYpZA?feature=shared

For all you storage haters:

https://youtu.be/g1wpIIfYpZA?feature=shared

Well, that explains a bit :)

For all you storage haters: https://youtu.be/g1wpIIfYpZA?feature=shared

Fun, but was this intended for April 1st? 😉

Anyway, I’d never ever trust MT ROS for business-critical data storage — for pretty obvious reasons! Now please go back and fix those routing issues. But maybe the development team that used to work with routing and protocols has switched to the new "now we're pretending to be a storage provider" department.

For all you storage haters:

https://youtu.be/g1wpIIfYpZA?feature=shared

This is cool, the audience is probably for homelabbers and even then probably the more novice homelabbers or individuals without serious performance needs. Listed below are my concerns and why I don't think this is at the level of enterprise and/or why it won't be used for high performance applications.


Performance
1) How many PCIe lanes are dedicated to each U.2 drive? To drive 20 NVME drives and access their full bandwidth especially if this is PCIe gen 4 or gen 5 you will need more than 16 arm cpus and more than 32gb ram for high performance applications.
2) What is the clock speed of the arm cpu? Why not do an Ampere build if you want Arm related CPUs but even then you need 50-60-70 cores.


Maintenance and Updates
1) How long does it already take for upstream kernel commits to be brought into ROS, now how long do you think it will take for upstream fixes on any storage related implementation to make it's way into ROS?
2) How many developers (out of the limited pool of developers) will be dedicated to fixing nuanced storage related issues?

And honestly, why would I buy this if I can simply buy a supermicro server with 9005 epyc, 20+ nvme gen 5 bays, full PCIe bandwidth on all drives, and I can run ROS in a vm? Not to mention I have a full upgrade path with a dedicated mainstream server that can accept any kind of future implementation I want and that's just talking hardware, not to mention I can mod the kernel, or update any storage implementation as soon as upstream has it available?

For all you storage haters:

https://youtu.be/g1wpIIfYpZA?feature=shared

So if i read it correctly it is CCR2216 basically - cheaper, green, different port set and with drivebays, but still CCR2216, right?

And honestly, why would I buy this if I can simply buy a supermicro server with 9005 epyc, 20+ nvme gen 5 bays, full PCIe bandwidth on all drives, and I can run ROS in a vm? Not to mention I have a full upgrade path with a dedicated mainstream server that can accept any kind of future implementation I want and that's just talking hardware, not to mention I can mod the kernel, or update any storage implementation as soon as upstream has it available?

This is a good question/discussion to start, but it's out of scope for 7.18rc. I merely shared the link to help explain why we're seeing a surge in BTRFS (and other storage-related fixes) in 7.18.

(I will point out that the advantage this likely has over other traditional hyperconverged platforms is that you have a wire-speed Layer 3 switch running ROS on the bare metal. It sounds like a CCR2116 or CCR2216 on storage steroids.)

So if i read it correctly it is CCR2216 basically - cheaper, green, different port set and with drivebays, but still CCR2216, right?

Yes, Rose Data Server (RDS2216). I built something similar using a CCR2116.


Here's how it looked racked up as part of the home lab with ESXi on the Macs:

I'm not against storage features or container support, only I think it should be a side project that gets done when the main features like routing and wireless are working OK.

For all you storage haters:
https://youtu.be/g1wpIIfYpZA?feature=shared

.
This video is "unlisted" on YouTube, and the YouTube Mikrotik account already commented asking people how they found the video, saying it's an unreleased product.
.
This was really leaked OR maybe it's an April Fools video ready with quite some time in advance :)

To: MikroTik Development Team
Subject: Request for MTU/MRU Parameter Separation, TCP MSS Clamping, and Improved PPPoE MTU Behavior
Ticket Number: SUP-179779

Best regards,
VOLKAN SALİH

Every discussion of releases always ends up in OT
It's really annoying…

**To: MikroTik Development Team**
**Subject: Request for MTU/MRU Parameter Separation, TCP MSS Clamping, and Improved PPPoE MTU Behavior**
**Ticket Number: SUP-179779**

Dear MikroTik Development Team,
........
Thank you for your time and dedication to improving RouterOS. I look forward to your response.

**Best regards,**
VOLKAN SALiH

This is good information, you should create an account here https://help.mikrotik.com/servicedesk/s ... r/portal/1 and post it under the "Suggest a new feature". I believe that's your best bet at someone reading it and implementing those changes.

In fact you can already set a lower MTU for IPv6 by configuring it in IPv6->ND.
Your end devices which receive IPv6 addresses via SLAAC will pick up the reduced MTU and will use it for their transmitted packets.
I have never encountered MTU=1488 on PPPoE over VLAN. Normally the 4 bytes of a VLAN header do not count towards the maximum packet size. PPPoE MTU on max-1500 networks is normally 1492, not 1488. I agree with you that PPPoE should fallback to 1492 MTU when required, not to 1480. But also, modern subscriber networks that use PPPoE usually support RFC4638 and allow MTU 1500 for both IPv4 and IPv6.
TCP MTU clamping for any packets being routed can be configured in the Firewall Mangle chains.

I wish you all best of success;
Best Regards and Best Wishes.

This was really leaked OR maybe it's an April Fools video ready with quite some time in advance :)

Yeah, @sirbryan totally wrecked Mikrotik's April Fool’s prank they’d been planning for over a year! 🤣

I know, @pe1chl, but, mikrotik has special clamping feature that works without firewall mangle rule and with fasttrack/fastpath afaik.

Thanks for your response anyway, i respect any opinion as we all are humans. Without respecting others we can not be respected

That "Change TCP MSS" feature (for instance in the PPP profiles) only works with IPv4 in RouterOS and has no effect on IPv6 (it's stated in the docs), and of course it only helps TCP connections whereas today even websites are switching to UDP (with HTTP/3 and QUIC). For IPv6 it's better to configure IPv6->ND like pe1chl already wrote.

And changing TCP MSS with mangle has no conflict with fasttrack, because the mangle rule only applies to the SYN and SYN/ACK packets. One is when the connection state is still new (and thus not yet affected by the fasttrack rule), and the other for the first packet in the "established" state, but because "Mangle Forward" is before "Filter Forward" in the packet flow https://help.mikrotik.com/docs/download ... 451&api=v2, the mangle rule can still change the MSS before the fasttrack rule can match the connection. I know this because I have those mangle rules for both IPv4 and IPv6 right now (needed because I tunnel devices accessing Netflix, both IPv4 and IPv6, inside Wireguard to another household for account sharing) with IPv4 and IPv6 fasttrack working flawlessly.

I kindly ask all users to keep the topic related to 7.18RC version as much as possible.

FWIW I'm testing CHR on smaller hardware, such as Intel N100 and N150 4-core machines, as well as a Raspberry Pi CM5. 7.18rc1 performs much better than 7.17 did on both systems. Both devices are able to push 2.5Gbps UDP in both directions, and up to 5Gbps when using a 10G AQC107 NIC.

However, the native Debian underneath is able to do 1Gbps more on CM5 and 3Gbps more on N150 when running iperf3 tests, and both do it on a single core, vs. CHR in KVM/Qemu utilizing 80% of all four cores. It makes me wonder how much is virtualization overhead and how much is RouterOS.

For the sake of clarity, I would like to emphasize that the MikroTik team is doing its utmost. Please consider RouterOS as a complimentary software that comes bundled with excellent hardware, along with nearly lifetime updates.

Let us remain optimistic and refrain from discouraging others.

------------------------------------------------------------------------

Best regards and best wishes.

@savage

So not quite sure here whether it is, or isn't hardware offloaded :-)

What is the model of that device?

However, the native Debian underneath is able to do 1Gbps more on CM5 and 3Gbps more on N150 when running iperf3 tests, and both do it on a single core, vs. CHR in KVM/Qemu utilizing 80% of all four cores. It makes me wonder how much is virtualization overhead and how much is RouterOS.

You have to make sure you're comparing pears to pears (not going to mention apples ;-) ). ROS in principle does firewalling as well and connection tracking machinery (identifying connections to which each packet belongs) is pretty costly operation. OTOH linux kernel might not be doing it. IIRC connection tracking is enabled whenever there's even a single firewall filter rule configured ...

My experience is that virtualization overhead (e.g. Proxmox VE) can be around 1 core, specially when there's lots of I/O using virtualized hardware (vmnet, disks, etc.). You can compare output of /tool/profile cpu=all with output of e.g. top run on physical machine. And keep in mind that mobile variants of CPUs are quite a bit slower than their desktop/server counterparts.

**Ticket Number: SUP-179779**

Dear MikroTik Development Team,

By implementing these enhancements, MikroTik RouterOS would become **more robust, efficient, and compatible with real-world networking scenarios**. These changes would:
✅ **Reduce packet fragmentation**
✅ **Improve IPv6 interoperability**
✅ **Enhance VPN and PPPoE performance**
✅ **Align RouterOS with industry best practices**

**Best regards,**
VOLKAN SALiH

I found this feature request to be as elegant as a glove slap!
The detail of mentioning the ticket ID in Jira is the cherry on the cake.
Congratulations!
P.S.: At some point I had the patience to do it like that... Like time, realizing that they don't care about it at all. I gave up. But please don't do what I did.

Every discussion of releases always ends up in OT
It's really annoying…

@massinia Your message came right after @volkirik's message.
I want to believe that this isn't the message you were referring to about Off Topic.
I found it extremely On Topic for a Release Candidate! Asking for features.

Just like other colleagues who have been talking about routing problems that they pretend to have fixed by writing "(additional fixes)", but you can see right away that they weren't extensively tested because the same names are repeated in the forum talking over and over and over about the same problems.

Unfortunately, betas and RC threads in this forum are the only place where you can truly reach the MikroTik team. Because they know that if they don't look at this, it will become public shaming. Maybe they should improve this attitude a little.

In addition, it is also On-Topic for a Release Candidate to talk about:

• The lack of 6PE and 6vPE, and BGP-LU.
• The lack of progress on Kernel bypass and hardware off-load on issues like VRF, MPLS L2VPN, and L3VPN.
• The lack of progress on BGP Flowspec (poor thing... It's been forgotten in the routing overview since the beginning.)

And it is also On-Topic for a Release Candidate to talk about the initial progress with VXLan and Hardware Offload.
Which inevitably leads to questions like:

• "Hey, what do you mean I can't pass VLANs over this?"
• "Is EVPN coming soon?
  • "Will it come with Type 5 Routes?"
  • "If yes, how would be possible without VRF hardware offload?"

What's new in 7.18rc1 (2025-Feb-18 08:57):
*) disk - allow to set only type=raid devices as raid-master;
*) disk - cleanup raid members mountpoint, improve default name of file base block-device;
*) disk - do not allow configuring empty slot as raid member;
*) disk - fixed setting up dependent devices when file-based block-device becomes available;
*) disk - improved stability;
*) disk - mount multi-device btrfs filesystems more reliably at startup;
*) disk - set non-empty fs label when formatting by default;
*) rose-storage - fixes for btrfs server;
Other changes since v7.17:
*) disk - add disk trim command (/disk format-drive diskx file-system=trim);
*) disk - allow to add swap space without container package;
*) disk - fix detecting disks on virtual machines;
*) disk - fixed showing free space on tmpfs (introduced in v7.17);
*) disk - improved system stability when SMB interface list is used (introduced in v7.17);
*) rose-storage - add btrfs filesystem add-device/remove-device/replace-device/replace-cancel commands to add/remove/replace disks to/from a live filesystem;
*) rose-storage - add btrfs filesystem balance-start/cancel commands;
*) rose-storage - add btrfs filesystem scrub-start, scrub-cancel commands (CLI only);
*) rose-storage - add btrfs transfers, supports send/receive into/from file for transferring subvolumes across btrfs filesystems;
*) rose-storage - add support to add/remove btrfs subvolumes/snapshots;
*) rose-storage - added support for advanced btrfs features: multi-disk support, subvolumes, snapshots, subvolume send/receive, data/metadata profiles, compression, etc;
*) rose-storage - allow to separately mount any btrfs subvolumes;
*) rose-storage - update rsync to 3.4.1;
*) rose-storage,ssh - support btrfs send/receive over ssh;

All of this is related to how Linux interacts with disks, and they still use Kernel 5.6.3 (April 2020) as a base.

If anyone here has had the opportunity to deal with distributed storage in Kubernetes clusters or hyper-converged virtualization, they must have read about significant changes in this regard in several versions of the Kernel after 5.6.3. Mainly regarding DMA.

Just to illustrate, here are two links that provide brief references on this.

https://en.wikipedia.org/wiki/Linux_ker ... on_history
https://btrfs.readthedocs.io/en/latest/ ... rsion.html

I can't imagine they have incorporated all patches for any improvement made to BTRFS in kernel 5.6+ and 6.0+. So what it the point of using outdated ROSE BTRFS when someone can have that on e.g. TrueNAS for example (or any Linux distribution)?

I can't imagine they have incorporated all patches for any improvement made to BTRFS in kernel 5.6+ and 6.0+. So what it the point of using outdated ROSE BTRFS when someone can have that on e.g. TrueNAS for example (or any Linux distribution)?

I partially agree with you! But what's done won't be undone...
So at least let's use this to make them realize that if they want to continue down this path of adding new features, they'll have to take better care of the building's foundation.

MikroTik should have already started migrating to 6.6.x, which is LTS and has all the storage improvements. The current OpenWrt is also on this branch. I think MikroTik currently use 5.6.3 because 5.6 is the first release that has WireGuard support in the kernel. Otherwise, they would have used an even older version 🙃.

Well, the latest LTS branch is 6.12.x...

That's why I wrote "should have already started". If they already started last year, then 6.6 would have been the right candidate (because 6.12 only came at the end of the year).

It has been discussed many times before. The trade-off is always between following the kernel releases and applying your in-house patches to ever changing kernel versions (having to adapt them all the time) or keeping the same kernel version+in-house patches and then following the kernel development and applying any security related patches and important bugfixes.
Most Linux distributions to the same thing as MikroTik: at release time they choose a kernel version and all further updates are to that same kernel version (adding some local version ID to it).
Of course the best would be to get local patches accepted into the release kernel so you don't have this issue all the time, but that is both extremely difficult (I have tried to get a 3-line patch into the kernel and have given up) and also probably not desired by MikroTik because they would lose some of their competitive advantage.

• LDP signaled VPLS is still not working at all

• over BGP signaled VPLS, IPv4 is ok, but IPv6 isn't [ ping status: "22 (Invalid argument)" ]

• VPNv6 is still not works, but at least in RC1 router doesn't crash

LDP signaled VPLS works
BGP signaled VPLS works
VPNv6 works

either misconfiguration or very specific setup.

LDP signaled VPLS works
BGP signaled VPLS works
VPNv6 works

either misconfiguration or very specific setup.

Could you please share an example config with at least 4 devices RouterOS, being at least one on P.Router Only, with the v7.18rc ?

VPNv6 does indeed work, but only partially, as it does not support an IPv4 backbone as a transport layer.

LDP signaled VPLS works
BGP signaled VPLS works
VPNv6 works

either misconfiguration or very specific setup.

Its totally basic setup in labs, both CHR and physical routerboards. There is a P router in the middle and 3 PE on that.
This is the MPLS and Routing config from first PE router (RB750Gr3): Maybe misconfiguration, but I can't figure out what or where. If you have any proposal, it would be appreciated.
Thanks!

What's new in 7.18rc2 (2025-Feb-21 12:50):

*) cloud - added "Back To Home Files" feature (additional fixes);
*) dhcpv6-relay - added option to create routes for bindings passing through relay (additional fixes);
*) disk - do not allow adding device in raid when major settings mismatch in superblock and config;
*) disk - fixed removing device from raid while resyncing;
*) ethernet - fixed issue with default-names for RB4011, RB1100Dx4, RB800 devices (additional fixes);
*) ethernet - fixed link-down on startup for ARM64 devices (introduced in v7.16);
*) l3hw - added initial HW offloading for VXLAN on compatible switches (additional fixes);
*) lte - added initial eSIM management support (additional fixes);
*) lte - fix R11e-4G modem initialization (introduced in v7.18beta4);
*) lte - fixed cases where the MBIM dialer could get stuck;
*) lte - fixed interface recovery in mixed multiapn setup for MBIM modems (additional fixes);
*) lte - improved initialization for external USB modems;
*) ptp - improved system stability;
*) qos-hw - fixed wred-threshold (introduced in v7.18beta2);
*) ssh - improved channel resumption after rekey and eof handling;
*) wifi-qcom - prevent AP from transmitting broadcast data unencrypted during authentication of first client;
*) winbox - added missing options under "System/Disk" menu (additional fixes);

What's new in 7.18rc2 (2025-Feb-21 12:50):

Oh man, I started to upgrade my routers 5 minutes ago to RC1 :D

What's new in 7.18rc2 (2025-Feb-21 12:50):

*) lte - added initial eSIM management support (additional fixes);

Just 0.02$ ... initial + fixes do not fit releasing stable version. That should be in 7.19beta.

You have to make sure you're comparing pears to pears (not going to mention apples ;-) ). ROS in principle does firewalling as well and connection tracking machinery (identifying connections to which each packet belongs) is pretty costly operation. OTOH linux kernel might not be doing it. IIRC connection tracking is enabled whenever there's even a single firewall filter rule configured ...

It's a blank install of CHR, so no rules, no filters, nothing. Simply doing bandwidth tests from the VM's to my 2116 and to each other. I'll have to see if I can get 7.16 or 7.15 to work, just for fun.

RPi5 is a Broadcom BCM2712 quad-core Arm Cortex A76 processor @ 2.4GHz. That's better than the 1.4GHz quad-core processor in RB4011 and RB5009, the 1.7GHz processor in CCR2004, and the 2GHz processor in CRS526. The 2004 can bridge and route (fast path) 19Gbps (it obviously has more PCIe lanes to the switch from the CPU), so I would hope to get at least the full 6Gbps out of the CHR on the Pi and 10Gbps out of the Intel processor (4 cores at 3GHz).

What's new in 7.18rc2 (2025-Feb-21 12:50):

*) lte - added initial eSIM management support (additional fixes);

Just 0.02$ ... initial + fixes do not fit releasing stable version. That should be in 7.19beta.

And no device yet which supports this ?

What's new in 7.18rc2 (2025-Feb-21 12:50):

*) cloud - added "Back To Home Files" feature (additional fixes);
*) dhcpv6-relay - added option to create routes for bindings passing through relay (additional fixes);
*) disk - do not allow adding device in raid when major settings mismatch in superblock and config;
*) disk - fixed removing device from raid while resyncing;
*) ethernet - fixed issue with default-names for RB4011, RB1100Dx4, RB800 devices (additional fixes);
*) ethernet - fixed link-down on startup for ARM64 devices (introduced in v7.16);
*) l3hw - added initial HW offloading for VXLAN on compatible switches (additional fixes);
*) lte - added initial eSIM management support (additional fixes);
*) lte - fix R11e-4G modem initialization (introduced in v7.18beta4);
*) lte - fixed cases where the MBIM dialer could get stuck;
*) lte - fixed interface recovery in mixed multiapn setup for MBIM modems (additional fixes);
*) lte - improved initialization for external USB modems;
*) ptp - improved system stability;
*) qos-hw - fixed wred-threshold (introduced in v7.18beta2);
*) ssh - improved channel resumption after rekey and eof handling;
*) wifi-qcom - prevent AP from transmitting broadcast data unencrypted during authentication of first client;
*) winbox - added missing options under "System/Disk" menu (additional fixes);

I can't find any LTE interface on my dozens of CCRs.
CCR owners don't lose your hope and keep your spirits up

I can't find any LTE interface on my dozens of CCRs.
CCR owners don't lose your hope and keep your spirits up

Of course not... until you plug in a LTE USB stick (when your CCR has an USB port).
Unfortunately there is no line with "*) bgp - improved stability;" in sight... that is what CCR users are hoping for.

@Mikrotik - since you just restored in this version the forgotten "/ip/route/check" feature for ipv4 (similar to "ip route get" in linux), why not complete the task and give ipv6 the same love ?
Thanks.

LDP signaled VPLS works
BGP signaled VPLS works
VPNv6 works

either misconfiguration or very specific setup.

Hi mrz, any reason why MT still hide vpn6 afi from winbox?
If there any limitation should we know about?

My IPsec tunnels broke on my RB5009 with 7.18rc1. I had to disable the IPv4 forwarding fasttrack rule to fix it for now. I opened ticket SUP-180137.

Strange. There is not even any ipsec related change in rc1.

Hi mrz, any reason why MT still hide vpn6 afi from winbox?
If there any limitation should we know about?

By the way, it is worth mentioning that the syntax between routing and routes is still incongruent:

• "address-families=" vs "afi="
• "vpnv4" vs "vpn4"
• "vpnv6" vs "vpn6"

*) console - put !empty sentence when API query returns nothing;

And why was this change even made?? Only in response to some customer who does not understand that an empty response could be returned on a query?

If only Mikrotik would actually write in more than partial sentence or have a proper KB-like system for these questions... My only guess is the API changed are for internal use with REST API. I think REST API just proxies to API, but uses cached/pipelined connection (based on login in log)... in which case knowing a tagged API request was !empty might be useful. But just guessing.

*) lte - added initial eSIM management support (additional fixes);

I have ask several times about what modems this works with, no response, now half-dozen times. The lack of clarity around eSIM is quite annoying. From reading the docs, it seems like a working feature on something. If it's nothing, then say that in docs! Since I read the docs, and eSIM came up in another thread, the eSIM docs don't mention if the QR code had a $$1 at the end. Which, I think, means the be required.... and the $$1 part should NOT be in the - but it wasn't clear at all... And working in theory here...

*) console - added dsv.remap to :serialize command to unpack array of maps from print as-value (additional fixes);
*) console - allow tab as dsv delimiter;

Now the bright spot is the new scripting changes are just wonderful. They made quick work of the theoretical problem eSIM activation codes use the $ dollar as the delimiter. So on the theoretical modem that support eSIM, you can cut-and-paste the eSIM code to CLI. This is possible by the new :deserialize delimiter="\$" specifically to deal with eSIM LPA format (with the new-ish /terminal/ask allowing cut-and-paste). See viewtopic.php?t=214985 for example.

But there should be something like /ip/dhcp-server/setup for the eSIM. Or, Winbox4 could natively use camera to capture the QR code, too.