RouterOS version 7.17beta 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 upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 7.17beta6 (2024-Nov-20 09:58):

!) device-mode - after upgrade, mode "enterprise" is renamed to "advanced" and traffic-gen, partition (command "repartition"), routerboard and install-any-version features will be disabled (additional fixes);
!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) bridge - fixed bridge packet transmit if dhcp-snooping is enabled (introduced in v7.17beta5);
*) disk - added mount-read-only and mount-filesystem options to allow read-only mounts and prevent mounting device at all (CLI only);
*) firewall - improved matching from deeply nested interface-lists (additional fixes);
*) ipv6 - added support for manual link-local address configuration;
*) lte - improved recovery after unexpected modem reboot for Chateau's 5G and 5G R16 series devices;
*) port - display a warning when using invalid log-file with the "remote-access" feature;
*) ptp - fixed DSCP values for IPv4 packets;
*) ptp - fixed synchronization on QSFP28 interfaces (additional fixes);
*) qos-hw - allow to disable/enable profiles, disabled or removed profile gets replaced with the default (additional fixes);
*) routerboot - improved stability for IPQ8072 and IPQ6010 when flash-boot is used ("/system routerboard upgrade" required);
*) smb - stability improvements for client/server (additional fixes);
*) supout - do not create autosupout.rif for second time after system reboot;
*) tftp - improved stability;
*) winbox - improved stability;

What's new in 7.17beta5 (2024-Nov-13 12:51):

!) device-mode - after upgrade, mode "enterprise" is renamed to "advanced" and bandwidth-test, traffic-gen, partition (command "repartition"), routerboard and install-any-version features will be disabled;
!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) bonding - hide mlag-id property on non-compatible devices;
*) bridge - added message for inactive port reason;
*) bridge - added priority setting to manually elect primary MLAG peer (CLI only);
*) bridge - fixed MVRP registrar and applicant port options;
*) bridge - prioritize MAC selection from Ethernet interfaces when using auto-mac feature;
*) bridge - re-synchronize MLAG system-id when bridge MAC changes;
*) bridge - update dynamic MSTI priority value when changing configuration;
*) certificate - do not download CRL if there is no enough free RAM;
*) certificate - do not show not relevant values for certificate template (CLI only);
*) certificate - removed unstructured address field support;
*) chr - added Chelsio VF driver for PCIID 5803;
*) console - added json.no-string-conversion to :serialize;
*) console - increased w60g scan-list size to 6;
*) console - show system-id in export for CHR;
*) container - fixed user and group ID range;
*) container - improved container shell;
*) defconf - do not add default password for CAP mode configuration on older Audience devices without a password;
*) detnet - remove dynamic DHCP client creation;
*) device-mode - added "allowed-versions" list which are allowed to be installed without "install-any-version" mode enabled;
*) device-mode - added routerboard, install-any-version and partitions features;
*) device-mode - limit device-mode update maximum allowed attempt count which can be reset only with reboot or button press;
*) device-mode - provide more precise device-mode update action printout;
*) dhcp-server - improved stability (introduced in v7.17beta4);
*) dhcp-server - use single RADIUS accounting session for IPv4 and IPv6 when dual stack is used (additional fixes);
*) dhcpv6-client - improved system stability when DHCPv6 client is enabled on non-existing interface;
*) dhcpv6-client - log message when response with invalid transaction-id received;
*) dhcpv6-server - added IPv6 address delegation support;
*) dhcpv6-server - improved system stability when removing actively used DHCPv6 server;
*) disk - add support for SWAP, currently allowed on any block device with "set x swap=yes" when container package is installed (CLI only);
*) disk - added "type=file" for file-based block devices, useful for using file as a swap, or when having file-based filesystem images (CLI only);
*) disk - added btrfs filesystems list (CLI only);
*) disk - auto mount iso and squashfs images;
*) disk - fixed managing and cleaning up mount points;
*) disk - fixed raid role auto selection for up to 64 drives;
*) disk - recognize virtual sd* interfaces;
*) disk - show usage as percentage (CLI only);
*) dns - added option to create named DNS servers that can be used as forward-to servers (additional fixes);
*) ethernet - improved linking after reboot for hAP ax lite devices ("/system routerboard upgrade" required);
*) ethernet - improved stability after reboot for Chateau PRO ax;
*) ethernet - improved system stability for CCR2004-1G-2XS-PCIe device;
*) firewall - added support for random external port allocation;
*) firewall - improved matching from deeply nested interface-lists;
*) ftp - added VRF support;
*) gps - LtAP mini, change default GPS antenna for new devices;
*) iot - added additional debug for LoRa logging;
*) iot - added support for USB Bluetooth dongles (LE 4.0+) which enables Bluetooth functionality;
*) iot - LoRa LNS improvement;
*) iot - modbus rework which improves Tx Rx switching behavior;
*) ipsec - ike2 improved process for policies;
*) lte - disabled ims service for Chateau 5G on operator "3 AT" network (PLMN ID 23205);
*) lte - drop operator selection support for R11e-4G modem as it is unreliable;
*) lte - fixed network registration for R11e-4G modem (introduced in v7.17beta2);
*) lte - fixed SMS sender parsing;
*) lte - improved R11eL-EC200A-EU modem firmware upgrade procedure;
*) lte - improvements to modem "firmware-upgrade" command (additional fixes);
*) lte - MBIM increased assignable APN profile count up to 8 then modem firmware allows it;
*) lte - modem firmware update (FOTA), added support to install provider specific version (additional fixes);
*) lte - set "sms-read=no" and "sms-protocol=auto" as default values;
*) modem - KNOT BG77 modem, improved handling of modem unexpected restarts;
*) netinstall - removed unused "Get key" button;
*) netwatch - fixed IP address variable for DNS probe;
*) ospf - improved stability on configuration update;
*) ovpn-client - added tls-crypt, tls-crypt-v2 support;
*) pimsm - improved system stability after interface disable;
*) poe-out - added low-voltage-too-low status;
*) poe-out - reset PoE-out configuration before reboot when using reset-configuration command;
*) poe-out - upgraded firmware for CRS354-48P-4S+2Q+ device (the update will cause brief power interruption to PoE-out interfaces);
*) port - more detailed print command output, include in "USED-BY" property channel number(s);
*) ppp - add routes in matching VRF;
*) ppp - added support for bridge-port-trusted configuration via ppp profile;
*) ppp - do not print local/remote pool related errors in log when configuration does not require pool usage;
*) ppp - fixed typos in log message;
*) ptp - added PTP support for CRS320-8P-8B-4S+ and CRS326-4C+20G+2Q+ devices;
*) ptp - fixed synchronization on QSFP28 interfaces;
*) romon - added dynamic switch rules on devices supporting it when enabling the service;
*) romon - added interface-list support;
*) route - fixed discourse attribute print;
*) route - fixed possible issue with inactive routes after reboot (introduced in v7.16);
*) routing-filter - fixed subtract and add for numerical values (+x, -x);
*) sfp - fixed 1Gbps supported rate for RB960 and RB962 devices;
*) sfp - improved SFP28, QSFP28 interface stability using DAC cable for CRS520 switch;
*) snmp - added wifi fields to MIKROTIK-MIB (additional fixes);
*) ssh - do not regenerate host key after update from RouterOS version older than 7.9;
*) ssh - fixed password authentication (introduced in v7.17beta2);
*) ssh - improved logging;
*) supout - added BGP advertisements section;
*) switch - fixed storm-rate accuracy on 98DX224S, 98DX226S, and 98DX3236 switch chips;
*) switch - improved system stability for RB5009 and CCR2004-16G-2S+ devices;
*) switch - updated dynamic switch rules when using HW bridge with IGMP snooping (224.0.0.0/24 and ff02::/16 destination addresses are forwarded and copied to CPU) (additional fixes);
*) vpls - added support for bridge-pvid configuration;
*) webfig - allow download from file details;
*) webfig - reduce flickering when table is sorted by column with duplicate values (additional fixes);
*) wifi - add information to each interface, showing which CAPsMAN manages it or which CAP hosts it when applicable;
*) wifi - added station-roaming support (additional fixes);
*) wifi - fixed failure with "auto" peer update on the OWE interface;
*) wifi-qcom-ac - fix possible conflict between radio and USB initialization on hAP ac2;
*) wifi-qcom-ac - improved CPU load balancing and system stability;
*) winbox - added Enable/Disable buttons under "Tools/Graphing" menus;
*) winbox - allow to edit Ethernet MAC address;
*) winbox - refresh values under "Bridge/VLANs/MVRP Attributes" menu;
*) winbox - renamed wrong invalid interface flag to inactive;
*) x86 - Realtek r8169 updated driver;

What's new in 7.17beta4 (2024-Oct-18 11:32):

