v7.16rc [testing] is released!

Tue Aug 06, 2024 10:57 am

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

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during the upgrade process;
3) Device has enough free storage space to download all RouterOS packages.

What's new in 7.16rc5 (2024-Sep-20 14:11):

*) leds - fixed SFP+ LEDs for CCR1072 (introduced in v7.16beta2);
*) lte - fixed R11e-LTE no traffic flow when modem with older firmware version is used (additional fixes);
*) modem - fixed PPP link recovery when port unexpectedly removed and returned due to modem firmware crash;
*) wifi-qcom-ac - improved interface and device stability while booting (introduced in v7.16beta2);
*) wifi-qcom-ac - improved memory allocating process;

What's new in 7.16rc4 (2024-Aug-30 09:24):

*) lte - improved modem AT/modem port open (additional fixes);
*) lte - improvements to "/interface/lte/show-capabilities" command (additional fixes);
*) system - improved system stability (additional fixes);

What's new in 7.16rc3 (2024-Aug-26 15:17):

*) bridge - fixed port enable after BPDU guard detected (introduced in v7.16beta1);
*) dhcp - improved DHCP IPv4 and IPv6 client/relay/server underlying interface state change handling (additional fixes);
*) dns - added support for mDNS proxy (additional fixes);
*) dns - revert "match NXDOMAIN static entry only if other type entries for the same name are not found" (introduced in v7.16beta7);
*) ethernet - fixed "disable/enable" for non-switch interfaces (introduced in v7.16beta7);
*) ethernet - fixed false running link status for ARM64 devices (introduced in v7.16beta5);
*) hotspot - properly escape all reserved URI characters;
*) ipsec - fixed setting "static-dns" for mode configuration (introduced in v7.16beta1);
*) lte - fixed cases where "at-chat" would become unavailable after modem hung up port (introduced in v7.16beta1);
*) lte - fixed signal info for R11e-LTE6 modem (introduced in v7.16beta1);
*) route - fixed blackhole route scope (introduced in v7.16beta2);
*) system - improved system stability for CCR2004-1G-2XS-PCIe device;
*) webfig - correctly display default value for number type (additional fixes);
*) webfig - fixed issue with incorrectly applying optional fields (additional fixes);

What's new in 7.16rc2 (2024-Aug-13 10:05):

*) 6to4 - improved system stability when initializing 6to4 interface (introduced in v7.16rc1);
*) bridge - added L2 MDB support for IGMP snooping (additional fixes);
*) console - improved large import file handling, error detection and stability (additional fixes);
*) dhcp - improved DHCP IPv4 and IPv6 client/relay/server underlying interface state change handling (additional fixes);
*) ovpn - improved system stability (additional fixes);
*) route - improved routing table update performance;
*) x86/chr - fixed invalid HDD size (introduced in v7.16beta7);

What's new in 7.16rc1 (2024-Jul-31 16:35):

*) bgp - fixed minor logging typo;
*) firewall - fixed an issue with unsetting src-address-type;
*) poe-out - fixed incorrect port mapping on CRS354-48P-4S+2Q+ device (introduced in v7.16beta1) (additional fixes);
*) route - improved system stability (introduced in v7.16beta7);

Other changes since v7.15:

*) 6to4 - fixed 6to4 tunnel LL address generation after system reboot;
*) 6to4 - improved system stability when using 6to4 tunnel without specified remote-address;
*) 6to4 - limit keepalive timeout maximum value;
*) 6to4 - make "remote-address" parameter not-mandatory (introduced in v7.16beta3);
*) address - added "S" flag for addresses that belong to a slave interface;
*) arm64 - fixed "disable-running-check" for ARM64 UEFI;
*) arm64 - increased reserved storage space for bootloader;
*) arm64/x86 - added rtl8111/8168/8411 firmware;
*) arp - fixed possible issue with invalid entries;
*) bgp - fixed BGP sessions missing vpnv6 afi;
*) bgp - fixed cluster-list and originator-id;
*) 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 (additional fixes);
*) 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 L2 MDB support for IGMP snooping (additional fixes);
*) 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 - do not allow duplicate ports;
*) bridge - fixed BPDU address when using "ether-type=0x88a8" configuration;
*) bridge - fixed MVRP leave;
*) bridge - fixed port "point-to-point" status after first link change;
*) bridge - fixed typo in filter and NAT error message;
*) 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);
*) bth - improved stability on system time change;
*) bth - improved system stability;
*) certificate - added no-key-export parameter for import;
*) 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;
*) certificate - improved DNS challenge error reporting for Let's Encrypt;
*) certificate - improved RSA key signature processing speed;
*) certificate - show validity beyond year 2038;
*) chr - added support for licensing over IPv6 network;
*) chr - fixed incorrect disk size for ARM64;
*) console - added "about" filters for "find" and "print where" commands;
*) console - added "verbose=progress" mode for import status updates, and verbose output only on failures;
*) console - added additional byte-array option to :convert command;
*) 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 an issue where certain MAC address can be interpreted as time value;
*) console - fixed negative values for gmt-offset clock property;
*) console - fixed output of ping command in certain cases;
*) console - fixed typo in firewall error message;
*) 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 pasting a large input;
*) console - improved stability when removing script;
*) console - increased default width for bitrate type of columns;
*) 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;
*) defconf - configure the default-route property for PPP clients only on devices with a built-in modem;
*) detnet - properly detect "Internet" status when multiple detnet instances preset in network;
*) dhcp - added comment property for matchers, options and option sets;
*) dhcp - improved DHCP IPv4 and IPv6 client/relay/server underlying interface state change handling;
*) 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 - added "class-id" parameter for DHCP server leases;
*) 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;
*) dhcpv4-server - fixed setting and getting "next-server" property;
*) dhcpv4-server - increased lease offer timeout to 120 seconds;
*) dhcpv4-server - remove corresponding dynamic leases if their address-pool gets removed;
*) 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 (additional fixes);
*) dhcpv6-client - update gateway address for default route on renew;
*) dhcpv6-server - improved system stability;
*) 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;
*) discovery - set unknown bit for any unspecified link type in MAC/PHY TLV;
*) disk - added "wipe-quick" file-system option to format-drive command (CLI only);
*) disk - added log message when disks get added or removed;
*) disk - added simple test command to test device and filesystem speeds (CLI only) (additional fixes);
*) disk - improved system stability;
*) disk - remove dummy "slot1" entries on CHR;
*) dns - added support for DoH with adlist (additional fixes);
*) dns - added support for DoH with static FWD entries;
*) 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 - refactored DNS service internal processes (additional fixes);
*) dns - show static entry type "A" field in console;
*) dude - fixed map element RouterOS package upgrade functionality;
*) ethernet - fixed port speed downshift functionality for CRS354 devices;
*) ethernet - improved system stability for Alpine CPUs when dealing with unexpected non-UDP/TCP packet transmit;
*) fetch - handle HTTP 401 status correctly;
*) fetch - improved logging;
*) 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);
*) firewall - added message when interface belonging to VRF is added in filter rules (additional fixes);
*) 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;
*) firewall - removed unnecessary TLS host matcher from NAT tables;
*) 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 - improved voltage measurements for RB912UAG-6HPnD and RB912UAG-5HPnD devices;
*) health - removed unnecessary health settings for RB921 and RB922 devices;
*) health - upgraded fan controller firmware to latest version;
*) ike1 - removed unsupported NAT-D drafts with invalid payload numbers;
*) install - allow to save old configuration during cdrom install;
*) install - fixed ARM64 cdrom install (introduced in v7.15);
*) 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 (additional fixes);
*) iot - added LoRa NetID and JoinEUI filtering for LNS and CUPS connections;
*) iot - added LoRa option to filter out proprietary packets (additional fixes);
*) iot - fixed incorrect LoRa filter export behavior;
*) iot - fixed LoRa inability to set SSL for LoRa servers via command line;
*) iot - fixed LoRa inability to use variables for GPS-spoofing setting;
*) ip - added max-sessions property for services;
*) ip/ipv6 - added multipath hash policy settings;
*) ipip6 - make IPv6 LL address random;
*) ipsec - changed default dpd-interval from 2 minutes to 8 seconds and dpd-maximum-failures from 5 to 4;
*) ipsec - improved installed SA statistics update;
*) ipsec - improved performance by balancing multicore CPU usage for key exchange calculation;
*) 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 (additional fixes);
*) ipv6 - fixed "no-dad" functionality;
*) ipv6 - fixed dynamic duplicate address showing when static address is already configured;
*) ipv6 - fixed pool allocated addresses missing after reboot (additional fixes);
*) ipv6 - fixed SLAAC address dynamic appearance;
*) ipv6 - improved handling of IPv6 address information;
*) ipv6 - improved LL address generation process (additional fixes);
*) ipv6 - properly initialize default ND "interface=all" entry;
*) ipv6 - respect APN settings for "add-default-route" and "use-peer-dns" also when "accept-router-advertisements=yes";
*) ipv6 - warn user that reboot is required in order to properly apply accept-router-advertisements changes;
*) isis - fixed filter-chain and filter-select settings;
*) isis - install IPv6 link-local gateways correctly;
*) l2tp - improved system stability;
*) l3hw - added per-VLAN packet and byte counters to compatible switches;
*) l3hw - disable L3HW on bonding modes that do not support it;
*) leds - fixed rgb LED blink (introduced in v7.16beta1);
*) leds - fixed system LED to indicate correct RAT for Chateau (introduced in v7.16beta1);
*) log - added basic validation for "disk-file-name" property;
*) 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 LTE interface would take long time to become ready after bootup for Chateau 5G and Chateau 5G R16 (introduced in v7.15);
*) lte - fixed cases where modem could be handled by multiple dialer instances;
*) lte - fixed MBIM modem registration on the network (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 - fixed possible crash when enabling/disabling config-less modem interface;
*) lte - fixed R11e-LTE no traffic flow when modem with older firmware version is used;
*) lte - fixed support for Fibocom modem fm150-na;
*) lte - improved modem AT/modem port open;
*) lte - improved system stability for MBIM modem during AT query (introduced in v7.16beta1);
*) lte - improvements to "/interface/lte/show-capabilities" command (additional fixes);
*) media - improved file indexing for DLNA;
*) modem - added authentication functionality to EC200A;
*) modem - fixed cases where USB bus could switch places (introduced in v7.16beta1) (additional fixes);
*) modem - fixed modem firmware upgrade for Chateau 5G and Chateau 5G R16 (introduced in v7.15) (additional fixes);
*) modem - fixed unresponsive PPP link recovery when TX bandwidth was exceeding link capacity;
*) modem - improved support for KNOT BG77 modem firmware update (additional fixes);
*) 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 (additional fixes);
*) netinstall-cli - allow mixed package architectures;
*) netwatch - added DNS probe;
*) netwatch - added ttl and accept-icmp-time-exceeded properties for ICMP probe;
*) netwatch - use time format according to ISO standard;
*) ospf - improved system stability during LSA monitoring;
*) ovpn - improved system stability;
*) pimsm - improved system stability;
*) poe-out - fixed incorrect port mapping on CRS354-48P-4S+2Q+ device (introduced in v7.16beta1);
*) poe-out - fixed low-voltage detection while PD is connected for KNOT device;
*) poe-out - fixed possible issue with "current_too_low" on devices with a single PoE out interface (introduced in v7.16beta1);
*) 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);
*) port - added IPv6 support for the "remote-access" feature;
*) ppp - added SIM hot-plug enable command to default init-string for KNOT and CME gateway;
*) ppp - added support for IPv6-only domain names to l2tp-client, ovpn-client and sstp-client;
*) ppp - automatically generate IPv6 firewall rules when filter-id is specified;
*) ppp - fixed dynamic queue default name (introduced in v7.15);
*) ppp - fixed PPP info parser showing error for BG77 modem running on KNOT AUX AT/modem port;
*) profiler - classify wifi processing as "wireless";
*) 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;
*) qos-hw - added new monitoring properties for ports and global QoS stats;
*) qos-hw - added queue-buffers property to tx-manager (additional fixes);
*) qos-hw - allow port print stats, usage and pfc while QoS is disabled;
*) qos-hw - allow to set queue-buffers in bytes, percent or auto;
*) qos-hw - enabling ECN forces WRED (unless share is disabled);
*) qos-hw - fixed egress-rate limit validation;
*) qos-hw - fixed global buffer limits for 98DX8212 and 98DX8332 switches;
*) qos-hw - fixed incorrect per-port packet and byte cap (introduced in v7.16beta1);
*) qos-hw - fixed WRED thresholds;
*) qos-hw - improved behavior when changing ports tx-manger;
*) qos-hw - limit WRED to queues with enabled shared buffers;
*) queue - improved system stability;
*) quickset - removed Basic AP mode;
*) rose-storage - fixed "/file sysnc status" parameter to be read-only;
*) rose-storage - moved "/rsync-daemon" to "/file rsync-daemon;
*) rose-storage - renamed sync "remote-addr" property to "remote-address";
*) route - added ability to redistribute isis routes;
*) route - fixed incorrectly handled route distinguisher and route targets (introduced in v7.15);
*) route - fixed memory leak (introduced in v7.15);
*) route - fixed some missing route parameters when printing (introduced in v7.15);
*) route - improved route attribute handling (may increase memory usage);
*) route - improved stability when getting entries from large routing tables;
*) route - place static route in the correct VRF when vrf-interface parameter is used;
*) route - rename route type from is-is to isis;
*) routerboard - improved Etherboot stability for CRS320-8P-8B-4S+ device ("/system routerboard upgrade" required);
*) routerboard - improved Etherboot stability for IPQ-40xx devices ("/system routerboard upgrade" required);
*) routerboot - improved boot process ("/system routerboard upgrade" required);
*) rpki - fixed preference sorting;
*) sfp - fixed calculated link length based on EEPROM in certain cases (additional fixes);
*) sfp - fixed missing traffic after reboot with S-RJ01 module running at 10/100 Mbps rate on CCR2004-16G-2S+ device;
*) 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;
*) ssh - fixed SSH cryptographic accelerator selection (introduced in v7.14);
*) ssh - fixed unsupported user SSH public key import (introduced in v7.15);
*) ssh - improved system stability when SSH tries to bind to non-existing interface;
*) 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;
*) 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;
*) switch - fixed bonding FDB entries (introduced in v7.16beta3);
*) switch - fixed Ethernet counters after switch reset for CRS354 devices (introduced in v7.16beta1);
*) switch - fixed Ethernet interface counter 32bit overflow for CRS354 devices;
*) switch - fixed limited Tx traffic on Ethernet ports for CRS354 devices (introduced in v7.15);
*) switch - improved switch reset;
*) switch - improved system stability on CCR2116-12G-4S+, CCR2216-1G-12XS-2XQ devices;
*) system - added "clock" logging topic for time change related messages;
*) system - added critical log message when not enough space to store new configuration;
*) system - added log message if device failed to reboot gracefully;
*) system - added more details to user initiated reboot (reset, upgrade, downgrade);
*) system - added support for upgrade over IPv6 network;
*) system - do not cancel package upgrade if another architecture packages found on the router;
*) system - do not download packages scheduled for uninstall;
*) system - do not start IPsec and certificate processes when not necessary;
*) system - fixed "free disk space" error message on system upgrade/downgrade;
*) 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 - fixed empty logs after reboot in certain cases;
*) system - improved internal system services messaging;
*) system - improved performance for TCP input;
*) system - improved reporting of total memory size;
*) system - improved system stability for RBSXTsq5nD and RBLDF-5nD;
*) system - improved system stability;
*) system - improved watchdog and kernel panic reporting (additional fixes);
*) system - reduced RAM usage for ARM64 devices;
*) 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;
*) traceroute - do not stop traceroute after 5 consecutive unreachable hops;
*) tunnel - allow specifying IPv6 LL address as "remote-address" for EoIPv6, GRE6 and IPIP6 tunnels;
*) user - added inactivity timeout for non-GUI sessions (additional fixes);
*) user-manager - updated logo;
*) vxlan - added comment support to VTEPs;
*) vxlan - prevent creating multiple VTEPs with same IP/port combination;
*) 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 issue with incorrectly applying optional fields;
*) 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 - adjusted virtual interface naming when provisioning local radios;
*) wifi - do not allow frequency-scan on virtual interfaces;
*) wifi - do not unset radio-mac and master-interface properties on reset;
*) wifi - enable creating virtual wifi interfaces using "copy-from" setting;
*) wifi - fixed packet receive when having multiple station interfaces (additional fixes);
*) wifi - fixed signal strength reporting during association (introduced in v7.15) (additional fixes);
*) wifi - fixed typo in log message;
*) wifi - improve regulatory compliance for Chateau ax devices;
*) wifi - improved interface stability when receiving invalid FT authentication frames;
*) wifi - improved system stability after interface hang;
*) 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 - send channel switch announcements to clients when switching channels at requested re-select intervals;
*) wifi - use name-format also for local interfaces when provisioning;
*) 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 - added "Import Router ID" parameter under "Routing/BGP/VPN" menu;
*) winbox - added "Switch/QoS" menu for CRS3xx, CRS5xx, CCR2116 and CCR2216 devices (additional fixes);
*) winbox - added "Trace" column under "System/History" menu;
*) winbox - added configuration settings for ROSE;
*) winbox - added extra "File System" under "Format Drive" button;
*) winbox - added missing "Default Name" property for interfaces;
*) 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 duplicated "MVRP Attributes" table;
*) winbox - fixed error when changing wifi interface settings in some rare conditions (introduced in v7.16beta1);
*) winbox - fixed false invalid flag under "System/Ports/Remote Access" menu;
*) winbox - fixed issue with skin file appearing as unknown in user group menu (introduced in v7.15);
*) winbox - fixed signal bar "excellent" tooltip;
*) winbox - fixed Switch menu for RB1100AHx4 device;
*) winbox - improved QR code display;
*) winbox - moved DHCPv6 Server "Allow Dual Stack Queue" property from General to Queues tab;
*) winbox - moved Switch menu tabs to individual menus (additional fixes);
*) winbox - properly display available address-pools for DHCPv6 server configuration;
*) 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 - renamed configurable wifi property "Tx Power" to "Max Tx Power";
*) winbox - separated different Watchdog settings into logical tabs;
*) winbox - use CAP serial number with "Set Identity" button under "WiFi/Remote CAP" menu;
*) winbox - use correct default value for "Partition Offset" property;
*) winbox/webfig - fixed skins (introduced in v7.15);
*) wireless - allow unsetting signal-range and ssid-regext properties for capsman access-list (additional fixes);
*) 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 missing PCI ids for bnx2x driver;
*) x86 - added RTL8156 driver support;
*) x86 - fixed missing serial ports with MCS9900;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

