RouterOS version 7.16beta 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.16beta7 (2024-Jul-25 12:55):

*) 6to4 - improved system stability when using 6to4 tunnel without specified remote-address;
*) 6to4 - make "remote-address" parameter not-mandatory (introduced in v7.16beta3);
*) arm64 - fixed "disable-running-check" for ARM64 UEFI;
*) arp - fixed possible issue with invalid entries;
*) bridge - added dynamic tagged entry when VLAN interface is created on vlan-filtering bridge (additional fixes);
*) bridge - added L2 MDB support for IGMP snooping (additional fixes);
*) bridge - fixed MVRP leave;
*) bridge - fixed port "point-to-point" status after first link change;
*) bth - improved stability on system time change;
*) console - added "about" filters for "find" and "print where" commands;
*) console - increased default width for bitrate type of columns;
*) dhcp - improved DHCP IPv4 and IPv6 client/relay/server underlying interface state change handling;
*) dhcpv4-server - remove corresponding dynamic leases if their address-pool gets removed;
*) discovery - added discover-interval setting (additional fixes);
*) discovery - added LLDP Port VLAN ID, Port And Protocol VLAN ID, VLAN Name TLVs support (additional fixes);
*) discovery - added LLDP-MED timeout (additional fixes);
*) discovery - changed default discover-interval setting from 60s to 30s;
*) disk - remove dummy "slot1" entries on CHR;
*) dns - added support for DoH with adlist (additional fixes);
*) dns - added support for mDNS proxy;
*) dns - fixed memory leak caused by DoH service (introduced in v7.16beta3);
*) dns - improved imported adlist parsing;
*) dns - match NXDOMAIN static entry only if other type entries for the same name are not found;
*) dns - refactored adlist service internal processes and improved logging;
*) dns - show static entry type "A" field in console;
*) ethernet - improved system stability for Alpine CPUs when dealing with unexpected non-UDP/TCP packet transmit;
*) file - renamed "creation-time" to "last-modified";
*) filesystem - improved boot speed after device is rebooted without proper shutdown (additional fixes);
*) filesystem - refactored internal processes to minimize sector writes (additional fixes);
*) iot - fixed incorrect LoRa filter export behavior;
*) iot - fixed LoRa inability to set SSL for LoRa servers via command line;
*) ipsec - improved installed SA statistics update;
*) ipsec - improved performance by balancing multicore CPU usage for key exchange calculation;
*) ipv6 - fixed pool allocated addresses missing after reboot (additional fixes);
*) ipv6 - improved handling of IPv6 address information;
*) ipv6 - improved LL address generation process (additional fixes);
*) leds - fixed rgb LED blink (introduced in v7.16beta1);
*) lte - fixed possible crash when enabling/disabling config-less modem interface;
*) lte - improved modem AT/modem port open;
*) lte - improvements to "/interface/lte/show-capabilities" command (additional fixes);
*) modem - fixed cases where USB bus could switch places (introduced in v7.16beta1) (additional fixes);
*) modem - improved support for KNOT BG77 modem firmware update (additional fixes);
*) poe-out - fixed incorrect port mapping on CRS354-48P-4S+2Q+ device (introduced in v7.16beta1);
*) ppp - added SIM hot-plug enable command to default init-string for KNOT and CME gateway;
*) ppp - fixed PPP info parser showing error for BG77 modem running on KNOT AUX AT/modem port;
*) qos-hw - added queue-buffers property to tx-manager (additional fixes);
*) qos-hw - fixed egress-rate limit validation;
*) qos-hw - fixed WRED thresholds;
*) qos-hw - improved behavior when changing ports tx-manger;
*) rose-storage - renamed sync "remote-addr" property to "remote-address";
*) route - improved route attribute handling (may increase memory usage);
*) route - improved stability when getting entries from large routing tables;
*) routerboard - improved Etherboot stability for CRS320-8P-8B-4S+ device ("/system routerboard upgrade" required);
*) sfp - fixed calculated link length based on EEPROM in certain cases (additional fixes);
*) ssh - fixed unsupported user SSH public key import (introduced in v7.15);
*) switch - fixed bonding FDB entries (introduced in v7.16beta3);
*) switch - fixed Ethernet counters after switch reset for CRS354 devices (introduced in v7.16beta1);
*) switch - improved switch reset;
*) system - added critical log message when not enough space to store new configuration;
*) system - fixed "free disk space" error message on system upgrade/downgrade;
*) system - improved internal system services messaging;
*) system - improved performance for TCP input;
*) traceroute - do not stop traceroute after 5 consecutive unreachable hops;
*) user - added inactivity timeout for non-GUI sessions (additional fixes);
*) webfig - allow to enter time that exceeds 23:59:59;
*) webfig - correctly display default value for number type;
*) webfig - enabled hotlock mode for terminal;
*) webfig - fixed an issue where wrong menu title was shown;
*) webfig - fixed sorting by datetime;
*) webfig - use "any" argument by default for Torch "Port" property;
*) wifi - added "slave-name-format";
*) wifi - added interface provisioning logs;
*) wifi - fixed packet receive when having multiple station interfaces (additional fixes);
*) wifi - improved system stability after interface hang;
*) wifi - send channel switch announcements to clients when switching channels at requested re-select intervals;
*) winbox - added "Switch/QoS" menu for CRS3xx, CRS5xx, CCR2116 and CCR2216 devices (additional fixes);
*) winbox - added configuration settings for ROSE;
*) winbox - added extra "File System" under "Format Drive" button;
*) winbox - added missing "Default Name" property for interfaces;
*) winbox - fixed Switch menu for RB1100AHx4 device;
*) winbox - improved QR code display;
*) winbox - moved Switch menu tabs to individual menus (additional fixes);
*) winbox - properly display available address-pools for DHCPv6 server configuration;
*) winbox - renamed configurable wifi property "Tx Power" to "Max Tx Power";
*) winbox - use correct default value for "Partition Offset" property;

What's new in 7.16beta4 (2024-Jul-02 15:47):

*) discovery - added discover-interval setting;
*) disk - added "wipe-quick" file-system option to format-drive command (CLI only);
*) dns - refactored DNS service internal processes (additional fixes);
*) filesystem - improved boot speed after device is rebooted without proper shutdown;
*) filesystem - refactored internal processes to minimize sector writes;
*) health - improved voltage measurements for RB912UAG-6HPnD and RB912UAG-5HPnD devices;
*) ipv6 - do not allow to manually delete LL address (additional fixes);
*) log - added basic validation for "disk-file-name" property;
*) lte - fixed R11e-LTE no traffic flow when modem with old firmware is used;
*) poe-out - fixed possible issue with "current_too_low" on devices with a single PoE out interface (introduced in v7.16beta1);
*) routerboard - improved Etherboot stability for IPQ-40xx devices ("/system routerboard upgrade" required);
*) user - added inactivity timeout for non-GUI sessions (additional fixes);
*) x86 - fixed missing serial ports with MCS9900;

What's new in 7.16beta3 (2024-Jun-27 08:33):

*) 6to4 - fixed 6to4 tunnel LL address generation after system reboot;
*) 6to4 - limit keepalive timeout maximum value;
*) 6to4 - make "remote-address" parameter mandatory;
*) address - added "S" flag for addresses that belong to a slave interface;
*) arm64/x86 - added rtl8111/8168/8411 firmware;
*) bridge - added L2 MDB support for switch chips with HW offloaded IGMP snooping;
*) bridge - do not allow duplicate ports;
*) bth - improved system stability;
*) certificate - added support for cloud-dns challenge validation for sn.mynetname.net (CLI only);
*) certificate - automatically parse uppercase symbols to lowercase when registering domain on Let's Encrypt;
*) chr - fixed incorrect disk size for ARM64;
*) console - added additional byte-array option to :convert command;
*) console - fixed an issue where certain MAC address can be interpreted as time value;
*) console - fixed typo in firewall error message;
*) console - improved stability when pasting a large input;
*) defconf - configure the default-route property for PPP clients only on devices with a built-in modem;
*) dhcp - added comment property for matchers, options and option sets;
*) dhcpv4-server - added matcher ability to match substring;
*) dhcpv4-server - added name for "User-Class" option (77), "Authentication" option (90), "SIP-Servers-DHCP-Option" option (120) and "Unassigned" option (163-174) in debug logs;
*) dhcpv6-client - release client on failed renew attempt (additional fixes);
*) discovery - added LLDP Port VLAN ID, Port And Protocol VLAN ID, VLAN Name TLVs support;
*) discovery - added LLDP-MED timeout;
*) discovery - set unknown bit for any unspecified link type in MAC/PHY TLV;
*) disk - added log message when disks get added or removed;
*) dns - added support for DoH with static FWD entries;
*) dns - added support for mDNS proxy (CLI only);
*) dns - refactored DNS service internal processes;
*) firewall - removed unnecessary TLS host matcher from NAT tables;
*) health - removed unnecessary health settings for RB921 and RB922 devices;
*) install - allow to save old configuration during cdrom install;
*) iot - added an option to log LoRa filtered packets (additional fixes);
*) iot - added LoRa option to filter out proprietary packets (additional fixes);
*) ipip6 - make IPv6 LL address random;
*) ipsec - improved performance by balancing multicore CPU usage;
*) ipv6 - added "d" deprecated flag for expired IPv6 SLAAC addresses;
*) ipv6 - allow to properly disable address when it is generated from pool;
*) ipv6 - allow to properly move IPv6 address from slave interface to a bridge interface;
*) ipv6 - do not allow adding address with invalid prefix when using pool;
*) ipv6 - do not allow to manually delete LL address;
*) ipv6 - fixed "no-dad" functionality;
*) ipv6 - fixed SLAAC address dynamic appearance;
*) ipv6 - properly initialize default ND "interface=all" entry;
*) ipv6 - warn user that reboot is required in order to properly apply accept-router-advertisements changes;
*) leds - fixed system LED to indicate correct RAT for Chateau (introduced in v7.16beta1);
*) lte - fixed modem dialer disable for Chateau 5G devices when cellular modem support mode set to serial (introduced in v7.16beta2);
*) lte - improved system stability for MBIM modem during AT query (introduced in v7.16beta1);
*) modem - fixed cases where USB bus could switch places (introduced in v7.16beta1);
*) modem - fixed modem firmware upgrade for Chateau 5G and Chateau 5G R16 (introduced in v7.15) (additional fixes);
*) netwatch - use time format according to ISO standard;
*) port - added IPv6 support for the "remote-access" feature;
*) ppp - automatically generate IPv6 firewall rules when filter-id is specified;
*) profiler - classify wifi processing as "wireless";
*) rose-storage - fixed "/file sysnc status" parameter to be read-only;
*) rose-storage - moved "/rsync-daemon" to "/file rsync-daemon;
*) route - fixed incorrectly handled route distinguisher and route targets (introduced in v7.15);
*) sfp - fixed calculated link length based on EEPROM in certain cases;
*) ssh - improved system stability when SSH tries to bind to non-existing interface;
*) ssh - fixed SSH cryptographic accelerator selection (introduced in v7.14);
*) supout - rename "store" section to "disk";
*) switch - fixed an issue where half-duplex links could occupy Tx resources for 98DX8xxx, 98DX4xxx, 98DX325x switch chips;
*) switch - fixed an issue with Ethernet port group hang for CRS354 devices;
*) system - added "clock" logging topic for time change related messages;
*) system - do not start IPsec and certificate processes when not necessary;
*) system - fixed an issue where routing configuration was missing after performing a reset, adding a new configuration and then upgrading (introduced in v7.15);
*) system - improved reporting of total memory size;
*) tunnel - allow specifying IPv6 LL address as "remote-address" for EoIPv6, GRE6 and IPIP6 tunnels;
*) user - added inactivity timeout for non-GUI sessions;
*) wifi - added "slave-name-format" (CLI only);
*) wifi - adjusted virtual interface naming when provisioning local radios;
*) wifi - do not allow frequency-scan on virtual interfaces;
*) wifi - fixed packet receive when having multiple station interfaces;
*) wifi - fixed signal strength reporting during association (introduced in v7.15) (additional fixes);
*) wifi - improve regulatory compliance for Chateau ax devices;
*) wifi-qcom - add spectral-scan and spectral-history tools (CLI only) (additional fixes);
*) wifi-qcom-ac - count dropped packets to "tx-drop" instead of "tx-error";
*) winbox - fixed false invalid flag under "System/Ports/Remote Access" menu;
*) winbox - moved Switch menu tabs to individual menus (additional fixes);
*) winbox - separated different Watchdog settings into logical tabs;
*) winbox/webfig - fixed skins (introduced in v7.15);
*) wireless - allow unsetting signal-range and ssid-regext properties for capsman access-list (additional fixes);
*) x86 - added missing PCI ids for bnx2x driver;