!) device-mode - after upgrade, mode "enterprise" is renamed to "advanced" and bandwidth-test, traffic-gen, partition (command "repartition"), bootloader and downgrade features will be disabled;
!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) arm64 - fixed for bare-metal servers to be able to access more than 2GB RAM;
*) arm64 - show CPU frequency on bare-metal installations;
*) bridge - correctly display PPP interfaces in VLAN menu;
*) bridge - fixed first host table response for SNMP;
*) bridge - fixed VLAN overlap check;
*) bridge - improved port handling;
*) certificate - fixed handling of capsman-cap certificates (introduced in v7.16);
*) console - added more argument definitions for mac-protocol property;
*) console - execute :return command without error;
*) crypto - improve crypto speeds (additional fixes);
*) crypto - use hardware accelerator for GCM cipher in TLS connection on Alpine CPUs;
*) defconf - changed wireless installation from "indoor" to "any";
*) defconf - disable 5GHz secondary channel on RB4011;
*) defconf - fixed new port name recognition;
*) device-mode - changed "partition" to allow activate and do not allow repartition (introduced in v7.17beta2);
*) device-mode - clarify message that pressing a button will reboot device;
*) device-mode - limit "/tool/ping-speed" and "/tool/flood-ping" under "traffic-gen" feature;
*) device-mode - show all features and active restrictions with "print" command;
*) dhcp-relay - added "local-address-as-src-ip" property;
*) dhcp-server - use interface ID for NAS-Port and added interface name to NAS-Port-ID attribute in RADIUS requests;
*) dhcp-server - use single RADIUS accounting session for IPv4 and IPv6 when dual stack is used;
*) dhcpv4-client - fixed crash when releasing disabled DHCP client;
*) dhcpv4-server - properly detect DHCP server address when underlying interface has multiple IP addresses configured;
*) dhcpv4-server/relay - added additional error messages for DHCP servers and relays;
*) discovery - added support for LLDP DCBX (additional fixes);
*) disk - added sshfs client to "/disk" menu (CLI only);
*) disk - improve slot naming and improvements for visualizing complex hardware topology;
*) disk - improve test to report zero byte iops;
*) disk - save raid superblock and raid bitmap superblock on member devices in 1.2 format/location;
*) disk - try all NFS versions (4.2,4.1,4.0,3,2) when mounting NFS in that order;
*) dns - added option to create named DNS servers that can be used as forward-to servers (CLI only) (additional fixes);
*) dns - do not look up local cache when executing ":resolve" command with specified "server" parameter (introduced in v7.16);
*) dns - refactored DNS service internal processes;
*) ethernet - log warning only about excessive broadcast (do not include multicast) and reduced log count;
*) file - do not needlessly scan large filesystems, could prevent unmounting;
*) graphing - fixed graphing rule removal (additional fixes);
*) health - changed PSU state from "no-ac" to "no-input";
*) igmp-proxy - refactored IGMP querier (additional fixes);
*) iot - fixed duplicate LoRa payloads in the traffic tab;
*) iot - limit mqtt publish message size to 32 KB;
*) iot - LoRa traffic tab RSSI now shows proper values for ARM architecture;
*) iot - mqtt improvement to support large payloads and gracefully discard payloads above size limit;
*) iot - removed some LoRa radio related parameters (e.g. RSSI-OFF and Tx-enabled) that were not meant to be changed (additional fixes);
*) ipv6 - added comment property to "/ipv6/nd/prefix" menu;
*) l3hw - improved system stability;
*) l3hw - rate limit error logging;
*) log - added hostname support to remote logging action;
*) log - added regex parameter for log filtering in rules;
*) lte - fixed "default-name" property in export when multiple LTE interfaces are used;
*) lte - fixed "lte monitor" signal reporting for RG520F-EU modem when connected to 5G SA network;
*) lte - fixed "operator" setting for EC200A-EU modem;
*) lte - fixed LTE band setting for SXT LTE 3-7;
*) lte - fixed roaming barring (allow-roaming=no) for EC200A-EU modem;
*) lte - set IPv6 address reporting format in modem init for AT modems and MBIM modems with AT channel;
*) mac-server - allow MAC-Telnet access through any bridged port when bridge interface is allowed;
*) mpls - added fast-path support for VPLS (additional fixes);
*) netwatch - added "ignore-initial-up" and "ignore-initial-down" properties (CLI only);
*) netwatch - fixed probe toggle when adding a comment;
*) ovpn-server - added "user-auth-method" property and allow mschap2 for RADIUS authentication;
*) ppp - added support for bridge-port-pvid configuration via ppp profile (additional fixes);
*) ppp - reuse link-local IPv6 address for static bindings when possible;
*) pppoe - added support for PPPoE server over 802.1Q VLANs (additional fixes);
*) ptp - added PTP support for CRS320-8P-8B-4S+ device;
*) ptp - make PTP process more stable and deterministic when applying configuration;
*) qos-hw - improved PFC behavior (additional fixes);
*) qos-hw - improved WRED and ECN behavior (additional fixes);
*) qos-hw - reworked PCP and DSCP mapping (now supports single, multiple and range values, previous configuration with minimal value mapping is converted to a single value);
*) rip - improved stability when changing metric;
*) route - fixed minor typo in failure message;
*) route - increased interface name length limit in log messages;
*) route - removed possibility for IPv6 routes to specify interface in the dst-address;
*) routerboot - fixed boot MAC for devices with Alpine CPU ("/system routerboard upgrade" required);
*) sfp - improved initialization for certain SFP modules on CRS309 and CRS317 devices ("/system routerboard upgrade" required);
*) smb - stability improvements for client/server (additional fixes);
*) snmp - added wifi fields to MIKROTIK-MIB;
*) ssh - added option to configure SSH ciphers (replaced allow-none-crypto parameter);
*) ssh - improved speed;
*) ssh - prefer GCM ciphers for arm64 and x86 devices when ciphers=auto;
*) storage - preserve permissions,owners,attributes when syncing under "/file/sync";
*) storage,rsync - fixed to work with clients passing "-a" option;
*) supout - added device-mode section;
*) switch - updated dynamic switch rules when using HW bridge with IGMP snooping (224.0.0.0/24 and ff02::/16 destination addresses are forwarded and copied to CPU) (additional fixes);
*) system - moved "/system/upgrade" to "/system/package/local-update";
*) vxlan - fixed issue causing to loose IPv6 VTEP address setting;
*) webfig - improved keyboard navigation (additional fixes);
*) webfig - reduce flickering when table is sorted by column with duplicate values (additional fixes);
*) wifi - added extra info to CAPsMAN about message;
*) wifi - fixed "disabled" property in certain cases;
*) wifi - fixed occasional failure to bring up management frame protection and channel switch capabilities;
*) wifi - improved FT roaming with WPA3 for some Apple devices;
*) wifi-qcom - updated regulatory info for Ukraine, Australia and United States;
*) winbox - renamed and moved "System/Auto Upgrade" to "System/Packages" menu;
*) winbox - show MLAG settings for CRS326-4C+20G+2Q+ device;
*) wireless - enable all chains by default for RB911 and RB922 series devices;

What's new in 7.17beta2 (2024-Sep-27 10:07):

!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;
!) webfig - redesigned HTML, styling and functionality;
*) 6to4 - fixed issue where 6to4 relay would not forward traffic unless destination address is set;
*) adlist - improved system stability;
*) adlist - improved logging;
*) adlist - optimized import on system with low disk space;
*) api - fixed REST API serialization of binary data;
*) arm64/x86 - added missing PCI id for mlx4 driver;
*) bridge - add HW offload support for active-backup bonds on 98DXxxxx, 88E6393X, 88E6191X and88E6190 switches;
*) bridge - added interface-list support for VLANs;
*) bridge - disallow duplicate static VLAN entries;
*) bridge - disallow multicast MAC address as admin-mac;
*) bridge - enable faster HW offloading when detect-internet is disabled;
*) bridge - fixed incorrect HW offloaded port state in certain cases on MSTI add;
*) bridge - fixed missing slave flag on port in certain cases;
*) bridge - fixed port monitor with interface-lists;
*) bridge - fixed port move command;
*) bridge - fixed setting bridge MTU to L2MTU value;
*) bridge - fixed unstable MLAG when host moved between bonds too quickly;
*) bridge - ignore disabled interfaces when calculating bridge L2MTU;
*) bridge - improved stability;
*) bridge - removed support for master port config conversion (used before version 6.41);
*) bth - improved stability on system time change;
*) chr/arm64 - fixed kernel crypto use without crypto extensions for RPi CM4;
*) cloud - changed ddns-enabled setting from "no" to "auto" (service is enabled when BTH is enabled);
*) cloud - improved DDNS and VPN state stability;
*) console - added :range command;
*) console - added group-by property for print command;
*) console - added lf/crlf options to :convert transform;
*) console - added password property to "/system/ssh-exec" command;
*) console - added to/from=num option for :convert command;
*) console - allow clearing history for a specific user;
*) console - allow setting width to supout.rif output;
*) console - clear history when removing user;
*) console - disallow autocomplete hints for user without read policy;
*) console - fixed endless loop when closing input prompt;
*) console - force print paging when output does not fit terminal width;
*) console - improved printing output in some menus;
*) console - improved scripting system stability;
*) console - print warning in CLI after enabling protected bootloader;
*) console - removed "chain" names from print parameter list and show all print parameters in "/ipv6/firewall/filter" directory;
*) container - allow import from .tar.gz file;
*) crypto - improve crypto speeds;
*) device-mode - added "basic" mode and renamed "enterprise" to "advanced";
*) device-mode - added bootloader, downgrade and partitions features;
*) device-mode - allow feature and mode update on x86 via power button and reboot/shutdown from AWS;
*) device-mode - fixed feature and mode update on ARM64 Hetzner;
*) device-mode - fixed feature and mode update via power-reset on MIPSBE devices;
*) dhcpv4-client - correctly handle adding/setting emtpy dhcp-options;
*) dhcpv4-client - respect Renewal-Time (58) and Rebinding-Time (59) options;
*) dhcpv4-server - do not remove options set config when DHCP network is changed;
*) dhcpv4/v6-server - added address-list parameter to which address will be added if the lease is bound;
*) dhcpv6-client - added prefix-address-list parameter;
*) dhcpv6-client/server - added support for DHCPv6 reconfigure messages;
*) dhcpv6-server - include all existing prefixes (with lifetime 0) in renew reply and new prefix if RADIUS returns different prefix;
*) discovery - added support for LLDP DCBX;
*) discovery - use LLDP description field to populate platform, version and board-name;
*) disk - allow to configure global and per disk mountpoint template - [slot],[model],[serial],[fw-version],[fs-label],[fs-uuid],[fs] variables supported;
*) disk - improved system stability;
*) disk - read/show exfat filesystem label;
*) disk - remove 32 character slot name limit;
*) disk - show detailed mountpoint users when unable to unmount;
*) disk,nvme - show nvme namespaces if configured more than one on a nvme drive;
*) dns - added option to create named DNS servers that can be used as forward-to servers (CLI only);
*) dns - DoH whitelist support for adlist using static FWD entries;
*) dns - whitelist support for adlist using static FWD entries;
*) ethernet - improved interface stability for RB4011 devices;
*) fetch - fixed certificate check when provided hostname is IP address;
*) fetch - fixed large file (over 4GB) fetch in HTTP/HTTPS mode;
*) file - correctly identify mounted disks;
*) file - improved handling of changes to the file system;
*) file - support files over 4GB size;
*) file - update file size before trying to request content;
*) firewall - added none-dynamic and none-static arguments for IPv6 address-list-timout settings;
*) firewall - added warning log for TCP SYN flood;
*) firewall - fixed "dst-limit" and "limit" mathers when using zero value for burst argument;
*) firewall - removed default mangle passthrough=yes configuration from export;
*) graphing - fixed graphing rule removal;
*) graphing - fixed queue graph storing on disk;
*) health - added cpu-overtemp-check on ARM, ARM64 devices (CLI only);
*) health - hide settings in CLI if there is nothing to show;
*) health - removed board-temperature on RB5009UPr+S+IN device;
*) igmp-proxy - refactored IGMP querier;
*) ike2 - improved performance by balancing multicore CPU usage for key exchange calculation also for initiator;
*) iot - added an option to print out LoRa traffic in CLI (not GUI-only option anymore);
*) iot - added new LoRa traffic FCnt packet counter parameter;
*) iot - bluetooth peripheral device menu now displays correct iBeacon major/minor values;
*) iot - fixed incorrect LoRa joineui filter export behavior;
*) iot - improvements to LoRa device's stats tab;
*) iot - removed crc-disabled and crc-error options from the LoRa forwarding;
*) iot - removed LoRa pause traffic option/setting;
*) iot - removed some LoRa radio related parameters (e.g. RSSI-OFF and Tx-enabled) that were not meant to be changed;
*) ipv6 - added IPv6 settings related to stale IPv6 neighbor cleanup;
*) isis - do not disable fast-path when isis is enabled on an interface;
*) isis - fixed console flags;
*) isis - fixed invalid L2 LSP type;
*) isis - make it work when MTU is larger than 1500;
*) isis - update interface MAC address on change (caused neighbor to stuck in init state);
*) kid-control - use time format according to ISO standard;
*) leds - fixed issue where interface LEDs might not properly disable in some cases;
*) log - added basic validation for "disk-file-name" property;
*) log - use time format according to ISO standard;
*) lte - added option to check/install modem firmware from early-access/testing channel (CLI only);
*) lte - added provider specific firmware update (FOTA) for Cosmote GR networks on Chateau 5G;
*) lte - fixed long "PLMN search in progress" for SXT 3-7;
*) lte - fixed signal info reporting for FG621-EA modem in UMTS network;
*) lte - improved modem FW upgrade for Chateau 5G;
*) lte - improvements to modem "firmware-upgrade" command;
*) lte - modem firmware update (FOTA), added support to install provider specific version;
*) lte - removed trailing "F" symbol from uicc;
*) mac-telnet - use ASCII DEL as erase/backspace char instead of BS (fixes mac-telnet backspace for WinBox4);
*) macvlan - improved error when trying to create new interface on already busy parent interface;
*) macvlan - updated driver;
*) mpls - added fast-path support for VPLS;
*) mpls - added MPLS mangle support;
*) mpls - added support for "ICMP Fragmentation needed";
*) mpls - do no drop LDP peering session on PW deactivation;
*) mpls - do not reconnect VPLS on name or comment changes;
*) netinstall - save and restore device-mode configuration on format;
*) netinstall-cli - added "-o" option to install devices only once per netinstall run;
*) netinstall-cli - fixed x86 detection;
*) ospf - fixed memory corruption;
*) ovpn - added VRF support to OVPN server (server menu now supports multiple entries and previous server configuration is automatically imported);
*) ovpn - improved system stability;
*) poe-out - upgraded firmware for PSE (BT) controlled boards (the update will cause brief power interruption to PoE-out interfaces);
*) ppp - added support for bridge-port-pvid configuration via ppp profile;
*) ppp - set APN/PDN type "IPv4/v6" according assigned PPP profile protocol setting;
*) pppoe - added support for PPPoE server over 802.1Q VLANs;
*) profiler - classify ppp processing;
*) profiler - improved process classification;
*) profiler - renamed radv process to radvd;
*) ptp - added dynamic switch ACL rules in order to trap PTP packets to CPU instead of forwarding;
*) ptp - added option to configure L2 transport with forwardable and non-forwardable MAC destination;
*) ptp - display warning when none of the PTP ports has a link;
*) ptp - restrict configuring g8275 profile with IPv4 transport;
*) qos-hw - allow to disable/enable profiles, disabled or removed profile gets replaced with the default;
*) qos-hw - enabling PFC on port also requires setting egress-rate-queueN;
*) qos-hw - fixed export when changing default Tx Manager;
*) qos-hw - fixed incorrect port byte-use counter;
*) qos-hw - improved PFC behavior;
*) qos-hw - improved WRED and ECN behavior;
*) qos-hw - rename pfcN-pause and pfcN-resume to pfcN-pause-threshold and pfcN-resume-threshold;
*) qos-hw - switch-cpu port trust settings are forced to "keep";
*) queue - improved system stability when too many simple queues are added;
*) quickset - added "LTE AP" quickset profile with one wifi interface;
*) romon - send uptime in discovery (CLI only);
*) rose-storage - allow to set iscsi-iqn only when type=iscsi and allow nvme-tcp-name only when type=nvme-tcp;
*) rose-storage - do not allow to format exported disks;
*) rose-storage - enable autocomplete for local-path property in "/file/sync" menu;
*) rose-storage - enable more threads for faster RAID sync;
*) rose-storage - ensure unique nvme-tcp-names for nvme-tcp clients;
*) rose-storage - improved error messages;
*) rose-storage - improved system stability;
*) rose-storage,raid - improved stability of degraded arrays on startup;
*) rose-storage,raid - store superblock in 1.2 format, show raid super block info when detected to help with reassembling arrays;
*) route - improved stability;
*) routerboot - fixed boot MAC for MIPSBE CRS3xx and CRS5xx switches ("/system routerboard upgrade" required);
*) rsync - fixed when used over ssh and spaces in directory names;
*) sfp - fixed linking with 1Gbps optical modules with "combo-mode=sfp" configuration for CRS312 device;
*) sfp - improved initialization for certain SFP modules on CRS309 and CRS317 devices;
*) sfp - improved initialization and linking for some SFP modules;
*) sfp - improved power control configuration for QSFP optical modules according to the EEPROM field;
*) sfp - improved SFP auto-negotiation for L22, L23 devices;
*) smb - stability improvements for client/server;
*) socks - fixed comment property for access configuration;
*) ssl/tls - improved performance;
*) sstp - added pfs=required option to allow only ECDHE during TLS handshake;
*) supout - print non BGP and OSFP routes if route list is too large;
*) supout - reduce minimal RAM required for export to be included;
*) supout - use separate LTE section;
*) switch - added "all" argument for "new-dst-ports" switch rule property for CRS3xx, CRS5xx, CCR2116 and CCR2216 devices;
*) switch - added IPv6 flow label matching in switch rules for CRS3xx, CRS5xx, CCR2116 and CCR2216 devices;
*) switch - allow bond interfaces in switch rules for CRS3xx, CRS5xx, CCR2116 and CCR2216 devices;
*) switch - allow matching network bitmask for IPv4 and IPv6 dst/src-address properties in switch rule;
*) switch - disallow switch-cpu in "ports" and "new-dst-ports" rule properties for CRS3xx, CRS5xx, CCR2116, CCR2216 and RB5009 devices;
*) switch - fixed L2MTU for 25Gbps ports;
*) switch - fixed RSPAN error message when using mirror-target=cpu;
*) switch - fixed rule disable in certain cases for 98DX224S, 98DX226S, and 98DX3236 switch chips;
*) switch - fixed wrong MAC learning when port learning is disabled for 88E6393X, 88E6191X and 88E6190 switch chips;
*) switch - force "mac-protocol" when matching IPv4 or IPv6 specific properties;
*) switch - improved CPU performance for CRS328-24P-4S+ switch;
*) switch - make switch rule "ports" property not required and unsettable (allows matching packets on all switch ports);
*) switch - updated dynamic switch rules when using HW bridge with IGMP snooping (224.0.0.0/24 and ff02::/16 destination addresses are forwarded and copied to CPU);
*) system - make ICMP error source address selection configurable (icmp-errors-use-inbound-interface-address parameter in ip settings);
*) system - make TCP timestamp handling configurable (tcp-timestamps parameter in ip settings);
*) upnp - rename service description file from gateway_description.xml back to gateway.xml;
*) user-manager - improved stability;
*) vrf - fixed packet handling with enabled queues;
*) webfig - added search option for settings;
*) webfig - fixed uploading files with Windows style newlines;
*) webfig - hide inherited wifi password;
*) webfig - improved keyboard navigation;
*) webfig - reduce flickering when table is sorted by column with duplicate values;
*) webfig - Skin Designer moved to centralized page;
*) webfig - status page is deprecated, old status page config will work, but can't be updated or created;
*) webfig - support unicode strings;
*) wifi - added a debug log entry when switching channel;
*) wifi - added ability to set security.owe-transition-interface to "auto";
*) wifi - added access-list stats (CLI only);
*) wifi - added configuration.installation property to limit use of indoor-only channels;
*) wifi - added debug log messages on station authentication mismatch;
*) wifi - added last-activity property in registration table;
*) wifi - added multi-passphrase (PPSK) support (CLI only);
*) wifi - added option to reset MAC address (CLI only);
*) wifi - added station-roaming support;
*) wifi - allow IPv6 LL address in caps-man-addresses;
*) wifi - disabled 802.11h on 2.4GHz station;
*) wifi - fixed failure to resume operation after DFS non-occupancy period has elapsed;
*) wifi - fixed the "no available channels" message still being displayed after a setting change has made some channels available;
*) wifi - indicate radios' ability to perform a channel switch in their "hw-caps" attribute;
*) wifi - indicate which channels are subject to DFS, or are indoor-only in output of "monitor" command;
*) wifi - re-word the "SA Query timeout" log message to "not responding";
*) wifi - show authentication type and wireless standard used by each client in registration table;
*) wifi - show regulatory limits on maximum bandwidth in output of radio/reg-info command;
*) wifi - when operating in station mode, log more information when AP switches to an unsupported channel;
*) wifi-qcom - added Superchannel country profile;
*) wifi-qcom-ac - allow use of channel 144 under "Japan" regulatory domain;
*) winbox - added "Scan" and "Test Disks" features under "System/Disks" menu;
*) winbox - added MAC address support for "Group" property under "Bridge/MDB" menu;
*) winbox - added missing properties under "IP/Neighbors" menu;
*) winbox - fixed duplicate timezone names;
*) winbox - fixed typo in "System/Reset Configuration" menu;
*) winbox - minimal required version is v3.41;
*) wireguard - do not initiate handshake when peer is configured as responder;
*) wireless - added option to reset MAC address (CLI only);
*) wireless - added vlan-id to registration-table;
*) wireless - allow to set Canada2 country profile when locked with US lock package for CubeG device;
*) wireless - fixed antenna gain for SXT5ac device;
*) wireless - preserve configured country while using setup-repeater, added "country" argument (CLI only);
*) zerotier - added debug logging;
*) zerotier - do not show default settings in export;
*) zerotier - upgraded to version 1.14.0;

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. The 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.