If you experience version related issues, please send a supout file from your router to support@mikrotik.com. File must be generated while a router is not working as suspected or after some problem has appeared on the device

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

jfim88 · Tue Aug 06, 2024 11:16 am

Was waiting to see the igmp-proxy issue found on SUP-152693 that affects IPTV Movistar Spain fixed in 7.16

kleshki · Tue Aug 06, 2024 11:47 am

Any fixes for WiFi disconnects on ax devices?
viewtopic.php?t=208199 this is annoying bug, not allowing to use any of new firmwares released

BrateloSlava · Tue Aug 06, 2024 1:01 pm

Any fixes for WiFi disconnects on ax devices?
viewtopic.php?t=208199 this is annoying bug, not allowing to use any of new firmwares released

I replied to you in that thread - I have not noticed any problems with the operation of WiFi access points in AC/AX bands. I use CAPsMAN.

slav0nic · Tue Aug 06, 2024 1:21 pm

I have not noticed any problems with the operation of WiFi access points in AC/AX bands. I use CAPsMAN.

It looks like the problem is only for Intel AX devices like (ax200/ax210 wifi cards)

patrick7 · Tue Aug 06, 2024 1:23 pm

PPP in VRF (Framed-Route, Delegated-IPv6-Prefix) unfortunately still not working after thousands of mails and technical infos.
I guess it will never be fixed. SUP-121505

Tue Aug 06, 2024 2:09 pm

We have found that there is a linux kernel driver issue with intel ax201/ax210 cards, that exists in all linux based operating systems, we are trying to find ways to handle these clients better, so if you can reliably repeat these issues and you have this card, send us a supout.rif file to support

ormandj · Tue Aug 06, 2024 2:38 pm

We have found that there is a linux kernel driver issue with intel ax201/ax210 cards, that exists in all linux based operating systems, we are trying to find ways to handle these clients better, so if you can reliably repeat these issues and you have this card, send us a supout.rif file to support

What issue is this? Is there an upstream bug report you can link?

slav0nic · Tue Aug 06, 2024 3:36 pm

What issue is this? Is there an upstream bug report you can link?

wpa3 + intel ax
https://bugzilla.kernel.org/show_bug.cgi?id=203709

kleshki · Tue Aug 06, 2024 3:54 pm

Any fixes for WiFi disconnects on ax devices?
viewtopic.php?t=208199 this is annoying bug, not allowing to use any of new firmwares released
I replied to you in that thread - I have not noticed any problems with the operation of WiFi access points in AC/AX bands. I use CAPsMAN.

I've tried various configurations from support guy recommendations and neither of them worked. The configuration is identical to yours. So it depends on many factors, someone is lucky, someone not.

We have found that there is a linux kernel driver issue with intel ax201/ax210 cards, that exists in all linux based operating systems, we are trying to find ways to handle these clients better, so if you can reliably repeat these issues and you have this card, send us a supout.rif file to support

I've sent a bunch of supout files from 7.14.1, 7.15 and 7.15.1 to support through email. I'm on Intel AX201

What issue is this? Is there an upstream bug report you can link?
wpa3 + intel ax
https://bugzilla.kernel.org/show_bug.cgi?id=203709

This seems to also reproduce without wpa3 (wpa2 only) for me.

maisondasilva · Tue Aug 06, 2024 5:54 pm

After updating to this version, I see this error every time my PPPoE connects. Anyone else experiencing this?

Aug/06/2024 11:49:12
memory
dhcp
error
pppoe-out1 took over pppoe-out1 handling (IPv6)

pe1chl · Tue Aug 06, 2024 7:03 pm

Upgraded a CHR from 7.16beta1 to 7.16rc1
Result: lost extra routing table and all BGP configuration (maybe second is caused by first).

cxcool · Tue Aug 06, 2024 7:05 pm

Upgrade from 7.16beta7 to 7.16rc1
Fixed :
1 Gre6 Tunnel Working Again
2 BGP doesn't Crash any more

Bug :
Total HDD Size = 0 Kib

S8T8 · Tue Aug 06, 2024 7:09 pm

From v7.15 the "sanitize-names" option was implemented, there is or will be an option to :convert to/transform=sanitize-names ?

pe1chl · Tue Aug 06, 2024 7:53 pm

Bug :
Total HDD Size = 0 Kib

I see that as well (CHR with 128MB storage on server, 71MB free inside RouterOS)

rzirzi · Tue Aug 06, 2024 8:01 pm

Upgrade from 7.16beta7 to 7.16rc1
Bug :
Total HDD Size = 0 Kib

I can confirm this at x86 machine. Total HDD Size = 0 Kib

eworm · Tue Aug 06, 2024 10:26 pm

I reported DHCP routes to disappear in beta thread. This was related to OSPF, and I can confirm this was caused by the routing crash and is now fix with this RC release.

Jotne · Tue Aug 06, 2024 11:48 pm

Was waiting to see the igmp-proxy issue found on SUP-152693 that affects IPTV Movistar Spain fixed in 7.16

And I was waiting for a rewrite of the syslog system to follow rfc 5424 that was released in 2009!!!
Hope we have more luck with 7.17...

hagoyi · Wed Aug 07, 2024 12:20 pm

Routing, BGP and DHCP client on 4011 works well.

x4b1 · Wed Aug 07, 2024 4:14 pm

Was waiting to see the igmp-proxy issue found on SUP-152693 that affects IPTV Movistar Spain fixed in 7.16

Yes, I hope they provide a solution quickly. Movistar TV in Spain is pixelated.

dang21000 · Wed Aug 07, 2024 7:38 pm

Disabling a entry in /ip/dns/addlist don't freeup dns cache size. I'm running rc1 on two rb5009.

[admmikrotik@router70] /ip/dns> adlist/print 
Flags: X - disabled 
 0   url="https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts" ssl-verify=no match-count=317 name-count=161549 
[admmikrotik@router70] /ip/dns> print     
....
                   cache-size: 40960KiB
                   cache-used: 18286KiB
....


[admmikrotik@router70] /ip/dns> adlist/disable numbers=0


[admmikrotik@router70] /ip/dns> adlist/print 
Flags: X - disabled 
 0 X url="https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts" ssl-verify=no match-count=317 name-count=161549 
[admmikrotik@router70] /ip/dns> print 
....
                   cache-size: 40960KiB
                   cache-used: 18284KiB
....

pe1chl · Wed Aug 07, 2024 8:12 pm

Routing, BGP and DHCP client on 4011 works well.

Did your BGP config survive during update? Do you have multiple routing tables?
On mine, the BGP config was lost together with multiple routing table config.

pjkundert · Wed Aug 07, 2024 8:17 pm

VLANs stopped working in 7.15, but now work again in 7.16rc1, however:

The /import of scripts that used to work fine for years now fail! It seems, due to line continuations not being respected.

If a necessary argument is on a subsequent line, the import fails. For example, I used to specify:

/interface wireless cap
set bridge=bridge-boss discovery-interfaces=bridge-boss enabled=yes \
    interfaces=wlan2,wlan1