What's new in 7.16beta2 (2024-Jun-12 12:03):

*) arm64 - increased reserved storage space for bootloader;
*) bgp - fixed BGP sessions missing vpnv6 afi;
*) bgp - fixed cluster-list and originator-id;
*) bridge - fixed typo in filter and NAT error message;
*) chr - added support for licensing over IPv6 network;
*) dhcpv4-server - added "class-id" parameter for DHCP server leases;
*) dhcpv4-server - fixed setting and getting "next-server" property;
*) dhcpv4-server - increased lease offer timeout to 120 seconds;
*) disk - added simple test command to test device and filesystem speeds (CLI only) (additional fixes);
*) disk - improved system stability;
*) dns - added support for DoH with adlist;
*) ethernet - fixed port speed downshift functionality for CRS354 devices;
*) firewall - added message when interface belonging to VRF is added in filter rules (additional fixes);
*) health - improved voltage measurements for RB912UAG-6HPnD device;
*) iot - added an option to delete default LoRa servers and a button to recover them if needed;
*) iot - added an option to log LoRa filtered packets;
*) ip/ipv6 - added multipath hash policy settings;
*) ip/ipv6 - warn user that reboot is required in order to properly apply changes under IP/Settings and IPv6/Settings menus;
*) ipsec - changed default dpd-interval from 2 minutes to 8 seconds and dpd-maximum-failures from 5 to 4;
*) ipv6 - fixed dynamic duplicate address showing when static address is already configured;
*) ipv6 - improved LL address generation process;
*) l2tp - improved system stability;
*) lte - fixed cases where LTE interface would take long time to become ready after bootup for Chateau 5G and Chateau 5G R16 (introduced in v7.15);
*) lte - fixed MBIM modem registration on the network (introduced in v7.16beta1);
*) modem - fixed modem firmware upgrade for Chateau 5G and Chateau 5G R16 (introduced in v7.15);
*) netinstall-cli - added support for multiple device install (additional fixes);
*) poe-out - upgraded firmware for SAMD20 PSE (AF/AT) controlled boards (the update will cause brief power interruption to PoE-out interfaces);
*) ppp - fixed dynamic queue default name (introduced in v7.15);
*) qos-hw - fixed incorrect per-port packet and byte cap (introduced in v7.16beta1);
*) queue - improved system stability;
*) route - fixed memory leak (introduced in v7.15);
*) route - fixed some missing route parameters when printing (introduced in v7.15);
*) routerboot - improved boot process ("/system routerboard upgrade" required);
*) sfp - fixed missing traffic after reboot with S-RJ01 module running at 10/100 Mbps rate on CCR2004-16G-2S+ device;
*) switch - fixed limited Tx traffic on Ethernet ports for CRS354 devices (introduced in v7.15);
*) system - added support for upgrade over IPv6 network;
*) system - improved watchdog and kernel panic reporting (additional fixes);
*) system - reduced RAM usage for ARM64 devices;
*) wifi-qcom - add spectral-scan and spectral-history tools (CLI only) (additional fixes);
*) winbox - added "Switch/QoS" menu for CRS3xx, CRS5xx, CCR2116 and CCR2216 devices;
*) winbox - added "Trace" column under "System/History" menu;
*) winbox - do not show "Last Logged In" and "Expire Password" when creating new system user;
*) winbox - fixed "Authority" property under "System/Certificates/Requests" menu;
*) winbox - fixed error when changing wifi interface settings in some rare conditions (introduced in v7.16beta1);
*) winbox - moved DHCPv6 Server "Allow Dual Stack Queue" property from General to Queues tab;
*) winbox - moved Switch menu tabs to individual menus;
*) wireless - allow to unset signal-range and ssid-regext properties for capsman access-list;

What's new in 7.16beta1 (2024-Jun-05 11:52):

*) bgp - fixed corrupted as-path when received update with empty AS_PATH attribute (introduced in v7.15);
*) bgp - fixed vpnv6 safi;
*) bgp - small logging improvements;
*) bridge - added dynamic tagged entry when VLAN interface is created on vlan-filtering bridge;
*) bridge - added forward-reserved-addresses property which controls forwarding of MAC 01:80:C2:00:00:0x range (separated from "protocol-mode=none" functionality, disabled by default after upgrade);
*) bridge - added max-learned-entries property for bridge;
*) bridge - added message about who created a dynamic VLAN entry;
*) bridge - added MVRP support for VLANs assigned to bridge;
*) bridge - fixed BPDU address when using "ether-type=0x88a8" configuration;
*) bridge - improved system stability when removing MLAG configuration;
*) bridge - show invalid flag for ports that fails to be added to bridge (e.g. maximum port limit of 1024 is reached);
*) certificate - added no-key-export parameter for import;
*) certificate - improved DNS challenge error reporting for Let's Encrypt;
*) certificate - show validity beyond year 2038;
*) console - added "verbose=progress" mode for import status updates, and verbose output only on failures;
*) console - added dry-run parameter to simulate import of files and find syntax errors without making configuration changes (verbose only);
*) console - added limits for dst-start and dst-end clock properties;
*) console - added lock screen via :lock command;
*) console - added uppercase and lowercase transform modes to :convert command;
*) console - disallow ping command with empty address;
*) console - display hint when requesting specific argument syntax;
*) console - do not show default boot-os setting in export;
*) console - fixed negative values for gmt-offset clock property;
*) console - fixed output of ping command in certain cases;
*) console - improve large import file handling, error detection and stability;
*) console - improved :serialize and :deserialize commands and added support for DSV (delimiter separated values) format;
*) console - improved stability when removing script;
*) console - removed follow-strict parameter;
*) console - show rest-api name for active user connections;
*) container - clear VETH address on container exit and mark interface as running only when VETH is in use;
*) detnet - properly detect "Internet" status when multiple detnet instances preset in network;
*) dhcp - improved insert-queue-before, parent-queue and allow-dual-stack-queue behavior;
*) dhcpv4-client - execute script on DNS server or gateway address change;
*) dhcpv4-server - show active-server and host-name in print active command;
*) dhcpv6-client - do not add default gateway twice when both prefix and address is acquired;
*) dhcpv6-client - fixed T1, T2, valid-lifetime and preferred-lifetime compliance with RFC8415 by using value 0;
*) dhcpv6-client - pause client and remove dynamically installed objects while it becomes invalid;
*) dhcpv6-client - release client on failed renew attempt;
*) dhcpv6-client - update gateway address for default route on renew;
*) dhcpv6-server - improved system stability;
*) disk - added simple test command to test device and filesystem speeds (CLI only);
*) dude - fixed map element RouterOS package upgrade functionality;
*) fetch - handle HTTP 401 status correctly;
*) fetch - improved logging;
*) firewall - added message when interface belonging to VRF is added in filter rules;
*) firewall - fixed IPv6 "nth" matcher showing up twice in help;
*) firewall - fixed issue that prevents restoring src-address-list and dst-addres-list properties using undo command;
*) health - fixed board-temperature for KNOT device (introduced in v7.15);
*) health - fixed bogus CPU temperature spikes for CCR2216 device;
*) health - fixed missing health for CRS112-8G-4S device (introduced in v7.15);
*) health - upgraded fan controller firmware to latest version;
*) ike1 - removed unsupported NAT-D drafts with invalid payload numbers;
*) install - fixed ARM64 cdrom install (introduced in v7.15);
*) iot - added LoRa NetID and JoinEUI filtering for LNS and CUPS connections;
*) iot - added LoRa option to filter out proprietary packets;
*) iot - fixed LoRa inability to use variables for GPS-spoofing setting;
*) ip - added max-sessions property for services;
*) ipv6 - fixed pool allocated addresses missing after reboot;
*) ipv6 - respect APN settings for "add-default-route" and "use-peer-dns" also when "accept-router-advertisements=yes";
*) isis - fixed filter-chain and filter-select settings;
*) isis - install IPv6 link-local gateways correctly;
*) l3hw - added per-VLAN packet and byte counters to compatible switches;
*) l3hw - disable L3HW on bonding modes that do not support it;
*) lte - added "sms-protocol" setting in "/interface lte" menu (CLI only);
*) lte - fixed "at-chat" for DELL T99W175 (PID: 0x05c6 VID: 0x90d5);
*) lte - fixed cases where modem could be handled by multiple dialer instances;
*) lte - fixed support for Fibocom modem fm150-na;
*) lte - improvements to "/interface/lte/show-capabilities" command;
*) media - improved file indexing for DLNA;
*) modem - added authentication functionality to EC200A;
*) modem - fixed unresponsive PPP link recovery when TX bandwidth was exceeding link capacity;
*) modem - improved support for KNOT BG77 modem firmware update;
*) mqtt - broker password is no longer exported unless "show-sensitive" flag is used;
*) netinstall-cli - added check for device and package architectures match;
*) netinstall-cli - added support for multiple device install;
*) netinstall-cli - allow mixed package architectures;
*) netwatch - added DNS probe;
*) netwatch - added ttl and accept-icmp-time-exceeded properties for ICMP probe;
*) ospf - improved system stability during LSA monitoring;
*) ovpn - improved system stability;
*) pimsm - improved system stability;
*) poe-out - fixed low-voltage detection while PD is connected for KNOT device;
*) poe-out - fixed silent firmware upgrade fail on CRS112-8P-4S device (introduced in v7.15);
*) poe-out - upgraded firmware for SAMD20 PSE (AF/AT) controlled boards (the update will cause brief power interruption to PoE-out interfaces);
*) ppp - added support for IPv6-only domain names to l2tp-client, ovpn-client and sstp-client;
*) ptp - added PTP support for CCR2116-12G-4S+, CCR2216-1G-12XS-2XQ, CRS518-16XS-2XQ, CRS504-4XQ, CRS510-8XS-2XQ devices;
*) qos-hw - added H and I flags to queues (CLI only);
*) qos-hw - added new monitoring properties for ports and global QoS stats (CLI only);
*) qos-hw - added queue-buffers property to tx-manager (CLI only);
*) qos-hw - allow port print stats, usage and pfc while QoS is disabled (CLI only);
*) qos-hw - allow to set queue-buffers in bytes, percent or auto (CLI only);
*) qos-hw - enabling ECN forces WRED (unless share is disabled);
*) qos-hw - fixed global buffer limits for 98DX8212 and 98DX8332 switches;
*) qos-hw - limit WRED to queues with enabled shared buffers;
*) quickset - removed Basic AP mode;
*) route - added ability to redistribute isis routes;
*) route - place static route in the correct VRF when vrf-interface parameter is used;
*) route - rename route type from is-is to isis;
*) rpki - fixed preference sorting;
*) sfp - fixed SFP28 interface with fec74 mode on CCR2004-1G-2XS-PCIe device;
*) sfp - fixed SFP28 jumbo frame processing on CCR2004-1G-2XS-PCIe device;
*) sms - added polling setting so that RouterOS itself checks SMS instead of relying on URC messages;
*) snmp - added support for KNOT BG77 modem cellular signal info;
*) snmp - fixed LAST-UPDATED format in MIKROTIK-MIB;
*) supout - added detnet section;
*) supout - added monitor command for all wifi interfaces;
*) supout - added netwatch section;
*) supout - added user SSH keys section;
*) supout - increased console output width;
*) supout - limit address-list and connection tracking entries to 999 in supout.rif;
*) switch - fixed Ethernet interface counter 32bit overflow for CRS354 devices;
*) switch - improved system stability on CCR2116-12G-4S+, CCR2216-1G-12XS-2XQ devices;
*) system - added log message if device failed to reboot gracefully;
*) system - added more details to user initiated reboot (reset, upgrade, downgrade);
*) system - do not cancel package upgrade if another architecture packages found on the router;
*) system - do not download packages scheduled for uninstall;
*) system - fixed empty logs after reboot in certain cases;
*) system - improved system stability for RBSXTsq5nD and RBLDF-5nD;
*) system - improved system stability;
*) system - improved watchdog and kernel panic reporting;
*) system - set flash-boot mode as "boot-device" after system reset initiated by reset button ("/system routerboard upgrade" required);
*) system - set flash-boot mode as "boot-device" after system reset initiated from software;
*) user - added inactivity timeout for non-GUI sessions (CLI only);
*) user-manager - updated logo;
*) vxlan - added comment support to VTEPs;
*) vxlan - prevent creating multiple VTEPs with same IP/port combination;
*) webfig - fixed issue with incorrectly applying optional fields;
*) wifi - do not unset radio-mac and master-interface properties on reset;
*) wifi - enable creating virtual wifi interfaces using "copy-from" setting;
*) wifi - fixed signal strength reporting during association (introduced in v7.15);
*) wifi - fixed typo in log message;
*) wifi - improved interface stability when receiving invalid FT authentication frames;
*) wifi - improved WPA3 PMKSA handling when access-lists with custom passphrases are used;
*) wifi - make sniffer tool return an error when attempting to sniff with a radio which does not support it;
*) wifi - use name-format also for local interfaces when provisioning;
*) wifi-qcom - add spectral-scan and spectral-history tools (CLI only);
*) winbox - added "Import Router ID" parameter under "Routing/BGP/VPN" menu;
*) winbox - fixed duplicated "MVRP Attributes" table;
*) winbox - fixed issue with skin file appearing as unknown in user group menu (introduced in v7.15);
*) winbox - fixed signal bar "excellent" tooltip;
*) winbox - removed deprecated x86/CHR specific settings under "System/Resources" menu;
*) winbox - removed spare argument for "PFS Group" property under "IP/IPsec/Proposals" menu;
*) winbox - use CAP serial number with "Set Identity" button under "WiFi/Remote CAP" menu;
*) wireless - allow to unset signal-range and ssid-regext properties for capsman access-list (CLI only);
*) wireless - fixed dynamic VLAN assignments for vlan-filtering bridge in certain cases;
*) wireless - limit antenna-gain property to 100;
*) www - log out inactive REST API users;
*) x86 - added RTL8156 driver support;

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.