Damn, you guys are killing it. Solid work, thank you!

And just before the weekend ...

Thanks for ZT update, have a good weekend all.

*) zerotier - upgraded to version 1.14.0;

Hi,

Does it have the same changes as the v7.17ab57 version provided by the MikroTik team for a possible IPsec policy solution?

Regards,

ab57 is newer than beta2

ab57 is newer than beta2

Thanks Normis, have a nice weekend and thanks for your hard work.

Regards,

*) dns - whitelist support for adlist using static FWD entries;
Thanks, trying now!

One tiny nitpicky thing, "Licence" on the login page is different than the "License" under /system. Can we standardize on a spelling? Either one is technically correct, one is old english and the other is new english.

*) igmp-proxy - refactored IGMP querier;

Really hoping that this fix the IPTV issues we are having with Movistar Spain (SUP-152693)

This is a game-changer

*) wifi - added multi-passphrase (PPSK) support (CLI only);

!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;

Oh! 😳

I have some remote Chateau (and other) devices with partitions. After update to 7.17beta2 and later I can not switch the active partition if the backup partition booted for what ever reason?

*) wifi-qcom - added Superchannel country profile;

Nice!

Thank Gooood for PPSK... Truly a great day... Will test it as soon as possible. Great job Mikrotik !!

After update CAPsMAN with wireless package stopped working, in the log there are tons of:

!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;

Oh!

I have some remote Chateau (and other) devices with partitions. After update to 7.17beta2 and later I can not switch the active partition if the backup partition booted for what ever reason?

you will have to enable this feature with the button or a cold reboot (power unplug), then you can switch partitions again

*) mpls - added fast-path support for VPLS;

This is huge, anyone has any performance improvement numbers?

*) igmp-proxy - refactored IGMP querier;

Really hoping that this fix the IPTV issues we are having with Movistar Spain (SUP-152693)

My illusion vanished. Tested and still having the TV cuts.

you will have to enable this feature with the button or a cold reboot (power unplug), then you can switch partitions again

Sure, I got that... But devices are remote and I do not have physical access...

Definitely something to be handled with care.

!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;

Oh!

I have some remote Chateau (and other) devices with partitions. After update to 7.17beta2 and later I can not switch the active partition if the backup partition booted for what ever reason?

!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;
The device-mode can be changed by the user, but remote access to the device is not enough to change it. After changing the device-mode, you need to confirm it, by pressing a button on the device itself, or perform a "cold reboot" - that is, unplug the power.
https://help.mikrotik.com/docs/display/ROS/Device-mode

Awesome! Only submitted this as a feature request (SUP-158802) mid of July. Now it already happened. This is real great job! Thank you, Mikrotik team!

Really hoping that this fix the IPTV issues we are having with Movistar Spain (SUP-152693)

My illusion vanished. Tested and still having the TV cuts.

Refactoring does not change functionality or fix bugs. It is just a process of "restructuring"/cleanup source code.

Do I understand correctly, that after upgrading to 7.17beta2, ROS downgrade will be available ONLY by changing the upgrade channel?

No. You will have to enable downgrade in device-mode, after that it works as before.

Awsome Change log Mikrotik Team.

Wish if we can get MPLS/VPLS and PPPOE Multi core processing feature will be a real game changer

I've just upgraded my RB5009, hAP ax3 and hAP ac3 from v7.16rc5 to v7.17beta2 and so far so good.

I just noticed that:

1. An OpenVPN server was created during the upgrade. Fixed that with /interface/ovpn-server/servers/remove [find]; and
2. /zerotier now shows disabled=no disabled=no.

Other than that, a very clean upgrade despite the lengthy changelog. Good work MikroTik!

So PPSK is available only on ax devices ?

Only supported on wifi-qcom interfaces, if wifi-qcom-ac AP has a client that uses a passphrase that has vlan-id associated with it, the client will not be able to join.

No. You will have to enable downgrade in device-mode, after that it works as before.

How then should we understand this?
From https://help.mikrotik.com/docs/display/ROS/Device-mode

Note, downgrade mode does not allow to run /system package downgrade command, but you can switch between RouterOS release channels (stable, testing, etc.) and change RouterOS versions.

After upgrade to 7.17beta2, my RB1100AHx4 test router upgraded no problem. However...a ROSE RAID "disk" did not mount. I rebooted and still did not mount. I removed the RAID "disk", and re-added it again, still did not work. I disabled/renabled the new raid disk, and then it come up without any data loss. But it should have come up mounted already...

!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;
The device-mode can be changed by the user, but remote access to the device is not enough to change it.

Since y'all making changing in device-mode... One request is there be some netinstall option (or another tool) to set the device-mode upon provisioning, since it not the convenient to set if you deal with many routers. Since physical access is required for netinstall, I don't think that changes the security modem. For CPEs, it be nice to restrict more in device-mode...but that not so easily automated. For my case, being able to set device-mode, without a power-cycle, from a netinstall/branding defconf (/system/default-configuration) be ideal.