and that now fails; I have to change it to (this, oddly, doesn't happen on *all* line continuations, only some of them):

/interface wireless cap
set bridge=bridge-boss discovery-interfaces=bridge-boss enabled=yes interfaces=wlan2,wlan1

This is only one example; any multi-line scripts fail on import, eg.:

#line 34..35
add add-default-route=special-classless default-route-distance=88 interface=\
    vlan88-backhaul script=":if ( \$bound != 0 ) do={\r\
#line 36
    \n    # Attempt DNS update, in case Internet is available now\r\
Script Error: expected command name (line 36 column 5)

hagoyi · Wed Aug 07, 2024 10:09 pm

Did your BGP config survive during update? Do you have multiple routing tables?
On mine, the BGP config was lost together with multiple routing table config.

Yes and yes, but just 3 tables.

fischerdouglas · Wed Aug 07, 2024 11:04 pm

Inconsistency on syntax of RouterOS it is a pain in the...
Ex:
/routing/bgp/connection/print where address-families -> ip, ipv6, vpnv4, vpnv6
/routint/route/print where afi -> ip, ipv6, vpv4, vpn6

fischerdouglas · Wed Aug 07, 2024 11:18 pm

Another thing that is getting blurry for me is the concepts of RIB and FIB in RouterOS.

It is clear that /ip/route/ and /ipv6/route/ are the same thing, just with a hidden address-family filter.
In winbox, by counting routes, this becomes even more evident.

And this same table seems to be the /routing/route/ table.

But how can I print the differences between RIB and FIB?
Isn't there the concept of RIB-ONLY?

Kaldek · Thu Aug 08, 2024 8:57 am

It looks like the problem is only for Intel AX devices like (ax200/ax210 wifi cards)

The Intel AX adapters are hot garbage. Last week I literally had a laptop with an AX200 card sitting next to one with a Realtek 8852CE. The Realtek was connecting to my cAP ax in the next room at 1201 Mbs (max rate) and the AX200 was connecting at 300 Mbs. It also randomly decides to connect to 2.4Ghz on a far AP even when sitting underneath a cAP ax, which requires turning WiFi off and back on to fix. This is in Windows 11 23H2 connecting to cAP ax units running ROS 7.15.1.

I do not blame Mikrotik for this, as I have a ton of Wireless devices (Apple, Android, Google Home, Nvidia Shield, Chromecasts, etc) and it's ONLY the devices with AX cards that act weird.

Thu Aug 08, 2024 9:12 am

We have noticed that all complaints relating to client connection to mikrotik 802.11ax AP are related with these intel chips. It seems that there is a known bug in the linux kernel, specifically relating to this intel chip. Like I said somewhere else in the forum, we are investigating if we can somehow work around this known issue

Thu Aug 08, 2024 10:00 am

But how can I print the differences between RIB and FIB?

Only active routes are in the FIB.

infabo · Thu Aug 08, 2024 11:50 am

Well, it is probably not just a Linux issue with these Intel AX cards. Kaldek is running Windows. It is more likely their Intel device firmware (firmware is proprietary binary regardless of OS/platform AFAIK)

ToTheFull · Thu Aug 08, 2024 12:04 pm

I have ZERO issues with ax200/210 cards on Windows 10 or 11 with the latest drivers. The only problem I ever had was with the Known sleep bug which was fixed a fair few iterations back. Of course I am using 7.16RC1 not 7.15. something...
The ax200 card connected to the cap-wifi1 is in another room with the door closed and still getting 1201 up down with internal antennas.

Thu Aug 08, 2024 12:36 pm

Well, it is probably not just a Linux issue with these Intel AX cards. Kaldek is running Windows. It is more likely their Intel device firmware (firmware is proprietary binary regardless of OS/platform AFAIK)

I was talking about linux kernel in the mikrotik AP, not the client side.

pe1chl · Thu Aug 08, 2024 2:22 pm

Is there any known reason why Routing->Tables and Routing->BGP configuration is lost on upgrade?
This was also reported earlier in beta by someone else.
Please do not release before this is solved, risk of lock-out of remote routers!

infabo · Thu Aug 08, 2024 2:43 pm

Well, it is probably not just a Linux issue with these Intel AX cards. Kaldek is running Windows. It is more likely their Intel device firmware (firmware is proprietary binary regardless of OS/platform AFAIK)
I was talking about linux kernel in the mikrotik AP, not the client side.

hum, 🪃 of using dated and EOL 5.5.x kernel.😶

itimo01 · Thu Aug 08, 2024 3:23 pm

It looks like the problem is only for Intel AX devices like (ax200/ax210 wifi cards)
The Intel AX adapters are hot garbage. Last week I literally had a laptop with an AX200 card sitting next to one with a Realtek 8852CE. The Realtek was connecting to my cAP ax in the next room at 1201 Mbs (max rate) and the AX200 was connecting at 300 Mbs. It also randomly decides to connect to 2.4Ghz on a far AP even when sitting underneath a cAP ax, which requires turning WiFi off and back on to fix. This is in Windows 11 23H2 connecting to cAP ax units running ROS 7.15.1.

I do not blame Mikrotik for this, as I have a ton of Wireless devices (Apple, Android, Google Home, Nvidia Shield, Chromecasts, etc) and it's ONLY the devices with AX cards that act weird.

Here in Europe (Germany) I've had an issue with all AX2XX and BE200 Cards ive owned with any channel above 124.
Above Channel 124 they only want to connect to 5GHz wifi if the channel width is a max of 20mhz.
Otherwise they connect with limited wifi speed.

I've had similar issues running a Qualcomm WCN685x. Which I think is an AMD Version.
The AMD RZ600 Qualcomm worked fine tho.

And a realtek card worked fine aswell.
Other devices dont seem to have any issues either. (specifically Phones with AX)

Back then I opened a topic on Intel forum where I reported most of my findings.
https://community.intel.com/t5/Wireless ... 533#M51074
P.s.: I tried 3 different intel Cards with 3 different APs.
Mikrotik hap AX3, AX2 and ZTE MF281 (only supports AC) which is rebranded by Deutsche Telekom

pe1chl · Thu Aug 08, 2024 3:34 pm

Here in Europe (Germany) I've had an issue with all AX2XX and BE200 Cards ive owned with any channel above 124.
Above Channel 124 they only want to connect to 5GHz wifi if the channel width is a max of 20mhz.
Otherwise they connect with limited wifi speed.

It may be related to incorrect country/region specific information.
There are several manufacturers where updating that info is a mess.
Probably the feeds of correct information are not that clear or are sometimes in error.

Thu Aug 08, 2024 3:34 pm

I was talking about linux kernel in the mikrotik AP, not the client side.
hum, of using dated and EOL 5.5.x kernel.

Not really true, since we apply lots and lots of patches

patrick7 · Thu Aug 08, 2024 4:10 pm

The more patches you need, the more complicated it becomes (and of course it needs much more time) to upgrade the kernel.
Not sure if that's good or bad.

osc86 · Thu Aug 08, 2024 5:20 pm

Not really true, since we apply lots and lots of patches

risky strategy.. https://youtu.be/_yWhsynnxEg?t=1211

pe1chl · Thu Aug 08, 2024 5:44 pm

Of course there is always the decision between "do we use a fixed kernel version, apply all our own patches, and then try to backport important patches from later kernel versions to keep it secure" and "do we follow the released kernel versions and maintain our own patches so that they can be applied to the released kernels".
I would opt for the latter. And maybe try to submit some of the in-house patches so that they become part of the released kernel, and no longer have to be maintained separately.

bommi · Thu Aug 08, 2024 9:51 pm

Great to see a discussion about the Linux Kernel, that brings me to a feature request I have seen in this forum a lot :-)
When will Mikrotik introduce the support of IPsec VTI?
It is supported by Linux Kernel since 3.6.

infabo · Fri Aug 09, 2024 1:25 am

hum, 🪃 of using dated and EOL 5.5.x kernel.😶
Not really true, since we apply lots and lots of patches

Not using a LTS kernel can't be "patched" by applying "lots of" patches. Your kernel branch is not supported anymore. It is kernel version 5.6.3 apparently. You may backport and apply all the patches you think you need selectively - nice try. This is wasting at least one developer manpower only for patch management for your diverging kernel. It gets harder every month/year. Randomly introducing bugs by this process included. In my opinion this is insane.
Maybe Mikrotik is already patching kernel heavily with their own code. Or maybe it is the size they could squeeze out of 5.6.x and after realizing that LOC are increasing heavily with every kernel release thus increasing size is a big issue when one deploys on 16MB platforms.
And of course you reach a point where you can't "cherry pick" commits anymore. It won't get better by finding workarounds for the AX compatibility thingy. My experience is: when someone talks about "finding a workaround" this is a clear sign of tech debt.

I mean: forget what I said. I am some random dude. Listen to Greg Kroah-Hartman.

Fri Aug 09, 2024 8:00 am

As stated in the post and many other posts in other version topics - please keep this topic related to its purpose. This is v7.16 topic. For other discussions, open up a new topic. The bigger half of posts in this article is not in any way related to this release.

coddy · Fri Aug 09, 2024 8:38 am

On Topic: 7.16 RC1 - Found an annoying bug with the 6to4 tunnel interface. I have VRRP on-backup and on-master scripts that disable or enable various interfaces to enable HA between to Mikrotiks.

One of the Mikrotiks ended up in a boot-loop. The root cause was a process failure when the 6to4 tunnel was re-enabled. (When booting the on-backup script is always run because VRRP starts in backup state, this disabled the 6to4 tunnel. A couple of seconds later the device transitioned to master, and the on-master script ran and enabled the 6to4 tunnel - this caused a router reboot, and then a boot-loop).

Reproduced on a blank netinstalled Mikrotik, and also a x64 CHR. Could also force the issue by disabling and re-enabling the 6to4 tunnel via Winbox a couple of times.

Created SUP-161728 to report the issue, included autosup.rif and also a script to re-create the problem. Hopefully this can be fixed before release.

eworm · Fri Aug 09, 2024 10:14 am

My hAP ax lite lte6 reported:

lte;error lte mbim: >>> E #15 - connect: connect, error: FAILURE

Though with no real issues recognized. Are you interested in a support output file?

pe1chl · Fri Aug 09, 2024 12:20 pm

As stated in the post and many other posts in other version topics - please keep this topic related to its purpose. This is v7.16 topic. For other discussions, open up a new topic. The bigger half of posts in this article is not in any way related to this release.

On the other hand, when issues related to this release are brought up, there is no reply from MikroTik employees, and when generic issues are discussed, they jump right in.

Fri Aug 09, 2024 1:39 pm

Thank you. Issue reproduced. We are working on a fix. Seems that problem is present if you configure 6to4 before adding any IPv4 configuration. Basically - while setting up.

On Topic: 7.16 RC1 - Found an annoying bug with the 6to4 tunnel interface. I have VRRP on-backup and on-master scripts that disable or enable various interfaces to enable HA between to Mikrotiks.

One of the Mikrotiks ended up in a boot-loop. The root cause was a process failure when the 6to4 tunnel was re-enabled. (When booting the on-backup script is always run because VRRP starts in backup state, this disabled the 6to4 tunnel. A couple of seconds later the device transitioned to master, and the on-master script ran and enabled the 6to4 tunnel - this caused a router reboot, and then a boot-loop).

Reproduced on a blank netinstalled Mikrotik, and also a x64 CHR. Could also force the issue by disabling and re-enabling the 6to4 tunnel via Winbox a couple of times.

Created SUP-161728 to report the issue, included autosup.rif and also a script to re-create the problem. Hopefully this can be fixed before release.

coddy · Fri Aug 09, 2024 2:07 pm

@strods,

The problem appears to exist regardless of IP configuration. It was first detected on a fully configured and working unit that was upgraded to 7.16 rc1. I just tried to find the minimalist config required to reproduce the issue. (Of course in my live mikrotik if the ISP pppoe tunnel is not up then there is no default route until it is established). I could also disable/enable 6to4 interface multiple times in winbox with a fully configured unit with ospf routes established and it would still crash.

But thank you for acknowledging the problem, I'm hopeful you'll discover the root cause before the release version. It would be nice to have my 'HA' back.

victorbayas · Sat Aug 10, 2024 6:34 am

I have some questions on how the reselect-interval works? Does it uses dedicated RF hardware like other vendors and most importantly does it interrupt WiFi network traffic on the interface when a DFS channel is being used and the background scan is triggered?

Thanks!

Edit: I have a hAP AX3

bratislav · Sat Aug 10, 2024 2:20 pm

Not really true, since we apply lots and lots of patches
Not using a LTS kernel can't be "patched" by applying "lots of" patches. Your kernel branch is not supported anymore. It is kernel version 5.6.3 apparently. You may backport and apply all the patches you think you need selectively - nice try. This is wasting at least one developer manpower only for patch management for your diverging kernel. It gets harder every month/year. Randomly introducing bugs by this process included. In my opinion this is insane.
Maybe Mikrotik is already patching kernel heavily with their own code. Or maybe it is the size they could squeeze out of 5.6.x and after realizing that LOC are increasing heavily with every kernel release thus increasing size is a big issue when one deploys on 16MB platforms.
And of course you reach a point where you can't "cherry pick" commits anymore. It won't get better by finding workarounds for the AX compatibility thingy. My experience is: when someone talks about "finding a workaround" this is a clear sign of tech debt.

I mean: forget what I said. I am some random dude. Listen to Greg Kroah-Hartman.

LTS kernel support was recently shortened to just 2 years and one of the reasons stated was that almost nobody is using them and that is according to Greg Kroah-Hartman. He is right of course when saying that the most recent mainline stable kernel is the most secure one but companies like Red Hat that also must care about stability of their product are using custom kernels with backported patches. RHEL 8 for example is using 4.18 and RHEL 9 is using 5.14, neither of which is supported by Linux mainline kernel developers for many years... Since Mikrotik must support their products for many years while keeping compatibility they cannot afford to change kernel to currently stable version every couple of months so Red Hat approach seems better fit for them...

Larsa · Sat Aug 10, 2024 2:43 pm

Just a heads-up about the Linux kernel support lifecycle: LTS now typically lasts around 2-5 years while SLTS/CIP is supported for a minimum of 10 years from the initial release but might go on much longer.

https://en.wikipedia.org/wiki/Linux_kernel_version_history
https://lwn.net/Articles/749530/
https://www.kernel.org/category/releases.html

victorbayas · Sat Aug 10, 2024 3:26 pm

LTS kernel support was recently shortened to just 2 years and one of the reasons stated was that almost nobody is using them and that is according to Greg Kroah-Hartman. He is right of course when saying that the most recent mainline stable kernel is the most secure one but companies like Red Hat that also must care about stability of their product are using custom kernels with backported patches. RHEL 8 for example is using 4.18 and RHEL 9 is using 5.14, neither of which is supported by Linux mainline kernel developers for many years... Since Mikrotik must support their products for many years while keeping compatibility they cannot afford to change kernel to currently stable version every couple of months so Red Hat approach seems better fit for them...

As a software engineer, I have to agree that latest and greatest is not always the best specially if you have to maintain such a complex codebase like RouterOS with custom network stack, device drivers and so on. It's not uncommon for networking vendors to build from whatever Linux/OpenWrt based SDK the chipset maker gives them but Mikrotik is building their own thing from scratch and I admire that.

pe1chl · Sat Aug 10, 2024 3:36 pm

Reasons to move to new kernel versions include:
- major new features that have been added and are not so easily "backported" to the kernel you use
- drivers from manufacturers, maybe in binary form, that are not compatible with an older kernel
- not wanting to track each and every patch to see if not having it could impact security of your device

But of course, we have seen that the decision to move to a new kernel version is so hard for companies like MikroTik that it can take many many years before they finally take the plunge.
(and all that time it becomes harder and harder, because there will be more changes that impact functionality of your device)

See how long it took before the promised land of v7 was finally delivered.
(and still today people are complaining because routing performance is less than it was with v6)

S8T8 · Sat Aug 10, 2024 5:03 pm

I have some questions on how the reselect-interval works?

Me too, also with the default !reselect-interval channels are not scanned?
Stil no answer to SUP-155649 asking to provide extra info about this feature.

You can read some advices: search.php?keywords=reselect-interval&t ... sf=msgonly

infabo · Sun Aug 11, 2024 12:10 am

Me too, also with the default !reselect-interval channels are not scanned?

I would answer with yes. It would be a breaking change otherwise.
I tried with a low interval and the interface status changes to scanning, dfs and whatever. So it is no background operation. May be different on AX hardware though.

S8T8 · Sun Aug 11, 2024 1:43 am

So it is no background operation. May be different on AX hardware though.

This should be a good thing, right?
Please confirm that clients are not disconnected during scan.

Should be nice to have some indications about recommended values too.

buset1974 · Sun Aug 11, 2024 5:28 am

Why is so hard for MT to make a real stable system, compare with cisco, juniper, even vyos, its suppose have a very powerfull cpu right? With so many rams and cpus