phew!!!

when BG--VRF--def-route can be fixed?

Can you please update the Zerotier package if needed.

dude - fixed map element RouterOS package upgrade functionality;

WOW! The Dude in changelog :-)

any chance to implement ANY information with new WIFI CapsMan and SNMP ?

in old wireless capsman, there was at least some basic info, but now ... null

any chance to implement ANY information with new WIFI CapsMan and SNMP ?

in old wireless capsman, there was at least some basic info, but now ... null

Just asked this to support, updated ww2 snmp OID is coming. No ETA.

Damn, I was just thinking the other day how nice it would be to have spectral-history again!
Thank you!

*) firewall - added message when interface belonging to VRF is added in filter rules;

I'm seeing this new warning message "in/out-interface matcher not possible when interface (interfaceXXX) belongs to vrf - use 'vrfXXX' interface instead" even on mangle and nat firewall rules, but I guess this new warning message should only be shown in filter rules that match in/out-interfaces within a VRF instance.

Good to see already one fix for one 7.15 bug

This is the beta with most changes in the 7 series as far as I can see.
And my MQTT support case was fixed :)

...

My adguard container won't start after update , nothing in log, anyone else has problem with containers ?

My adguard container won't start after update , nothing in log, anyone else has problem with containers ?

No problems here on a CCR2116. Six containers (pihole, open-speedtest, samba, uptime-kuma, home-assistant, esphome).

My adguard container won't start after update , nothing in log, anyone else has problem with containers ?

No problems here on a CCR2116. Six containers (pihole, open-speedtest, samba, uptime-kuma, home-assistant, esphome).

I see now whats wrong, update decided to change my usb from USB2 to USB1 so paths are broken, which also some of previous updates changed from USB1 to USB2..

Why is this change happening i wonder?

spectral-scan, wow ... nice ...

*) bgp - fixed vpnv6 safi;

Now I manage to establish the BGP session against the route reflector. However, there are some issues:
- Although the VPNv6 session is established, it does not appear in the remote.afi parameter: - The way the default route is represented is strange:

Was hoping 7.16 to fix roaming issues, but no luck, all worked perfect until 7.15 and new drivers.
My devices keep roaming from 5ghz to 2ghz and thats very next to router under full signal, and often multiple devices roam same time(Samsung s23, LG OLED TV, ASUS tablet).
I already reduced 2ghz to 10 TX which is over 10db difference from 5ghz, dont know what else to do.

*) console - improved :serialize and :deserialize commands and added support for DSV (delimiter separated values) format;

That's going to be useful. Thought I'd provide an example, since I tested it (and works with a couple files at least).

As example script to use them... this takes the product matrix "CSV" from https://mikrotik.com/products/matrix using /tool/fetch. The file is actually a semi-colon separated file, or properly a DSV, and put into a RouterOS array for processing. And show using the newer options=json.pretty to take "DSV" and "pretty print" to JSON as string. All seems to work*.
* the product matrix CSV is oddly formed... so product count has to be adjusted... But [:deserialize] matches exactly Numbers app on MacOS does with same file - so Mikrotik's website download... not the [:deserialize] - which seems work right given the data given

- The way the default route is represented is strange:

It is not strange, it is how it is supposed to be when you send ipv6 routes over ipv4 session. It is ipv4 mapped address.

Still no ipv6 fastpath :/

Was hoping 7.16 to fix roaming issues, but no luck, all worked perfect until 7.15 and new drivers.
My devices keep roaming from 5ghz to 2ghz and thats very next to router under full signal, and often multiple devices roam same time(Samsung s23, LG OLED TV, ASUS tablet).
I already reduced 2ghz to 10 TX which is over 10db difference from 5ghz, dont know what else to do.

If you deactivate 2.4, are the devices able to connect to 5?
I had the same problem and in the end it was my devices fault because they didn't "see" channels above 100.
2.4/5 GHz roaming works great in my case.

It is not strange, it is how it is supposed to be when you send ipv6 routes over ipv4 session. It is ipv4 mapped address.

I expected it to be something like "::/0&52308:1000"

Was hoping 7.16 to fix roaming issues, but no luck, all worked perfect until 7.15 and new drivers.
My devices keep roaming from 5ghz to 2ghz and thats very next to router under full signal, and often multiple devices roam same time(Samsung s23, LG OLED TV, ASUS tablet).
I already reduced 2ghz to 10 TX which is over 10db difference from 5ghz, dont know what else to do.

If you deactivate 2.4, are the devices able to connect to 5?
I had the same problem and in the end it was my devices fault because they didn't "see" channels above 100.
2.4/5 GHz roaming works great in my case.

Roaming works fine for me when I'm at distance of router, but devices close to router are doing stupid things which they didn't before in 7.14 and all versions before.

As I said , devices roam from 5ghz to 2ghz, so yes they can connect, sometimes they are connected for hours then suddenly all roam to 2ghz, it must be router sending something, no way multiple different vendor devices decided to roam same time unless roaming protocol on mikrotik did send something..

This was good too:
It even put comments on in /interface/bridge/vlan on what triggered the "D" dynamic vlan entry there, i.e. "added by pvid", "added by vlan on bridge", ...

sometimes they are connected for hours then suddenly all roam to 2ghz

Ah OK, then maybe it depends on the DFS.
What 5GHz channel are you using?

Was hoping 7.16 to fix roaming issues, but no luck, all worked perfect until 7.15 and new drivers.
My devices keep roaming from 5ghz to 2ghz and thats very next to router under full signal, and often multiple devices roam same time(Samsung s23, LG OLED TV, ASUS tablet).
I already reduced 2ghz to 10 TX which is over 10db difference from 5ghz, dont know what else to do.

USE
WiFi Security -> FT(TAB) --> FT Enabled = YES
Should fix that for you

sometimes they are connected for hours then suddenly all roam to 2ghz

Ah OK, then maybe it depends on the DFS.
What 5GHz channel are you using?

Not using dfs, no radar detects,5220.

Was hoping 7.16 to fix roaming issues, but no luck, all worked perfect until 7.15 and new drivers.
My devices keep roaming from 5ghz to 2ghz and thats very next to router under full signal, and often multiple devices roam same time(Samsung s23, LG OLED TV, ASUS tablet).
I already reduced 2ghz to 10 TX which is over 10db difference from 5ghz, dont know what else to do.

USE
WiFi Security -> FT(TAB) --> FT Enabled = YES
Should fix that for you

Enabled day one.

IS-IS towards Cisco no longer works on ptp , only broadcast

Is anyone can tell slow and unstable autoneg with XL710 already fixed?

IS-IS towards Cisco no longer works on ptp , only broadcast

Also with Huawei not working on p2p Level 2.

Are there any plans to bring features of wifi-qcom-ac on par with wifi-qcom ... the list of differences is growing with every new ROS version ...

Are there any plans to bring features of wifi-qcom-ac on par with wifi-qcom ... the list of differences is growing with every new ROS version ...

Probably not possible without bloating the size of the package, thus causing more problems for devices like hAP ac². wifi-qcom is over 3.5x the size of wifi-qcom-ac.

Still no ipv6 fastpath :/

So sad

USE
WiFi Security -> FT(TAB) --> FT Enabled = YES
Should fix that for you

Enabled day one.

Until Mikrotik decides to provide the correct level of logging for Wifi, and especially roaming/band steering etc. you won't be able to understand what is going on.
And as such won't know what to do and if behavior is correct.
Another missing option is to be able to set steering thresholds etc.

>> I already reduced 2ghz to 10 TX which is over 10db difference from 5ghz, dont know what else to do.

maybe a stupid workaround : allow devices to connect to 2.4GHz only if signal is WEAKER than let's say -75dBm. While it seems like very skewed logic, let me try to explain : you have approx. 10dBm difference between TX Power of 5GHz and 2.4GHz radios. That, together with slighly worse propagation compared to 5GHz, should mean that only devices which are approx. -85dBm signal on 5GHz will roam and stay on 2.4ghz : when "non-warranted" client connects to 2.4GHz (that is, a client that *should not* be connected to 2.4GHz) and the device has signal stronger than -75dBm, it will be rejected by 2.4GHz and it should reconnect back to 5GHz.

When it has -75dBm signal on 2.4GHz, it should have around -85dBm or less on 5GHz. Set this threshold per your local conditions, don't know what throughput you achieve on 5GHz with -80/-85dBm signal, don't know what you have at 2.4GHz/-75dBm. Test it out.

Sure, when such client decides to roam unnecessarily, there will be slight disruption of communication. A network outage. Correct.
The question is, if that makes a real problem for you once in a couple of hours as you said - for me, it would not be any problem at all.

Next option would be to question roaming generally : do you really need that ? Make those networks independent, connect to 2.4GHz only when necessary. Connect low-throughput devices AND DISTANT devices to 2.4GHz (air conditioning units, Alexa, intelligent house appliances...) and keep them there (no roaming at all), dedicate 5GHz for high-throughput / low-latency devices only. Don't roam.

Yeah, but i dont want to do any workarounds when i just can just revert to 7.14.3 and i dont have any problems... Fact is new Qualcomm drivers in 7.15 messed up allot of stuff regarding wireless...

And as i said, i dont have problem at those signal levels, problem is ONLY for devices very next to router, my devices roam from (-30 db 5ghz) to (-20db 2ghz), that is the problem...
Im running 2ghz on 10tx and 5ghz on 24tx now, before on 7.14 i ran 16tx and 22tx and never devices preferred or roamed to 2ghz at such high levels of signal..

USE
WiFi Security -> FT(TAB) --> FT Enabled = YES
Should fix that for you

Enabled day one.

Actually you shouldn't enable FT unless using CAPsMAN and multiple APs...

Enabled day one.

Actually you shouldn't enable FT unless using CAPsMAN and multiple APs...

Not quite. It can also be used for roaming between radios of the same AP provided same SSID is used.

*) l3hw - added per-VLAN packet and byte counters to compatible switches;

That is very interesting!
Where are these values showed? In which cli command branch?
Thanks.

Are there any plans to bring features of wifi-qcom-ac on par with wifi-qcom ... the list of differences is growing with every new ROS version ...