BGP still missing ibgp-rr-client local.role since 7.16

*) mpls - added fast-path support for VPLS;

Is there any updated documentation on fast-path? The information I could find is very outdated (https://help.mikrotik.com/docs/pages/vi ... S-FastPath).

BGP still missing ibgp-rr-client local.role since 7.16

It will be missing because ibgp-rr-client had no special meaning, it is the same as ibgp.

How then should we understand this?
From https://help.mikrotik.com/docs/display/ROS/Device-mode

Note, downgrade mode does not allow to run /system package downgrade command, but you can switch between RouterOS release channels (stable, testing, etc.) and change RouterOS versions.

You can still downgrade from 7.17beta2 to 7.16 by switching the channel from testing to stable. That works for the versions channels only.

But you can not upload old npk files and run the downgrade command by default. For that you need to enable the downgrade feature in device-mode.

may you clarify this?
*) pppoe - added support for PPPoE server over 802.1Q VLANs;

regards

BGP still missing ibgp-rr-client local.role since 7.16

It will be missing because ibgp-rr-client had no special meaning, it is the same as ibgp.

I'm losing l2vpn routes ever since 7.16
So it's either l2vpn is broken , or ibgp-rr-client does have effect

Because up to 7.15.3 ( which does have ibg-rr-client functionality ) , BGP l2vpn works

"So PPSK is available only on ax devices" - no the limitation is only if you use vlan-id. You can still use multi-passphrase feature on wifi-qcom-ac interfaces, it's just that you can't use entries that would assign vlan-id. "vlan-id" will only work with wifi-qcom interfaces.

on 7.16 and above
before 7.16

On hAP ax3

"So PPSK is available only on ax devices" - no the limitation is only if you use vlan-id. You can still use multi-passphrase feature on wifi-qcom-ac interfaces, it's just that you can't use entries that would assign vlan-id. "vlan-id" will only work with wifi-qcom interfaces.

What a pity. Assigning VLAN ID is a major use case. I hope that wifi-qcom-ac overcomes this restriction here and also in datapath one day.

you will have to enable this feature with the button or a cold reboot (power unplug), then you can switch partitions again

We have ~2000 devices high up on towers, some of them hundreds of kilometers away. Are you saying that once we upgrade to v7.17, we won't be able to downgrade them to an older version? That's a big yikes.

on 7.16 and above

Code: Select all

> routing/route/print where afi=l2vpn
Flags: H - HW-OFFLOADED
Columns: DST-ADDRESS, AFI
  DST-ADDRESS  AFI  

before 7.16

Code: Select all

> routing/route/print where afi=l2vpn
Flags: U - UNREACHABLE, A - ACTIVE; b - BGP; H - HW-OFFLOADED; + - ECMP
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE, IMMEDIATE-GW
     DST-ADDRESS  GATEWAY   AFI    DISTANCE  SCOPE  TARGET-SCOPE  IMMEDIATE-GW        

The width of the current terminal does affect how many columns it outputs.... sure it ain't that?

Would it be possible to have the upgrade process look at something in the pre-upgraded configuration to determine what the device-mode would be afterwards? Like maybe something in /system/note or some other text field that already exists in older versions, something like that? Or maybe a script that can set the option without having to put hands on the device to change it afterwards?

I am having issues with the beta on my RB5009, I have some stability issues with the SFP+ to RJ45 modules, even at 1G.
Also I am no unable to set the CPU frequency, something that was possible on 7.16.

"So PPSK is available only on ax devices" - no the limitation is only if you use vlan-id. You can still use multi-passphrase feature on wifi-qcom-ac interfaces, it's just that you can't use entries that would assign vlan-id. "vlan-id" will only work with wifi-qcom interfaces.

Understood, but as @infabo stated assigning VLANs is a major use case here. But in my case it doesn't matter much. All of my devices at home are ax.

Thanks for ZT update, have a good weekend all.

*) zerotier - upgraded to version 1.14.0;

+1

*) mpls - added fast-path support for VPLS;

This is huge, anyone has any performance improvement numbers?

I'm interested too! :P

On the stats from 7.16 to 7.17beta2, there are +74 new commands and +803 new attributes (although the "group-by" gins up the numbers since that in a lot of places ;))

*) zerotier - upgraded to version 1.14.0;

+1

+½

There are also newer options in ZeroTier too that are not exposed... yet? i.e. be nice to control multipath and enable low-bandwidth mode

I must say, R0S 7.x is shaping quite nicely. Up until... 7.12? it was quite a bumpy ride, but things are shaping up really well lately.. I think the worst teething problems are over, and now Mikrotik found its pace. These later versions have a much more... solid feeling. Of course, we still need feature parity with 6.x, but recently I've got the feeling things are more "business as usual" than before.

And the 7.17 changelog is really good. :D

I agree.

!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;

Please re-evaluate this

For SOHO devices managed by an end-user, this makes some sense

But for managed (and already deployed!) networks with hundreds of devices, mounted in inaccessible datacenter cages, ceilings and towers

The inability to switch partitions back, and/or downgrade to a previous working version is an absolute incentive to never-ever upgrade
This must be at least delayed until 7.x has a long-term channel

you will have to enable this feature with the button or a cold reboot (power unplug), then you can switch partitions again

Sure, I got that... But devices are remote and I do not have physical access...

Definitely something to be handled with care.

I agree that this is BAD. I always put a second partition on routers, and do all upgrades remotely.
Now I would have to physically visit all the routers at the time I upgrade to 7.17 to get partition functionality back again???

Even worse: I assume the auto-switching of partitions on boot failure remains, and when due to a spiky power failure the router reboots to another partition I will no longer be able to switch it back to the partition it is supposed to run on, remotely???

I think such a change at least should have a workaround. E.g. on upgrade to 7.17 we can pass some parameter or put some file on the router so that it will automatically set the device mode compatible with what it was before.
Maybe even always do that when there are multiple partitions on the device, and perform that newfangled functionality only when a new partition is created with 7.17 already present, or when the user indicates he wants to.

While I understand that partitions could be abused by an attacker, effectively crippling them as part of an upgrade is a bad idea.

The width of the current terminal does affect how many columns it outputs.... sure it ain't that?

Very sure

*) mpls - added MPLS mangle support;

Yes, Mikrotik, thank you! This was needed for so long.

Looks like documentation/examples are already available:

https://help.mikrotik.com/docs/display/ ... LS+Queuing

This is a huge feature for us, fantastic news.

The width of the current terminal does affect how many columns it outputs.... sure it ain't that?

Very sure

Hmm, I couldn't repo in 7.17beta, RB1100AHx, WinBox4 terminal:
Still I'd try winbox, or ssh if already using winbox... Maybe something broke here, dunno... just your TERMCAPS be my first bet.

*) dns - DoH whitelist support for adlist using static FWD entries;
*) dns - whitelist support for adlist using static FWD entries;

May you please make some samples, how to?

*) sfp - improved initialization for certain SFP modules on CRS309 and CRS317 devices;
*) sfp - improved initialization and linking for some SFP modules;

Is this the fix for the Zaram xgspon modules? Can you please give a bit more details?

Upgrade from 7.16 to 7.17beta2 changed /ip/neighbor/discovery-settings/mode from rx-only to tx-and-rx.

*) leds - fixed issue where interface LEDs might not properly disable in some cases;

Would be nice if you added the ability to disable LEDs on CRS310-8G+2S+, if that is possible.

Awsome Change log Mikrotik Team.

Wish if we can get MPLS/VPLS and PPPOE Multi core processing feature will be a real game changer

What's new in 7.17beta2 (2024-Sep-27 10:07):
*) mpls - added fast-path support for VPLS;

Should help with the first one, have you tested it ?

how is the ax devices going with the wifi and roaming guys?

*) pppoe - added support for PPPoE server over 802.1Q VLANs;

Can we please get some documentation on this feature. Its potentially a game changer...

Up dated all my AX hap and cap devices with firmwares all seems to be working so far but early days
Should i wipe out my wifi config back to default with only ssid and passphrase intalled and test it??
as i have changed a few things from previous ros to get the ax to play nice or should i leave it and say it is ok??

i Just had the openvpn as well what is it? and why did it get intalled and enabled??
i had
possible SYN flooding on tcp port 2828
this is why i went looking for what and why and how

havent looked at zeroter yet as i dontr have it installed nor do i use it

I've just upgraded my RB5009, hAP ax3 and hAP ac3 from v7.16rc5 to v7.17beta2 and so far so good.

I just noticed that:

1. An OpenVPN server was created during the upgrade. Fixed that with /interface/ovpn-server/servers/remove [find]; and
2. /zerotier now shows disabled=no disabled=no.

Other than that, a very clean upgrade despite the lengthy changelog. Good work MikroTik!

Very sure

Hmm, I couldn't repo in 7.17beta, RB1100AHx, WinBox4 terminal:

Code: Select all

routing/route/print where afi~"ip6" 
Flags: U - UNREACHABLE, A - ACTIVE; c - CONNECT, d - DHCP; H - HW-OFFLOADED; B - BLACKHOLE
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE, IMMEDIATE-GW
     DST-ADDRESS                  GATEWAY           AFI  DISTANCE  SCOPE  TARGET-SCOPE  IMMEDIATE-GW    
Ac   ::1/128                      lo                ip6         0     10             5  lo              

Still I'd try winbox, or ssh if already using winbox... Maybe something broke here, dunno... just your TERMCAPS be my first bet.

My case is for BGP signaled VPLS, using Cisco route reflector
l2vpn and l2vpn-cisco afi

I don’t run any other afi, even ip

It stops working since 7.16 beta
Tried on PPC RB1100AHx2 and ARM CRS326 and CRS328

*) health - removed board-temperature on RB5009UPr+S+IN device;

why?

*) mpls - added fast-path support for VPLS;

is there any flag that we can that this is running?

*) adlist - optimized import on system with low disk space;

Worked well on my hap ac2's. 260+ entry list.

However, they would no longer operate as caps, so i reverted back for the time being.

*) ovpn - added VRF support to OVPN server (server menu now supports multiple entries);
This si bing one. Well done

*) health - removed board-temperature on RB5009UPr+S+IN device;

why?

Well, I noticed that the value is ridiculous. On most devices it is higher than CPU temperature, one one device even 10 degrees higher.
Probably someone has researched that and concluded that the circuitry is wrong and the value cannot be used.

Hello Mikrotik team,

I have 2 questions:

!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;

1. what does bootloader restriction do?
2. can you allow partitions feature in advanced mode if it is used in production already?

Something like:
system/device-mode/update mode=advanced partitions=yes

Why?
I have devices with not easy physical access to it and I use partitions for upgrades. After upgrade when the device does not have connectivity, the script changes the active partition back to original pre-upgrade one and reboots to previous working state.

This change would break it and need of visit all devices physically.

*) adlist - optimized import on system with low disk space;

Worked well on my hap ac2's. 260+ entry list.

However, they would no longer operate as caps, so i reverted back for the time being.

Same also for me, I will wait for the new beta with CAPsMAN working 😅

Hi,

v7.17Beta2 and v7.17ab57. They cause me a "high" CPU consumption, IPSEC process. Reverting to v7.16 "stabilizes" the CPU, but policies may become stuck again, we'll see over the weekend.




Regards,

Good to see new beta releases :)
But sad to see no information about fixing the broken log format. :(
Have waited 7 year, so can wait some more ;)
viewtopic.php?t=124291

Jotne, could you please stop reminding everyone on this forum about the logging prefix/format. It is annoyingly repetitive and not (see opening post) "strictly related to this particular RouterOS release."

I will do when rfc 5424 is implemented. MT told this may wait to a mayor new release.
As far as I see there are several mayor new function even i this release, all marked !)
Like these two:
!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;
!) webfig - redesigned HTML, styling and functionality;

You do not need to read my posts.

*) dhcpv4-client - respect Renewal-Time (58) and Rebinding-Time (59) options;
*) dhcpv6-client/server - added support for DHCPv6 reconfigure messages;
*) dhcpv6-server - include all existing prefixes (with lifetime 0) in renew reply and new prefix if RADIUS returns different prefix;