Kernel panic
Unstable bgp
Suddenly Reboot by watchdog.

Thx

Reasons to move to new kernel versions include:
- major new features that have been added and are not so easily "backported" to the kernel you use
- drivers from manufacturers, maybe in binary form, that are not compatible with an older kernel
- not wanting to track each and every patch to see if not having it could impact security of your device

But of course, we have seen that the decision to move to a new kernel version is so hard for companies like MikroTik that it can take many many years before they finally take the plunge.
(and all that time it becomes harder and harder, because there will be more changes that impact functionality of your device)

See how long it took before the promised land of v7 was finally delivered.
(and still today people are complaining because routing performance is less than it was with v6)

victorbayas · Sun Aug 11, 2024 6:36 am

Me too, also with the default !reselect-interval channels are not scanned?
I would answer with yes. It would be a breaking change otherwise.
I tried with a low interval and the interface status changes to scanning, dfs and whatever. So it is no background operation. May be different on AX hardware though.

I tried it as well on my AX3 and the clients get disconnected, that’s not good.

infabo · Sun Aug 11, 2024 8:38 am

So it is no background operation. May be different on AX hardware though.
This should be a good thing, right?
Please confirm that clients are not disconnected during scan.

Should be nice to have some indications about recommended values too.

re read my post please. I said the interface status changes from running to scanning (don't remember the exact term). So of course the clients are disconnected.
But with the change of 7.16 something changed and it may not noticable because anymore:

*) wifi - send channel switch announcements to clients when switching channels at requested re-select intervals;

But I don't know what it actually does. Mikrotik did not explain it thoroughly. Classic Mikrotik changelog item that leaves you behind with a lot of questions. Mikrotik - please explain this functionality. Thank you.

ivicask · Sun Aug 11, 2024 12:09 pm

Updated hap AX3 from 7.15.3 to 7.16RC.
Entire WIFI/capsman configuration empty(All the tabs, configuration, channel, security..etc), router half responsive, cant connect phone to WIFI at all, barely managed to connect via Winbox.
I tried to make supout file for support but that also was somehow broken and saved nothing.
Reverted to 7.15.3 and all back in working order.

Does Mikrotik support maybe want my router config so you can try reproduce entire thing locally for your self?

pe1chl · Sun Aug 11, 2024 12:39 pm

Why is so hard for MT to make a real stable system, compare with cisco, juniper, even vyos, its suppose have a very powerfull cpu right? With so many rams and cpus

Kernel panic
Unstable bgp
Suddenly Reboot by watchdog.

Thx

Compare the price of these products and you know!
Also note that with MikroTik you get free software upgrades and technical support, while with those other brands you need to pay for a support contract to get these.
And that makes you pay the device again in a couple of years.

infabo · Sun Aug 11, 2024 1:26 pm

not to forget e.g. Cisco APs in the 150€ business line have a very very bad reputation. A "serious" Cisco AP from the catalyst line cost at least 5x of a cap ax for example. So lol.

kcarhc · Mon Aug 12, 2024 11:00 am

With the recent update:

*) DNS - match NXDOMAIN static entry only if other type entries for the same name are not found;

I’ve noticed an issue that affects the way DNS rules are applied. Previously, it was possible to block adservice.google.com by returning NXDOMAIN and then forward the rest of google.com domains to an external DNS server. However, with this update, it’s no longer possible to block ads this way because the second forwarding rule matches *.google.com, which overrides the first NXDOMAIN entry for adservice.google.com.

I believe this change introduces a problem. In most DNS-related configurations, like in dnsmasq, the rules are executed sequentially from top to bottom. I’m not sure why this change was made, but I strongly suggest that the rules should be executed based on their order, rather than checking for matches with other rules.

Here is the example code I’m referring to:

/ip dns static
add name=adservice.google.com type=NXDOMAIN
add forward-to=dns.google regexp="(\\.|^)google\\.com\$" type=FWD

peri · Mon Aug 12, 2024 11:17 am

With the recent update:

*) DNS - match NXDOMAIN static entry only if other type entries for the same name are not found;

I’ve noticed an issue that affects the way DNS rules are applied. Previously, it was possible to block adservice.google.com by returning NXDOMAIN and then forward the rest of google.com domains to an external DNS server. However, with this update, it’s no longer possible to block ads this way because the second forwarding rule matches *.google.com, which overrides the first NXDOMAIN entry for adservice.google.com.

I believe this change introduces a problem. In most DNS-related configurations, like in dnsmasq, the rules are executed sequentially from top to bottom. I’m not sure why this change was made, but I strongly suggest that the rules should be executed based on their order, rather than checking for matches with other rules.

Here is the example code I’m referring to:
Code: Select all
/ip dns static
add name=adservice.google.com type=NXDOMAIN
add forward-to=dns.google regexp="(\\.|^)google\\.com\$" type=FWD

I have the same problem. I hope the developers will seriously consider it.

infabo · Mon Aug 12, 2024 12:53 pm

I always had the issue that a regex FWD record had priority over a static A record. Was that different with NXDOMAIN?

kcarhc · Mon Aug 12, 2024 1:15 pm

I always had the issue that a regex FWD record had priority over a static A record. Was that different with NXDOMAIN?

The priority should normally be determined by the order of the rules, not by their type. In other words, rules that appear earlier should have higher priority than those that come later.

infabo · Mon Aug 12, 2024 2:12 pm

Well, your opinion. RFC 1034 is what is relevant.

https://www.ietf.org/rfc/rfc1034.txt

The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS.

pe1chl · Mon Aug 12, 2024 2:28 pm

Here is the example code I’m referring to:
Code: Select all
/ip dns static
add name=adservice.google.com type=NXDOMAIN
add forward-to=dns.google regexp="(\\.|^)google\\.com\$" type=FWD

I wonder why you use a regexp match instead of an explicit match for google.com + the setting "match subdomain"?
I would think that is much more efficient...
Maybe because that capability was introduced later?

pe1chl · Mon Aug 12, 2024 2:29 pm

Well, your opinion. RFC 1034 is what is relevant.

https://www.ietf.org/rfc/rfc1034.txt

The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS.

That is something different! It specifies the order of the data in the DNS reply, not the order of processing of rules.

infabo · Mon Aug 12, 2024 2:42 pm

Indeed, pe1chl.
As I understand it, regardless of order, NXDOMAIN should overrule anything. It says basically the domain does not exist, so it makes no sense to look further. IMHO it is a bug when NXDOMAIN records exist but other records are considered instead. In fact a huge bug.

kcarhc · Mon Aug 12, 2024 3:21 pm

Here is the example code I’m referring to:
Code: Select all
/ip dns static
add name=adservice.google.com type=NXDOMAIN
add forward-to=dns.google regexp="(\\.|^)google\\.com\$" type=FWD
I wonder why you use a regexp match instead of an explicit match for google.com + the setting "match subdomain"?
I would think that is much more efficient...
Maybe because that capability was introduced later?

It's difficult for me to evaluate the match subdomain feature, but I can say that it's not very useful. Besides the fact that it randomly fails to match, which many people around me have experienced (including myself, leading me to abandon it), there's also the reason why I’m using regex. Below is the complete code, which match subdomain simply can't achieve:

/ip dns static
add forward-to=dns.google regexp="(\\.|^)google\\.[a-z][a-z]([a-z]|)(\\.[a-z][a-z]|)\$" type=FWD

pe1chl · Mon Aug 12, 2024 3:30 pm

Indeed, pe1chl.
As I understand it, regardless of order, NXDOMAIN should overrule anything. It says basically the domain does not exist, so it makes no sense to look further. IMHO it is a bug when NXDOMAIN records exist but other records are considered instead. In fact a huge bug.

This "fix" was probably introduced for the case where you have two explicit static entries, one for "machine.example.com IN A 1.2.3.4" and another for "machine.example.com NXDOMAIN" and then the client asks for MX or AAAA or whatever.
In that case a proper DNS server should reply with "no data" instead of "no such domain", but we all know the quality of the MikroTik DNS service and it probably had issues with this, which they fixed.
But now it runs in trouble with wildcard entries...

It will continue like this until they throw the towel and use an established and well-tested resolver.

infabo · Mon Aug 12, 2024 3:47 pm

Mikrotik is not known for "throwing the towel". Not a single line of code is given up voluntarily.

blacksnow · Mon Aug 12, 2024 3:59 pm

You do realize you can simply set the regexp to be the explicit name and that will ensure it gets blocked accordingly and the rest is allowed. Like below.

/ip dns static
add regexp=adservice.google.com type=NXDOMAIN
add forward-to=dns.google regexp="(\\.|^)google\\.com\$" type=FWD

sirbryan · Mon Aug 12, 2024 6:27 pm

But with the change of 7.16 something changed and it may not noticable because anymore:

*) wifi - send channel switch announcements to clients when switching channels at requested re-select intervals;
But I don't know what it actually does. Mikrotik did not explain it thoroughly.

The AP has the ability to tell clients that the AP's channels are going to change at a specific time, then everybody jumps at the exact same time to provide seamless switching. If the hardware has the capability to listen in the background for cleaner channels, then it will do a background scan, then (ideally) jump to a cleaner/clearer section of the band.

bommi · Mon Aug 12, 2024 6:40 pm

*) wifi - send channel switch announcements to clients when switching channels at requested re-select intervals;

Is it supported for standalone wifi, capsman or both?

faxxe · Mon Aug 12, 2024 6:45 pm

You do realize you can simply set the regexp to be the explicit name and that will ensure it gets blocked accordingly and the rest is allowed. Like below.
Code: Select all
/ip dns static
add regexp=adservice.google.com type=NXDOMAIN
add forward-to=dns.google regexp="(\\.|^)google\\.com\$" type=FWD

If i understand correct, can i use this commands as a kind of whitelist?
-faxxe

pe1chl · Mon Aug 12, 2024 7:03 pm

If i understand correct, can i use this commands as a kind of whitelist?
-faxxe

You would expect that to work, but the bug reported here is that it does not work (in this version).

infabo · Mon Aug 12, 2024 7:43 pm

But with the change of 7.16 something changed and it may not noticable because anymore:

But I don't know what it actually does. Mikrotik did not explain it thoroughly.
The AP has the ability to tell clients that the AP's channels are going to change at a specific time, then everybody jumps at the exact same time to provide seamless switching. If the hardware has the capability to listen in the background for cleaner channels, then it will do a background scan, then (ideally) jump to a cleaner/clearer section of the band.

Cool that you try to interpret their changelog entry. But I want that confirmed by Mikrotik staff. The changelog leaves too much room for interpretation. It could be either a background scan and then the AP promotes the new channel right away. But it could also be that the AP just promotes the 2ghz BSSID when the 5ghz BSSID goes down for scanning (or vice versa)...

faxxe · Mon Aug 12, 2024 7:59 pm

You would expect that to work, but the bug reported here is that it does not work (in this version).

OK thanks... what do you think, will they get it right at some point...7.2x?
In the food industry, it probably wouldn't work to simply bring a raw piece of meat onto the market with the intention of "frying it a little later, maybe"
Strange mic(k)rocosm

-faxxe

sirbryan · Tue Aug 13, 2024 3:28 am

But it could also be that the AP just promotes the 2ghz BSSID when the 5ghz BSSID goes down for scanning (or vice versa)...

That's not how the standard works, which is years-old, by the way. (Google for Channel Switch Announcement, 802.11h.)

mantouboji · Tue Aug 13, 2024 4:06 am

The link-local address of WireGuard interfaces lost randomly

kcarhc · Tue Aug 13, 2024 8:29 am

Below is the update log regarding the routing in this release:

*) route - added ability to redistribute isis routes;
*) route - fixed incorrectly handled route distinguisher and route targets (introduced in v7.15);
*) route - fixed memory leak (introduced in v7.15);
*) route - fixed some missing route parameters when printing (introduced in v7.15);
*) route - improved route attribute handling (may increase memory usage);
*) route - improved stability when getting entries from large routing tables;
*) route - place static route in the correct VRF when vrf-interface parameter is used;
*) route - rename route type from is-is to isis;

The routing-mark in IPv6 routing still does not work unless the following code is added in /routing/rule:

The code is as follows:

/routing rule
add action=lookup disabled=no routing-mark=main table=main

The reason for not wanting to add the code below is that it has been found that having or not having code in /routing/rule (which should bypass the /routing/rule functionality) makes a difference.
Tests have shown that enabling /routing/rule results in a performance drop of at least 5%-10% and also increases response latency.

Please check SUP-151768 for confirmed details of the issue.

infabo · Tue Aug 13, 2024 10:00 am

But it could also be that the AP just promotes the 2ghz BSSID when the 5ghz BSSID goes down for scanning (or vice versa)...
That's not how the standard works, which is years-old, by the way. (Google for Channel Switch Announcement, 802.11h.)

Oh, did not know that there is a separate standard. Thanks for the information. Googled it, should be defined in IEEE 802.11-2012.
But when it really is this, I would want Mikrotik to include this reference in their changelog as well. So we all can lookup/google for more info.

Tue Aug 13, 2024 5:13 pm

What's new in 7.16rc2 (2024-Aug-13 10:05):

*) 6to4 - improved system stability when initializing 6to4 interface (introduced in v7.16rc1);
*) bridge - added L2 MDB support for IGMP snooping (additional fixes);
*) console - improved large import file handling, error detection and stability (additional fixes);
*) dhcp - improved DHCP IPv4 and IPv6 client/relay/server underlying interface state change handling (additional fixes);
*) ovpn - improved system stability (additional fixes);
*) route - improved routing table update performance;
*) x86/chr - fixed invalid HDD size (introduced in v7.16beta7);

jfim88 · Tue Aug 13, 2024 6:04 pm

What's new in 7.16rc2 (2024-Aug-13 10:05):

*) bridge - added L2 MDB support for IGMP snooping (additional fixes);

I bet here is nothing for igmp issue found on SUP-152693?

pe1chl · Tue Aug 13, 2024 6:11 pm

Upgraded a CHR from 7.16beta1 to 7.16rc1
Result: lost extra routing table and all BGP configuration (maybe second is caused by first).