Where such list can be found please? Looked into the docs, not being able to find any. I am just curious, if wifi-qcom-ac still does not allow 4 address (repeater mode), or if it will allow one in future?

Are there any plans to bring features of wifi-qcom-ac on par with wifi-qcom ... the list of differences is growing with every new ROS version ...

Probably not possible without bloating the size of the package, thus causing more problems for devices like hAP ac². wifi-qcom is over 3.5x the size of wifi-qcom-ac.

I wouldn't be so sure about it. I'm pretty sure the main reason for size difference is number of radio chipset drivers included and only minor size difference is due to additional functionality available in wifi-qcom.

Are there any plans to bring features of wifi-qcom-ac on par with wifi-qcom ... the list of differences is growing with every new ROS version ...

Where such list can be found please? Looked into the docs, not being able to find any. I am just curious, if wifi-qcom-ac still does not allow 4 address (repeater mode), or if it will allow one in future?

I don't think MT publishes extensive list of differences. But we all know that there are differences in VLAN tag handling (wifi-qcom-ac doesn't do it at all, wifi-qcom does it to certain extent) and the newly introduced spectral-* tools. It should be enough to check all the changelogs starting with 7.13 (when wifiwave2 got split into 3 parts), I believe that changes between wifi-qcom and wifi-qcom-ac started to accumulate since then, as far as I remember there were numerous entries about wifi-qcom and only very sparse entries about wifi-qcom-ac.

Actually you shouldn't enable FT unless using CAPsMAN and multiple APs...

Not quite. It can also be used for roaming between radios of the same AP provided same SSID is used.

Exactly, i do have CAP and roaming between them works wonderful (HAP AX3(capsman) and HAP AC3(cap)), the problem i described is roaming of devices under same AP interfaces, sometimes they even flap around 2ghz and 5ghz few times in 5mins for no apparent reason, (tv mounted on wall not moving inch and 1m from router...)

*) l3hw - added per-VLAN packet and byte counters to compatible switches;

Where are these values showed? In which cli command branch?

You can now see Tx/Rx byte and packet counters for each VLAN interface when using L3HW for inter-VLAN routing (on compatible switches). These counters are accessible in the Interface List section of WinBox/WebFig or by running specific CLI commands.

Are there any plans to bring features of wifi-qcom-ac on par with wifi-qcom ... the list of differences is growing with every new ROS version ...

Mikrotik doesn't want to touch wifi-qcom-ac for a good reason. The moment they do that complaints will start flowing because of the package size increase and lack of storage. It has been the same size for the past couple releases, but the regular wireless package gets a slimdown again. Spectral scan would be nice as well for anything that has support for wifi-qcom-ac package because that has been on the "to-do list" for almost 10 years for ac chipsets: viewtopic.php?t=89696#p455926

Cool, 10th anniversary is around the corner. 🎉

This was good too:

Code: Select all

*) bridge - added dynamic tagged entry when VLAN interface is created on vlan-filtering bridge;

It even put comments on in /interface/bridge/vlan on what triggered the "D" dynamic vlan entry there, i.e. "added by pvid", "added by vlan on bridge", ...

Ammo, is that a feature that goes with MVLAN.... or whatever the acronym is for automatically adding vlans on trunk ports.

Actually you shouldn't enable FT unless using CAPsMAN and multiple APs...

Not quite. It can also be used for roaming between radios of the same AP provided same SSID is used.

As always, is this something that is inferred or do we have a statement or wiki where this is stated?

I would ask MK (whom I thank for the excellent work he is doing version after version, for once do we want to congratulate the developers? :) ) if in a next version of ROS (or WinBox?) it is possible to add next to a command, a card or button a small guide or explanation.

For example, the FT option once and for all... is it ONLY useful with Capsman or does it actually work even without Capsamn but with the same SSID?

It even put comments on in /interface/bridge/vlan on what triggered the "D" dynamic vlan entry there, i.e. "added by pvid", "added by vlan on bridge", ...

Ammo, is that a feature that goes with MVLAN.... or whatever the acronym is for automatically adding vlans on trunk ports.

Nope. No "vlan sharing" required (MVRP).

It radically simplifies VLAN configurations IMO.

Essentially, you can tick the "vlan-filtering=yes" on fresh config and it won't break anything (since default pvid=1 everywhere). You add a /interface/vlan vlan-id=42 (and ip address/dhcp-server) on the bridge. Then to use it on a port, just set pvid=42 in /interface/bridge/port to untag it. There is NO configuration needed in /interface/bridge/vlan - bridge is tagged on 42 automatically by using /interface/vlan & port's pvid= will also untag. The both happen in "D" dynamic entry in /interface/bridge/vlan – that's visible with print (and, correctly, not in export): VLAN 42 didn't exist anywhere, and bridge has mvrp=no set, and set an active port "/interface/bridge/port set ether10 pvid=42". Above was result. The comments in print aren't mine - they are added by RouterOS. If you have hybrid ports or don't want this... you can still just add "static" (normal) entries for VLAN 42 and do what you want.

Solves the whole "make sure tagged=bridge is in /interface/bridge/vlan". If you set /interface/vlan to listen on the bridge, it does automatically in 7.16beta1. Great work Mikrotik!

*) bridge - show invalid flag for ports that fails to be added to bridge (e.g. maximum port limit of 1024 is reached);

From this line we found out that there is a limit of maximum 1024 ports per bridge!
(now we see that that limit has been added to the documentation on gen 02 2024.)

We have a CCR1072 that we use to terminate a lot of layer 2 FTTH/FTTC lines. So we have a lot of VLAN interfaces that go to a single bridge and then out on an ethernet interface.

Currently the router is working flawlessly and with veeery low CPU usage, but we are approaching this 1024 limit.

Is there any way we can overcome this limit?

Thanks.

@Valerio5000
I already gave you the answer.
But don't believe me.
Test it for yourself.

As always, is this something that is inferred or do we have a statement or wiki where this is stated?

Well, there is a YouTube video by Toms from Mikrotik. He tells us this as a fact.

viewtopic.php?p=1072359#p1072359

And 802.11r is a wireless standard. Of course it would be nice when MT would describe it in detail in their docs for their ROS specialities. But basically it is a standard implemention (by Qualcomm actually; as they use the manufacturer driver)

For ip>media, any chance to add support for sending metadata to the client? miniDLNA does this using NFO files. Otherwise, using a container will still be better.

IPv6 PD over PPPoE still not working. Mixing user prefixes for a while.

Jun/08/2024 08:53:12 dhcp,debug processing client:005056bf3ea9 iapd:0x2
Jun/08/2024 08:53:12 dhcp,debug binding belongs to other server: 005056bf3ea9 xxxx:xxxx:3:3001::/64
Jun/08/2024 08:53:12 dhcp,debug binding not updated
Jun/08/2024 08:53:12 dhcp,debug,packet send <pppoe-user3> -> fe80::16af:edd3:0:2%2d

Running CHR on amazon ec2: 7.15 broke ipv6, but it is working again in 7.16beta1.

lte ep06-e
After the update, the modem does not see the iccid of the SIM card, writes: transmission failed and does not connect

from 7.14 to 7.15 my ssh-exec mode will not authenticate anymore. Ive tried loading a new Pub and Pri key but still no luck.

What changed and will 7.16 introduce a fix or can someone help me out with a fix on it for 7.15?

Can confirm that my devices are now stable for the first time since the ax launch, so thats good news. Ipad Air2
Would be even better if I could fully enable FT on all 4 Radios, I still have to have one Radio with FT Disabled just for the device above.

Where are these values showed? In which cli command branch?

You can now see Tx/Rx byte and packet counters for each VLAN interface when using L3HW for inter-VLAN routing (on compatible switches). These counters are accessible in the Interface List section of WinBox/WebFig or by running specific CLI commands.

Code: Select all

/interface/print stats
/interface/monitor-traffic

While this is partially good news it obviously means no vlan-interface-counters for layer2 traffic only?
Also will those counters be exposed via SNMP?

thx!
hk

What's new in 7.16beta2 (2024-Jun-12 12:03):

*) arm64 - increased reserved storage space for bootloader;
*) bgp - fixed BGP sessions missing vpnv6 afi;
*) bgp - fixed cluster-list and originator-id;
*) bridge - fixed typo in filter and NAT error message;
*) chr - added support for licensing over IPv6 network;
*) dhcpv4-server - added "class-id" parameter for DHCP server leases;
*) dhcpv4-server - fixed setting and getting "next-server" property;
*) dhcpv4-server - increased lease offer timeout to 120 seconds;
*) disk - added simple test command to test device and filesystem speeds (CLI only) (additional fixes);
*) disk - improved system stability;
*) dns - added support for DoH with adlist;
*) ethernet - fixed port speed downshift functionality for CRS354 devices;
*) firewall - added message when interface belonging to VRF is added in filter rules (additional fixes);
*) health - improved voltage measurements for RB912UAG-6HPnD device;
*) iot - added an option to delete default LoRa servers and a button to recover them if needed;
*) iot - added an option to log LoRa filtered packets;
*) ip/ipv6 - added multipath hash policy settings;
*) ip/ipv6 - warn user that reboot is required in order to properly apply changes under IP/Settings and IPv6/Settings menus;
*) ipsec - changed default dpd-interval from 2 minutes to 8 seconds and dpd-maximum-failures from 5 to 4;
*) ipv6 - fixed dynamic duplicate address showing when static address is already configured;
*) ipv6 - improved LL address generation process;
*) l2tp - improved system stability;
*) lte - fixed cases where LTE interface would take long time to become ready after bootup for Chateau 5G and Chateau 5G R16 (introduced in v7.15);
*) lte - fixed MBIM modem registration on the network (introduced in v7.16beta1);
*) modem - fixed modem firmware upgrade for Chateau 5G and Chateau 5G R16 (introduced in v7.15);
*) netinstall-cli - added support for multiple device install (additional fixes);
*) poe-out - upgraded firmware for SAMD20 PSE (AF/AT) controlled boards (the update will cause brief power interruption to PoE-out interfaces);
*) ppp - fixed dynamic queue default name (introduced in v7.15);
*) qos-hw - fixed incorrect per-port packet and byte cap (introduced in v7.16beta1);
*) queue - improved system stability;
*) route - fixed memory leak (introduced in v7.15);
*) route - fixed some missing route parameters when printing (introduced in v7.15);
*) routerboot - improved boot process ("/system routerboard upgrade" required);
*) sfp - fixed missing traffic after reboot with S-RJ01 module running at 10/100 Mbps rate on CCR2004-16G-2S+ device;
*) switch - fixed limited Tx traffic on Ethernet ports for CRS354 devices (introduced in v7.15);
*) system - added support for upgrade over IPv6 network;
*) system - improved watchdog and kernel panic reporting (additional fixes);
*) system - reduced RAM usage for ARM64 devices;
*) wifi-qcom - add spectral-scan and spectral-history tools (CLI only) (additional fixes);
*) winbox - added "Switch/QoS" menu for CRS3xx, CRS5xx, CCR2116 and CCR2216 devices;
*) winbox - added "Trace" column under "System/History" menu;
*) winbox - do not show "Last Logged In" and "Expire Password" when creating new system user;
*) winbox - fixed "Authority" property under "System/Certificates/Requests" menu;
*) winbox - fixed error when changing wifi interface settings in some rare conditions (introduced in v7.16beta1);
*) winbox - moved DHCPv6 Server "Allow Dual Stack Queue" property from General to Queues tab;
*) winbox - moved Switch menu tabs to individual menus;
*) wireless - allow to unset signal-range and ssid-regext properties for capsman access-list;

*) bridge - added dynamic tagged entry when VLAN interface is created on vlan-filtering bridge;

what a mess

i put by hand both WIFI interface as
wifi24 tagged 2,98,100 on br1
wifi58 tagged 2,98,100 on br1

and after first station is connected, no matter on what vlan,
vlan entry are AGAIN dynamically created on bridge with "D" flag, with same ID

cAPGi-5HaxD2HaxD
7.16b1

no, please, don't do this

I greatly appreciate that you have taken my feedback seriously and now label "duplicate" changelog entries with "(additional fixes)". Thank you very much! For reference: viewtopic.php?t=206877#p1075072

Cisco peer will now be happy

Have not tested, but is it possible that...

*) dns - added support for DoH with adlist;