Hurray! Hurray!
Years and years and maybe now will respect the RFC!

I will test it as soon as possible!

But if it really works, operators of IPoE with MikroTik CPEs will thank you a lot!

Hi,

v7.17Beta2 and v7.17ab57. They cause me a "high" CPU consumption, IPSEC process. Reverting to v7.16 "stabilizes" the CPU, but policies may become stuck again, we'll see over the weekend.

🤔

*) pppoe - added support for PPPoE server over 802.1Q VLANs;

Can we please get some documentation on this feature. Its potentially a game changer...

it is huge!
we tested in the lab.
No need to have the vlan interfaces created on the ethernet interface, just one pppoe-server specifying all the vlan id where it could work and applied on the ethernet interface.
And all the pppoe-client on the vlans get authenticated!

*) zerotier - upgraded to version 1.14.0;

Thanks for ZT update, have a good weekend all.

+1

There are also newer options in ZeroTier too that are not exposed... yet? i.e. be nice to control multipath and enable low-bandwidth mode

Has anyone checked if private moons support is really working?

There are many expectations among the most active users regarding MPLS performance optimization.

My personal expectation is that MPLS ingress/egress (PE) will have the same type of performance as label swapping, being done in hardware offload.
viewtopic.php?p=1097834#p1097834


Nithinkumar2000 frequently requests that this type of traffic be forwarded using MultiThreading.

Wish if we can get MPLS/VPLS and PPPOE Multi core processing feature will be a real game changer

Both requests are well-founded!

On this latest beta release what we had was:

*) mpls - added fast-path support for VPLS;

I may be wrong, but what has come so far (fast-path) despite meaning a very good performance gain, is neither hardware offload nor multithreading support, right?

I imagine it is a step closer to taking this to hardware offloading, but it is not there yet.

Could the MikroTik guys explain this better?

*) pppoe - added support for PPPoE server over 802.1Q VLANs;

Can we please get some documentation on this feature. Its potentially a game changer...

it is huge!
we tested in the lab.
No need to have the vlan interfaces created on the ethernet interface, just one pppoe-server specifying all the vlan id where it could work and applied on the ethernet interface.
And all the pppoe-client on the vlans get authenticated!

Sounds like the "stacked-vlan-ranges dynamic-profile" for vlan demux of Junos, or the "user-vlan any-other" of Huawei.
But the lack of documentation scares me a bit.

What if I want that one specific vlan on a range operates on a different profile?
What if I want that one specific vlan dot not listen PPPoE?

No need to have the vlan interfaces created on the ethernet interface, just one pppoe-server specifying all the vlan id where it could work and applied on the ethernet interface.

What if I want that one specific vlan on a range operates on a different profile?
What if I want that one specific vlan dot not listen PPPoE?

I don't need this but I can see in ISP world how this be handy: benefits of VLANs for switching and PPPoE for accounting/etc.

My crystal ball tells me there is a new "pppoe-over-vlan-range=1001-1999" on /interface/pppoe-server/server. So appears you specify a single range of VLANs to use. And, while not documented, I'd hope if it's not in that range (or untagged)... it should be ignore by the PPPoE server.

So to @fischerdouglas point, and since in beta, the "pppoe-over-vlan-range=" should actually accept a comma and/or multiple ranges. It apparently right now is exactly one range. I would have expected something like pppoe-over-vlan-range=100,200-299,1010-1020 to work - but it really only a single range with "-" that's accepted. So if you want just one VLAN, it's still a range. And if the VLANs you'd like to use that are not continuous, well, they'd have to be to use "PPPoEoVLAN" feature.

why?

Well, I noticed that the value is ridiculous. On most devices it is higher than CPU temperature, one one device even 10 degrees higher.
Probably someone has researched that and concluded that the circuitry is wrong and the value cannot be used.

It is still advertised as having PCB temperature monitor:

PCB temperature monitor Yes

https://mikrotik.com/product/rb5009upr_s_in

I get your explanation, might be so, or not, could be that the sensor is in a hot spot. Or an offset could be added to correct errors.

My crystal ball tells me there is...

Hey @Amm0, It probably will sound weird... haha
But your crystal ball is fantastic!

Your code? Gooood!
I will take a look on it this weekend.

In my opinion, It surely is a thing to be on Useful user articles .

Unfortunately I do not doubt of the possibility of some effort of them to avoid that kind of transparency.

*) wifi-qcom - added Superchannel country profile;

Impossible for wifi-qcom-ac?

What a pity. Assigning VLAN ID is a major use case. I hope that wifi-qcom-ac overcomes this restriction here and also in datapath one day.

That already works with RADIUS.

Hi,

v7.17Beta2 and v7.17ab57. They cause me a "high" CPU consumption, IPSEC process. Reverting to v7.16 "stabilizes" the CPU, but policies may become stuck again, we'll see over the weekend.

Code: Select all

*) crypto - improve crypto speeds;

🤔

Hi,

Of course, now a l009uigs-rm has the H flag in the SAs.
Regards,

hi Gurus what is this?? i have never had this before until i upgraded to this beta 7.17
Possible SYN FLOODING on ports?
shouold i be worried or is it normal
Did my internet just try and refresh a ip from my ISP? dont no what it is

Would be great if MikroTik had rDNS for DHCP clients, I miss being able to identify the clients making requests to my Adguard Home server.

Wow! This is an another great release, congratulations to the whole team!

---

*) bth - improved stability on system time change;

Is there any info on cases when this can cause crashes? We observed some hangs and it appears to be related to time changes, but since they're very infrequent it's hard to debug.
Overall, it would be amazing if changelogs could contain or link to some information about what "improved stability of X" actually means. Naturally I'm not asking for a full writeup, as this would be horrendously time consuming, but a single sentence of approximately what scenarios this can apply to.

*) dhcpv6-client - added prefix-address-list parameter
*) firewall - added none-dynamic and none-static arguments for IPv6 address-list-timout settings

Is this maybe a preparation to support prefix mask, similarly to how ip6tables allows it, or am I reading too far? ;)

*) ptp - added dynamic switch ACL rules in order to trap PTP packets to CPU instead of forwarding

Is there any device support matrix, or any device with hardware ACLs can utilize that? Is it possible to copy-and-forward instead of just forwarding to CPU?

---

Possible SYN FLOODING on ports?
shouold i be worried or is it normal

@Coughy: Welcome to the open Internet - if you're not hosting anything on these ports just DROP on WAN. If you are, just ignore it and accept automatic scanners are normal nowadays.

cheers m8 yer i added these ports just never seen them before
cheers

Wow! This is an another great release, congratulations to the whole team!

---

*) bth - improved stability on system time change;

Is there any info on cases when this can cause crashes? We observed some hangs and it appears to be related to time changes, but since they're very infrequent it's hard to debug.
Overall, it would be amazing if changelogs could contain or link to some information about what "improved stability of X" actually means. Naturally I'm not asking for a full writeup, as this would be horrendously time consuming, but a single sentence of approximately what scenarios this can apply to.

*) dhcpv6-client - added prefix-address-list parameter
*) firewall - added none-dynamic and none-static arguments for IPv6 address-list-timout settings

Is this maybe a preparation to support prefix mask, similarly to how ip6tables allows it, or am I reading too far? ;)

*) ptp - added dynamic switch ACL rules in order to trap PTP packets to CPU instead of forwarding

Is there any device support matrix, or any device with hardware ACLs can utilize that? Is it possible to copy-and-forward instead of just forwarding to CPU?

---

Possible SYN FLOODING on ports?
shouold i be worried or is it normal

@Coughy: Welcome to the open Internet - if you're not hosting anything on these ports just DROP on WAN. If you are, just ignore it and accept automatic scanners are normal nowadays.

Thanks, I see Apple devices with latest macOS/iOS are able to connect to 2.4GHz again on hAP AX3.

Would be great if MikroTik had rDNS for DHCP clients, I miss being able to identify the clients making requests to my Adguard Home server.

You can add a script that will be run when the DHCP server issues a lease, and in that script you can add a static DNS entry.
Some people have done that and published their script (of course they not all are great programmers...).

Anyone got problems with DHCP on this version ? Seems that addressed are not getting assigned, had to revert back to 7.16

Strange, but I got this error on devices inside the local network (wireless access points and switches):

Strange, but I got this error on devices inside the local network (wireless access points and switches):

Code: Select all

possible SYN flooding on tcp port 8291

Setup up a firewall rule to log addresses trying to reach these ports

7.17beta2 does not solve the problem of disconnecting wifi on AX devices. I am very disappointed, I really wanted to buy a Mikrotik router, because it provides great flexibility of settings, but now I see that Mikrotik engineers can not cope even with basic tasks. Why should I, like an idiot, go through the firmware in the hope that they fixed the banal problem of disconnecting wifi on AX devices, which everyone has known about for a long time.Again, this was broken after 7.15beta8. Everything that was there before works fine. It's been more than half a year...If you can not solve it yourself, roll back the Qualcom driver. I am very disappointed. I use more than 400 Mikrotik devices in my work as a system administrator, and I always recommended them to my clients, but apparently this has come to an end.

Something strange happens with wireguard.
Only 2 of 5 wireguard peer connections connects.
Copy paste keys from scratch but no connection at all

7.17beta2 does not solve the problem of disconnecting wifi on AX devices. I am very disappointed, I really wanted to buy a Mikrotik router, because it provides great flexibility of settings, but now I see that Mikrotik engineers can not cope even with basic tasks. Why should I, like an idiot, go through the firmware in the hope that they fixed the banal problem of disconnecting wifi on AX devices, which everyone has known about for a long time.Again, this was broken after 7.15beta8. Everything that was there before works fine. It's been more than half a year...If you can not solve it yourself, roll back the Qualcom driver. I am very disappointed. I use more than 400 Mikrotik devices in my work as a system administrator, and I always recommended them to my clients, but apparently this has come to an end.

I had same problems as you, disabling WPA3 solved the problem. WiFi is now really rock solid. I hope Mikrotik solve this in the future.

Anyone got problems with DHCP on this version ? Seems that addressed are not getting assigned, had to revert back to 7.16

What your logs say ? If you are experiencing a problem please create supout.rif file and open a ticket with support so they can fix the bug.

I have few devices on 7.17beta and i experience no problems with dhcp server.

any documentation ? example ?

Would be great if MikroTik had rDNS for DHCP clients, I miss being able to identify the clients making requests to my Adguard Home server.

I Guess it can be done with scripting on DHCP leases.

Something strange happens with wireguard.
Only 2 of 5 wireguard peer connections connects.
Copy paste keys from scratch but no connection at all

have seen that happen especially when wan dhcp renews and my wireguard connections freak out and some will not connect again. no amount of disable/enable of peer/interface works. your best option is delete interface and recreate it. i have a script now to recreate all my wireguard connections.

Code: Select all

*) wifi - added multi-passphrase (PPSK) support (CLI only);

any documentation ? example ?

https://help.mikrotik.com/docs/display/ ... Properties
Scroll down / search for "multi-passphrase".

ok so fun fact i dropped to wan these ports
guess what i cant log into the router via winbox with the ip address??
i can only log in via the mac id
so it is winbox trying to open /connect to ports in the router
i disabled the ports i was dropping to wan and i can now log in to the router again with the ip from winbox

EDIT PORT 8291 is the one dropping for winbox deleted it now i can login via ip from winbox

Strange, but I got this error on devices inside the local network (wireless access points and switches):

Code: Select all

possible SYN flooding on tcp port 8291

multi-passphrase is not supported for the WPA3-PSK authentication type.

Code: Select all

*) wifi - added multi-passphrase (PPSK) support (CLI only);

any documentation ? example ?

https://help.mikrotik.com/docs/display/ ... Properties
Scroll down / search for "multi-passphrase".

Hmm, looks like the SFTP client is broken... The backup script on my lab device failed. All other devices running 7.16 did succeed, so I am sure the server is ok.

Not again something with the special character replacement in filenames?