Support told me that this happened because the VM memory was still at 256MB (which was the result of deploying the VM with the 7.15.1 .ova file and then upgrading it to 7.16beta1).
So, whenever you have a CHR that was originally installed on an older version, FIRST upgrade the memory to 1GB before you attempt upgrade to this version.
(increased memory requirement is documented but belongs in the "Before an upgrade" section, where only storage space is mentioned and not RAM allocation)

br0kenPKI · Tue Aug 13, 2024 8:22 pm

It seems that SUP-161182 has not been fixed.

infabo · Tue Aug 13, 2024 10:04 pm

out of interest: support tickets are private only. why do so many people just drop a support ticket number while moaning: "meh, not fixed. boo boo". We don't know what's reported and written in these tickets. what is the intention or goal?

mkx · Tue Aug 13, 2024 10:18 pm

what is the intention or goal?

The goal is to boo-boo. AFAIK the most optimistic feedback provided by support is "the issue was reproduced, it'll be fixed but we can't give any ETA". Except when the fix was already done and has passed whatever internal check points, in which case they'll say it'll be included in next beta/RC.

maisondasilva · Tue Aug 13, 2024 10:50 pm

What's new in 7.16rc2 (2024-Aug-13 10:05):

*) 6to4 - improved system stability when initializing 6to4 interface (introduced in v7.16rc1);
*) bridge - added L2 MDB support for IGMP snooping (additional fixes);
*) console - improved large import file handling, error detection and stability (additional fixes);
*) dhcp - improved DHCP IPv4 and IPv6 client/relay/server underlying interface state change handling (additional fixes);
*) ovpn - improved system stability (additional fixes);
*) route - improved routing table update performance;
*) x86/chr - fixed invalid HDD size (introduced in v7.16beta7);

After 7.16.X show

Aug/13/2024 16:46:36
memory
dhcp
error
pppoe-out1 took over pppoe-out1 handling (IPv6)

robtor · Tue Aug 13, 2024 11:37 pm

What does the following feature exactly mean?
*) wifi - added "slave-name-format";

Will this solve the issue with CAPsMAN and qcom-ac devices when configuring vlans manually?

Currently on 7.15 they get named inconsistent after repro visioning the CAP's and brake the vlan filtering configuration on the bridge when having slaves-static enabled.

(See viewtopic.php?t=209909)

And are there any plans for vlan datapath support for qcom-ac?

Coughy · Wed Aug 14, 2024 7:18 am

hi guys is there anywhere i can download 7.16rc1? as i try rc2 and it has a bug i dont like wont to reveert backl to rc1 but i didnt download it i just upgraded from cloud

Wed Aug 14, 2024 7:20 am

You can download basically any RouterOS version from our upgrade server. Just change the version number in URL.

https://upgrade.mikrotik.com/routeros/7 ... -arm64.npk

coddy · Wed Aug 14, 2024 7:32 am

7.16rc2 fixed the issue with the 6to4 tunnel crashing the Mikrotik when you disable / re-enable the tunnel. Thank you MT!

Coughy · Wed Aug 14, 2024 7:50 am

You can download basically any RouterOS version from our upgrade server. Just change the version number in URL.

https://upgrade.mikrotik.com/routeros/7 ... -arm64.npk

thanks so much appreciate it cheers

Wed Aug 14, 2024 8:33 am

Some people seem to think this forum is a support system. No it's not, people reading this are regular users. They have no use for your support ticket numbers.

Wed Aug 14, 2024 12:36 pm

robtor "wifi - added "slave-name-format";" just adds more control on how virtual interfaces can be named.
Regarding the forum post you linked, a lot of issues can be caused by re-provision, there seems to be a misconception that configuration needs to be "pushed" via help of provisioning the interfaces. That is not the case, provision must be done only initially, and is done automatically upon CAP joining if there are matching provisioning rules that are enabled.
If you adjust any configuration profile that is linked to provisioned interface, all changes will be "pushed" as soon as you apply changes to the profile. With no need to re-create already existing interface.
Provisioning itself is not for sending configuration, it is for essentially creating a new interface. In most cases, there is no reason to perform manual provisioning once you already have CAP interfaces running.

Now, if create-enabled together with slave-static is used and interface names change after reboot or upgrade, please let us know via support@mikrotik.com along with details of what was upgraded/rebooted. In our tests, names should not change, and references to CAP interfaces should work, and not be lost, both on CAPsMAN and CAP side, even if virtual CAP interface is renamed on CAP.

infabo · Wed Aug 14, 2024 1:02 pm

If you adjust any configuration profile that is linked to provisioned interface, all changes will be "pushed" as soon as you apply changes to the profile.

I have experienced cases where the configuration changes where not pushed "automatically" and it needed to call "provision" again. I can't remember the concrete cases though.

S8T8 · Wed Aug 14, 2024 1:24 pm

@Guntis, should be nice to have a detailed explanation like the last one, also for reselect-interval

I have some questions on how the reselect-interval works?
Me too, also with the default !reselect-interval channels are not scanned?
Stil no answer to SUP-155649 asking to provide extra info about this feature.

You can read some advices: search.php?keywords=reselect-interval&t ... sf=msgonly

robtor · Wed Aug 14, 2024 1:30 pm

Regarding the forum post you linked, a lot of issues can be caused by re-provision, there seems to be a misconception that configuration needs to be "pushed" via help of provisioning the interfaces.

@Guntis Thank you for your clear information on my misunderstand of the reprovisioning. Is it okay if I quote/cite your post here into the forum thread I linked to help others stumbling over the same topic? I would then update my configuration and do not do reprovisioning after each config change and check if the issue happens again. Your answer helped a lot. Thank you!

If I didn't overseen it in the documentation, maybe a warning or information banner could be added, to make clear what the provisioning actually does. I actually can't find anything about the

 /interface/wifi/capsman/remote-cap/provision

command.

infabo · Wed Aug 14, 2024 2:18 pm

it is undocumented.

/interface/wifi/radio/provision

isn't documented either.

osc86 · Wed Aug 14, 2024 3:50 pm

I have experienced cases where the configuration changes where not pushed "automatically" and it needed to call "provision" again. I can't remember the concrete cases though.

Have this issue all the time. config updates are not applied by the caps unless reprovisioned, it's highly unreliable.

erlinden · Wed Aug 14, 2024 3:57 pm

Do you have examples on what changes you have made that weren't provisioned?

Wed Aug 14, 2024 5:29 pm

If there are examples where configuration was changed, but CAPs didn't reflect the change, please let us know, and share with us supout.rif files from both CAP and CAPsMAN, they should be made before manual "provision" is performed to fix the issue.

If you don't explicitly configure reselect-interval no automatic rescan will take place, unless interface goes down - CAP-CAPsMAN communication was interrupted, restart, etc. Reselect-interval uses a background scan.

maigonis · Wed Aug 14, 2024 5:35 pm

robtor "wifi - added "slave-name-format";" just adds more control on how virtual interfaces can be named.
Regarding the forum post you linked, a lot of issues can be caused by re-provision, there seems to be a misconception that configuration needs to be "pushed" via help of provisioning the interfaces. That is not the case, provision must be done only initially, and is done automatically upon CAP joining if there are matching provisioning rules that are enabled.
If you adjust any configuration profile that is linked to provisioned interface, all changes will be "pushed" as soon as you apply changes to the profile. With no need to re-create already existing interface.
Provisioning itself is not for sending configuration, it is for essentially creating a new interface. In most cases, there is no reason to perform manual provisioning once you already have CAP interfaces running.

Now, if create-enabled together with slave-static is used and interface names change after reboot or upgrade, please let us know via support@mikrotik.com along with details of what was upgraded/rebooted. In our tests, names should not change, and references to CAP interfaces should work, and not be lost, both on CAPsMAN and CAP side, even if virtual CAP interface is renamed on CAP.

Exactly, I don't understand why people are doing it. My guess is, for example, on Unify after config change you see status change to "provisioning" (or smth similar), maybe that's the urge, or I cant rule out some edge case where there can be issue. Otherwise for me all 50+ APs I manage receive changes instantly after config change in capsman.

sirbryan · Wed Aug 14, 2024 5:39 pm

That's not how the standard works, which is years-old, by the way. (Google for Channel Switch Announcement, 802.11h.)
Oh, did not know that there is a separate standard. Thanks for the information. Googled it, should be defined in IEEE 802.11-2012.
But when it really is this, I would want Mikrotik to include this reference in their changelog as well. So we all can lookup/google for more info.

It literally says "channel switch announcement" in the changelog entry.

*) wifi - send channel switch announcements to clients when switching channels at requested re-select intervals;

In other words, "We're using this standard (802.11h) to ensure smooth[er] channel changes at the reselect interval, instead of just dumping clients when making a change."

jszakmeister · Wed Aug 14, 2024 6:16 pm

If there are examples where configuration was changed, but CAPs didn't reflect the change, please let us know, and share with us supout.rif files from both CAP and CAPsMAN, they should be made before manual "provision" is performed to fix the issue.

If you don't explicitly configure reselect-interval no automatic rescan will take place, unless interface goes down - CAP-CAPsMAN communication was interrupted, restart, etc. Reselect-interval uses a background scan.

Is it true you don't have to explicitly configure reselect-interval? Having a reselect interval seems to be required in 7.15.

S8T8 · Wed Aug 14, 2024 7:05 pm

If you don't explicitly configure reselect-interval no automatic rescan will take place, unless interface goes down - CAP-CAPsMAN communication was interrupted, restart, etc. Reselect-interval uses a background scan.

Thanks @Guntis, so to make more clearer;
- using !reselect-interval no automatic rescan
- using reselect-interval=6h..8h CAPsMAN or standalone AP will scan randomly for alternative channels in the background between 6h - 8h from device restart (and not between 6AM - 8AM) and then inform + disconnect clients (in case of a switch)
- diffrenentrly from the old CAPsMAN, reselect-interval works also if frequency is used and is not possible to set a specific time (12:00:00)
Correct?

smotrov · Thu Aug 15, 2024 12:15 pm

In other words, "We're using this standard (802.11h) to ensure smooth[er] channel changes at the reselect interval, instead of just dumping clients when making a change."

In my case (RB5009 + 3 HaP ax2) it does disconnects clients. At least the ones which are on 5Ghz with DFS-10min skip.

It shows DFS 1min pause any all existing connections are dropped.

Am I correct that smooth transition could be possible for NON-dfs channels? If so, it seams usless for me.

nmt1900 · Thu Aug 15, 2024 12:33 pm

It does not seem to be possible to do seamless channel change as there is no dedicated radio to do the scan while current channel is active. Other vendors have this feature even on devices at ~100 $ price point.

Interruptions caused by false "radar detections" have been one of worst problem of Mikrotik wireless hardware for years.
How do I define "false"? How about completely RF isolated room (metal roof and metal lined concrete walls with no windows) containing wireless AP's as only obvious RF source in them?

smotrov · Thu Aug 15, 2024 3:13 pm

It does not seem to be possible to do seamless channel change as there is no dedicated radio to do the scan while current channel is active

Thank you, this was my concern as well. But what does this mean int he chage log?

wifi - send channel switch announcements to clients when switching channels at requested re-select intervals;

To whoom does this announsment will be sent? To the ones who just been disconnected? :-)

Pea · Thu Aug 15, 2024 3:51 pm

wifi - send channel switch announcements to clients when switching channels at requested re-select intervals;

To whoom does this announsment will be sent? To the ones who just been disconnected? :-)

AP announces that it is switching to a new channel before it begins transmitting on that channel.
This allows supported clients to transition to the new channel with minimal downtime (the client must not begin scanning to discover the new channel on which the AP is operating).

Thu Aug 15, 2024 3:53 pm

jszakmeister -no it is not required to set reselect-interval, you can ignore this parameter if you don't want to use this functionality

S8T8 - "!reselect-interval no automatic rescan", yes, if no interval is set then wifi interface will not evaluate for better channels unless interface status changes.
Yes, if a better channel is found, channel switch announcment will be sent, and clients will be disconnected. 6h..8h means that in random interval after 6, but before 8 hours, reselect.interval will perform a background scan to evaluate if there is a better channel available. This does not relate to AM/PM - clock. The interval is started from moment radio got provisioned, it is not related to system uptime.
It is not possible to set specific time when scan should be performed, the parameter is intentionally made as an interval with random element to it, as the intended goal is that in multiple CAP scenario the scans and subsequent channel changes are not done at the same time.
It will still perform background scan for better channel, even if you set just a few frequencies, though we would recommend using "auto" frequency - not setting a frequency on the interface.

smotrov · Thu Aug 15, 2024 4:22 pm

...
- using reselect-interval=6h..8h CAPsMAN or standalone AP will scan randomly for alternative channels in the background between 6h - 8h from device restart...

I really doubt background. According to what I see in my setup it just kicks off everyove and starts scanning. Which is not exactly in background...

Meanwhile it is clearly stated in the documentaion

reselect-interval (time interval)
Specifies when the interface should rescan channel availability and select the most appropriate one to use. Specifying interval will allow the system to select this interval dynamically and randomly. This helps to avoid a situation when many APs at the same time scan network, select the same channel, and prefer to use it at the same time. reselect-interval uses a background scan.

So I belive this documentation is not really correct. Would love to see MT comments on this.

smotrov · Thu Aug 15, 2024 4:27 pm

It will still perform background scan for better channel, even if you set just a few frequencies, though we would recommend using "auto" frequency - not setting a frequency on the interface.

a) Will clients be disconected begore background scan in order to perform it? Or it will be done using the same radio keeping clients connected during the scan happening?

b) If better chennel requires DFS 10 minutes wait. Will all clients be disconnected for 10 minutes?[/list]

infabo · Thu Aug 15, 2024 4:46 pm

I really doubt background. According to what I see in my setup it just kicks off everyove and starts scanning. Which is not exactly in background...

It is also what I saw in lab. Just tried it again: used a interval of "1m..2m" so I can see it happen. The interface goes into reselect and scan for channel and even when the frequency stays the same - the clients are all kicked off. I can proof that by log entries that all clients that were connected to the particular interface either connect again once the interface is running state again (so there must have been a disconnect otherwise why should the connect???) or the switch to another CAP in the same second of reselect is running. Coincidence? I guess not. So the "background" scan is clearly not a background one. It is clearly interrupting.

mkx · Thu Aug 15, 2024 5:52 pm