... now also allows type=FWD records (that forward to specific servers) to function with DoH? That's on my wishlist for a long time (and requested in SUP-132300), and would be nice to finally have it.

Awesome update, but a couple of things, all related to webfig.

1) Active Class ID is a new field under /ip/dhcp-server/leases in webfig which is really cool but not listed in the changelog.
2) VLAN packet counters are wrong. It looks like VLAN ID - 1 is counting the total of all egress traffic that comes from any of the VLAN IDs while the appropriate VLAN ID is also showing that traffic. So if VLAN 5 is sending 500MB/s, then VLAN 5 TX will show that traffic (also has an issue outlined in point 3) but VLAN 1 will also have a TX rate equaling to 500MB/s. Only occurs with wireguard traffic (I didn't test with other encryption like ipsec etc), and this traffic is cpu routed only it is never offload nor fasttracked.

3) VLAN TX/RX counters are incorrect when CPU-only traffic is flowing through the VLAN (ingress). The RX of the specific VLAN is correct but for whatever reason the TX shows double of whatever the RX is, when realistically if I am downloading to a device behind VLAN 500 at 2GB/s I expect to see the RX rate at 2GB/s and the TX rate < 10MB/s (maybe 5-10MB/s for tcp ack messages). --- Not a true bug, just the effect of linux and wireguard calculations, maybe?.

EDIT: Point 3 is not a bug or I'm not entirely sure, I realized this only applies to wireguard connections. Point 2 also only applies to wireguard connections, for whatever reason.

...

Have not tested, but is it possible that...

*) dns - added support for DoH with adlist;

... now also allows type=FWD records (that forward to specific servers) to function with DoH? That's on my wishlist for a long time (and requested in SUP-132300), and would be nice to finally have it.

I am waiting for this as well. I did never understood the argument "DoH takes it all no matter what".

CCR1009 RoS v 7.16beta2

Starting with ROS 7.16beta1 and now with RoS v 7.16beta2 my USB disk gets reset. This causes some of my scripts to fail.

Starting with Ros 7.15 Scheduler is still broken as it tries to launch my on STARTUP script ... all the scripts have been tested and have zero errors ... very annoying ...

Yeah something is wrong with disk mounting or something.

On RB1100AHx4, it's had ROSE installed since it was in beta and is my main test box, so it's seen many beta/rc/etc's. Disk/ROSE has never messed up BEFORE... But in 7.16beta1, all containers stopped worked and could not add new ones — figured out it was there was no disk mounts. My RAID1 setup was shown as "unknown" and nothing mounted in files, other the reference to a raid1-part1 disk that should have contained a bunch of files.

I tried upgrading to 7.16beta2, but disk still in "unknown" and not mounted state. Since recovery is not document and there was nothing important on the disk, I figured go to 7.15.1 and just re-create the RAID (since it had been same for as long as ROSE) in "stable" just to sure.

Nope... when I upgrade back to the 7.16beta2: Disks are back in "unknown" state and unmounted. Formatting/setting them up in 7.16beta2 also does not survive a reboot & goes to same "unknown" state (even without a more complex partition scheme I had before): LMK, I can file bug report if needed, but given @mozerd's comments, I'm guess something more generically is wrong in /disk in 7.16beta1/2.

*) poe-out - upgraded firmware for SAMD20 PSE (AF/AT) controlled boards (the update will cause brief power interruption to PoE-out interfaces);

PoE statistics are off by 1 port on beta2. I have only 1 device plugged into ether14, but PoE statistics show on ether15. This is on my CRS354-48p-4S-+2Q+. You can see the log show ether15 powered on PoE and then ether14 showing the link.

LMK, I can file bug report if needed, but given @mozerd's comments, I'm guess something more generically is wrong in /disk in 7.16beta1/2.

Not too sure about that issue being generic.
No disk nor container problems on my RB5009

May I suggest splitting change logs into additions/changes and fixes?

Still not fixed in v7.16beta2

IPv6 PD over PPPoE still not working. Mixing user prefixes for a while.

Jun/08/2024 08:53:12 dhcp,debug processing client:005056bf3ea9 iapd:0x2
Jun/08/2024 08:53:12 dhcp,debug binding belongs to other server: 005056bf3ea9 xxxx:xxxx:3:3001::/64
Jun/08/2024 08:53:12 dhcp,debug binding not updated
Jun/08/2024 08:53:12 dhcp,debug,packet send <pppoe-user3> -> fe80::16af:edd3:0:2%2d

That was the solution up until now. It was not enough for some users. Previously, changes were divided "change in this release" and "other since previous stable".

May I suggest splitting change logs into additions/changes and fixes?

I have never seen this. txfz means "group by". Like:

I have never seen this. txfz means "group by". Like:

Code: Select all

Fixes:

- a
- b

New in this release:

- foo
- bar

Breaking changes:

- baz

Yes! Plese do like that!

Or, at least, mark at the beginning of the line the classification.

Yes, exactly. Not to replace the version specific structure, but to complement it. (probably breaking changes at the top, though)

Ran into two issues:

Issue 1) Upgrading from 7.16beta1 to 7.16beta2 from WebFig caused my CRS518 to crash completely (necessitated a hard power cycle).

Issue 2) After upgrading from 7.16beta1 to 7.16beta2 on my CCR2216, IPv6 prefix delegation configuration disappeared completely; global IPv6 addresses were also not delegating to my VLAN interfaces. Downgrading to 7.15.1 stable restored both the configuration and IPv6 global addresses.

Edit:
Issue 3) On both 7.16beta1 and 7.16beta2 on my CCR2216, it appears that running dual stack (IPv4 and IPv6) and having firewall rules that permit both versions of traffic disables hardware offloading for IPv4. Blocking all IPv6 traffic with a simple firewall rule (but leaving the IPv6 addresses in place) restores hardware offloading for IPv4. Definitely an odd behaviour.

LMK, I can file bug report if needed, but given @mozerd's comments, I'm guess something more generically is wrong in /disk in 7.16beta1/2.

Not too sure about that issue being generic.
No disk nor container problems on my RB5009 :?

Perhaps. It may be specific to ROSE + RAID in my case.

I narrowed down the issue after several reboot, re-formats, etc. Turn out the raid'ed hardware disks (sata1 and sata2) lose their "raid-master=raid1" settings. So adding the "lost setting" back manually restores the raid (without data loss). But this seems to be needed after EVERY REBOOT of v7.16beta2 - so not just after upgrade:
It might be a timing issue. I added those the settings now to a "startup" scheduler...but took adding a ":delay 2s" before them for it to work.

Code: Select all

Fixes:

- a
- b

New in this release:

- foo
- bar

Breaking changes:

- baz

Yes! Plese do like that!

Or, at least, mark at the beginning of the line the classification.

+1

2024/06/15 12:29:41.394275 [fatal] writing config file: write /opt/adguardhome/conf/.AdGuardHome.yaml9142876731003399955: no space left on device

Container doesn't start after beta 2, I got 27gb free on usb...

EDIT:Update again messed up paths and keeps changing my only one usb from usb1 to usb2..

It would be better when all the "What's new" entries were actually put in a database, with each entry having besides the
condensed line shown here on the forum also having a more descriptive paragraph, a pointer to changed documentation,
the subsystem, a version number where the fixed bug first appeared, etc.
Then there would be a webpage where you can enter an existing and new version and you get all relevant changed between
those versions (limited to a subsystem when you also specify that). It would omit the lines for bugs that were introduced
and fixed between the versions you query (so query between 7.14.3 and 7.16beta2 would not list "introduced in 7.15" bugs).
Each entry would have a "hover" text or linked page showing the more descriptive text when available.
This same query could be made from the webfig or other UI when "update is available", just direct to the webpage with the
relevant versions. Some work to setup, but saves a lot of questions from customers so also saves time at the support department.

RouterOS version 7.16beta has been released on the "v7 testing" channel!

https://mikrotik.com/product/product_ge ... 3_16_41_07

After upgrading to 7.16beta[1-2] I have two LTE interfaces instead of a single LTE interface on RBLHGGR...?

This behaviour is only visibile after upgrading to the 7.16beta[1-2] series ROS. (from 7.14.3/7.15.1)

Have not tested, but is it possible that...



... now also allows type=FWD records (that forward to specific servers) to function with DoH? That's on my wishlist for a long time (and requested in SUP-132300), and would be nice to finally have it.

I am waiting for this as well. I did never understood the argument "DoH takes it all no matter what".

Would also like this functionality.

Whitelist would be the obvious next item for "basic" blocklist functionality.

On this beta the switch menu is present in CHR please hide it just like with the previous CHR version

Updated CRS354-48P-4S+2Q+ from 7.15.1 to 7.16beta2 because of ethernet port issues (Download speed is limited to 10 Mbps)

In result on 7.16beta2 several ethernet ports have some issues with PoE - can't power the devices. The devices are High voltage PoE and can randomly stop working. Reverted back to 7.15.1 - all PoE devices are working again, but having issues again with the port speed.

7.16b2

lots of SNMP errors
SNMP engine sometime stop and won't start until reboot, or disable/enable snmp
cAPGi-5HaxD2HaxD

CHR ARM on Hetzner can't detect full disk size - viewtopic.php?t=207658

look at the units, GB is not the same as GiB. Disk size is detected properly if you convert form GiB to GB

We have 2 VM's and both with 40GB disks.

On x86 CHR show 37.9GiB, on arm64 CHR show 9.0GiB - shouldn't they show same value in both cases?

We have 2 VM's and both with 40GB disks.

On x86 CHR show 37.9GiB, on arm64 CHR show 9.0GiB - shouldn't they show same value in both cases?

Maybe this is something you should discuss with Hetzner, after all it is their virtual platform...
On the other hand do you really need more than 9GB for CHR?

But he pays for 40gib :D

bratislav, perhaps more storage for container purposes.

Note that enabling container support (device mode) requires additional steps: viewtopic.php?t=206877#p1072366

stmx38, you can expand the filesystem manually in Hetzner rescue console:


Relevant issue: SUP-151589 CHR auto expansion failed & bad disk image on Hetzner Cloud arm64 instance

nescafe2002, thanks - that works.

But why enabling Containers is so hard on ARM, is it one more bug?

CHR x86 works with just "Power cycle" button.

I would say it is a bug in Hetzner VM installation procedure, on x86 it automatically extends file system for given image to full HDD size, on ARM is does not so you have to do it manually...

I would say it is a bug in Hetzner VM installation procedure, on x86 it automatically extends file system for given image to full HDD size, on ARM is does not so you have to do it manually...

This was a RouterOS bug, and will be fixed in next version. Resize was 1/4 from actual size

Was hoping 7.16 to fix roaming issues, but no luck, all worked perfect until 7.15 and new drivers.
My devices keep roaming from 5ghz to 2ghz and thats very next to router under full signal, and often multiple devices roam same time(Samsung s23, LG OLED TV, ASUS tablet).
I already reduced 2ghz to 10 TX which is over 10db difference from 5ghz, dont know what else to do.

Have you tried to reduce tx power on 5 GHz instead of 2,4 GHz to see how that would affect the situation? There is a possibility that high signal level (near the router as in this case) can saturate the the radio on client device causing unpredictable behaviour....

Please add a "Client MTU" option to wireguard peer configuration page, in order to set the MTU value in some occasion。

It is possible to add [2.5G baseX] in SFP Supported based on Linux sfp-bus.c#L327
Here address that indicate 2500baseX on SFP I2C:
Address: 0x06, Value: 0x00
Address: 0x0c, Value: 0x1F

Currently, Mikrotik detect these value as 10G baseSR LR which is wrong.

It would be nice if auto neg to 2.5G baseX when SFP has this: 0x06@0x00 & 0x0c@0x1F

Please add a "Client MTU" option to wireguard peer configuration page, in order to set the MTU value in some occasion。

The interface MTU is device local. "Client MTU" must be set on the client side.

For it to be part of the "Client Config" (that can be copy-paste) provided under Wireguard > Peers > Wireguard Peer to another device. This would indeed be a need solution. Rather. Just copy the MTU value of the WG interface configured under Wireguard > Wireguard directly to the example client config shown for the individual Wireguard Peer. The Client MTU should not be ale to be set differently than the parent Wireguard interface.

Please add a "Client MTU" option to wireguard peer configuration page, in order to set the MTU value in some occasion。

The interface MTU is device local. "Client MTU" must be set on the client side.