ok so fun fact i dropped to wan these ports
guess what i cant log into the router via winbox with the ip address??
i can only log in via the mac id
so it is winbox trying to open /connect to ports in the router
i disabled the ports i was dropping to wan and i can now log in to the router again with the ip from winbox

EDIT PORT 8291 is the one dropping for winbox deleted it now i can login via ip from winbox

Strange, but I got this error on devices inside the local network (wireless access points and switches):

Code: Select all

possible SYN flooding on tcp port 8291

Set an address list call it "support" add IP range you wish to be able to access the router from then add rule
/ip firewall address-list
add address=X.X.X.X/X list=support

/ip firewall filter
add action=accept chain=input comment="Allow WinBox" dst-port=8291 protocol=tcp src-address-list=support

Or you could use port knock

/ip firewall filter
add action=add-src-to-address-list address-list=port:1778 \
address-list-timeout=15s chain=input dst-port=6789 protocol=tcp
add action=add-src-to-address-list address-list=support address-list-timeout=\
5m chain=input dst-port=1778 protocol=udp src-address-list=port:6789
add action=accept chain=input comment="Allow WinBox" dst-port=8291 protocol=\
tcp src-address-list=support

What's new in 7.17beta2 (2024-Sep-27 10:07):
*) pppoe - added support for PPPoE server over 802.1Q VLANs;

Vlan Demux Interface - auto decapsule vlans

Will we see the equivalent to that on IPoE(DHCPv4, DHCPv6)?
I'm willing to bet we won't! Or at least not until RouterOSv8.

I feel like they solved the right problem in the wrong way...
They used eXtreme Go Horse methodology, reducing the scope to just what was badly described in issue of the sprint.
They forgot that the same methodology of Vlan-Demuxing(single or double tag) would apply to PPPoE, but also with IPoE and L2TP.

MVP is my ass!

cheers My GURU
did the address list version see if i did it correctly and if it works for me lol
so far it is give it a couple days to test more
but ty for the help thats above my pay grade
i have created a drop to wan like this
add action=drop chain=input comment="Blocked ports" protocol=tcp Dst-Port 8728,53,2828
Is this the way to do it?
cheeers pete

ok so fun fact i dropped to wan these ports
guess what i cant log into the router via winbox with the ip address??
i can only log in via the mac id
so it is winbox trying to open /connect to ports in the router
i disabled the ports i was dropping to wan and i can now log in to the router again with the ip from winbox

EDIT PORT 8291 is the one dropping for winbox deleted it now i can login via ip from winbox

Set an address list call it "support" add IP range you wish to be able to access the router from then add rule
/ip firewall address-list
add address=X.X.X.X/X list=support

/ip firewall filter
add action=accept chain=input comment="Allow WinBox" dst-port=8291 protocol=tcp src-address-list=support

Or you could use port knock

/ip firewall filter
add action=add-src-to-address-list address-list=port:1778 \
address-list-timeout=15s chain=input dst-port=6789 protocol=tcp
add action=add-src-to-address-list address-list=support address-list-timeout=\
5m chain=input dst-port=1778 protocol=udp src-address-list=port:6789
add action=accept chain=input comment="Allow WinBox" dst-port=8291 protocol=\
tcp src-address-list=support

I feel like they solved the right problem the wrong way...

PPPoE is a special case as it's not IP on the physical interface side ... so they can easily add VLAN ID handling to pppoe process. And tge feature is (currently) only available for PPPoE server, which may serve multiple VLANs and hence handling of VLAN internally really is handy (one server for nany VLANs instead of many servers one per VLAN).
With IPoE it's much harder ... because it's not DHCP client which handles all the traffic, DHCP client could only configure VLAN interface instead of you (but then who is going to remove it when it's not needed any more? Etc.). Not the way to go IMO. If setting of VLAN ID for internet service is so hard, then MT should add possibiliry to set it in QuickSet (or the "provisioning for dummies" app) ... if that's not a thing yet.

cheers My GURU
did the address list version see if i did it correctly and if it works for me lol
so far it is give it a couple days to test more
but ty for the help thats above my pay grade
i have created a drop to wan like this
add action=drop chain=input comment="Blocked ports" protocol=tcp Dst-Port 8728,53,2828
Is this the way to do it?
cheeers pete

Set an address list call it "support" add IP range you wish to be able to access the router from then add rule
/ip firewall address-list
add address=X.X.X.X/X list=support

/ip firewall filter
add action=accept chain=input comment="Allow WinBox" dst-port=8291 protocol=tcp src-address-list=support

Or you could use port knock

/ip firewall filter
add action=add-src-to-address-list address-list=port:1778 \
address-list-timeout=15s chain=input dst-port=6789 protocol=tcp
add action=add-src-to-address-list address-list=support address-list-timeout=\
5m chain=input dst-port=1778 protocol=udp src-address-list=port:6789
add action=accept chain=input comment="Allow WinBox" dst-port=8291 protocol=\
tcp src-address-list=support

Very good, you could also put before the winbox accept rule below;

/ip firewall filter
add action=drop chain=input comment="Blocked ports" dst-port=8728,53,2828 protocol=tcp src-address-list=!support

This will block addresses trying to each listed port that is not in support list

I feel like they solved the right problem the wrong way...

PPPoE is a special case as it's not IP on the physical interface side ... so they can easily add VLAN ID handling to pppoe process. And tge feature is (currently) only available for PPPoE server, which may serve multiple VLANs and hence handling of VLAN internally really is handy (one server for nany VLANs instead of many servers one per VLAN).
With IPoE it's much harder ... because it's not DHCP client which handles all the traffic, DHCP client could only configure VLAN interface instead of you (but then who is going to remove it when it's not needed any more? Etc.). Not the way to go IMO. If setting of VLAN ID for internet service is so hard, then MT should add possibiliry to set it in QuickSet (or the "provisioning for dummies" app) ... if that's not a thing yet.

Just like PPPoE is an ephemeral interface that exists while tunnel is active, a dynamic sub-if of a stacked vlan is an ephemeral interface that exist while exists traffic that specifies it.

This is pure control-plane.
- Trigger -> Any specified type of packet
- Action -> Create a sub-if, bind the specified service(PPPoE or DHCP) on it.
- Trigger -> Mac in sub-if = 0
- Action -> Remove sub-if.

If they had gone that way, that solution could be used to many contexts... Including PPPoE, DHCP, L2TP, 802.1X, VXLan, and etc...
But, as they put a band-aid on it, it will never be on the priority list again.

This is pure control-plane.
- Trigger -> Any specified type of packet
- Action -> Create a sub-if, bind the specified service(PPPoE or DHCP) on it.
- Trigger -> Mac in sub-if = 0
- Action -> Remove sub-if.

I have made several forum posts and support requests to MikroTik to open the box a bit...

Hooks that would allow some scripting, passing some variables.

This is exactly a case for that.

Just like PPPoE is an ephemeral interface that exists while tunnel is active, a dynamic sub-if of a stacked vlan is an ephemeral interface that exist while exists traffic that specifies it.

Sorry, I simply don't agree that having plethora of dynamic interfaces is a good thing ... just to work around a bit of (manual / scripted) configuration.

And: PPPoE is (kind of) ephemeral interface, tied to a tunnel ... which is either up or not and the transition between the two is pretty obvious (among others due to keep-alive mechanizms). You can't run PPPoE without running client (or server) so it's not even ephemeral in that sense (it can often be a very permanent interface).
DHCP client OTOH serves as an almost "stateless" client which simply pulls config from server ... so per-se it doesn't run any (ephimeral) tunnel or interface.

I have 1 issue so far after upgrading from 7.16 to 7.17 beta2 on LAB CCR2216

I have port showing as running/slave on interface list but on bridge its showing as Inactive.

Sorry, I simply don't agree that having plethora of dynamic interfaces is a good thing ... just to work around a bit of (manual / scripted) configuration.

Okay! You have the right to disagree!

But all other vendors with significant market share(Cisco, Huawei, Nokia, Juniper) have an approach to solving this!

The one I find most elegant is Juniper's.
https://www.juniper.net/documentation/u ... rface.html

And in this world "no-so-big players", I have lost in somewhere in my mind that even VyOS can do that kind of dynamic sub-interface.
And running Accell binaries directly yourself (not in VyOS or other appliance), I'm sure allows you to handle this through LUA scripts both in PPPoE and DHCP.

P.S.: Is valid to say that this is a solution to be used in a Carrier Grade scenario, not in an enterprise or soho environment.

On the stats from 7.16 to 7.17beta2, there are +74 new commands and +803 new attributes (although the "group-by" gins up the numbers since that in a lot of places ;))

+1

+½

There are also newer options in ZeroTier too that are not exposed... yet? i.e. be nice to control multipath and enable low-bandwidth mode

I totally agree :)

some solid work on bridge regarding mlag and VLANs (will have to rework some bridge setups xD )

thanks a lot for the impressive work you doing here! pace is on!! cheers guys

7.17beta2 does not solve the problem of disconnecting wifi on AX devices. I am very disappointed, I really wanted to buy a Mikrotik router, because it provides great flexibility of settings, but now I see that Mikrotik engineers can not cope even with basic tasks. Why should I, like an idiot, go through the firmware in the hope that they fixed the banal problem of disconnecting wifi on AX devices, which everyone has known about for a long time.Again, this was broken after 7.15beta8. Everything that was there before works fine. It's been more than half a year...If you can not solve it yourself, roll back the Qualcom driver. I am very disappointed. I use more than 400 Mikrotik devices in my work as a system administrator, and I always recommended them to my clients, but apparently this has come to an end.

Open a ticket with a support file this should help resolve this!

Guys, you can complain here about wifi issues. But more important is a support ticket. The forum topics are not read regularly by Mikrotik staff and even then it is just a comment inside a long topic of a tons of reported issues. Every official support ticket helps.

Just updated one of my CAPs (CAP AX) and it's completely gone.
I first updated my device which has capsman running(RB5009) before updating one of the CAPs.

It does not show up in capsman nor windows, and no signs of it in the logs on the RB5009.
I can however find it's MAC-address when running mac-scan on the port that it is connected to on the RB5009, but it doesn't show up if I scan the Mac addresses on the MGMT VLAN that it (should)use.
But can't ping the MAC nor use Mac-telnet to connect to it.

Any recommendation on how to proceed?


----EDIT-----
Managed to reach it by changing the port on the RB5009 to which the CAP is connected to 'admit all' frame types instead of only tagged.
After I managed to login to it I noticed that the CAP AX had it ETH1 disabled and also the default route. Enabled those and it seemed to start working again, but reverted back to 6.16 stable.
Will keep it that way for a couple of beta versions more I guess :)

Is there documentation for

*) wifi - added multi-passphrase (PPSK) support (CLI only);

?

----EDIT-----
Managed to reach it by changing the port on the RB5009 to which the CAP is connected to 'admit all' frame types instead of only tagged.
After I managed to login to it I noticed that the CAP AX had it ETH1 disabled and also the default route. Enabled those and it seemed to start working again, but reverted back to 6.16 stable.
Will keep it that way for a couple of beta versions more I guess

That doesn't seem related to RouterOS version upgrade, it never changes essential configuration such as disabling ethernet interfaces.
I would suggest to double check your configuration - Do you have any scripts scheduled on reboot? was this state of configuration one of your previous configurations? are you sure there are nobody else with access to that device?

Is there documentation for

*) wifi - added multi-passphrase (PPSK) support (CLI only);

?

https://help.mikrotik.com/docs/display/ ... passphrase

Anyone got problems with DHCP on this version ? Seems that addressed are not getting assigned, had to revert back to 7.16

What your logs say ? If you are experiencing a problem please create supout.rif file and open a ticket with support so they can fix the bug.

I have few devices on 7.17beta and i experience no problems with dhcp server.

Found the issue, I had to change the interfaces for other relays (up/down) - when I had all set to bridge, it stopped working on 7.17 beta.
I changed it as per relevant interfaces and works again fine.
Re logs, there were no erros just : "dhcp_main offering lease 10.0.0.XX for XX:XX:XX:XX:XX:XX without success"