So the "background" scan is clearly not a background one. It is clearly interrupting.

Perhaps it's intended to be in background but it messes with timing of beacon frames?

The only way of doing background scan with single radio is to transmit what's essential (beacons) but use the rest of air time to scan other frequencies. So it will clearly affect service to active stations (they won't get much/any response from AP during that time) and clearly can't be properly done for DFS channels (which have to be monitored 100% of time - whatever duration required - prior to start of transmission).

The problem is similar even if AP uses dedicated receiver for background scanning (a 4x4 MIMO device could temporarily degrade to 2x2 and use free receivers for background scan) because own transmissions will overwhelm the scanning receiver ... and no "digital band filters" can help there due zo the fact that it's analog pre-amplifier which gets hit. Real analog band pass filters would help, but proper tunable ones are bulky and cost a few cents too much.
So the only benefit of using separate receivers for background scanning is that uplink service is not interrupted during background scans. It's useless for DFS channels as much as without dedicated receivers.

infabo · Thu Aug 15, 2024 6:15 pm

For 5Ghz interfaces it is 💯 no background scan. One went into 10min CAC check and was not broadcasting in this time.
Interesting that Mikrotik employees have a different view in this.

own3r1138 · Thu Aug 15, 2024 7:27 pm

It would be awesome if someone could elaborate.

What's new in 7.16rc2 (2024-Aug-13 10:05):
*) ovpn - improved system stability (additional fixes);

Fri Aug 16, 2024 7:24 am

There was a possibility that OVPN router can get a "Kernel Failure". If you have a router running OVPN and it sometimes reboots due to a Kernel Failure, then upgrade and see how it goes. If the problem remains, then of course contact support@mikrotik.com and send supout file.

coddy · Fri Aug 16, 2024 9:14 am

FYI: MLAG issue: two CRS317 in MLAG, with ESX hosts dual connected to CRS317 (not LACP, but having ESX decide which switch to send traffic based on the port up status, and the MAC address of the VM). When switch 1 goes down for firmware upgrade, all is ok, ESX starts using switch 2 for all VMs. When switch 1 comes back on line, ESX switches back to using switch 1 for some VMs. But I can't access half of my VMs for around 15 minutes. Then all is well again. Frustrating. I also cannot ping switch 1 for that period of time even though it is up (so it is not just the ESX hosts having an issue with the MLAG mac cache). The CRS317s are connected LACP to a CRS328P floor switch, which I am connected to. Since I can't ping switch 1, I assume the floor switch has learnt that its path is via switch 2, and something is going wrong there.

Fri Aug 16, 2024 10:59 am

There was a possibility that OVPN router can get a "Kernel Failure". If you have a router running OVPN and it sometimes reboots due to a Kernel Failure, then upgrade and see how it goes....

Perfect extended version of changelog you have been asked for for years. Keep going ... please, please, please

infabo · Fri Aug 16, 2024 11:04 am

I would not call it "perfect" as it is still very vague. "there was a possibility" and "sometimes" does not tell one anything more than the original "improved stability" entry.

BrateloSlava · Fri Aug 16, 2024 11:08 am

though we would recommend using "auto" frequency - not setting a frequency on the interface.

This is the first time I've seen an “official” recommendation to use automatic frequency selection instead of manually setting values.

Fri Aug 16, 2024 11:25 am

I would not call it "perfect" as it is still very vague. "there was a possibility" and "sometimes" does not tell one anything more than the original "improved stability" entry.

As one-liner, two short sentences long ... please do not kill my motivation speach

Kanzler · Fri Aug 16, 2024 11:35 am

@BrateloSlava,
Guess it’s time to let the robots handle the frequencies while we handle the snacks :-)))

Fri Aug 16, 2024 11:54 am

BrateloSlava "This is the first time I've seen an “official” recommendation to use automatic frequency selection instead of manually setting values."
- it was not meant as an endorsement to use auto frequencies, it was more in line of if you use reselect-interval to let it select frequencies for you, give it a wider range of possible frequencies to pick from, if you want to give it more data to select best frequency.

Planned and monitored manually set frequencies are of course better than all left on auto.

To re-iterate, reselect-interval does use background scan, it will not go into CAC unless it chose to change the channel, using background scan doesn't mean that the new frequency won't have to be monitored for radar, if reselect-interval finds a better frequency and actually changes to that channel. It is also true that there is no dedicated radio for scanning.
Similar as with station-roaming feature in Wireless https://wiki.mikrotik.com/wiki/Manual:I ... on-Roaming although it is done in background and doesn't immediately disconnect all users, but there can be cases where it affects the stations, given that there is no dedicated radio, it is not recommended to set low interval.

infabo · Fri Aug 16, 2024 12:06 pm

But as I already proofed by experimental setup:

- reselect interval 1m..2m
- wifi1 at frequency 2442 with 3 clients connected
- wifi1 starts reselect procedure according to interface state value
- wifi1 reselect procedure finished. state running again. frequency not changed - still 2442
- all clients kicked. Clients either reconnect to wifi1 or chose to switch over to another CAP

Any thoughts on this?

Fri Aug 16, 2024 12:13 pm

While in some cases clients might get disconnected, it is not the rule, we have tested it locally on both 2.4GHz and 5GHz, and generally clients stay connected, and it is implemented as background scan. If it causes issues in your environment, use a larger interval or plan out frequencies manually.

That being said, this discussion should be in a separate topic.
Please keep this forum topic strictly related to this particular RouterOS release.

BrateloSlava · Fri Aug 16, 2024 1:31 pm

That being said, this discussion should be in a separate topic.
Please keep this forum topic strictly related to this particular RouterOS release.

IMHO, you should limit the minimum value for the “reselect interval” parameter anyway. For example, set it to 30 minutes. So that end users cannot “force” the devices to be in the “permanent” selection state.

infabo · Fri Aug 16, 2024 1:52 pm

While in some cases clients might get disconnected, it is not the rule, we have tested it locally on both 2.4GHz and 5GHz, and generally clients stay connected, and it is implemented as background scan. If it causes issues in your environment, use a larger interval or plan out frequencies manually.

The "Link Down" counter increases ever time a reselect happens. Why does that happen? It should not go down on a background scan. I mean, as links go down if no clients connected also. But the time between down/up is so minimal I cant believe in coincidence.

I can only report what I see in Winbox: 3 connected/active clients. State changes from "running" to "reselecting channel". State changes to "running". 0 connected/active clients. They all went to another CAP 2ghz BSSID. And this must be some huge coincidence when 3 clients leave at the same time without a specific reason.

Bildschirmfoto 2024-08-16 um 12.53.41.png

That being said, this discussion should be in a separate topic.

In another topic we/I dont have the attention of Mikrotik staff. Separate topics are more like community-only discussions.

Fri Aug 16, 2024 3:40 pm

If different channel is selected, as result of reselect-interval, the state will change and clients will be disconnected - as they need to use different channel.
When reselect-interval is ran (the background scan is being performed), the "state" won't change from "running". It will only change in the event of actual channel change.
Why the clients got disconnected in your tests, we can only speculate, perhaps they were more sensitive to changes in RF, perhaps slightly increased latency during scan. In our lab tests, we can confirm that both wifi-qcom and wifi-qcom-ac can keep client's connected during the reselect-interval, and for simple test, ping to connected station is not dropped either during it, both on 2.4GHz and 5GHz interfaces, on DFS and on non-DFS channels. Of course, this is only in the event that the channel is not actually changed.
If you believe that there is something we can improve, please feel free to write to suppport@mikrotik.com, let's keep this topic specific to this release.

toxicfusion · Fri Aug 16, 2024 8:43 pm

I feel MikroTik needs to do futher testing in their lab, or we continue to send supout files. Clients are being disconnected during reselect-interval; there is no real background scan being performed...

Also. wifi-qcom-ac driver package we feel is not as stable as the regular wireless package [WiFi5]. We're seeing ALOT of client disconnects / re-connects, without any real reason. This was after "uprade" to qcom-ac.

Lastly. MikroTik -- Please update documentation or release a statement about the CAPsMAN "Provision" functionality. There are times were config changes are NOT immediately pushed to CAPs and we see the "Provision" option, and we assume this does what states.... provision the CAP(s)....... But no, it instead re-creates the WLAN interfaces on the CAPS. Which in turn, breaks the interfaces in bridge for VLAN assignment when using qcom-ac.

own3r1138 · Fri Aug 16, 2024 9:29 pm

There was a possibility that OVPN router can get a "Kernel Failure". If you have a router running OVPN and it sometimes reboots due to a Kernel Failure, then upgrade and see how it goes. If the problem remains, then of course contact support@mikrotik.com and send supout file.

Thank you very much.

pe1chl · Fri Aug 16, 2024 9:44 pm

One problem that has been in RouterOS v7 for some time and is still in 7.16rc2 is that when a BGP session is established, the routes are not exchanged until after one "keepalive" time.
(initially there is the Open message received and sent, but no routes are established, then after the keepalive time, 60s by default, the route updates are sent)

sirbryan · Fri Aug 16, 2024 11:06 pm

FYI: MLAG issue: two CRS317 in MLAG, with ESX hosts dual connected to CRS317 (not LACP, but having ESX decide which switch to send traffic based on the port up status, and the MAC address of the VM). When switch 1 goes down for firmware upgrade, all is ok, ESX starts using switch 2 for all VMs. When switch 1 comes back on line, ESX switches back to using switch 1 for some VMs. But I can't access half of my VMs for around 15 minutes. Then all is well again. Frustrating. I also cannot ping switch 1 for that period of time even though it is up (so it is not just the ESX hosts having an issue with the MLAG mac cache). The CRS317s are connected LACP to a CRS328P floor switch, which I am connected to. Since I can't ping switch 1, I assume the floor switch has learnt that its path is via switch 2, and something is going wrong there.

Does it work fine on earlier versions? (I'm asking because I'm considering a similar setup in the future. I have three MLAG stacks, just not using them for ESXi yet)

I have seen behavior similar to this when my bridge and RSTP settings on the switches weren't exactly identical.

pe1chl · Fri Aug 16, 2024 11:46 pm

FYI: MLAG issue: two CRS317 in MLAG, with ESX hosts dual connected to CRS317 (not LACP, but having ESX decide which switch to send traffic based on the port up status, and the MAC address of the VM).

Are you sure you want to configure MLAG for that? I think in this config you should just plug the two ESXi ethernet ports into two switchports without any special config on the switch...

coddy · Sat Aug 17, 2024 2:32 am

MLAG is configured to support the top of rack switches and floor switches which connect to both fabric switches using LACP. Yes ESXi will happily work without mlag across two switches.

The issue is the floor switch losing connectivity to half the VMs and one of the fabric switch management IPS when the fabric switch comes back up, after a period of time this resolves (5-15 mins) and everything works again. Rapid Spanning tree is not blocking. But I'll do more looking into that. The mlag switches are connected together with two dac cables in lag for the peerlink.

The issue looks like some L2 Mac forwarding table issue, the other fabric switch possibly thinks it owns those macs still, and eventually they expire and things start working again.

Possibly mlag not synchronising these with its peer for some reason. I'm not sure.

pe1chl · Sat Aug 17, 2024 10:40 am

Yes, it looks like there is some issue with updating of the MAC table. Probably the switches do not send MAC table updates around when they observe a new MAC incoming on some port, and it had seen before on another port, without link down/up event.
Only after the MAC entry times out, it is being refreshed and everything works again.
Maybe things would be better when ESXi would support a port aggregation protocol like LACP, but it does not.
(at least not without buying extra products)

coddy · Sat Aug 17, 2024 11:44 am

ESXi is just the obvious user facing issue. Ignoring that, I still have the obvious problem of not being able to ping one of the switch management interfaces for this period of time also, indicating the problem is to do with the L2 Mac table, not ESXi. At a guess the mlag switches are not synchronising L2 information regularly enough, especially on restart.

pgotze · Sat Aug 17, 2024 12:07 pm

IP / SMB / SHARES - required-encryption option leads to hard restart of RB5009 in 7.15, is it already solved in this version, or in what version is planned? Some info?

saaremaa · Sat Aug 17, 2024 1:24 pm

Hardware: CCR1016-12G
Firmware: 7.16rc2
We observe an oddity in the Radius: Interim-Update packets from the DHCPv6 north. The session time is reset even if no STOP packet has arrived.

Let's try to describe in detail:
1. The user obtained IPV6 using DHCPv6. The session has started.

Fri Aug 16 18:12:25 2024
	NAS-Port-Type = Ethernet
	NAS-Port = 2209353285
	Service-Type = Framed-User
	Calling-Station-Id = "e48d8c2f405b"
	User-Name = "E4:8D:8C:2F:40:5B"
	Called-Station-Id = "171000351.ipv6"
	Delegated-IPv6-Prefix = <removed>
	Event-Timestamp = "Aug 16 2024 18:12:25 EET"
	Acct-Status-Type = Start
	Acct-Session-Id = "450eb083"
	Acct-Authentic = RADIUS
	Class = 0x3238393838646232383939323239303264623134646436613364383636373965
	NAS-Identifier = "IPOE-0"
	Acct-Delay-Time = 0
	NAS-IP-Address = <removed>
	Acct-Unique-Session-Id = "40b7eea37b07aa4543e826c0a80b737b"
	Timestamp = 1723824745

2. Interim-Update packages arrive and the Acct-Session-Time in them increases as it should.

Fri Aug 16 18:17:05 2024
	NAS-Port-Type = Ethernet
	NAS-Port = 2209353318
	Service-Type = Framed-User
	Calling-Station-Id = "e48d8c2f405b"
	User-Name = "E4:8D:8C:2F:40:5B"
	Called-Station-Id = "171000351.ipv6"
	Delegated-IPv6-Prefix = <removed>
	Event-Timestamp = "Aug 16 2024 18:17:05 EET"
	Acct-Status-Type = Interim-Update
	Acct-Session-Id = "660eb083"
	Acct-Authentic = RADIUS
	Acct-Session-Time = 60
	Class = 0x3238393838646232383939323239303264623134646436613364383636373965
	NAS-Identifier = "IPOE-0"
	Acct-Delay-Time = 0
	NAS-IP-Address = <removed>
	Acct-Unique-Session-Id = "33ab053815a4fd07179d97876cb508c3"
	Timestamp = 1723825025