For it to be part of the "Client Config" (that can be copy-paste) provided under Wireguard > Peers > Wireguard Peer to another device. This would indeed be a need solution. Rather. Just copy the MTU value of the WG interface configured under Wireguard > Wireguard directly to the example client config shown for the individual Wireguard Peer. The Client MTU should not be ale to be set differently than the parent Wireguard interface.

There's room for improvement in that menu. AllowedIPs was requested before, official answer 'till now was "edit it manually on the client", well that's not the point of having a qr / config generator in the first place if you still have to dig into the config to tweak missing pieces, is it?
If it was me, I'd also move the entire "client config" section (that's only used for generating the client qr/config) to another tab on the selected peers menu.

If it was me, I'd also move the entire "client config" section (that's only used for generating the client qr/config) to another tab on the selected peers menu).

+1 - it is nice feature but really confusing if you don't know. If on another tab... it both be easy to have some add'l WG attributes like allowedip, mtu, or whatever & be way clear what these "Client Xxxxx:" things are used for. i.e. official WG clients only let you edit (or paste) a config file, so being able to just cut-and-paste all the right WG keys+config from RouterOS is pretty handy to setup a new peer.

I'm running into the "client was disconnected because could not assign vlan".
Is this due to the fact I'm running hybrid (both wifi-qcom and wifi-qcom-ac? Didn't have this with an wifi-qcom-ac only environment.

Yes, I'm using FT. Would setting ft-preserve-vlanid to yes make sense in this case?
Or is it related to the existing accesslist (rejecting clients below thresshold)?

I noticed that clients also get an IP address of the untagged assigned VLAN ID DHCP server and the correct VLAN ID DHCP server (both management and corporate).

I'm running into the "client was disconnected because could not assign vlan".
Is this due to the fact I'm running hybrid (both wifi-qcom and wifi-qcom-ac? Didn't have this with an wifi-qcom-ac only environment.

I ran into the same issue at home this week when installing wAP AC using wifi-qcom-ac drivers in capsman environment.
For that device you need to set ft-preserve-vlanid to NO (open it in Winbox and leave it blank).

Thanks @holvoetn, will try this later today.

Update: Yes, this is indeed solving the issue I had.

CCR1009 RoS v 7.16beta2
Starting with Ros 7.15 Scheduler is still broken as it tries to launch my on STARTUP script ... all the scripts have been tested and have zero errors ... very annoying ...

The issue with the scheduler is now solved. The first script in the “startup” chain had a delay of 10 seconds … apparently this was not enough time cause when RoS reboots the interfaces do not initialize within that time delay so the dynu scrip generates an error condition that it cannot find the pppoe interface - and that kills scheduler from proceeding … I increased the delay to 15 seconds and this time all the scripts completed their tasks … picking 15 seconds was just a random number … when I have time I play with the time element by increments of 1 second and see if I can shorten the delay.

I actually consider it a bug that the startup script (just like the "run after reset" script that can be specified in a reset-configuration) is being run before the router finishes initialization.
In the past it has caused me much hair-pulling when I wanted to reinitialize a router, doing an export, some editing, and then reset-configuration with run-after-reset. Some interfaces (like wireless) not yet present and the script is failing.
There the workaround is "insert a delay" too, but that kind of kludges should not be necessary.

There the workaround is "insert a delay" too, but that kind of kludges should not be necessary.

Yes I agree with your assessment — that it’s a bug …

What's new in 7.16beta3 (2024-Jun-27 08:33):

*) 6to4 - fixed 6to4 tunnel LL address generation after system reboot;
*) 6to4 - limit keepalive timeout maximum value;
*) 6to4 - make "remote-address" parameter mandatory;
*) address - added "S" flag for addresses that belong to a slave interface;
*) arm64/x86 - added rtl8111/8168/8411 firmware;
*) bridge - added L2 MDB support for switch chips with HW offloaded IGMP snooping;
*) bridge - do not allow duplicate ports;
*) bth - improved system stability;
*) certificate - added support for cloud-dns challenge validation for sn.mynetname.net (CLI only);
*) certificate - automatically parse uppercase symbols to lowercase when registering domain on Let's Encrypt;
*) chr - fixed incorrect disk size for ARM64;
*) console - added additional byte-array option to :convert command;
*) console - fixed an issue where certain MAC address can be interpreted as time value;
*) console - fixed typo in firewall error message;
*) console - improved stability when pasting a large input;
*) defconf - configure the default-route property for PPP clients only on devices with a built-in modem;
*) dhcp - added comment property for matchers, options and option sets;
*) dhcpv4-server - added matcher ability to match substring;
*) dhcpv4-server - added name for "User-Class" option (77), "Authentication" option (90), "SIP-Servers-DHCP-Option" option (120) and "Unassigned" option (163-174) in debug logs;
*) dhcpv6-client - release client on failed renew attempt (additional fixes);
*) discovery - added LLDP Port VLAN ID, Port And Protocol VLAN ID, VLAN Name TLVs support;
*) discovery - added LLDP-MED timeout;
*) discovery - set unknown bit for any unspecified link type in MAC/PHY TLV;
*) disk - added log message when disks get added or removed;
*) dns - added support for DoH with static FWD entries;
*) dns - added support for mDNS proxy (CLI only);
*) dns - refactored DNS service internal processes;
*) firewall - removed unnecessary TLS host matcher from NAT tables;
*) health - removed unnecessary health settings for RB921 and RB922 devices;
*) install - allow to save old configuration during cdrom install;
*) iot - added an option to log LoRa filtered packets (additional fixes);
*) iot - added LoRa option to filter out proprietary packets (additional fixes);
*) ipip6 - make IPv6 LL address random;
*) ipsec - improved performance by balancing multicore CPU usage;
*) ipv6 - added "d" deprecated flag for expired IPv6 SLAAC addresses;
*) ipv6 - allow to properly disable address when it is generated from pool;
*) ipv6 - allow to properly move IPv6 address from slave interface to a bridge interface;
*) ipv6 - do not allow adding address with invalid prefix when using pool;
*) ipv6 - do not allow to manually delete LL address;
*) ipv6 - fixed "no-dad" functionality;
*) ipv6 - fixed SLAAC address dynamic appearance;
*) ipv6 - properly initialize default ND "interface=all" entry;
*) ipv6 - warn user that reboot is required in order to properly apply accept-router-advertisements changes;
*) leds - fixed system LED to indicate correct RAT for Chateau (introduced in v7.16beta1);
*) lte - fixed modem dialer disable for Chateau 5G devices when cellular modem support mode set to serial (introduced in v7.16beta2);
*) lte - improved system stability for MBIM modem during AT query (introduced in v7.16beta1);
*) modem - fixed cases where USB bus could switch places (introduced in v7.16beta1);
*) modem - fixed modem firmware upgrade for Chateau 5G and Chateau 5G R16 (introduced in v7.15) (additional fixes);
*) netwatch - use time format according to ISO standard;
*) port - added IPv6 support for the "remote-access" feature;
*) ppp - automatically generate IPv6 firewall rules when filter-id is specified;
*) profiler - classify wifi processing as "wireless";
*) rose-storage - fixed "/file sysnc status" parameter to be read-only;
*) rose-storage - moved "/rsync-daemon" to "/file rsync-daemon;
*) route - fixed incorrectly handled route distinguisher and route targets (introduced in v7.15);
*) sfp - fixed calculated link length based on EEPROM in certain cases;
*) ssh - improved system stability when SSH tries to bind to non-existing interface;
*) ssh - fixed SSH cryptographic accelerator selection (introduced in v7.14);
*) supout - rename "store" section to "disk";
*) switch - fixed an issue where half-duplex links could occupy Tx resources for 98DX8xxx, 98DX4xxx, 98DX325x switch chips;
*) switch - fixed an issue with Ethernet port group hang for CRS354 devices;
*) system - added "clock" logging topic for time change related messages;
*) system - do not start IPsec and certificate processes when not necessary;
*) system - fixed an issue where routing configuration was missing after performing a reset, adding a new configuration and then upgrading (introduced in v7.15);
*) system - improved reporting of total memory size;
*) tunnel - allow specifying IPv6 LL address as "remote-address" for EoIPv6, GRE6 and IPIP6 tunnels;
*) user - added inactivity timeout for non-GUI sessions;
*) wifi - added "slave-name-format" (CLI only);
*) wifi - adjusted virtual interface naming when provisioning local radios;
*) wifi - do not allow frequency-scan on virtual interfaces;
*) wifi - fixed packet receive when having multiple station interfaces;
*) wifi - fixed signal strength reporting during association (introduced in v7.15) (additional fixes);
*) wifi - improve regulatory compliance for Chateau ax devices;
*) wifi-qcom - add spectral-scan and spectral-history tools (CLI only) (additional fixes);
*) wifi-qcom-ac - count dropped packets to "tx-drop" instead of "tx-error";
*) winbox - fixed false invalid flag under "System/Ports/Remote Access" menu;
*) winbox - moved Switch menu tabs to individual menus (additional fixes);
*) winbox - separated different Watchdog settings into logical tabs;
*) winbox/webfig - fixed skins (introduced in v7.15);
*) wireless - allow unsetting signal-range and ssid-regext properties for capsman access-list (additional fixes);
*) x86 - added missing PCI ids for bnx2x driver;

finally we can test anycast now and mDNS proxy this is awesome any docs?

*) dns - added support for mDNS proxy (CLI only);

OMG it is what I think is? mDNS repeater trough VLANs?

yes, real mDNS repeater. Very simple config, just add interfaces and enable.

What's new in 7.16beta3 (2024-Jun-27 08:33):

*) bridge - added L2 MDB support for switch chips with HW offloaded IGMP snooping;

Am I right that this is Hardware Multicast support ?

This update enhances the existing hardware multicast support. Now, you can create static multicast group entries using MAC addresses, for example: Although it may not be very useful right now, it could become helpful in the future when you need to use dynamic multicast groups with MAC addresses instead of IPs from IGMP.

yes, real mDNS repeater. Very simple config, just add interfaces and enable.

I found /ip dns mdns-repeat-ifaces but overlooked "enable". Can you please give a hint? Thanks.

Hi there,

I'm using DNS FWD entries and usually could ping to a FQDN for those FWD entries from the terminal. This is not working anymore in 7.16. Please fix it, it is really useful.

ping portal.test.internal
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
while resolving ip-address: name does not exist

Thank you!

My DoH stopped working when I updated to 7.16_beta3 from beta2
I didn't reboot my router since adding the DoH function last week so it might be that. To correct the problem I had to add 1.1.1.1 to Servers My previous setting was just adding the following to static, thoughts please.

Static
cloudflare-dns.com
104.16.249.249
cloudflare-dns.com
104.16.248.249

Rolling back the dns is shit

Ok, rolled back with my old settings, all works fine!

Mikrotik ??

yes, real mDNS repeater. Very simple config, just add interfaces and enable.

I found /ip dns mdns-repeat-ifaces but overlooked "enable". Can you please give a hint? Thanks.

You just need to specify the interface where mDNS should be "shared".
There is no enable, just add the interfaces.

But "disable"... there is should be a "reset" in /ip/dns to do it, but isn't. But using an empty string will "disable" it:

Had to revert to 16.2 due to WireGard not starting. It looked like Current Endpoint could not retrieve static DNS entries. Looking in the cache table the IP was present for the static DNS entry.

I had the same issue with WG DNS endpoints. Maybe this drop has the "overhauled" DNS?

...just add interfaces and enable.

Humm... A new feature, and it already comes without support to Interface-Lists.

😭

Maybe this drop has the "overhauled" DNS?

"overhauled" DNS already makes me shiver...

Yeah, it looks like the people who managed the “refactored DNS service internal processes” didn't carry out the most basic tests. It makes me wonder if they're even conducting CI/CD pipeline test automation at all..

I would have cheered when the changelog line was "changed DNS resolver to unbound" but unfortunately that does not seem to be what is happening...
That resolver includes an elaborate regression test set and -tool in the source code. Those guys know why that is important for DNS resolvers...

And it seems like making /ip/dns VRF-aware in 7.15 according to https://download.mikrotik.com/routeros/7.15/CHANGELOG is still broken in 7.16beta3 :-(

I am assuming that the mDNS feature requires that the Firewall allows inbound on all the relevant interfaces for udp port 5353 for IP packets addressed even if addressed to 224.0.0.251 ?