ofca, I understand your concern, but if you do not have any kind of backup access to these devices, how are you recovering in case of some failed upgrade? An alternative to push-button is cold reboot (power cycle).

**I would like to stress, that device-mode settings are entirely optional. Do your CPEs require traffic generator? If no, there is no need for this operation. **

ofca, I understand your concern, but if you do not have any kind of backup access to these devices, how are you recovering in case of some failed upgrade? An alternative to push-button is cold reboot (power cycle).

In case of some failed upgrade, I use "partitions" to recover. But you are blocking that by making it part of device-mode settings.

**I would like to stress, that device-mode settings are entirely optional. Do your CPEs require traffic generator? If no, there is no need for this operation. **

They are NOT. As far as I understand, the new 7.17 release will disallow the use of partitions (and some other things) unless you have enabled their use in device-mode. Which you can only do in physical presence of the device.
If it is not like that, please explain.

For device-mode settings to be "entirely optional", there should be a way to remotely add new device-mode settings that are added to a new release as part of an upgrade procedure.

What's new in 7.17beta2 (2024-Sep-27 10:07):

!) device-mode - after upgrade, mode "advanced" is set by default and traffic-gen, changing active partitions, bootloader and downgrade features will be disabled;

Would this be applied to all devices or only to devices which have their device-mode at default setting prior to update? It would be madness if it is applied to all devices - this would even enable some features disabled by user...

I sure hope there will be a clear explanation of what happens to existing devices that use those features, for all reasonable existing device-mode settings.
E.g. in my devices, the setting is "enterprise" and on some of them "container: yes".
After I upgrade to 7.17, will my partitions still be functional and will I be able to downgrade when desired?
Or do I need to set a device mode and thus physically visit the device and make a change within 5 minutes before I can press the button?
(even that is not easy at some locations)

Device-mode is poorly documented for what it is meant for. Take the list of "List of available properties" for example. It is a list of abstract "terms" but lacking any details. What does the property "bootloader" restrict? Does it prevent routerboard firmware upgrade? Or does it prevent changing routerboard settings? Or what exactly? Neither is clear by the word "partitions". What does "partition" restrict exactly? I am not allowed to have any partitions? No additional partitions to root partition? Am I allowed to have USB disks when "partitions" property effective? I could continue with many more questions. I dont know why this is not documented better.

Be honest:
A one-liner is all we get? I don't care that much, I am just a home user, but some professionals already commented her. How can one - managing hundreds of devices - take precautions? Not ending up by locking down devices and climb up to some poles somewhere in the wild?

PS:
My favorite quote from the docs:

Disabled list feature is self-explanatory

https://help.mikrotik.com/docs/display/ ... xplanatory

I sure hope there will be a clear explanation of what happens to existing devices that use those features, for all reasonable existing device-mode settings.