Fri Aug 16 18:18:05 2024
	NAS-Port-Type = Ethernet
	NAS-Port = 2209353318
	Service-Type = Framed-User
	Calling-Station-Id = "e48d8c2f405b"
	User-Name = "E4:8D:8C:2F:40:5B"
	Called-Station-Id = "171000351.ipv6"
	Delegated-IPv6-Prefix = <removed>
	Event-Timestamp = "Aug 16 2024 18:18:05 EET"
	Acct-Status-Type = Interim-Update
	Acct-Session-Id = "660eb083"
	Acct-Authentic = RADIUS
	Acct-Session-Time = 120
	Class = 0x3238393838646232383939323239303264623134646436613364383636373965
	NAS-Identifier = "IPOE-0"
	Acct-Delay-Time = 0
	NAS-IP-Address = <removed>
	Acct-Unique-Session-Id = "33ab053815a4fd07179d97876cb508c3"
	Timestamp = 1723825085

3. The user requested an ipv6 update from DHCPv6. The address has been updated. No radius stop packet from the hardware as expected. Acct-Session-Time reset and started counting down from some arbitrary value of its own. Why is this happening? Acct-Session-Time should not reset unless there is no STOP packet.

Fri Aug 16 18:19:05 2024
	NAS-Port-Type = Ethernet
	NAS-Port = 2209353318
	Service-Type = Framed-User
	Calling-Station-Id = "e48d8c2f405b"
	User-Name = "E4:8D:8C:2F:40:5B"
	Called-Station-Id = "171000351.ipv6"
	Delegated-IPv6-Prefix = <removed>
	Event-Timestamp = "Aug 16 2024 18:19:05 EET"
	Acct-Status-Type = Interim-Update
	Acct-Session-Id = "660eb083"
	Acct-Authentic = RADIUS
	Acct-Session-Time = 30
	Class = 0x3238393838646232383939323239303264623134646436613364383636373965
	NAS-Identifier = "IPOE-0"
	Acct-Delay-Time = 0
	NAS-IP-Address = <removed>
	Acct-Unique-Session-Id = "33ab053815a4fd07179d97876cb508c3"
	Timestamp = 1723825145

Fri Aug 16 18:20:06 2024
	NAS-Port-Type = Ethernet
	NAS-Port = 2209353318
	Service-Type = Framed-User
	Calling-Station-Id = "e48d8c2f405b"
	User-Name = "E4:8D:8C:2F:40:5B"
	Called-Station-Id = "171000351.ipv6"
	Delegated-IPv6-Prefix = <removed>
	Event-Timestamp = "Aug 16 2024 18:20:05 EET"
	Acct-Status-Type = Interim-Update
	Acct-Session-Id = "660eb083"
	Acct-Authentic = RADIUS
	Acct-Session-Time = 90
	Class = 0x3238393838646232383939323239303264623134646436613364383636373965
	NAS-Identifier = "IPOE-0"
	Acct-Delay-Time = 0
	NAS-IP-Address = <removed>
	Acct-Unique-Session-Id = "33ab053815a4fd07179d97876cb508c3"
	Timestamp = 1723825206

Is this a bug or normal behavior?
Please check this point. It is important for us, because of this kind of work the accounting in Freeradius is incorrect.
Meanwhile, in the Interim-Update radius packages from DHCPv4, everything is fine and works as it should.
Thnx.

bommi · Sun Aug 18, 2024 11:41 am

IP / SMB / SHARES - required-encryption option leads to hard restart of RB5009 in 7.15, is it already solved in this version, or in what version is planned? Some info?

On my hEX s the smb with encryption is stable on 7.16rc2, but this device uses an other CPU architecture.

I would suggest to create a supout after your device crashed and send it to the support.

pgotze · Sun Aug 18, 2024 11:52 am

IP / SMB / SHARES - required-encryption option leads to hard restart of RB5009 in 7.15, is it already solved in this version, or in what version is planned? Some info?
On my hEX s the smb with encryption is stable on 7.16rc2, but this device uses an other CPU architecture.

I would suggest to create a supout after your device crashed and send it to the support.

It is, its confirmed bug, which will be corrected in some new RouteOS version. Im just interested, if in this version problem still exists, or is solved.

pe1chl · Sun Aug 18, 2024 12:08 pm

Usually when a bug like that is solved, you will see a line like "improved system stability when smb is used with encryption".
As long as it is not there, it is safest to assume it has not yet been solved.

bratislav · Mon Aug 19, 2024 12:48 pm

Maybe things would be better when ESXi would support a port aggregation protocol like LACP, but it does not.
(at least not without buying extra products)

vSphere supports LACP on distributed switches which are available with Enterprise license and not as a separate extra product...

coddy · Mon Aug 19, 2024 1:50 pm

The issue is not ESX, that is just a highly visible victim. The floor switch (crs328p) connected lacp across both crs317 (mlag) switches also loses the ability to ping one of the mlag switches for a period of time 5-15mins after the switch has actually finished rebooting. It seems like the mlag is not flushing its L2 mac cache when it's peer comes back online, or the two are not synchronising their L2 mac caches. That is a guess. Let's leave ESX out of it. MT issue.

bratislav · Wed Aug 21, 2024 2:42 pm

The issue is not ESX, that is just a highly visible victim. The floor switch (crs328p) connected lacp across both crs317 (mlag) switches also loses the ability to ping one of the mlag switches for a period of time 5-15mins after the switch has actually finished rebooting. It seems like the mlag is not flushing its L2 mac cache when it's peer comes back online, or the two are not synchronising their L2 mac caches. That is a guess. Let's leave ESX out of it. MT issue.

I was replying to the claim that ESX lacks LACP which may be the issue, on the other hand I do have environment with ESX hosts without LACP support configured and switches that do use LACP (some not Mikrotik ) with 2 CRS309-1G-8S+ in MLAG setup and I don't experience any communication issues when restarting either one of them...
I do have dedicated peer interface (2 DACs in 802.3ad bond) and with dedicated PVID and once it is up MLAG goes up too and MAC tables are synced... and everything works fine... at least for me it does... so it may not be MT issue after all...

erlinden · Wed Aug 21, 2024 4:37 pm

I ran into a problem with VLAN's: wireless clients got MGT VLAN addresses assigned as well as HOME VLAN addresses. Found out from looking at the DHCP leases and IP ARP entries. After downgrading to 7.15.3 the problem was solved.

Yes, all information was supplied to support.

bommi · Wed Aug 21, 2024 8:18 pm

I ran into a problem with VLAN's: wireless clients got MGT VLAN addresses assigned as well as HOME VLAN addresses. Found out from looking at the DHCP leases and IP ARP entries. After downgrading to 7.15.3 the problem was solved.

Yes, all information was supplied to support.

Standalone AP or using CAPsMan?

coddy · Thu Aug 22, 2024 12:47 am

@bratislav, interesting, as I have the same setup, including 2 DACs in 802.3ad bond for peer link with dedicated PVID. All VLANs are tagged on the LAG-PeerLink except for the PVID (3999) for the peerlink, which is untagged on LAG-PeerLink. Multiple LACP bonds to fabric switches (some MT some not), and yet I have this problem. Bridge shows both MLAG peers are connected one as primary, the other as secondary with the same system id.

LACP bonds from remote switches across the fabric are working, with traffic on both ports. Rapid spanning tree setup is identical on both MAG switches with their priority set to ensure they are the root (2000 hex).

Only thing I can think of is how are you managing the switches (assigning the L3 IP address). In my case I create a VLAN interface under my br-trunk and add an IP address to that VLAN interface. Bridge is set with vlan filtering enabled, each interface ethernet switch port is set to l3-hw-offloading=no. Any differences (I am using CRS-317 vs you using CRS-309 but that should not be an issue).

erlinden · Thu Aug 22, 2024 9:53 am

Standalone AP or using CAPsMan?

CAPsMAN:

RB4011, 2x RB960 (v6.49.13), 1x Powerbox Pro (v6.49.13), 2x cAP AX, 1x wAP ac

bratislav · Thu Aug 22, 2024 11:35 am

@bratislav, interesting, as I have the same setup, including 2 DACs in 802.3ad bond for peer link with dedicated PVID. All VLANs are tagged on the LAG-PeerLink except for the PVID (3999) for the peerlink, which is untagged on LAG-PeerLink. Multiple LACP bonds to fabric switches (some MT some not), and yet I have this problem. Bridge shows both MLAG peers are connected one as primary, the other as secondary with the same system id.

LACP bonds from remote switches across the fabric are working, with traffic on both ports. Rapid spanning tree setup is identical on both MAG switches with their priority set to ensure they are the root (2000 hex).

Only thing I can think of is how are you managing the switches (assigning the L3 IP address). In my case I create a VLAN interface under my br-trunk and add an IP address to that VLAN interface. Bridge is set with vlan filtering enabled, each interface ethernet switch port is set to l3-hw-offloading=no. Any differences (I am using CRS-317 vs you using CRS-309 but that should not be an issue).

Peer link seems to be the same as mine, just to mention that it shouldn't have MLAG ID assigned...

I am using MSTP since it is VLAN aware unlike RSTP, but my MLAG switches are not the root on any MSTI...

IP address is assigned to Bridge (using bridge PVID for management), although I should have probably used management interface ether1 which is not part of the switch/bridge...
Not to mess with every single interface L3 offloading is set to no globally, the default actually, with:

interface/ethernet/switch/set switch1 l3-hw-offloading=no

prawira · Thu Aug 22, 2024 12:08 pm

hello,

is it possible to add the following features (security reasons) for users who log-in into router ?
+ max active session on the same time for each apps; winbox, telnet, ssh, etc
+ automatic logged out if inactive during certain duration

also, please fix the DIH flag on /ip arp for the interface with arp=reply-only and hotspot active on it - [SUP-136090]
i understand ros v6 having different behaviour with ros v7. but if this method can run on v6, why this can not be done on v7 ?

thank you

infabo · Thu Aug 22, 2024 10:53 pm

We have found that there is a linux kernel driver issue with intel ax201/ax210 cards, that exists in all linux based operating systems, we are trying to find ways to handle these clients better, so if you can reliably repeat these issues and you have this card, send us a supout.rif file to support

These cards cost around 20eur. Make the investment and do investigation. It is easier and more efficient than analyzing supout files from customers. 😉

ormandj · Thu Aug 22, 2024 11:07 pm

We have found that there is a linux kernel driver issue with intel ax201/ax210 cards, that exists in all linux based operating systems, we are trying to find ways to handle these clients better, so if you can reliably repeat these issues and you have this card, send us a supout.rif file to support
These cards cost around 20eur. Make the investment and do investigation. It is easier and more efficient than analyzing supout files from customers. 😉

It's also one of the most prolific cards in use today, generally considered one of the best options available, at least in the US.

remkolodder · Fri Aug 23, 2024 10:42 am

The issue is not ESX, that is just a highly visible victim.

Only taking that part to respond to: ESXi works perfectly fine without bonding (LACP, etc). It has an internal mechanism in it's switching technology (mainly distributed switches) that handles this for you. At work we have a lot of these hosts connected to regular downlink ports (more or less) and ar enot using LACP. If you face issues it is (in a normal configuration) not ESXi's problem but upstream (switches etc.).

Edited: got complaints to make it a more normal post.. here it is Master Onno ;-)

bjoerns · Tue Aug 27, 2024 12:37 pm

getting this when i try to connect arm64 chr instances running 7.16rc2. no tests done running other versions. x86 and and routerboards on 7.16rc2 are fine:

[admin@xxx] > system/ssh 192.168.0.157
signatures are not matching!

root@xxx:~# ssh admin@192.168.0.157
ssh_dispatch_run_fatal: Connection to 192.168.0.157 port 22: incorrect signature

syadnom · Tue Aug 27, 2024 2:47 pm

7.16r2 'stops routing' on an RB4011. can't ping out from the device, but winbox works.

unfortunately this was in production and I couldn't pull support files.

pe1chl · Tue Aug 27, 2024 3:26 pm

7.16r2 'stops routing' on an RB4011. can't ping out from the device, but winbox works.

unfortunately this was in production and I couldn't pull support files.

Not really useful when there is no info at all about what e.g. the previous installed version was, and what kind of configuration it is running.
When it has multiple routing tables, check if the extra tables weren't deleted during upgrade.

Wed Aug 28, 2024 9:48 am

What's new in 7.16rc3 (2024-Aug-26 15:17):

*) bridge - fixed port enable after BPDU guard detected (introduced in v7.16beta1);
*) dhcp - improved DHCP IPv4 and IPv6 client/relay/server underlying interface state change handling (additional fixes);
*) dns - added support for mDNS proxy (additional fixes);
*) dns - revert "match NXDOMAIN static entry only if other type entries for the same name are not found" (introduced in v7.16beta7);
*) ethernet - fixed "disable/enable" for non-switch interfaces (introduced in v7.16beta7);
*) ethernet - fixed false running link status for ARM64 devices (introduced in v7.16beta5);
*) hotspot - properly escape all reserved URI characters;
*) ipsec - fixed setting "static-dns" for mode configuration (introduced in v7.16beta1);
*) lte - fixed cases where "at-chat" would become unavailable after modem hung up port (introduced in v7.16beta1);
*) lte - fixed signal info for R11e-LTE6 modem (introduced in v7.16beta1);
*) route - fixed blackhole route scope (introduced in v7.16beta2);
*) system - improved system stability for CCR2004-1G-2XS-PCIe device;
*) webfig - correctly display default value for number type (additional fixes);
*) webfig - fixed issue with incorrectly applying optional fields (additional fixes);

zharov · Wed Aug 28, 2024 10:25 am

After an 11 day of uptime on 7.16rc2 I got a very strange issue. It was fixed after hard-reboot (unplug the device).

- Every tab on the Webfig and Winbox shows nothing, except of logs, showing only logs prior the issue
- Couldn't connect to the device using IKEv2/IPSec
- Couldn't generate Supout.inf
- Couldn't ask the device to reboot
- Bridge/WAN works, I could access Internet/Webfig/Winbox from the LAN (Wi-Fi, LAN)

hAP ax2. Stock home config + RW IKEv2/IPsec + UserManager