@Apachez are you the same Apachez on VYOS forum, if you are I'm glad you are here too

*) 6to4 - make "remote-address" parameter mandatory;

In other words, you're dropping support for RFC 3056. Because that needs unspecified remote address. Is it intentional?

I know that the whole thing is not very popular. Accompanied RFC 3068 is even deprecated. I'm probably one of the few who still use it (not with v7, because attempting to do so crashes it; SUP-97719). I'll (have to) survive without it, but I was hoping that you would eventually fix it, since you broke it (it works fine in Linux), and it might still be useful for someone.

Static DNS querying will be fixed in the upcoming RouterOS beta release. Please remember - this is beta. Released for testing new features and fixes. Some services might not work properly, and these version should not be used on important routers. As for the DoH - we are looking into this and will update later on.

In IPv6 my VLANs no longer show up dynamically under ND - only the bridge. Do I need to add them manually and the global addresses and routes? I moved from 7.15.2 stable to 7.16beta3.

Static DNS querying will be fixed in the upcoming RouterOS beta release. Please remember - this is beta. Released for testing new features and fixes. Some services might not work properly, and these version should not be used on important routers. As for the DoH - we are looking into this and will update later on.

I have had my issues where the /ip/dns VRF-awareness is failing for both the stable 7.15.1 and 7.15.2 aswell as the 7.16beta2 and 7.16beta3.

Dear MikroTik team, please do not take this negatively. This is well-intentioned advice. There is a quote that even beta releases are tested by thousands of automated tests (viewtopic.php?t=208346#p1080582). Then a beta version appears with a DoH that cannot work at all - due to a dead-lock situation (static DNS entries are ignored, but DoH domains must be resolved to IP). No one tested this - not even manually. And it is not that a bug occurred somewhere one would say: "woah, that is pretty weird that this change broke unrelated functionality X". No, the feature in changelog itself was not working as intended. It would be so wise and positive to cover new features with corresponding tests! Software quality would increase dramatically! It is clear that it is almost impossible to retrospectively cover an entire ROS with automated tests; with all possible configuration options, it would be an absurd amount of effort, and probably not all cases would be covered still. But as mentioned: when adding new features, it is certainly advisable to have the basic functionality of the feature covered by a few tests.

@Apachez are you the same Apachez on VYOS forum, if you are I'm glad you are here too

Yup, thats me! (failed to find how to send you a DM so the reply is public instead).

This was brought up in a previous thread, but here is my proposal for formatting the change logs. Add and adjust headers as necessary.

7.16beta1 (2024-06-05 11:52)

Changes

• supout - added netwatch section

Fixes

• route - fixed memory leak (introduced in v7.15);

Rolling back the dns is shit

This is a beta version, not a production version.
Using beta in production are just asking for trouble.
If you have error, report it and it many be fixed.

Yeah sure, but bugs in the DNS resolver are often complex and difficult to hunt down, I have already wasted way too much time on them.
I already made a mental note: skip 7.16 upgrades until at least 7.16.2 is released....

I am assuming that the mDNS feature requires that the Firewall allows inbound on all the relevant interfaces for udp port 5353 for IP packets addressed even if addressed to 224.0.0.251 ?

Yes that's correct. If your firewall drops the udp multicasts on the input chain, the mDNS proxy will not see the traffic and thus does not repeat anything.

*) dns - added support for DoH with static FWD entries;
*) dns - added support for mDNS proxy (CLI only);

These are both so exciting!

I am assuming that the mDNS feature requires that the Firewall allows inbound on all the relevant interfaces for udp port 5353 for IP packets addressed even if addressed to 224.0.0.251 ?

Yes that's correct. If your firewall drops the udp multicasts on the input chain, the mDNS proxy will not see the traffic and thus does not repeat anything.

So does the firewall rule need to allow 5353udp on the forward chain or the input chain?

*) dns - added support for DoH with static FWD entries;
*) dns - added support for mDNS proxy (CLI only);

So does the firewall rule need to allow 5353udp on the forward chain or the input chain?

AFAIK, repeated mDNS via input (or output) chain (NOT forward) since it's a local process in Packet Flow diagrams.

Keep in mind mDNS is just IP name resolution... So if the interface involved in mDNS repeating have firewall rules between them, you'd have to allow any protocols used by mDNS devices, in addition to 5353/udp. For example, while allowed 5353/udp is going to let you see printers/etc, if the IPP port isn't also opened (via "forward" chain)... mDNS discovery isn't going to help to print without IPP being allowed too.

If VLANs/interfaces using by mdns-repeat-ifaces= are just in the "LAN" interface-list, then the default firewall should allow repeating and protocol used. Now...If inter-VLAN routing is restricted, then you need firewall rules – both for mDNS 5353/udp & what ever protocol the discovered devices use too.

Very excipted to finally see this:

*) dns - added support for DoH with static FWD entries;

Thanks a lot, Mikrotik!

Anyway... This does not (yet) work for me.

Though... Even disabling DoH does not help here, the forwarding does not work as expected. I think I have the regular expression right, so wondering what's the deal here. Anybody else?

This is really scary whenever someone from the dev enhancing the DNS code base one way or another they always broke the dns resolver, can you just adapt other code base like tinydns/dnscache from djb or any reputable alternatives so that you can concentrate on more pressing issues and do what you do best?, this is a recurring issues and the code is very fragile so to speak

Does the mDNS proxy handle multiple VLANs - not just two? How do I remove it if I decide to implement later instead?

@loloski @eworm yes, and now you/we are lucky because it does not work at all, a clear state. but once those bugs are fixed we again risk to be in the situation were it seems to work but it fails in all kinds of border cases, as happened several times before. a sad situation...

This is really scary whenever someone from the dev enhancing the DNS code base one way or another they always broke the dns resolver ... this is a recurring issues and the code is very fragile so to speak

and

... now you/we are lucky because it does not work at all, a clear state. but once those bugs are fixed we again risk to be in the situation were it seems to work but it fails in all kinds of border cases, as happened several times before. a sad situation...

This version of RouterOS is marked as beta software. Such breaking issues are to be expected, usually one should expect far worse issues considering it's a beta (regardless of the manufacturer), and one shouldn't run such software in production eg. you should run bleeding edge software only on devices for which critical issues that cause downtime are acceptable.

If you are running beta versions on mission critical boxes where a box failing to boot causes real harm, you should re-evaluate your update preferences and use stable versions instead. That is the reason stable releases exist after all. The idea of a beta software is to surface these critical issues so that they do not end up in stable.

But at the same time these "betas" fixes critical errors found in the "stable" releases - which gives?

Should I use a "stable" release who is more broken than the "beta" release who is just slightly broken? Which one would you recommend to be used in production?

But at the same time these "betas" fixes critical errors found in the "stable" releases - which gives?

Should I use a "stable" release who is more broken than the "beta" release who is just slightly broken? Which one would you recommend to be used in production?

It is totally possible for stable releases to have issues as well: no software release is perfect. However the difference is that beta software is expected to have critical issues, while stable software is not. What I'm after is that it is totally acceptable for beta software to have major issues and while these should of course be relayed to the manufacturer and fixed, also avoided by the manufacturer in the first place to the best of their abilities, it seems odd to complain about such issues existing when the expectation is that there are going to be such issues indeed. I'd understand complaints of bad quality if a stable version failed to boot due to some trivial issue, or the DNS refactoring in question was sent to stable as-is, however in beta such a thing is the norm.

Generally manufacturers (MikroTik included) backport fixes first tested in beta versions to the stable versions. These are the minor RouterOS releases you see on the stable branch (eg. 7.15.2). Why do they usually end up in beta first? Bugfixes need to be tested just like any other change to ensure they do not cause more serious bugs. This process may be expedited if the bug in question is a severe one, however expediting requires factoring in the risk and benefit ratio of the process. It's a balance.

Now back to your original question: Should I use a "stable" release who is more broken than the "beta" release who is just slightly broken? In exceptional cases with serious issues in stable using beta might make sense, however most of the time the issues uncovered in stable are relatively minor and urgent fixes will be expedited anyways. So once in a blue moon would be my answer.

This is of course a balance of personal risk factors similar to the one the manufacturer performs. For one I run beta versions "in production" for my home internet when at home, because the risk of running a beta version for me is the 15 minutes it'll take to downgrade my home router to a stable version if so required. Thus in my personal case the benefits of running beta outweigh the risk.

Would I make the same choice for an office with say 20 or 100 employees on a Monday? No way and neither if I didn't have physical access to the device. This comes from past experience of having to drive 4 hours in total to the datacenter and back in order to reboot a router. Learned my lesson.

Couldn't this be solved by creating "long term" or "mature" branch which would only contain final versions of previous stable branches - which would currently be 7.14.3 (or 7.14.4 for clarity) and final version of 7.15 branch when 7.16 comes out as stable release?

This is obviously far from a perfect solution but still significantly better option than current absence of this option...

This version of RouterOS is marked as beta software. Such breaking issues are to be expected, usually one should expect far worse issues considering it's a beta

Well, after MikroTik being in the field of router software development for nearly 30 years we could kind of expect that the developers have gotten around to setting up some automated test environment that runs a series of regression tests before even a beta release hits the download servers.
That test set would contain tests for basic functionality, and also for any problems that have been found and fixed in the past.
Even when not all tests are run at every beta release (it may take too much time), one would at least expect the tests for any features that have been modified (in this case: the DNS resolver) to be run.
When beta versions can go out with such issues, at what point in time will the tests be done that make the "stable" version go out without them? Or are "we" (the users) supposed to do the testing?

Well, after MikroTik being in the field of router software development for nearly 30 years we could kind of expect that the developers have gotten around to setting up some automated test environment that runs a series of regression tests before even a beta release hits the download servers.

They most likely have such tests for previously identified regressions. New features are new, for a regression test to be written a regression first has to happen: either in the MikroTik internal alpha testing phase or the public beta testing phase like here.

That test set would contain tests for basic functionality, and also for any problems that have been found and fixed in the past.

Exactly, this DNS functionality is novel on RouterOS and thus these problems have not been found and fixed in the past. If they had been why would MikroTik intentionally ship bugs (without marking them as known issues)? The issues concerning this beta version may have been uncovered in this thread for the first time ever.

When beta versions can go out with such issues, at what point in time will the tests be done that make the "stable" version go out without them?

Such tests are usually ready in the release candidate phase. As the release candidate is a candidate for stable unless new issues are discovered in brief period of running a release candidate. So stable release by definition is the point in time where the tests have been done for the release to be made without these bugs present anymore. Of course this doesn't guarantee that all bugs were found.

If I had to criticize MikroTik's processes I'd point out that new features probably shouldn't be added in the release candidate phase like they commonly do. However release candidate might just be the public facing name of these releases and internally such features might have been in testing for a long time, so it's hard to tell.

Or are "we" (the users) supposed to do the testing?

Yes! That is the very definition of beta software and the reason beta versions exist in the first place. If MikroTik wouldn't like the community to help test unstable versions, they would not do beta releases: preparing such releases for no benefit would be a waste of time and effort.

Couldn't this be solved by creating "long term" or "mature" branch which would only contain final versions of previous stable branches - which would currently be 7.14.3 (or 7.14.4 for clarity) and final version of 7.15 branch when 7.16 comes out as stable release?

Long-term releases already exist for RouterOS, however the branch lags behind in features by a lot (as is to be expected). Right now the long term tree has yet to be updated to RouterOS 7+ for example. I'd guess the users of long-term releases have some very mission critical installations or they just want the peace of mind of not having to worry about updates as much.

The beta versions are released in order to find the bugs! The more, the better. That is the whole point of betas - find issues before the stable releases. Otherwise we would not release them at all. You should use betas if you agree to risk and help for us to find issues of different kind of sets of configuration combinations. So to sum up - the goal is reached every time you report that something is not working as expected!

Beta should be used when something is not working for you and you see a fix in changelog which might help - see if it does. Or if you want to test a new feature and comment if it is working as you might expect.

Please keep this topic related to 7.16 features and fixes, not the version release concept.

If you gave a little more detail on new things, people might try them. i.e.

*) ip/ipv6 - added multipath hash policy settings;

Does "l4" mean ports/protocols? Does it work with static ECMP routes, or only some/all routing protocols?