On my test RB1100AHx4 with 7.17beta2, it showed partitioning menu (with device-mode showing "mode: advanced" and container=yes".

I have always thought @pe1chl/others scheme to use 2 partitions was a good one, but never set it up. i.e. if RouterOS works on 16MB flash, and you have 128MB NAND, why not have a backup version with older version to use the "extra space"? But my blocker was help.mikrotik.com does not exactly describe the process to do that, or much at all: https://help.mikrotik.com/docs/display/ROS/Partitions - I guess hiding it beyond device-mode avoid the need to cleanup the docs on it ;).

But given that device-mode should block this in 7.17beta2, I tried it anyway*. And 7.17 did let me change from 1 to "/partition/repartition 2", and asked to reboot. That got a bootloop with an error that it could not find an "system" showing up on serial port from RouterBOOT. Change the partitions back to 1 in RouterBOOT, and that fixed the bootloop (and all the files came back from NAND). But clearly "device-mode" didn't block anything, at least on RB1100 with whatever device-mode I had set.

Anyway...I actually like the device-mode concept - since we lost the ability to remove packages to pairing down the UI/attack surface. But.... I'm not sure it a good idea for an upgrade to change the mode. And do think device-mode should be able to at least be set via netinstall. Since operationally if you want to enable container on batch of units, to install a container during defconf... that cannot be automated.

* The RB1100 has serial port... so it's easier to be so cavalier. And I keep a LtAPmini with serial cables & does make quick work to get it out of a bootloop ;)

What happens to devices, running ROS 7.16, upgrading to 7.17 with this setting:
Does it change to false? Or is it kept as is?

Normally, partitioning works like this: you set the number of partitions to 2, the device will reboot and now you see 2 partitions, one is your running system and the other one is empty.
Then you highlight part0 and choose "copy to" part1.
After that you have two partitions that are the same, and part0 is "active" and "running".
Now when you upgrade, after reboot you will see part0 is the new version and part1 still is the old version. You can right-click part1, select "make active" and reboot, now you are back in the old version and when you check partitions you will see part1 is "active" and "running".
Every time before you upgrade or do some drastic config rework, you first copy the running partition to the other one, and you always have a backup.

There is one other feature: when the router crashes during boot, or when you interrupt power during boot, it will auto-switch to the other partition.
So when you have locked yourself out or the upgrade has gone very badly, it will recover by booting the other part.
This also is a risk, because when the power is flaky it may select the other partition unintentionally!
To prevent big problems, copy the partition (or only the config, when routeros version is the same) somewhat regularly.

@pe1chl, I kinda figured that, since you can see those options in /partition – I just played dumb, and followed winbox... it wanted asked to reboot, so I just said yes & wanted to see what happen. And, I confirmed it was running the matching firmware before doing this too. But after reboot, I could not even get to winbox to do the "copy-to" step - since it got this bootloop:

Press any key within 2 seconds to enter setup..
writing settings to flash... OK

loading kernel partition 1... kernel not found or data is corrupted
writing settings to flash... OK

loading kernel partition 0... OK
setting up elf image... OK
jumping to kernel code
opendir: No such file or directory
opendir: No such file or directory
ERROR: no system package found!
[ 1.664332][ T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[ 1.672676][ C2] CPU2: stopping
[ 1.676077][ C2] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.6.3 #2
[ 1.682592][ C2] Hardware name: Annapurna Labs Alpine
[ 1.687901][ C2] {bf099f34} _stext+0x9888/0x4fd230
[ 1.692944][ C2] {bf099f3c} _stext+0x4e902c/0x4fd230
[ 1.698161][ C2] {bf099f4c} _stext+0xbfd0/0x4fd230
[ 1.703204][ C2] {bf099f64} _stext+0x1fe26c/0x4fd230
[ 1.708420][ C2] {bf099f7c} _stext+0x1acc/0x4fd230
[ 1.713461][ C2] Exception stack(0xbf099f80 to 0xbf099fc8)
[ 1.719199][ C2] 9f80: 00000c0c 00000000 00000c0c 80114760 bf098000 00000004 80904eec 80904f28
[ 1.728054][ C2] 9fa0: 0004406a 412fc0f4 00000000 00000000 00000000 bf099fd0 8010700c 80106ffc
[ 1.736908][ C2] 9fc0: 60000013 ffffffff
[ 1.741085][ C2] {bf099fcc} _stext+0x6ffc/0x4fd230
[ 1.746127][ C2] {bf099fd4} _stext+0x4c120/0x4fd230
[ 1.751256][ C2] {bf099fec} _stext+0x4c3b0/0x4fd230
[ 1.756384][ C2] {bf099ff4} 0x10246c
[ 1.760214][ C1] CPU1: stopping
[ 1.763616][ C1] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.6.3 #2
[ 1.770130][ C1] Hardware name: Annapurna Labs Alpine
[ 1.775435][ C1] {bf097f34} _stext+0x9888/0x4fd230
[ 1.780478][ C1] {bf097f3c} _stext+0x4e902c/0x4fd230
[ 1.785695][ C1] {bf097f4c} _stext+0xbfd0/0x4fd230
[ 1.790737][ C1] {bf097f64} _stext+0x1fe26c/0x4fd230
[ 1.795952][ C1] {bf097f7c} _stext+0x1acc/0x4fd230
[ 1.800994][ C1] Exception stack(0xbf097f80 to 0xbf097fc8)
[ 1.806732][ C1] 7f80: 00001038 00000000 00001038 80114760 bf096000 00000002 80904eec 80904f28
[ 1.815587][ C1] 7fa0: 0004406a 412fc0f4 00000000 00000000 00000000 bf097fd0 8010700c 80106ffc
[ 1.824440][ C1] 7fc0: 60000013 ffffffff
[ 1.828617][ C1] {bf097fcc} _stext+0x6ffc/0x4fd230
[ 1.833658][ C1] {bf097fd4} _stext+0x4c120/0x4fd230
[ 1.838786][ C1] {bf097fec} _stext+0x4c3b0/0x4fd230
[ 1.843915][ C1] {bf097ff4} 0x10246c
[ 1.847744][ C3] CPU3: stopping
[ 1.851145][ C3] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.3 #2
[ 1.857660][ C3] Hardware name: Annapurna Labs Alpine
[ 1.862964][ C3] {bf09bf34} _stext+0x9888/0x4fd230
[ 1.868008][ C3] {bf09bf3c} _stext+0x4e902c/0x4fd230
[ 1.873222][ C3] {bf09bf4c} _stext+0xbfd0/0x4fd230
[ 1.878265][ C3] {bf09bf64} _stext+0x1fe26c/0x4fd230
[ 1.883480][ C3] {bf09bf7c} _stext+0x1acc/0x4fd230
[ 1.888521][ C3] Exception stack(0xbf09bf80 to 0xbf09bfc8)
[ 1.894258][ C3] bf80: 00000b80 00000000 00000b80 80114760 bf09a000 00000008 80904eec 80904f28
[ 1.903114][ C3] bfa0: 0004406a 412fc0f4 00000000 00000000 00000000 bf09bfd0 8010700c 80106ffc
[ 1.911967][ C3] bfc0: 60000013 ffffffff
[ 1.916144][ C3] {bf09bfcc} _stext+0x6ffc/0x4fd230
[ 1.921186][ C3] {bf09bfd4} _stext+0x4c120/0x4fd230
[ 1.926314][ C3] {bf09bfec} _stext+0x4c3b0/0x4fd230
[ 1.931442][ C3] {bf09bff4} 0x10246c
[ 1.935283][ T1] Rebooting in 5 seconds..
:00000050
AL31400X-140

I also tried to set partition 2 as active, in case that's where it put (or maybe, I thought, it made TWO copies when you change the partition count). Same bootloop.

But none of this matches the release note here, since I should not have been able to even see partitions - at least in my reading of the !) note.

Code: Select all

/system/device-mode/update mode=enterprise traffic-gen=yes

I'll add that /system/device-mode print should have a "detail" option that shows all the =yes / =no as resolved by the mode and other switches. AFAIK it takes consulting the docs to see what mode= means – with the meaning of mode= change between version.

I use and enable partitions remotely ***all the time*** (on anything with large enough flash, particularly RB4011/5009/CCR's). And sometimes I forget to set all the things while I have physical access to it (i.e. on the bench/in the lab) before I deploy the router in the field.

Blocking the ability to change partition settings on already-deployed devices (without some kind of non-physical-access upgrade workaround) would be a huge hinderance, since many of my routers are in hard-to-reach locations. It's not easy/practical to change a setting, then have to drive + climb within 2-5 minutes and hit a button.

I agree that this change (and its ramifications) needs to be spelled out better in documentation somewhere instead of a terse, vague one-liner in release notes.

ofca, I understand your concern, but if you do not have any kind of backup access to these devices, how are you recovering in case of some failed upgrade? An alternative to push-button is cold reboot (power cycle).

**I would like to stress, that device-mode settings are entirely optional. Do your CPEs require traffic generator? If no, there is no need for this operation. **

We don't only use CPEs, and yes, we sometimes use debugging features like bw-test or traffic gen to communicate with for example Eltek PSUs. We also have hundreds of CCRs. You are effectively taking features away from us, unless we allocate manpower to drive around the city and needlessly waste time pushing buttons, instead of making money to buy more MikroTik devices. Please figure out a better way that isn't a regression. It's not a question of backup access. It's a question of scale. We are not talking about two routers here.
Do you want to drive around to all of them and push the button? I didn't think so. We already had to waste time to use containers on few occasions - now the scale will be even higher to just keep features that we currently have in case we'll need to use them one day.

I'm all for security and locking down the devices. What I definitely don't like is me being locked out from my own devices. Please figure out a better way. I'd also like this better way to include possibility of enabling containers remotely. I've sent you an idea for consideration under SUP-166837. Thanks.

I agree that this change (and its ramifications) needs to be spelled out better

Actually, this change needs to not happen at all, in my opinion. I'm really glad, that MikroTik guys changed the dev model, and now we have long-running betas, so we can help avoiding such disastrous design choices.

Our field technicians don't ever login to devices; it's all centrally auto-provisioned with high-level staff remotely accessing the devices if and when needed - devices they've never seen with their own eyes. Recent idea of custom default passwords already requires manual waste of time when deploying new devices. Now there will be even more waste of time to do some coordinated button-pushing -- and that's only talking about new devices; what about thousands of existing devices that will need to be visited for a button push?

I fully agree! I think that when an existing feature requires a new device-mode setting after an upgrade, the corresponding device-mode should be automatically set as part of the upgrade.
Only on new devices or after reset-to-defaults, a new device-mode regime should become active by default.

So it seems that when you try to setup partitions while not having that device-mode option set, it just corrupts the device?
That is even worse than being unable to switch partitions after upgrade...

That be my take. I only went down the rabbit hole since the RB1100 had a physical serial port. Clearly it shouldn't end up in a bootloop.

Normally if something is blocked by device-mode, it does not show up in UI/CLI - so there that initial problem here IMO.

Why there is no device-mode called "this-is-my-router-and-I-want-everything-to-be-enabled-always-and-forever"?

Why there is no device-mode called "this-is-my-router-and-I-want-everything-to-be-enabled-always-and-forever"?

The knee-jerk reaction of most SoHo, and supermarket IT people would be to set this, defeating it's purpose

That said, there must be a better way than forcing a truck-roll for people managing thousands of devices, especially when involving partitions/downgrade
those are recovery features by their very nature, and messing with them has a wide range of ramifications

We don't only use CPEs, and yes, we sometimes use debugging features like bw-test or traffic gen to communicate with for example Eltek PSUs.

Very off-topic, but can you share why would you need to hit those PSU's with traffic-gen?
Emulating some kind of magic-packet maybe?

Also, i can definitelly see why they hid traffic-gen behind a config-wall, as it's essenially a wirespeed DDOS generator, and should not be trusted to the average home user

I have installed this new beta to check some fixes, but after downgrading back to 7.16 I started to receive an error in the log each 5 seconds. I don't remember exact error text, but it was something like "the router can't save changes because of problem in file system". And it was impossible to reboot. Only netinstall helped.

Documentation of device-mode has been updated with more info. If anyone has any doubts or questions, please post them here and we will answer them in the documentation

Thanks for adding the "feature clarification table". 👍

We don't only use CPEs, and yes, we sometimes use debugging features like bw-test or traffic gen to communicate with for example Eltek PSUs.

Very off-topic, but can you share why would you need to hit those PSU's with traffic-gen?
Emulating some kind of magic-packet maybe?

Yes, this exactly. We are using traffic gen to detect presence and current config of a device, to avoid bridging and using proprietary windows app.

Coordinated button press is not the only option. Power cycle / remove power from device is an alternative.

Deploy your devices from now on with some remote-controlled powerplug and you're good to go. future proof kind of....

....what if these remote-controlled powerplugs are online and somehow easily accessible (backdoor, unsecured, auth bypass, etc.) by "evil people" as well? Ransomware gangs triggering power plugs to unlock ROS device mode....🤯🤯🤯

😂😂😂

Yeah, sure; we've also started in a garage; luckily, today we are way past that. If device requires any power-cycling to keep working, it's replaced as failed. If it's "normal behavior", then it's decommissioned and vendor is banned. I sincerely hope you were just making a joke about adding point of failures to "always on" setups. MikroTik devices are quite robust and, with exception of first batch(es) of CRS317 switches, I don't remember any cases that would consistently require power interventions ;)

I don't know what you understood. In simple words: any change you make to device-mode settings can be either commited/confirmed by pusing reset-button or a cold reboot. Cold reboot stands for "take away power and restore power", "unplug power cable, re-attach power cable", or any other action that takes away energy from the device. I hope this is clear now. My - rather a sarkastic comment - had nothing to do with "stability", "reliability", or with "failures" or any regular behaviours of devices.

https://help.mikrotik.com/docs/display/ ... he%20power.

The device-mode can be changed by the user, but remote access to the device is not enough to change it. After changing the device-mode, you need to confirm it, by pressing a button on the device itself, or perform a "cold reboot" - that is, unplug the power.

I hope this is clear now.

I do understand why Mikrotik wants to lock down some device functionality, it makes perfect sense in regards of security.

On the other side I think the current situation (7.17beta2) with device-mode is not acceptable either. (I think I was the first to complain in this thread.) Visiting thousands of devices physically is just a huge issue.

So how about adding a kind of "grace period" for post-7.16 updates? The newly introduced device modes could be activated without physical interaction for a period of something like 24 hours after that update. If no action is taken in that time the modes become locked, just as they are now. Does that help most of us?

I don't know what you understood. In simple words: any change you make to device-mode settings can be either commited/confirmed by pusing reset-button or a cold reboot.

Well, I should mention that I was quite surprised the first time when I confirmed a device mode change with pressing the reset button that the device actually cold booted...
I assumed that the reset button was just a soft input button, not hardwired to CPU reset, because you can also configure a script that will be run after pressing it for a short time. And of course there is all those different operations when pressing it for shorter or longer time during powerup.
So when I changed device-mode and pressed reset to confirm, I expected that it would print "OK! you have pressed reset!" and make the change, not to do a cold boot.
When a reboot would be required, I would have expected a warm boot (like /system reboot from commandline)...

The message shown on CLI is quite clear and does not leave room for interpretations:

So how about adding a kind of "grace period" for post-7.16 updates? The newly introduced device modes could be activated without physical interaction for a period of something like 24 hours after that update. If no action is taken in that time the modes become locked, just as they are now. Does that help most of us?

That would be one solution.
Another one would be to auto-set all "newly added device-mode properties" to "yes" whenever RouterOS is upgraded.
One can argue "then it would not be very effective for its original purpose", but we already have the situation where all existing devices are in enterprise/advanced mode and will not (I HOPE NOT!) switch to the new default device mode for 7.17 on that device.
(when I read the help page I conclude that all devices now running 7.16 will be in "advanced" mode after upgrade to 7.17)

The message shown on CLI is quite clear and does not leave room for interpretations:

Code: Select all

update: please activate by turning power off or pressing reset or mode button in 4m27s

Maybe for you? For me that is not clear. When I press reset or mode button, it will activate the setting. But will it also reboot???
It does not tell that.
Maybe it even depends: pressing reset will reboot it, pressing mode button will not. Who knows?
(I was not able to test that because the devices I tested it on have no mode button)

We have added to the manual some more info about device mode, including that it will reboot in any case.
The console message will also be amended in future betas.

Well, I should mention that I was quite surprised the first time when I confirmed a device mode change with pressing the reset button that the device actually cold booted...

Device mode gets set into routerboot (could be it's even baked into permanent storage just like the rest of routerboot contents) and I'd guess that as with every other change in routerboot, device has to be reset.

As to hard/soft reset ... it's hard to self-inflict hard reset on RB devices since they don't have necessary (power management) hardware. So it was probably a (normal?) reboot.

Maybe for you? For me that is not clear. When I press reset or mode button, it will activate the setting. But will it also reboot???
It does not tell that.

Point taken. I don't know either what happens on button press. That's a bad thing I have to admit. Last time I changed device-mode was to enable "container" flag - but pressing the reset-button did not confirm it. Don't know why it did not work. So I had to do the other thing: "turning power off".

Pressing the button will initiate a reboot when device-mode command is issued before this.

Well, that whole "it will reboot to change the setting" makes the whole thing even worse than it already is.
Not only is it required to physically go to each router, and to connect to the CLI and issue the command and press the button, but also it will cause an interruption in the network at that time.
It is usually even more difficult to get physical access in a maintenance service window than it already is in the first place.
Even when a reboot is required to activate the new settings, it could be noted and the reboot could be done later.
(just as when you upgrade routerboot, for example)
And we cannot even prepare the new device-settings ahead of time, because 7.16 does not allow to set the new properties yet.
The fact that it is a "cold reboot" is also bad, e.g. we have "add ARP for dhcp leases" and "arp mode reply-only" on all the networks, and a cold reboot leaves some clients in a confused state because new leases have not yet been written to storage and after boot will have no ARP entry. At least do a warm reboot!

Documentation of device-mode has been updated with more info. If anyone has any doubts or questions, please post them here and we will answer them in the documentation

I want to prepare a site of which I don’t have physical access to in the next months.

What is the best command to be ready and have all features enabled?

Please, what will happen to the running containers after the update to 7.17?

Nothing should happen, on my ax3 everything is working. Do you have an issue ?

nothing it works fine nothing to do with containers unless you have different partitions for them but most run on usb??

Please, what will happen to the running containers after the update to 7.17?

in your log do you get HapAx3_5Ghz detect LAN if you have that active??
seem to show up every 3 hrs or so only the HapAx3_5Ghz detect LAN no other interface does it

Nothing should happen, on my ax3 everything is working. Do you have an issue ?

We have added to the manual some more info about device mode, including that it will reboot in any case.
The console message will also be amended in future betas.

But it's still not clear what I need to do to make sure I can still use all features (including traffic-gen, container, partitions, bootloader and downgrade) on our 2000+ devices in the field without having to physically visit each one of them and do a powercycle.

Also, the documentation is still confusing. It first mentions (under 'Available device-mode modes') that traffic-gen, container, partitions, bootloader, downgrade are disabled for 'advanced mode'. But then under 'List of available properties' it says "Default: yes, for advanced mode" describing properties that also include traffic-gen, container, partitions, bootloader and downgrade?

No, we do not plan to implement annual licensing or any other licensing changes.

Device mode, as clarified in the manual, is meant to protect home users who have their routers taken over by attackers and are using them for botnet purposes.

EVEN THOUGH we have no known security issues in RouterOS AND we have added default passwords out of the box, improved security will ensure the devices stay secure for a long time. Home user does not need traffic generator.

Nothing should happen, on my ax3 everything is working. Do you have an issue ?

It's not ok on my RB5009.
None of my containers start (iperf, openspeedtest, pi-hole) and yesterday I noticed a couple of drops during Teams calls (never saw that happening before).
Will troubleshoot later this evening.

We have added to the manual some more info about device mode, including that it will reboot in any case.
The console message will also be amended in future betas.

But it's still not clear what I need to do to make sure I can still use all features (including traffic-gen, container, partitions, bootloader and downgrade) on our 2000+ devices in the field without having to physically visit each one of them and do a powercycle.

Also, the documentation is still confusing. It first mentions (under 'Available device-mode modes') that traffic-gen, container, partitions, bootloader, downgrade are disabled for 'advanced mode'. But then under 'List of available properties' it says "Default: yes, for advanced mode" describing properties that also include traffic-gen, container, partitions, bootloader and downgrade?

Home and Advanced mode are like presets, that allow certain list of features. Groups of features, that are listed next to them in the manual.
BUT there is no mode that allows ALL features, if you have Advanced and also need some additional features, you have to enable them one by one. I suggest reading the entire documentation page, it clarifies this further in the text.

Containers ALWAYS had device-mode requirement, since day one. Maybe you forgot you set it. So nothing changes if you had a running container.

Thank's to all for the confirmation regarding containers....

I have posted further updates to the manual, so all your Device mode questions should be answered in there .

If your containers stopped working after upgrade to 7.17, it might not be related to device mode at all.