pe1chl · Wed Aug 28, 2024 10:40 am

I would guess a memory leak... but little that can be diagnosed after a reboot.
You could still send the supout.rif in a support ticket, they often claim they can see things there even after a crash/reboot.

ppptran · Wed Aug 28, 2024 11:01 am

Wow , and X86 wifi still broken .

infabo · Wed Aug 28, 2024 11:07 am

ppptran, this is your first comment in this topic. Have you reported your issue somewhere else? Mikrotik are no mind-reader.

ppptran · Wed Aug 28, 2024 1:53 pm

ppptran, this is your first comment in this topic. Have you reported your issue somewhere else? Mikrotik are no mind-reader.

Well, i am well aware of the issue. I have search the whole mikrotik forum and it came up with several fellas have the same issue.
Basically:

Im using X86 and Compex WLE900VX 7AA ( QCA9880 , mpcie)

The only version of Router OS that make this wifi card fully functional is Ver 7.5 and 7.6 . That's it.
All other version up until now ver 7.16RC, it seem that the card Radio is Disable.

Bellow picture is current Ver 7.16RC

infabo · Wed Aug 28, 2024 2:25 pm

I think this is worth reporting to https://help.mikrotik.com/servicedesk/servicedesk

And:

*) dns - revert "match NXDOMAIN static entry only if other type entries for the same name are not found" (introduced in v7.16beta7);

Glad to see this changed revered. 👍

pe1chl · Wed Aug 28, 2024 2:28 pm

Indeed. Although sometimes MikroTik employees read the forum, they do not use it to collect information about problems and any problems reported (only) here rarely do end up being fixed.

kleshki · Wed Aug 28, 2024 4:34 pm

ppptran, this is your first comment in this topic. Have you reported your issue somewhere else? Mikrotik are no mind-reader.
Well, i am well aware of the issue. I have search the whole mikrotik forum and it came up with several fellas have the same issue.
Basically:

Im using X86 and Compex WLE900VX 7AA ( QCA9880 , mpcie)

The only version of Router OS that make this wifi card fully functional is Ver 7.5 and 7.6 . That's it.
All other version up until now ver 7.16RC, it seem that the card Radio is Disable.

Bellow picture is current Ver 7.16RC

Have you give a shot for another wireless packages (i.e. wifi-qcom-ac or wave2)?

msilcher · Wed Aug 28, 2024 9:41 pm

*) dns - revert "match NXDOMAIN static entry only if other type entries for the same name are not found" (introduced in v7.16beta7);

Can someone from Mikrotik explain why?

infabo · Wed Aug 28, 2024 10:01 pm

you can look up the discussion on the negative impact of the original change here in the topic.

msilcher · Wed Aug 28, 2024 11:10 pm

you can look up the discussion on the negative impact of the original change here in the topic.

I did. I have a different condition and this revertion is affecting me. Example:

DNS servers: 8.8.8.8/8.8.4.4 -> public
Static FWD for private zone: subdomain1.private -> 10.10.10.1

When there is a client that asks for subdomain2.private Mikrotik forwards this query to 8.8.8.8 and gets a NXDOMAIN for the WHOLE .private zone, then the static FWD entry doesn't work anymore.

I reported this to Mikrotik. Maybe this DNS issue needs a rework but a NXDOMAIN for a TLD should not break a FWD zone entry.

infabo · Wed Aug 28, 2024 11:19 pm

I think I understand your use-case - but not your explanations why it would break. Mikrotik DNS client does - AFAIK - not cache NXDOMAIN. So no matter how often you try to resolve "<random>.private": once you make an NS resolve request to "subdomain1.private" the FWD entry will be used. Isn't this working for you?

msilcher · Thu Aug 29, 2024 3:21 am

I think I understand your use-case - but not your explanations why it would break. Mikrotik DNS client does - AFAIK - not cache NXDOMAIN. So no matter how often you try to resolve "<random>.private": once you make an NS resolve request to "subdomain1.private" the FWD entry will be used. Isn't this working for you?

In fact negative DNS entries are cached. I got the whole TLD (.private) cached as NXDOMAIN and the FWD didn't work. I tested the whole thing and provided evidence to Mikrotik support.

Institor · Thu Aug 29, 2024 5:28 am

In fact negative DNS entries are cached. I got the whole TLD (.private) cached as NXDOMAIN and the FWD didn't work. I tested the whole thing and provided evidence to Mikrotik support.

Didn't install 7.16 yet, and i do not see this behavior in 7.15.3... But: you can add static entry to the whole TLD:

 /ip/dns/static/add name=private. forward-to=10.10.10.1 match-subdomain=yes

Have you tried this?

pe1chl · Thu Aug 29, 2024 10:04 am

I'm still not sure if I should laugh or if I should cry...

thorkelau · Thu Aug 29, 2024 10:29 am

Quick potential ‘gotcha’ for people (that got me anyway).
I installed the 7.16 beta on a new RB5009 a month or two ago because of the native mDNS repeater support. But, at the time, it didn’t seem to work for me so I kept the beta on the device but went back to the container I’d been using for mDNS repeating across VLANs. What I didn’t do was turn off the native mDNS functionality……

Rc3 appears to have fixed the native mDNS support for me (fantastic). But, the only reason I noticed is I had a lot of client devices on the network spinning up to very high CPU - this was homebridge and avahi processes maxing out. The mDNS container and the native mDNS were basically amplifying each other. RB5009 was running absolutely fine, and mDNS was functioning - the main symptom was seeing computing devices go to 100% CPU use after installing rc3 on the router.

msilcher · Thu Aug 29, 2024 2:23 pm

In fact negative DNS entries are cached. I got the whole TLD (.private) cached as NXDOMAIN and the FWD didn't work. I tested the whole thing and provided evidence to Mikrotik support.
Didn't install 7.16 yet, and i do not see this behavior in 7.15.3... But: you can add static entry to the whole TLD:
Code: Select all
 /ip/dns/static/add name=private. forward-to=10.10.10.1 match-subdomain=yes 
Have you tried this?

I did and I also tried adding a static entry for "private" pointing to 127.0.0.1 (to avoid getting a NXDOMAIN from the upstream public DNS) and then using a FWD for subdomain1.private to 10.10.10.1. Those count as workarounds, not real fixes.

infabo · Thu Aug 29, 2024 2:28 pm

In fact negative DNS entries are cached. I got the whole TLD (.private) cached as NXDOMAIN and the FWD didn't work. I tested the whole thing and provided evidence to Mikrotik support.

Is this a 7.16 behaviour? I can't see any NXDOMAIN cache entry added on 7.15.3 when doing e.g.

:put [:resolve foo.private]

msilcher · Thu Aug 29, 2024 2:30 pm

To continue with Mikrotik DNS issues, here is another one:

- Static A record for "test.example.com" -> 1.2.3.4
- static A record for "example.com" with "match subdomain" (as wildcard entry) -> 4.3.2.1

The first one will never work, wildcard takes precedency always. More specific entries should have priority. This happens in any real DNS server...

infabo · Thu Aug 29, 2024 2:32 pm

This is not specific to 7.16. It has been this way < 7.16 as well. It bugged me as well.

msilcher · Thu Aug 29, 2024 2:38 pm

In fact negative DNS entries are cached. I got the whole TLD (.private) cached as NXDOMAIN and the FWD didn't work. I tested the whole thing and provided evidence to Mikrotik support.
Is this a 7.16 behaviour? I can't see any NXDOMAIN cache entry added on 7.15.3 when doing e.g.
Code: Select all
:put [:resolve foo.private]

Using 7.15.2 BTW

infabo · Thu Aug 29, 2024 2:41 pm

Then your upstream DNS server responds with 0.0.0.0. Basically it.

msilcher · Thu Aug 29, 2024 2:44 pm

Then your upstream DNS server responds with 0.0.0.0. Basically it.

It is a negative answer, Mikrotik puts 0.0.0.0 in their cache. This breaks basically any FWD entry for this parent zone as I mentioned before.

infabo · Thu Aug 29, 2024 2:50 pm

TIL: there is

/ip/dns/cache/all/print

which shows you really all cache entries.

Unlike

/ip/dns/cache/print

msilcher · Thu Aug 29, 2024 2:51 pm

Then your upstream DNS server responds with 0.0.0.0. Basically it.
It is a negative answer, Mikrotik puts 0.0.0.0 in their cache. This breaks basically any FWD entry for this parent zone as I mentioned before.

Here is the real example, the whole TLD "private" gets negative cached. No FWD entry for submain will work.
Tested from a Windows client, not a script within the terminal

infabo · Thu Aug 29, 2024 2:53 pm

Then your upstream DNS server responds with 0.0.0.0. Basically it.
It is a negative answer, Mikrotik puts 0.0.0.0 in their cache. This breaks basically any FWD entry for this parent zone as I mentioned before.

I can confirm. Negative answers are cached and live until you flush the cache. This is really a PITA and I am wondering if this is "mikrotik way" or if this is conforming a RFC.

But still: not strictly related to 7.16.

msilcher · Thu Aug 29, 2024 2:59 pm

It is a negative answer, Mikrotik puts 0.0.0.0 in their cache. This breaks basically any FWD entry for this parent zone as I mentioned before.
I can confirm. Negative answers are cached and live until you flush the cache. This is really a PITA and I am wondering if this is "mikrotik way" or if this is conforming a RFC.

But still: not strictly related to 7.16.

Thank you!

FWD entries should have precedence, thats why you set them up in the first place. I agree that a NXDOMAIN should ban anything under it, but FWD entries are there for a reason ;). Particulary for private zones living togheter with public internet zones.

infabo · Thu Aug 29, 2024 3:08 pm

I don't know if NXDOMAIN (non-existing domain) is the same as "NEGATIVE" from Mikrotik DNS cache.

pe1chl · Thu Aug 29, 2024 3:12 pm

I can confirm. Negative answers are cached and live until you flush the cache.

Of course, caching negative answers is "normal", but in most normal resolvers you can separately set the cache time for negative answers (so you can set it very low or 0).
Still, this complicated handling of priority of different kinds of records has never been under control in RouterOS. Every time the programmer touches the code, there is another "unexpected" problem. Probably it is hard to find a programmer with experience in DNS, and we will have to live with this until finally we get the option of using a well-established resolver (if only as an optional package).

msilcher · Thu Aug 29, 2024 3:13 pm

I don't know if NXDOMAIN (non-existing domain) is the same as "NEGATIVE" from Mikrotik DNS cache.

It is, create a static NXDOMAIN record and look in the cache...

msilcher · Thu Aug 29, 2024 4:16 pm

I can confirm. Negative answers are cached and live until you flush the cache.
Of course, caching negative answers is "normal", but in most normal resolvers you can separately set the cache time for negative answers (so you can set it very low or 0).
Still, this complicated handling of priority of different kinds of records has never been under control in RouterOS. Every time the programmer touches the code, there is another "unexpected" problem. Probably it is hard to find a programmer with experience in DNS, and we will have to live with this until finally we get the option of using a well-established resolver (if only as an optional package).

Having the option to set NXDOMAIN ttl to 0 (or very low) is also not really a smart choice, it would help in the specific use case you need it but would also affect the other 99,9% of the NXDOMAIN queries you would normally cache (to avoid hammering upstream DNS servers with NXDOMAIN queries).

IMHO setting internal "logics" or "priorities" in the Mikrtok DNS server for some type of records should fix the whole thing in a smart way. This could also cover the "wildcard vs specific record" issue I mentioned before.

pe1chl · Thu Aug 29, 2024 4:40 pm

I don't want to claim that it is smart to do that, but at least it offers the opportunity to work around some bugs, not only in the resolver but also sometimes in the DNS configuation on internet (e.g. some domain with a server that is no longer serving the domain).
I usually set the cache for positive replies to like 1-2 hours, and for negative replies to 10 minutes.

jfim88 · Thu Aug 29, 2024 5:00 pm

Still no fix for igmp bug found on SUP-152693 that has my ax2 parked until I can use my ISP IPTV service with no cuts/pixelations. Sad.

infabo · Thu Aug 29, 2024 5:07 pm

You can set your hopes in 7.17. Introducing "new" fixes in a RC is not the goal of a RC release.

jfim88 · Thu Aug 29, 2024 6:27 pm

You can set your hopes in 7.17. Introducing "new" fixes in a RC is not the goal of a RC release.

Fingers crossed for 7.17

Fri Aug 30, 2024 2:13 pm

What's new in 7.16rc4 (2024-Aug-30 09:24):

*) lte - improved modem AT/modem port open (additional fixes);
*) lte - improvements to "/interface/lte/show-capabilities" command (additional fixes);
*) system - improved system stability (additional fixes);

itimo01 · Fri Aug 30, 2024 8:56 pm

I have a single hap ac2 running with a wireless uplink on the 5ghz interface.

When upgrading from 7.15.3 to 7.16rc3 it ran into a kernel panic and then when it finally booted i was missing the wifi2 interface.
Then again upgrading from 7.16rc3 to rc4 also caused the same issue.

I had to netboot to restore the wifi2 interface.

 15:45:37 system,error,critical router was rebooted without proper shutdown, probably kernel failure
 15:45:37 system,error,critical router was rebooted without proper shutdown, probably kernel failure
 15:45:38 system,error,critical kernel failure in previous boot
 15:45:38 system,error,critical kernel failure in previous boot
 15:45:38 interface,info lo link up
 15:45:40 disk,info add usb1-part1 size:31.5G fs:fat32
 15:45:47 bridge,info hardware offloading activated on bridge "bridge" ports: ether1,ether3,ether2,ether5,ether4
 15:45:50 interface,info ether3 link up (speed 1G, full duplex)
 15:46:19 system,info,account user admin logged in from 34:29:8F:99:9F:62 via winbox
 15:46:20 script,warning DefConf gen: Unable to find wifi radio data
 15:46:20 system,error,critical error while running customized default configuration script: interrupted
 15:46:20 system,error,critical error while running customized default configuration script: interrupted
 15:46:20 system,error,critical 
 15:46:20 system,error,critical

EDIT: Did anyone else run into a similar issue?

infabo · Fri Aug 30, 2024 9:20 pm

*) lte - improved modem AT/modem port open;

What is "modem port open"? Faster? More stable?