Update: F1 does work here, that's progress.

l3 -- layer-3 hashing of src IP, dst IP
l3-inner -- layer-3 hashing or inner layer-3 hashing if available
l4 -- layer-4 hashing of src IP, dst IP, IP protocol, src port, dst port

If you gave a little more detail on new things, people might try them. i.e.

Especially how new things **should** work. So one can spot a bug eventually. E.g. mDNS proxy put up some questions.

If you gave a little more detail on new things, people might try them. i.e.

It is in the manual:
https://help.mikrotik.com/docs/display/ ... CMP)routes

Fair enough. Since I use ECMP, this a great.

More that you might get more testers if they knew what to test. ;) Load balancing is always a topic. The practical effect of new "/ip/settings/set ipv4-multipath-hash-policy=l4" means there is no downside to using ECMP/routing approach over PCC/firewall approach for LB. Since IMO ECMP is WAY easier to setup, the subtle "added multipath hash policy settings" may not garner a lot of testers of it.

Well, after MikroTik being in the field of router software development for nearly 30 years we could kind of expect that the developers have gotten around to setting up some automated test environment that runs a series of regression tests before even a beta release hits the download servers.

They most likely have such tests for previously identified regressions. New features are new, for a regression test to be written a regression first has to happen: either in the MikroTik internal alpha testing phase or the public beta testing phase like here.

That test set would contain tests for basic functionality, and also for any problems that have been found and fixed in the past.

Exactly, this DNS functionality is novel on RouterOS and thus these problems have not been found and fixed in the past. If they had been why would MikroTik intentionally ship bugs (without marking them as known issues)? The issues concerning this beta version may have been uncovered in this thread for the first time ever.

When beta versions can go out with such issues, at what point in time will the tests be done that make the "stable" version go out without them?

Such tests are usually ready in the release candidate phase. As the release candidate is a candidate for stable unless new issues are discovered in brief period of running a release candidate. So stable release by definition is the point in time where the tests have been done for the release to be made without these bugs present anymore. Of course this doesn't guarantee that all bugs were found.

If I had to criticize MikroTik's processes I'd point out that new features probably shouldn't be added in the release candidate phase like they commonly do. However release candidate might just be the public facing name of these releases and internally such features might have been in testing for a long time, so it's hard to tell.

Or are "we" (the users) supposed to do the testing?

Yes! That is the very definition of beta software and the reason beta versions exist in the first place. If MikroTik wouldn't like the community to help test unstable versions, they would not do beta releases: preparing such releases for no benefit would be a waste of time and effort.

So what is your explanation that the broken VRF-support of /ip/dns which was released in 7.15 stable (and is still broken in 7.15.2 stable AND 7.16beta3) got through the basic testing internally at Mikrotik HQ (if such tests even exists)?

Its not like some exotic error with 42 dependencies that must happen with nano-second precision in order and a full moon to occur - its simple as adding the VRF syntax to the /ip/dns and try to perform a DNS lookup form within the Mikrotik verifying that the DNS service will use the configured VRF and it currently fails big time (disclaimer: it could be me who is doing something wrong here but since the other VRF-aware services works along with both ping and traceroute towards the DNS-server when selecting this VRF then I doubt the error is at my end - also if I reconfigure so I use VRF=main for both /ip/dns and the mgmt-interface (ether1) the DNS lookups works which proofs that there is not something odd going on at my end or internetconnection etc).

To me thats a hint that the quality assurance is going downhill and I agree with that other thread questioning why Mikrotik is currently rushing new features which seems to be broken rather than fixing already known issues: viewtopic.php?t=208900

Also I dont agree with your claim that betas are expected to be flawed and have errors. Its rather the other way around. Betas are something that should have passed the internal testing ready to be shown to the public but with the disclaimer that there MIGHT exist bugs, not that there WILL exist bugs. If none of the public users finds anything odd then the very same code will become the stable release. Which boils down to if none of the public users tests the betas it means that the bugs you claim WILL exist will go unnoticed into the stable release...

So yes I agree with you that betas (generally speaking) are not suitable to be used in production - but when the latest beta fixes more issues than the latest stable (who were released after the beta) I still question should I use the latest stable who is more broken than the latest beta?

I don't want to get this into a long discussion as that does not belong here, but:

Exactly, this DNS functionality is novel on RouterOS and thus these problems have not been found and fixed in the past

When something is changed in a core component like the DNS resolver, I fully expect that the basic functionality is tested.
Can it resolve a static record that has been added to the router?
Even if that hasn't ever failed in a released version in the past, I still expect it to be tested.

Or are "we" (the users) supposed to do the testing?

Yes! That is the very definition of beta software and the reason beta versions exist in the first place. If MikroTik wouldn't like the community to help test unstable versions, they would not do beta releases: preparing such releases for no benefit would be a waste of time and effort.

Well, I consider it a waste of people's time and effort to release beta versions that have not been tested to a minimal level in-house.
I did not install this version anywhere except on my test CHR, and I am not affected by these problems, but I think beta testing would assume testing for complicated situations that may be present only on some customer's configuration.

More to the point of this release: I am worried that again the DNS code is being fiddled with. A DNS resolver is a complicated piece of software and it is very apparent that MikroTik (or only the developer that has been assigned to this task) severely underestimates it.
I am still a proponent of dropping the entire existing resolver and switching to "unbound", an open source resolver with a good reputation that comes with an automated test harness and many tests. Those people know what they are doing.
When there is a space issue on 16MB routers, it could be considered to have an optional package that, when installed, replaces the current DNS resolver with unbound. And that can be installed on routers with enough free space.
Besides all the features that the current resolver has or that are currently being added, unbound also supports DNSSEC.
That will certainly be a feature that people want, and at some point it will be a minus for RouterOS when it does not have it.

It is most probably about dependencies (openssl, etc.) that makes it so hard to adopt/integrate it into ROS.

What's new in 7.16beta4 (2024-Jul-02 15:47):

*) discovery - added discover-interval setting;
*) disk - added "wipe-quick" file-system option to format-drive command (CLI only);
*) dns - refactored DNS service internal processes (additional fixes);
*) filesystem - improved boot speed after device is rebooted without proper shutdown;
*) filesystem - refactored internal processes to minimize sector writes;
*) health - improved voltage measurements for RB912UAG-6HPnD and RB912UAG-5HPnD devices;
*) ipv6 - do not allow to manually delete LL address (additional fixes);
*) log - added basic validation for "disk-file-name" property;
*) lte - fixed R11e-LTE no traffic flow when modem with old firmware is used;
*) poe-out - fixed possible issue with "current_too_low" on devices with a single PoE out interface (introduced in v7.16beta1);
*) routerboard - improved Etherboot stability for IPQ-40xx devices ("/system routerboard upgrade" required);
*) user - added inactivity timeout for non-GUI sessions (additional fixes);
*) x86 - fixed missing serial ports with MCS9900;

Hi there,

I'm using DNS FWD entries and usually could ping to a FQDN for those FWD entries from the terminal. This is not working anymore in 7.16. Please fix it, it is really useful.

ping portal.test.internal
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
while resolving ip-address: name does not exist

Thank you!

It looks like this has been fixed in beta4, thank you!

Anyway... This does not (yet) work for me.

Though... Even disabling DoH does not help here, the forwarding does not work as expected. I think I have the regular expression right, so wondering what's the deal here. Anybody else?

Works in 7.16beta4 now. Thanks a lot!

Static problem resolved thanks.

7.16.beta4 still have bugs in BGP VPN4 in a particular cases.
has been reported almost a month ago.
Please check ticket no SUP-3085 for details & videos what the problem is and response the ticket please


thx

What kind of errors?

Has anyone found that ND "all" in IPv6 is no longer picking up VLANs (interfaces under a single Bridge) and assigning prefixes to each? It worked fine in 7.15.2 stable and then I got greedy and wanted to try the new mDNS proxy functionality.

Nothing has changed in my setup except adding in the mDNS CLI line...

What has changed in the IPv6 section that could be intentionally or unintentionally causing this?

What's new in 7.16beta5 (2024-Jul-25 15:47):

*) log - logging now following rfc 5424 standard;

I do hope to see the above message regarding logging mess SUP-105353 SUP-144261:
viewtopic.php?t=124291

Let me check my crystal ball:

What's new in 7.91beta3 (2030-Jul-25 15:47):

*) log - logging now partially following rfc 5424 standard;

😋

v7.16b4 still mixing IPv6 PD over PPPoE for a while.

PPPoE Server PPPoE Client

on ccr2216 and large bgp enviroment with l3hw enabled for ipv4 and ipv6, we got Kernel failure with 7.16beta3:
- router was rebooted without proper shutdown, probably kernel failure
- kernel failure in previous boot

sup-135376 updated with the autosupout

Anyone else unable to get interface assigned IPv6 addresses from pools in 7.16 (running beta4 now, no change)?

Mine just says "couldn't add new IPv6 address already have such address (6)".

Here's the base config which has been working for ages. This gets a prefix, then assigns the outside interface an IPv6 Global address: Here is the command and result in the CLI when I try to add an address to an internal interface. This used to work: These are the interfaces and addresses as they stand right now: This is the DHCP and prefix info:

I’m not sure if your IPv6 issue is the same as mine, but before the 7.16beta my VLANs were automatically detected and assigned prefixes from the pool. Now I have to manually create the ipv6 addresses using the Bridge dynamic assignment as a guide, copying the address and changing the prefix slightly for each VLAN. Then the pool kicks in and routes and the rest get created dynamically.

@Kaldek, I'm facing the same as you. I rolled back to 7.15.2 for now, everything else (FWD with DOH was working fine, Capsman...) was working fine.

Let me check my crystal ball:

What's new in 7.91beta3 (2030-Jul-25 15:47):

*) log - logging now partially following rfc 5424 standard;

😋

With close to 7 years since my first post, I guess we are closer to version 18 before some gets done.
For people working with more high end/larger network solutions, logging are important to get the maximum out of their networks.
So I do still hope some gets done.

Aside of that rfc, I am also still hoping that at some point the assignment of topics will be cleaned up, there will be a unique "topic" for every message (a numeric code), and the "level" of the message (critical/debug/info/warning/error) would occur in each message only once and as the first topic.
Furthermore, it would be nice when logging rules could include a matching regexp on the message content.

Indeed, this weird "multi-logging" is very unique to ROS. Once I enabled "wifi,debug" then some log-messages from "wifi,info" occur as well on "wifi,debug" which bloats the log unnecessarily. Never seen such kind of logging on any other software. It's either one of those. And a message that is already output on info, should not repeat on debug level. Looks like logging levels are not hierarchical. debug logging does not include info/warn implicitly.

I think you are mistaken. It works like you described it should work.
Only problem is some messages have topics from different levels (e.g. info and debug appear in the same message), and topic is not enough to filter one unique message because different messages are sent with the same set of topics.

Now I have to manually create the ipv6 addresses using the Bridge dynamic assignment as a guide, copying the address and changing the prefix slightly for each VLAN. Then the pool kicks in and routes and the rest get created dynamically.

I'm not sure what you mean, can you explain this in more detail? I don't mind hacking things a bit to get IPv6 functionality back while Mikrotik works the problem.

After the upgrade I only had a global address showing for my Bridge - not my VLANs also. I copied the Bridge global address and changed the interface to my first VLAN interface and changed the global address in the 8 bits I have to work with in the /56 I am provided from 00 to 10 (for example for VLAN10). Saved the new global address.

I then saw that I had a route created, the VLAN now shows up in /IPV6/ND/Prefix…

It has been stable. I repeated the process for my other VLANs where I want IPV6.

Aside of that rfc, I am also still hoping that at some point the assignment of topics will be cleaned up, there will be a unique "topic" for every message (a numeric code), and the "level" of the message (critical/debug/info/warning/error) would occur in each message only once and as the first topic.
Furthermore, it would be nice when logging rules could include a matching regexp on the message content.

It would also be nice to be able to log stuff per IPsec tunnel, or per BGP Peer, etc.
As it is now, if you have 20-30 IPsec tunnels and turn on debugging because you have an issue with one single tunnel, good luck finding any useful logs in that sea of log entries.
Same with BGP when you have 20-30 BGP peers and you have an issue with one specific peer. Debug logging shows tons of unrelated (to the peer you care about) log entries, making it unusable.