Community discussions

MikroTik App
 
EdPa
MikroTik Support
MikroTik Support
Topic Author
Posts: 325
Joined: Fri Sep 15, 2017 10:05 am
Location: Riga
Contact:

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
Frequent Visitor
Frequent Visitor
Posts: 66
Joined: Tue May 07, 2024 8:57 pm

Re: v7.16rc [testing] is released!

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
Member Candidate
Member Candidate
Posts: 199
Joined: Tue Mar 10, 2020 6:37 am

Re: v7.16rc [testing] is released!

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
 
User avatar
BrateloSlava
Member Candidate
Member Candidate
Posts: 176
Joined: Mon Aug 09, 2021 10:33 am
Location: Ukraine, Kharkiv

Re: v7.16rc [testing] is released!

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
just joined
Posts: 9
Joined: Sun Oct 26, 2014 10:14 am

Re: v7.16rc [testing] is released!

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
Member
Member
Posts: 351
Joined: Sat Jul 20, 2013 2:40 pm

Re: v7.16rc [testing] is released!

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
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26807
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

Re: v7.16rc [testing] is released!

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
just joined
Posts: 18
Joined: Tue Jun 15, 2021 12:25 am

Re: v7.16rc [testing] is released!

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
just joined
Posts: 9
Joined: Sun Oct 26, 2014 10:14 am

Re: v7.16rc [testing] is released!

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
Member Candidate
Member Candidate
Posts: 199
Joined: Tue Mar 10, 2020 6:37 am

Re: v7.16rc [testing] is released!

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.
 
User avatar
maisondasilva
just joined
Posts: 1
Joined: Sun Apr 21, 2024 1:56 pm
Contact:

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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).
 
User avatar
cxcool
just joined
Posts: 7
Joined: Sun May 12, 2019 5:13 am

Re: v7.16rc [testing] is released!

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
Member Candidate
Member Candidate
Posts: 126
Joined: Thu Sep 15, 2022 7:15 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
Member
Member
Posts: 393
Joined: Mon Oct 09, 2006 2:33 pm

Re: v7.16rc [testing] is released!

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
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1083
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v7.16rc [testing] is released!

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.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3333
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: v7.16rc [testing] is released!

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
newbie
Posts: 31
Joined: Wed May 17, 2023 8:36 pm

Re: v7.16rc [testing] is released!

Wed Aug 07, 2024 12:20 pm

Routing, BGP and DHCP client on 4011 works well.
 
x4b1
just joined
Posts: 1
Joined: Fri Jun 16, 2023 3:55 am

Re: v7.16rc [testing] is released!

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.
 
User avatar
dang21000
newbie
Posts: 35
Joined: Sat Feb 25, 2023 2:30 pm
Location: France

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
just joined
Posts: 7
Joined: Tue Aug 18, 2009 5:48 am

Re: v7.16rc [testing] is released!

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
newbie
Posts: 31
Joined: Wed May 17, 2023 8:36 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.16rc [testing] is released!

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
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.16rc [testing] is released!

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
Member Candidate
Member Candidate
Posts: 113
Joined: Sat Jul 11, 2015 2:40 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26807
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

Re: v7.16rc [testing] is released!

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
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7154
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Member
Member
Posts: 367
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.16rc [testing] is released!

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.
You do not have the required permissions to view the files attached to this post.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26807
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
just joined
Posts: 18
Joined: Thu Jun 29, 2023 2:55 am
Location: Germany
Contact:

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26807
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

Re: v7.16rc [testing] is released!

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
Member
Member
Posts: 351
Joined: Sat Jul 20, 2013 2:40 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
osc86
Member Candidate
Member Candidate
Posts: 203
Joined: Wed Aug 09, 2017 1:15 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Jan 24, 2014 9:13 am
Location: Germany
Contact:

Re: v7.16rc [testing] is released!

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.
Last edited by bommi on Fri Aug 09, 2024 8:27 am, edited 1 time in total.
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1648
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v7.16rc [testing] is released!

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
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

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.
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1083
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1648
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v7.16rc [testing] is released!

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
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

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
just joined
Posts: 16
Joined: Wed Aug 07, 2024 1:56 pm

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Mon May 05, 2014 10:36 am

Re: v7.16rc [testing] is released!

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...
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1455
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: v7.16rc [testing] is released!

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
just joined
Posts: 16
Joined: Wed Aug 07, 2024 1:56 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
Member Candidate
Member Candidate
Posts: 126
Joined: Thu Sep 15, 2022 7:15 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Member Candidate
Member Candidate
Posts: 126
Joined: Thu Sep 15, 2022 7:15 pm

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Wed Sep 13, 2006 12:12 pm
Location: Jakarta

Re: v7.16rc [testing] is released!

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
just joined
Posts: 16
Joined: Wed Aug 07, 2024 1:56 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Member
Member
Posts: 434
Joined: Tue Jul 07, 2015 2:40 pm
Location: Croatia, Zagreb

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: v7.16rc [testing] is released!

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
just joined
Posts: 4
Joined: Mon Sep 07, 2020 12:26 pm

Re: v7.16rc [testing] is released!

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:
/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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

Mon Aug 12, 2024 2:28 pm

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
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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: v7.16rc [testing] is released!

Mon Aug 12, 2024 3:21 pm

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
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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 56
Joined: Wed Feb 15, 2023 4:46 pm

Re: v7.16rc [testing] is released!

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
 
User avatar
sirbryan
Member
Member
Posts: 372
Joined: Fri May 29, 2020 6:40 pm
Location: Utah
Contact:

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Jan 24, 2014 9:13 am
Location: Germany
Contact:

Re: v7.16rc [testing] is released!

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
newbie
Posts: 40
Joined: Wed Dec 12, 2018 1:46 pm

Re: v7.16rc [testing] is released!

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.
/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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
newbie
Posts: 40
Joined: Wed Dec 12, 2018 1:46 pm

Re: v7.16rc [testing] is released!

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
 
User avatar
sirbryan
Member
Member
Posts: 372
Joined: Fri May 29, 2020 6:40 pm
Location: Utah
Contact:

Re: v7.16rc [testing] is released!

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.)
 
User avatar
mantouboji
newbie
Posts: 47
Joined: Mon Aug 01, 2022 2:21 pm
Location: Shanghai

Re: v7.16rc [testing] is released!

Tue Aug 13, 2024 4:06 am

The link-local address of WireGuard interfaces lost randomly
 
kcarhc
Frequent Visitor
Frequent Visitor
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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.
 
EdPa
MikroTik Support
MikroTik Support
Topic Author
Posts: 325
Joined: Fri Sep 15, 2017 10:05 am
Location: Riga
Contact:

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 66
Joined: Tue May 07, 2024 8:57 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
just joined
Posts: 1
Joined: Wed May 31, 2023 10:10 pm

Re: v7.16rc [testing] is released!

Tue Aug 13, 2024 8:22 pm

It seems that SUP-161182 has not been fixed.
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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?
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 12425
Joined: Thu Mar 03, 2016 10:23 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
maisondasilva
just joined
Posts: 1
Joined: Sun Apr 21, 2024 1:56 pm
Contact:

Re: v7.16rc [testing] is released!

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)
Last edited by maisondasilva on Wed Aug 14, 2024 11:37 am, edited 1 time in total.
 
User avatar
robtor
Frequent Visitor
Frequent Visitor
Posts: 95
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

Re: v7.16rc [testing] is released!

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?
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 59
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.16rc [testing] is released!

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
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1648
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v7.16rc [testing] is released!

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
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

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!
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 59
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.16rc [testing] is released!

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
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26807
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia
Contact:

Re: v7.16rc [testing] is released!

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.
 
Guntis
MikroTik Support
MikroTik Support
Posts: 194
Joined: Fri Jul 20, 2018 1:40 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Member Candidate
Member Candidate
Posts: 126
Joined: Thu Sep 15, 2022 7:15 pm

Re: v7.16rc [testing] is released!

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
 
User avatar
robtor
Frequent Visitor
Frequent Visitor
Posts: 95
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Wed Aug 14, 2024 2:18 pm

it is undocumented.
/interface/wifi/radio/provision
isn't documented either.
 
User avatar
osc86
Member Candidate
Member Candidate
Posts: 203
Joined: Wed Aug 09, 2017 1:15 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 2367
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: v7.16rc [testing] is released!

Wed Aug 14, 2024 3:57 pm

Do you have examples on what changes you have made that weren't provisioned?
 
Guntis
MikroTik Support
MikroTik Support
Posts: 194
Joined: Fri Jul 20, 2018 1:40 pm

Re: v7.16rc [testing] is released!

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
Member Candidate
Member Candidate
Posts: 198
Joined: Sat Jul 20, 2019 8:16 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
sirbryan
Member
Member
Posts: 372
Joined: Fri May 29, 2020 6:40 pm
Location: Utah
Contact:

Re: v7.16rc [testing] is released!

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
just joined
Posts: 1
Joined: Tue May 14, 2024 2:11 pm

Re: v7.16rc [testing] is released!

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
Member Candidate
Member Candidate
Posts: 126
Joined: Thu Sep 15, 2022 7:15 pm

Re: v7.16rc [testing] is released!

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?
 
User avatar
smotrov
Frequent Visitor
Frequent Visitor
Posts: 72
Joined: Mon Dec 26, 2022 8:55 pm
Location: Ukraine 🇺🇦

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 83
Joined: Wed Feb 01, 2017 12:36 am

Re: v7.16rc [testing] is released!

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?
 
User avatar
smotrov
Frequent Visitor
Frequent Visitor
Posts: 72
Joined: Mon Dec 26, 2022 8:55 pm
Location: Ukraine 🇺🇦

Re: v7.16rc [testing] is released!

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
Member Candidate
Member Candidate
Posts: 234
Joined: Fri Jul 17, 2015 11:07 pm
Location: Czech

Re: v7.16rc [testing] is released!

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).
 
Guntis
MikroTik Support
MikroTik Support
Posts: 194
Joined: Fri Jul 20, 2018 1:40 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
smotrov
Frequent Visitor
Frequent Visitor
Posts: 72
Joined: Mon Dec 26, 2022 8:55 pm
Location: Ukraine 🇺🇦

Re: v7.16rc [testing] is released!

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.
 
User avatar
smotrov
Frequent Visitor
Frequent Visitor
Posts: 72
Joined: Mon Dec 26, 2022 8:55 pm
Location: Ukraine 🇺🇦

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 12425
Joined: Thu Mar 03, 2016 10:23 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
own3r1138
Forum Veteran
Forum Veteran
Posts: 727
Joined: Sun Feb 14, 2021 12:33 am
Location: Pleiades
Contact:

Re: v7.16rc [testing] is released!

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);
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1648
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v7.16rc [testing] is released!

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
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

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.
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 2942
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
BrateloSlava
Member Candidate
Member Candidate
Posts: 176
Joined: Mon Aug 09, 2021 10:33 am
Location: Ukraine, Kharkiv

Re: v7.16rc [testing] is released!

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.
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 2942
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

Re: v7.16rc [testing] is released!

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 :)
 
User avatar
Kanzler
Member Candidate
Member Candidate
Posts: 134
Joined: Wed Oct 05, 2022 6:55 pm
Location: Ukraine

Re: v7.16rc [testing] is released!

Fri Aug 16, 2024 11:35 am

@BrateloSlava,
Guess it’s time to let the robots handle the frequencies while we handle the snacks :-)))
 
Guntis
MikroTik Support
MikroTik Support
Posts: 194
Joined: Fri Jul 20, 2018 1:40 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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?
 
Guntis
MikroTik Support
MikroTik Support
Posts: 194
Joined: Fri Jul 20, 2018 1:40 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
BrateloSlava
Member Candidate
Member Candidate
Posts: 176
Joined: Mon Aug 09, 2021 10:33 am
Location: Ukraine, Kharkiv

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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.
You do not have the required permissions to view the files attached to this post.
 
Guntis
MikroTik Support
MikroTik Support
Posts: 194
Joined: Fri Jul 20, 2018 1:40 pm

Re: v7.16rc [testing] is released!

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
Member
Member
Posts: 310
Joined: Mon Jan 14, 2013 6:02 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
own3r1138
Forum Veteran
Forum Veteran
Posts: 727
Joined: Sun Feb 14, 2021 12:33 am
Location: Pleiades
Contact:

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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)
 
User avatar
sirbryan
Member
Member
Posts: 372
Joined: Fri May 29, 2020 6:40 pm
Location: Utah
Contact:

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

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
just joined
Posts: 7
Joined: Mon Apr 11, 2022 12:21 pm

Re: v7.16rc [testing] is released!

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?
 
User avatar
saaremaa
Member Candidate
Member Candidate
Posts: 162
Joined: Tue Feb 02, 2010 7:48 pm
Location: Lithuania, Kaunas

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Jan 24, 2014 9:13 am
Location: Germany
Contact:

Re: v7.16rc [testing] is released!

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
just joined
Posts: 7
Joined: Mon Apr 11, 2022 12:21 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Mon May 05, 2014 10:36 am

Re: v7.16rc [testing] is released!

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
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Mon May 05, 2014 10:36 am

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 2367
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Jan 24, 2014 9:13 am
Location: Germany
Contact:

Re: v7.16rc [testing] is released!

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
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 2367
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Mon May 05, 2014 10:36 am

Re: v7.16rc [testing] is released!

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
Member
Member
Posts: 361
Joined: Fri Feb 10, 2006 5:11 am
Contact:

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
just joined
Posts: 18
Joined: Tue Jun 15, 2021 12:25 am

Re: v7.16rc [testing] is released!

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
just joined
Posts: 3
Joined: Mon Feb 16, 2015 12:43 pm

Re: v7.16rc [testing] is released!

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
just joined
Posts: 8
Joined: Mon Aug 08, 2016 10:00 am

Re: v7.16rc [testing] is released!

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
Forum Veteran
Forum Veteran
Posts: 815
Joined: Thu Jan 27, 2011 7:29 am

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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.
 
EdPa
MikroTik Support
MikroTik Support
Topic Author
Posts: 325
Joined: Fri Sep 15, 2017 10:05 am
Location: Riga
Contact:

Re: v7.16rc [testing] is released!

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
just joined
Posts: 1
Joined: Mon Jul 08, 2024 2:35 pm

Re: v7.16rc [testing] is released!

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
Last edited by zharov on Wed Aug 28, 2024 10:51 am, edited 4 times in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
just joined
Posts: 5
Joined: Sun Dec 30, 2018 9:18 am

Re: v7.16rc [testing] is released!

Wed Aug 28, 2024 11:01 am

Wow , and X86 wifi still broken .
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
just joined
Posts: 5
Joined: Sun Dec 30, 2018 9:18 am

Re: v7.16rc [testing] is released!

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
You do not have the required permissions to view the files attached to this post.
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
Member Candidate
Member Candidate
Posts: 199
Joined: Tue Mar 10, 2020 6:37 am

Re: v7.16rc [testing] is released!

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)?
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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?
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.16rc [testing] is released!

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
just joined
Posts: 22
Joined: Sat Apr 29, 2017 3:28 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

Thu Aug 29, 2024 10:04 am

I'm still not sure if I should laugh or if I should cry...
 
thorkelau
just joined
Posts: 5
Joined: Sun Feb 11, 2024 7:38 am

Re: v7.16rc [testing] is released!

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.
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.16rc [testing] is released!

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:
 /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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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]
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.16rc [testing] is released!

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.
:put [:resolve foo.private]
Using 7.15.2 BTW
You do not have the required permissions to view the files attached to this post.
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Thu Aug 29, 2024 2:41 pm

Then your upstream DNS server responds with 0.0.0.0. Basically it.
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.16rc [testing] is released!

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
You do not have the required permissions to view the files attached to this post.
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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.
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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).
Last edited by pe1chl on Thu Aug 29, 2024 3:13 pm, edited 1 time in total.
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.16rc [testing] is released!

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...
 
User avatar
msilcher
just joined
Posts: 7
Joined: Mon Mar 09, 2009 9:39 pm
Location: Argentina

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 66
Joined: Tue May 07, 2024 8:57 pm

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

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
Frequent Visitor
Frequent Visitor
Posts: 66
Joined: Tue May 07, 2024 8:57 pm

Re: v7.16rc [testing] is released!

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
 
EdPa
MikroTik Support
MikroTik Support
Topic Author
Posts: 325
Joined: Fri Sep 15, 2017 10:05 am
Location: Riga
Contact:

Re: v7.16rc [testing] is released!

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
just joined
Posts: 18
Joined: Thu Jun 29, 2023 2:55 am
Location: Germany
Contact:

Re: v7.16rc [testing] is released!

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
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Fri Aug 30, 2024 9:20 pm

*) lte - improved modem AT/modem port open;
What is "modem port open"? Faster? More stable?
 
bjoerns
just joined
Posts: 8
Joined: Mon Aug 08, 2016 10:00 am

Re: v7.16rc [testing] is released!

Sat Aug 31, 2024 2:44 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?
No wireless package installed, but kernel failure after 30 mins uptime (ros x86):
Aug 31 13:03:31 xxx system,info installed system-7.16rc4
Aug 31 13:03:31 xxx system,info installed dude-7.16rc4
Aug 31 13:03:31 xxx system,info router rebooted by windows-nt-10.0-win64-x64/web:admin@192.168.0.57/upgrade
Aug 31 13:03:31 xxx interface,info lo link up
Aug 31 13:03:31 xxx interface,info ether8-link up (speed 100M, full duplex)
Aug 31 13:03:31 xxx interface,info ether7-link up (speed 1G, full duplex)
Aug 31 13:03:32 xxx interface,info ether6-link up (speed 1G, full duplex)
Aug 31 13:04:15 xxx system,info,account user admin logged in from 192.168.0.57 via web
Aug 31 13:05:06 xxx system,info,account user admin logged in from 192.168.0.200 via winbox
Aug 31 13:32:43 xxx system,info router rebooted
Aug 31 13:32:43 xxx interface,info lo link up
Aug 31 13:32:43 xxx system,error,critical kernel failure in previous boot
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1648
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v7.16rc [testing] is released!

Mon Sep 02, 2024 9:44 am

itimo01, bjoerns - Can you please send supout.rif files from your router to support@mikrotik.com?
 
ppptran
just joined
Posts: 5
Joined: Sun Dec 30, 2018 9:18 am

Re: v7.16rc [testing] is released!

Mon Sep 02, 2024 12:49 pm



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)?
Brother, I'm talking about the X86. There's no such wifi-qcom-ac / wave2 package in the X86 Extra Package
I have created a Support Ticket (SUP-163590) about this issue; and there's no one reply yet.
 
User avatar
bpwl
Forum Guru
Forum Guru
Posts: 3085
Joined: Mon Apr 08, 2019 1:16 am

Re: v7.16rc [testing] is released!

Mon Sep 02, 2024 2:41 pm

Release 7.16rc4, upgrade from 7.16rc3 , on hAP ac3 with WLAN dirvers (wifi-qcom-ac not active) but wireless active.
After upgrade the "wireless" package is disabled !
Needs to be enabled and do a reboot to have again some wireless access.

Had lost wireless access to the device that way.
 
roadracer96
Forum Veteran
Forum Veteran
Posts: 736
Joined: Tue Aug 25, 2009 12:01 am

Re: v7.16rc [testing] is released!

Mon Sep 02, 2024 4:07 pm

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 ;-)
Esxi does not work perfectly fine without lacp. Their internal means of loop prevention breaks the second you start using promiscuous mode. It is a horrible idea and breaks networking. In particularly, when bridging between 2 layer2 networks (in my case it was a layer2 traffic inspection device).
 
itimo01
just joined
Posts: 18
Joined: Thu Jun 29, 2023 2:55 am
Location: Germany
Contact:

Re: v7.16rc [testing] is released!

Mon Sep 02, 2024 7:31 pm

itimo01, bjoerns - Can you please send supout.rif files from your router to support@mikrotik.com?
Sent!
SUP-163935
 
User avatar
spippan
Member
Member
Posts: 440
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.16rc [testing] is released!

Mon Sep 02, 2024 9:54 pm

TIL: there is
/ip/dns/cache/all/print
which shows you really all cache entries.

Unlike
/ip/dns/cache/print
thanks ... didn't know about that or at least never realized this was there
 
bjoerns
just joined
Posts: 8
Joined: Mon Aug 08, 2016 10:00 am

Re: v7.16rc [testing] is released!

Tue Sep 03, 2024 10:32 am

itimo01, bjoerns - Can you please send supout.rif files from your router to support@mikrotik.com?
I have no supouts available and also cannot reproduce the issue. But logging showed that the router already rebooted several times after few hours of uptime before the upgrade, i didn't see it because it recovered that fast... I've downgraded to stable channel and then back to testing, disabled multi cpu and removed a stale interface from a disabled ipv6 nd config. Will do tests on a different box.
 
uCZBpmK6pwoZg7LR
Frequent Visitor
Frequent Visitor
Posts: 57
Joined: Mon Jun 15, 2015 12:23 pm

Re: v7.16rc [testing] is released!

Tue Sep 03, 2024 5:19 pm

Any plan to fix VRF export static routes over bgp ?
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1648
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: v7.16rc [testing] is released!

Wed Sep 04, 2024 7:24 am

There was a possibility that if you use an ARM router with wireless that has 128 MB of RAM and is using wifi-qcom-ac package, not wireless, then simply router could run out of RAM resources causing the router to reboot. That happened just because a RAM usage slightly increased in these releases. We are working on a memory usage improvement for wifi-qcom-ac which should help for those of you who experienced such issues in latest 7.16beta/rc releases and maybe before.

However, please note that every router has as much RAM as it has and running out of it due to overconfiguration or other reasons is not a software issue usually, but simply not appropriate choice of hardware+software+configuration. In this particular case - improvements are coming soon. Of course, if there is a memory leak, then that is a completely another story.
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Wed Sep 04, 2024 11:03 am

Thanks, strods! I appreciate that you're maintaining the wifi-qcom-ac package. Will these changes be already in the 7.16rc, in version 7.16.0, or in a 7.16.1+ release?
 
coddy
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

Wed Sep 04, 2024 11:57 am

@bratislav - MLAG & v7.16RC4

I changed my MLAG configuration to have the management IP on the bridge (br-trunk) instead of a VLAN interface (vl-switches) under the br-trunk bridge. I then upgraded to 7.16RC4 and it went fine, I lost a couple of pings and switches went up/down, nothing unexpected. ESXi VMs worked just fine without having to wait for ARP cache to clear/synchronize. Upstream LACP switches remained pingable during the upgrade of each fabric switch.

The only change was where I assigned the management IP (and of course setting the PVID on the br-trunk to the switches management VLAN ID). Very interesting - so at this stage it appears MLAG requires the management IP on the bridge, not on a VLAN assigned to the bridge (although it works, it has problems during reboot/re-sync with MLAG peer).

So thank you @bratislav for giving me the hint that helped! (Of course it could have been something to do with RC4, but the change log does not indicate it!). I shall leave the management IP on the bridge going forward.
 
holvoetn
Forum Guru
Forum Guru
Posts: 6133
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: v7.16rc [testing] is released!

Wed Sep 04, 2024 12:01 pm

There was a possibility that if you use an ARM router with wireless that has 128 MB of RAM and is using wifi-qcom-ac package, not wireless, then simply router could run out of RAM resources causing the router to reboot.
One of the reasons why I configured about a month ago a daily auto-reboot on 1 cap AC using wifi-qcom-ac driver... otherwise it kept crashing somewhere in the 2nd or 3th day of uptime. Now I control at least when it reboots, when nobody is connected. It's behaving nicely since then.
Literally nothing running on that device except for it acting as AP.
Oddly enough, no such issue on ac2 with exact same config (same RAM amount so why ??).

Good to see this is acknowledged and being looked at.
And yes, I did have a SUP for that with supouts and other monitoring (since early august, I never received a response, FWIW).
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Wed Sep 04, 2024 12:56 pm

One of the reasons why I configured about a month ago a daily auto-reboot on 1 cap AC using wifi-qcom-ac driver... otherwise it kept crashing somewhere in the 2nd or 3th day of uptime. Now I control at least when it reboots, when nobody is connected. It's behaving nicely since then.
Literally nothing running on that device except for it acting as AP.
No such reboot issues here. cAP ac is managed by capsman. And strods said this RAM consumption is 7.16 related and only "maybe before". Maybe 7.15 is not affected?
                   uptime: 1w4h10m2s
                  version: 7.15.3 (stable)
               build-time: 2024-07-24 10:39:01
         factory-software: 6.44.6
              free-memory: 31.6MiB
             total-memory: 128.0MiB
                      cpu: ARM
                cpu-count: 4
            cpu-frequency: 448MHz
                 cpu-load: 1%
           free-hdd-space: 780.0KiB
          total-hdd-space: 15.2MiB
  write-sect-since-reboot: 1600
         write-sect-total: 27259
        architecture-name: arm
               board-name: cAP ac
                 platform: MikroTik
 
holvoetn
Forum Guru
Forum Guru
Posts: 6133
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: v7.16rc [testing] is released!

Wed Sep 04, 2024 1:19 pm

I'm not 100% sure anymore why I moved on to 7.16b/rc channel for that one device.
Having been 2 weeks off in between can create that situation :lol:

Now I think of it, I also have a wAP AC at home running 7.16rc, (same resources) no crashes there either.
I have another AC2 running 7.15.1 and wave2, it's been running for 65d straight now.
So it may be related specifically to 7.16 version after all.

Maybe I should take that misbehaving device down and perform netinstall on it (but it's high on the wall in a shop right now, about 75km away from where I live, so it's not like I pass by there on a weekly basis).

And before anyone starts: I am fully aware it's experimental SW-version, I know issues can happen and I did mitigate the most important problem for that specific installation so I'm not complaining at all on that aspect. I'm happy those wave2 drivers have been made available.

I'm only providing info so the issue can be resolved.
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Wed Sep 04, 2024 1:39 pm

I'm not 100% sure anymore why I moved on to 7.16b/rc channel for that one device.
And added a scheduled reboot instead of downgrading to 7.15 again :P
 
holvoetn
Forum Guru
Forum Guru
Posts: 6133
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: v7.16rc [testing] is released!

Wed Sep 04, 2024 1:45 pm

I'm more into testing and moving forward and I accept consequences of doing so.

Most of my client production devices are steady on 7.15.1. I'm not even moving them to 7.15.3 since it's not needed for me.
A couple though I use for testing (where I know it doesn't hurt too much) and at home I always use most recent test versions (unless something really breaks down but then my wife will tell me soon enough).
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 12425
Joined: Thu Mar 03, 2016 10:23 pm

Re: v7.16rc [testing] is released!

Wed Sep 04, 2024 3:13 pm

... on 1 cap AC using wifi-qcom-ac driver...

Oddly enough, no such issue on ac2 with exact same config (same RAM amount so why ??).
hAP ac2 has 3 more ethernet ports, so more buffer on switch chip is in use ... perhaps that's a life saver? LOL
 
bratislav
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Mon May 05, 2014 10:36 am

Re: v7.16rc [testing] is released!

Wed Sep 04, 2024 5:19 pm

... on 1 cap AC using wifi-qcom-ac driver...

Oddly enough, no such issue on ac2 with exact same config (same RAM amount so why ??).
hAP ac2 has 3 more ethernet ports, so more buffer on switch chip is in use ... perhaps that's a life saver? LOL
cAP ac and hAP ac are using exactly the same SOC IPQ-4018 with same integrated switch chip 8327 inside, the only difference being that on cAP only two ethernet lines are in use... I have the same OOM issues and I presume that the reason is number of wifi connections over time and wifi-qcom-ac driver not releasing memory on disconnects...
Last edited by bratislav on Wed Sep 04, 2024 5:39 pm, edited 1 time in total.
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Wed Sep 04, 2024 5:34 pm

Is it possible to use SWAP file in ROS? E.g. on a USB disk
 
1day
just joined
Posts: 2
Joined: Wed Aug 07, 2024 10:29 pm

Re: v7.16rc [testing] Wifi borked after Update from 7.15.3

Wed Sep 04, 2024 9:40 pm

Hi,
In order to try and resolve what I think to be an ARP issue (that's driving me nuts) I decided to try the beta, namely 7.16rs4 as that mentions fixes for arp and bridging related issues.

However, immediately after the update, the wireless was non-functional, so a breaking update. Not sure if that is intentional but now needs post update reconfig/reboot to bring it back.
It seems it's reverted to the old 'wireless' package instead of the newer 'wifi-qcom', which I can see is present but deactivated.

The logs from first boot in case that helps look into this, but I can't see anything that would be useful myself....

Note there were three lines that appeared on the console but not in the downloaded log file using
/log/print detail without-paging 
They had no prefix on the console, but are in the in-memory log, so I added that here by hand
They seem out of place as this is not a new install so no defaults need apply, why was it trying to run a script?
After this (apart from the missing wireless) nothing out of the ordinary.

1.time="Sep/04/2024 19:08:46" topics="script,warning" message="DefConf gen: Unable to find wireless interface(s)"
2.time="Sep/04/2024 19:08:46" topics="system,error,critical" message="error while running customized default configuration script: interrupted"
3.time="Sep/04/2024 19:08:46" topics="system,error,critical" message="" <i.e. an empty log message>
time=19:08:04 topics=system,info message="installed system-7.16rc4" 
time=19:08:04 topics=system,info message="installed rose-storage-7.16rc4" 
time=19:08:04 topics=system,info message="installed container-7.16rc4" 
time=19:08:04 topics=system,info message="installed wireless-7.16rc4" 
time=19:08:04 topics=system,info message="installed wifi-qcom-7.16rc4" 
time=19:08:04 topics=system,info message="router rebooted" 
time=19:08:05 topics=interface,info message="lo link up" 
time=19:08:05 topics=interface,info message="VLAN100<->F/W link up" 
time=19:08:05 topics=interface,info message="isp<->VLAN666<->f/w link up" 
time=19:08:05 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <selecting...> state" 
time=19:08:06 topics=bridge,info message=""BR100-dmz" mac address changed to 3A:96:B4:xx:xx:xx" 
time=19:08:06 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <stopped> state" 
time=19:08:06 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <selecting...> state" 
time=19:08:06 topics=interface,info message="VLAN99 link up" 
time=19:08:06 topics=bridge,info message=""BR11-lan" mac address changed to 8E:DD:3A:yy:yy:yy" 
time=19:08:06 topics=interface,info message="VLAN11 link up" 
time=19:08:06 topics=interface,info message="VLAN22 link up" 
time=19:08:06 topics=interface,info message="VLAN24 link up" 
time=19:08:06 topics=bridge,info message=""BR99-work" mac address changed to 8E:DD:3A:yy:yy:yy" 
time=19:08:07 topics=bridge,info message=""BR100-dmz" mac address changed to 8E:DD:3A:yy:yy:yy" 
time=19:08:07 topics=bridge,info message=""BR22-wifi-p" mac address changed to 8E:DD:3A:yy:yy:yy" 
time=19:08:07 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <stopped> state" 
time=19:08:07 topics=bridge,info message=""BR24-wifi-d" mac address changed to 8E:DD:3A:yy:yy:yy" 
time=19:08:07 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <selecting...> state" 
time=19:08:07 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <stopped> state" 
time=19:08:07 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <selecting...> state" 
time=19:08:10 topics=interface,info message="1:ISP-Virgin link down" 
time=19:08:10 topics=interface,info message="2:LAG3 link down" 
time=19:08:10 topics=interface,info message="3:LAG3 link down" 
time=19:08:10 topics=interface,info message="4:eth2-vlan11 link down" 
time=19:08:10 topics=interface,info message="5:eth1-vlan55 link down" 
time=19:08:12 topics=interface,info message="3:LAG3 link up (speed 1G, full duplex)" 
time=19:08:12 topics=interface,info message="18:LAG3(P2+P3) link up" 
time=19:08:12 topics=bridge,info message=""BR11-lan" mac address changed to 78:9A:18:zz:zz:zz" 
time=19:08:12 topics=bridge,info message=""BR99-work" mac address changed to 78:9A:18:zz:zz:zz" 
time=19:08:12 topics=bridge,info message=""BR22-wifi-p" mac address changed to 78:9A:18:zz:zz:zz" 
time=19:08:12 topics=bridge,info message=""BR24-wifi-d" mac address changed to 78:9A:18:zz:zz:zz" 
time=19:08:12 topics=bridge,info message=""BR100-dmz" mac address changed to 78:9A:18:zz:zz:zz" 
time=19:08:13 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <stopped> state" 
time=19:08:13 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <selecting...> state" 
time=19:08:13 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <stopped> state" 
time=19:08:13 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <selecting...> state" 
time=19:08:13 topics=interface,info message="1:ISP-Virgin link up (speed 1G, full duplex)" 
time=19:08:13 topics=interface,info message="2:LAG3 link up (speed 1G, full duplex)" 
time=19:08:16 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <requesting...> state" 
time=19:08:16 topics=dhcp,info message="dhcp-client on isp<->VLAN666<->f/w got IP address 82.1.1.1" 
time=19:08:16 topics=dhcp,debug,state message="dhcp-client on isp<->VLAN666<->f/w entering <bound> state" 
time=19:08:20 topics=system,info,account message="user admin logged in from 192.168.31.69 via winbox" 

 
LionB12
just joined
Posts: 4
Joined: Fri Jun 09, 2023 5:32 pm

Re: v7.16rc [testing] is released!

Thu Sep 05, 2024 12:31 am

It seems that the traceroute command no longer shows the return packet size? It was present in the 7.11.3 version, but no longer. In both cli and winbox
 
bjoerns
just joined
Posts: 8
Joined: Mon Aug 08, 2016 10:00 am

Re: v7.16rc [testing] is released!

Thu Sep 05, 2024 10:30 am

installation check fails on any of my arm chr instances, even if i change to stable channel. i dont know if that happened during testing upgrades, thus i post it here. offline fsck of both partitions are fine.
[admin@xxx] /system> reso pr 
                   uptime: 1m6s
                  version: 7.16rc4 (testing)
               build-time: 2024-08-30 06:24:51
              free-memory: 274.4MiB
             total-memory: 576.0MiB
                      cpu: ARM64
                cpu-count: 2
                 cpu-load: 1%
           free-hdd-space: 67.4MiB
          total-hdd-space: 80.7MiB
  write-sect-since-reboot: 235
         write-sect-total: 235
        architecture-name: arm64
               board-name: CHR QEMU KVM Virtual Machine
                 platform: MikroTik

[admin@xxx] /system> check-installation  
damaged system package: bad image
 
S8T8
Member Candidate
Member Candidate
Posts: 126
Joined: Thu Sep 15, 2022 7:15 pm

Re: v7.16rc [testing] is released!

Fri Sep 06, 2024 5:27 pm

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. ...
If anyone is interested in how reselect.interval is affecting wireless connection, this is what I found in my log connecting two Wi-FI ac AP using v7.16rc4:
MAC.ADD@Bridge-WLAN: AP changed channel to 5660/ac/Ceee
MAC.ADD@Bridge-WLAN: disconnected, reason code 8, signal -84
- 2/4min later -
MAC.ADD@Bridge-WLAN: connected on 5660/ac/Ceee, signal -74
MAC.ADD@Bridge-WLAN: authorized, signal -74
 
MauriceW
just joined
Posts: 10
Joined: Fri Jan 12, 2024 12:15 am

Re: v7.16rc [testing] is released!

Sun Sep 08, 2024 6:05 pm

*) lte - added "sms-protocol" setting in "/interface lte" menu (CLI only);
What exactly does this do? I'm aware it's possible to send and receive SMS either via AT commands over a (virtual) serial port or via MBIM commands. But isn't that already determined by setting the port in "/tool sms" accordingly (usbX for AT or lteX for MBIM)? In which use cases would you need to use this new setting?
 
User avatar
bpwl
Forum Guru
Forum Guru
Posts: 3085
Joined: Mon Apr 08, 2019 1:16 am

Re: v7.16rc [testing] is released!

Sun Sep 08, 2024 6:28 pm

Probably not new to this release, but at least it is still there. User Manager things.

- Terminating EAP wifi sessions by User manager doesn't work (NAK received from NAS , error cause in the packet = 605 = not implemented)
- Many "UM NAS rebooted" messages (with but sometimes also without any reboot of the AP (=NAS), what triggers even much more disconnect attemps by UM with NAK responses
- Trying to limit wifi EAP session time, to stop the NAK loop, ...
--- with UM Attribute "Session Timeout " fails to be triggered (Attribute is set in User Group)
--- Idem for the "Session Limit" parameter in the limitation. Assigned to user via User -> User Profiles -> Profile -> Profile Limitations -> Limitations

Only thing that is triggered and works is the validity set in Profiles.

While testing the failover to the next "User Profile" , the information to the user is missing the GMT Offset correction. (GMT time shown?)
.
.
Klembord2.jpg
You do not have the required permissions to view the files attached to this post.
 
bjoerns
just joined
Posts: 8
Joined: Mon Aug 08, 2016 10:00 am

Re: v7.16rc [testing] is released!

Mon Sep 09, 2024 5:20 pm

itimo01, bjoerns - Can you please send supout.rif files from your router to support@mikrotik.com?
Sent by email a few minutes ago, thus no ticket number...
 
mszru
Frequent Visitor
Frequent Visitor
Posts: 85
Joined: Wed Aug 10, 2016 10:42 am

Re: v7.16rc [testing] is released!

Mon Sep 09, 2024 7:16 pm

I am facing Wi-Fi connection issues with my hAP ax3, causing the laptop to disconnect during Zoom meetings. As you can see in the logs the laptop gets disconnected from AP despite having the strong signal. This happened in the recent stable version (7.15.3) and still happens in the latest rc version.

The laptop has an Intel(R) Wi-Fi 6 AX203 adapter, and the version of the driver is 23.60.1.2. Anything I can do to fix it myself?
So far the only solution for me was temporarily replacing hAP ax3 with my old hAP ac2 running wifi-qcom-ac drivers, which works pretty well.

 18:05:54 wireless,info 90:09:DF:**:**:E9@wifi1 disconnected, SA Query timeout, signal strength -51
 18:05:55 wireless,info 90:09:DF:**:**:E9@wifi2 connected, signal strength -44
 18:06:59 wireless,info 90:09:DF:**:**:E9@wifi2 disconnected, SA Query timeout, signal strength -46
 18:07:00 wireless,info 90:09:DF:**:**:E9@wifi2 connected, signal strength -50
 18:12:06 wireless,info 90:09:DF:**:**:E9@wifi2 disconnected, SA Query timeout, signal strength -47
 18:12:20 wireless,info 90:09:DF:**:**:E9@wifi1 connected, signal strength -51
 18:14:12 wireless,info 90:09:DF:**:**:E9@wifi1 disconnected, SA Query timeout, signal strength -58
 18:14:12 wireless,info 90:09:DF:**:**:E9@wifi2 connected, signal strength -50
 18:14:22 wireless,info 90:09:DF:**:**:E9@wifi2 disconnected, SA Query timeout, signal strength -46
 18:14:22 wireless,info 90:09:DF:**:**:E9@wifi1 connected, signal strength -50
 18:14:36 system,info,account user ***** logged in from 192.168.11.233 via winbox
 18:14:36 system,info,account user ***** logged in from 192.168.11.233 via winbox
 18:18:28 wireless,info 90:09:DF:**:**:E9@wifi1 disconnected, SA Query timeout, signal strength -56
 18:18:34 wireless,info 90:09:DF:**:**:E9@wifi1 connected, signal strength -51
 18:28:42 wireless,info 90:09:DF:**:**:E9@wifi1 disconnected, SA Query timeout, signal strength -56
 18:28:42 wireless,info 90:09:DF:**:**:E9@wifi2 connected, signal strength -48
 18:28:57 wireless,info 90:09:DF:**:**:E9@wifi2 disconnected, SA Query timeout, signal strength -48
 18:29:12 wireless,info 90:09:DF:**:**:E9@wifi1 connected, signal strength -52

Another observation is the network adapter does not always select the latest and greatest AX standard with the WPA3 security type. It often favors the AC standard over AX.
ax-wpa3.png
ax-wpa2.png
ac-wpa3.png
You do not have the required permissions to view the files attached to this post.
 
kleshki
Member Candidate
Member Candidate
Posts: 199
Joined: Tue Mar 10, 2020 6:37 am

Re: v7.16rc [testing] is released!

Mon Sep 09, 2024 7:48 pm

I am facing Wi-Fi connection issues with my hAP ax3, causing the laptop to disconnect during Zoom meetings. As you can see in the logs the laptop gets disconnected from AP despite having the strong signal. This happened in the recent stable version (7.15.3) and still happens in the latest rc version.

The laptop has an Intel(R) Wi-Fi 6 AX203 adapter, and the version of the driver is 23.60.1.2. Anything I can do to fix it myself?
So far the only solution for me was temporarily replacing hAP ax3 with my old hAP ac2 running wifi-qcom-ac drivers, which works pretty well.
Current solution is rollback to 7.14.3
 
Rox169
Member
Member
Posts: 464
Joined: Sat Sep 04, 2021 1:47 am

Re: v7.16rc [testing] is released!

Mon Sep 09, 2024 7:52 pm

Disable WPA3...
 
ToTheFull
Member
Member
Posts: 367
Joined: Fri Mar 24, 2023 3:24 pm

Re: v7.16rc [testing] is released!

Mon Sep 09, 2024 8:12 pm

I'm using the latest driver as of posting and here's my uptime for my ax210 WPA2 only.
netsh wlan show drivers

Interface name: WiFi

    Driver                    : Intel(R) Wi-Fi 6E AX210 160MHz
    Vendor                    : Intel Corporation
    Provider                  : Intel
    Date                      : 24/07/2024
    Version                   : 23.70.2.3
    INF file                  : oem27.inf
    Type                      : Native Wi-Fi Driver
You do not have the required permissions to view the files attached to this post.
 
kleshki
Member Candidate
Member Candidate
Posts: 199
Joined: Tue Mar 10, 2020 6:37 am

Re: v7.16rc [testing] is released!

Mon Sep 09, 2024 10:13 pm

I'm using same version 23.70.2.3 adapter is AX201
 
mszru
Frequent Visitor
Frequent Visitor
Posts: 85
Joined: Wed Aug 10, 2016 10:42 am

Re: v7.16rc [testing] is released!

Mon Sep 09, 2024 10:46 pm

Thanks everyone! I've disabled WPA3 for now.
 
gudvinr
just joined
Posts: 5
Joined: Sat Aug 31, 2019 2:07 pm

Re: v7.16rc [testing] is released!

Tue Sep 10, 2024 8:51 am

Will there be a mDNS announce for the MT devices?
Right now to use a pretty name you need to set up a static record which can't be in .local AND you need to change its address manually (or write weird scripts to update address automatically).
 
Valerio5000
Member Candidate
Member Candidate
Posts: 101
Joined: Fri Dec 06, 2013 2:38 am

Re: v7.16rc [testing] is released!

Tue Sep 10, 2024 1:11 pm

Will there be a mDNS announce for the MT devices?
Right now to use a pretty name you need to set up a static record which can't be in .local AND you need to change its address manually (or write weird scripts to update address automatically).
+1
 
bommi
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Jan 24, 2014 9:13 am
Location: Germany
Contact:

Re: v7.16rc [testing] is released!

Thu Sep 12, 2024 4:49 pm

Could you please insert the used WPA version inside the capsman registration table?
So that we could see which version of WPA is used by a client?
I think that this would be a valuable enhancement.
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Thu Sep 12, 2024 7:21 pm

I already requested that feature via SUP-158802.
Details11/Jul/24 11:09 AM
Description
Hello,
I have a feature request:
It would be nice to have a column in wifi/registration-table which shows the active security-type of the registered client. e.g. wpa2-psk,wpa3-psk,etc. Maybe even more “granular” as there are many subtypes for WPA and EAP as well. WPA2-PSK+FT, WPA3+FT to just name these two.
Such a column would really help people to troubleshoot “problematic” clients. As the used authentication types if quite often the source of issues at some clients.
Thank you!
 
bommi
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Fri Jan 24, 2014 9:13 am
Location: Germany
Contact:

Re: v7.16rc [testing] is released!

Thu Sep 12, 2024 7:38 pm

I already requested that feature via SUP-158802.
Details11/Jul/24 11:09 AM
Description
Hello,
I have a feature request:
It would be nice to have a column in wifi/registration-table which shows the active security-type of the registered client. e.g. wpa2-psk,wpa3-psk,etc. Maybe even more “granular” as there are many subtypes for WPA and EAP as well. WPA2-PSK+FT, WPA3+FT to just name these two.
Such a column would really help people to troubleshoot “problematic” clients. As the used authentication types if quite often the source of issues at some clients.
Thank you!
Great!
Have they already answered to your request?
 
User avatar
bpwl
Forum Guru
Forum Guru
Posts: 3085
Joined: Mon Apr 08, 2019 1:16 am

Re: v7.16rc [testing] is released!

Thu Sep 12, 2024 7:47 pm

WLAN driver has "Authentication Type" in registration table.
It is collected by DUDE as well, for a general overview of all registration tables.

Would like to see the other fields as well. (and their collection in DUDE)
Klembord2.jpg
and yes 192.168.22.13 is too close to the AP. (People forget that mobile routers/hotspots/chromecasts have a stronger signal than smartphone/tablet/laptop. They should stay 1 meter away from the AP.)
You do not have the required permissions to view the files attached to this post.
Last edited by bpwl on Thu Sep 12, 2024 11:00 pm, edited 4 times in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

Thu Sep 12, 2024 7:52 pm

Interestingly, the same request is pending at the competitor for at least 3 years...
Start wondering if it may be technically difficult or impossible to get that information on the AP side...
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Thu Sep 12, 2024 7:53 pm

I already requested that feature via SUP-158802.

Great!
Have they already answered to your request?
Yes, they thanked me for making suggestions.
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Thu Sep 12, 2024 8:13 pm

Interestingly, the same request is pending at the competitor for at least 3 years...
Start wondering if it may be technically difficult or impossible to get that information on the AP side...
made me curious. stumbled upon a user called "pe1chl" over at un*f* community forum feature request. lol. nevertheless, having this feature would be a great thing for debugging and understanding "troublesome" wifi-clients better.
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 2942
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

Re: v7.16rc [testing] is released!

Thu Sep 12, 2024 9:40 pm

Seems to be possible as other brand shows that:
You do not have the required permissions to view the files attached to this post.
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 59
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.16rc [testing] is released!

Fri Sep 13, 2024 3:26 am

are we getting a new rc soon? hopefully fixing some more AX problems please
 
gigabyte091
Forum Guru
Forum Guru
Posts: 1434
Joined: Fri Dec 31, 2021 11:44 am
Location: Croatia

Re: v7.16rc [testing] is released!

Fri Sep 13, 2024 7:51 am

Looking at how little fixes there is in rc4 i think that 7.16 will go stable and 7.17 beta is around the corner.
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 59
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.16rc [testing] is released!

Fri Sep 13, 2024 8:01 am

hope so sooner rather then later as im having a horrible time with these ax devices for months now cant get it working properly
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1083
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v7.16rc [testing] is released!

Fri Sep 13, 2024 8:02 am

I am wondering the same. This cycle does take really long... My guess is that they are doing some internal changes to polish behavior with new Winbox 4, but - who knows...
 
gigabyte091
Forum Guru
Forum Guru
Posts: 1434
Joined: Fri Dec 31, 2021 11:44 am
Location: Croatia

Re: v7.16rc [testing] is released!

Fri Sep 13, 2024 8:07 am

hope so sooner rather then later as im having a horrible time with these ax devices for months now cant get it working properly
Did you open new topic, maybe someone can help you ?
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Fri Sep 13, 2024 8:53 am

polish behavior with new Winbox 4, but - who knows...
Would not make sense to me. Winbox 4 is early beta and that should not be any priority for any stable ROS version right now.
 
User avatar
Coughy
Frequent Visitor
Frequent Visitor
Posts: 59
Joined: Tue Apr 23, 2024 2:53 am
Location: Brisbane Au

Re: v7.16rc [testing] is released!

Fri Sep 13, 2024 11:06 am

hope so sooner rather then later as im having a horrible time with these ax devices for months now cant get it working properly
Did you open new topic, maybe someone can help you ?
no ive read all i can find here and everyone has same if not similiar problems
it is the roaming / steering / disconnects / reauthentisication loops saga and unstable wifi
but in saying that i have well i think i might of had some sort of a win it is roaming and working so far only been a few hours but lets see tonight when i stream the foot ball finals if my stream cuts out like it normally does. touch wood it dont gggrrr annoying

but i have notised that the 2.4Ghz isnt roaming?? is it spose to as i see the 5Ghz roaming?? on this latest RC
at least i dont have disconecting 2.4Ghz for now
 
coddy
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

Fri Sep 13, 2024 3:08 pm

v7.16rc4 - DNS VRF does not work.
When setting:
/ip dns set vrf=mgmtvrf
the system always sends DNS queries via the main vrf, regardless of this setting.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

Fri Sep 13, 2024 5:18 pm

It means "listen for DNS queries on vrf=mgmtvrf", right?
It does not determine where DNS queries are sent.
Of course the right solution would be to have multiple DNS resolver instances that can all be set up differently...
Even without VRF, I may want to have different external DNS servers for different internal networks, so DNS resolver instances should be bound to local interfaces (default=all) and have separate setup (servers, outgoing VRF, etc).
 
coddy
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

Fri Sep 13, 2024 10:41 pm

The documentation (https://help.mikrotik.com/docs/display/ROS/DNS) does not even list the vrf parameter, so who knows!

But I agree, this would appear to be messy. Both the 'server' settings and 'client/resolver' settings are in the same flat list.

A better solution for the dns client would be to use something like /ip dns set servers=8.8.8.8@internet, and have dynamic dns servers being listed in the same fashion with the vrf they got their settings from, but that is not accepted.

So, yes, no way for the dns resolver to function on anything other than the 'main' vrf.

I do really agree, the only proper way forward is multiple DNS instances allowing you to 'bind' listeners to multiple IP@vrf, and set resolvers to use multiple IP@vrf syntax also. This would allow the MT to have mgmt dns for itself, and still be able to provide dns to the client if needed using a completely different dns instance and parameter set.
 
User avatar
nithinkumar2000
Member Candidate
Member Candidate
Posts: 164
Joined: Wed Sep 11, 2019 7:42 am
Location: Coimbatore
Contact:

Re: v7.16rc [testing] is released!

Sat Sep 14, 2024 8:20 am

Is there any chance of Multicore Processing of Following in ROS v7.x:

1. MPLS + VPLS
2. PPPOE
3. VXLAN
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Sat Sep 14, 2024 10:52 am

The documentation (https://help.mikrotik.com/docs/display/ROS/DNS) does not even list the vrf parameter, so who knows!
This help page knows:

https://help.mikrotik.com/docs/pages/vi ... edfeatures
 
pe1chl
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

Sat Sep 14, 2024 11:23 am

The big problem with the VRF construct in RouterOS is that most of services that support VRF only support a single VRF.
That may be OK for something like a management interface that you would want to have only on the management VRF, but for services like DNS resolver or NTP server which you would want to make available on more than one VRF (possibly with different configuration) this model is not suitable.
That is (mostly) why I do not use VRF, but instead use route marking. Of course that is only possible when the networks do not overlap, which fortunately is true in my use case.
 
noradtux
newbie
Posts: 39
Joined: Mon May 24, 2021 6:33 pm

Re: v7.16rc [testing] is released!

Mon Sep 16, 2024 8:03 am

Is there any chance of Multicore Processing of Following in ROS v7.x:

1. MPLS + VPLS
2. PPPOE
3. VXLAN
+1 for PPPoE. My CCR2116 maxes out at around 900MBps on my pppoe uplink.
 
bbs2web
Member Candidate
Member Candidate
Posts: 233
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: v7.16rc [testing] is released!

Mon Sep 16, 2024 10:35 am

MLAG on 2 x CRS354-48G-2S+2Q+ switches continues to be a problem. MLAG peer link is a 802.3ad (LACP) bond interface utilising two Q+ (40G) ports with MikroTik DACs. We've tried swapping the DACs which made no difference.

Bond and slave interface status shows zero 'link down' events but MLAG peer status is reported as flapping regularly:
 09:28:26 bridge,warning "bridge" peer disconnected
 09:28:26 bridge,warning "bridge" peer link down
 09:28:26 bridge,info "bridge" peer link up
 09:28:26 bridge,info "bridge" peer connected
 09:28:26 bridge,info "bridge" peer becomes secondary DC:2C:6E:D2:AF:4B
 

I've sent numerous supout.rif files, for all 7.15 versions of the firmware and now 7.16rc4; never hear anything back from support@mikrotik.com



PS: Works perfectly 99.9% of the time, but these frequent peer link flaps interrupt Teams calls for 2-3 seconds each time they occur and the result is that we can't recommend this for client networks as a result.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

Mon Sep 16, 2024 10:41 am

+1 for PPPoE. My CCR2116 maxes out at around 900MBps on my pppoe uplink.
And/or support of the hardware-accellerated PPPoE that some chips support (even low-end ones)...
 
coddy
just joined
Posts: 3
Joined: Mon Nov 11, 2013 7:13 am

Re: v7.16rc [testing] is released!

Mon Sep 16, 2024 1:43 pm

@bbs2web: MLAG peerlink

I have 2 x CRS317 with LACP 802.3ad peerlink, connected via 2 x 10g DAC cables. No issues with the peerlink flapping. Zero.
Since you have already tried replacing the DAC cables without success, maybe try moving the peerlink to two SFP+ (10G) ports with suitable DAC cables. Rule out an issue with the Q+ port(s). Alternatively since you said this occurs frequently, unplug one of the Q+ ports (I know it breaks redundancy, but for the testing period hopefully that is acceptable), and see if the flapping continues. Then plug that Q+ port back and unplug the other Q+ port... Trying to determine if this is the peerlink over Q+ failing, or a bad Q+ port, or a bad Q+ cable.
 
User avatar
nithinkumar2000
Member Candidate
Member Candidate
Posts: 164
Joined: Wed Sep 11, 2019 7:42 am
Location: Coimbatore
Contact:

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 7:08 am

Without Multicore Processing Support its same as TILE Now.

Efficiency of Multiple Cores cannot be harnessed. Most efficient HW like CCR2216 and CCR2116 are facing issues when running MPLS VPLS or PPPoE as the entire load is over a single core.
 
User avatar
nithinkumar2000
Member Candidate
Member Candidate
Posts: 164
Joined: Wed Sep 11, 2019 7:42 am
Location: Coimbatore
Contact:

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 7:11 am

+1 for PPPoE. My CCR2116 maxes out at around 900MBps on my pppoe uplink.
Yes This is because of Entire load on of PPPoE is getting Processed by Single Core. You can Observe one of the CPU Core will be Fully Choked while Other Cores will be Idle or Free.

Currently i think Mikrotik is only allowing Multicore Processing for some features like BGP, Routes Print, OSPF, RIP ,etc... but MPLS, VPLS, VXLAN, PPPoE etc are still same not multicore processing support.
 
wispmikrotik
Member Candidate
Member Candidate
Posts: 142
Joined: Tue Apr 25, 2017 10:43 am

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 9:59 am

I am wondering the same. This cycle does take really long... My guess is that they are doing some internal changes to polish behavior with new Winbox 4, but - who knows...
Hi,

New stable?

Image

Regards,
 
Rox169
Member
Member
Posts: 464
Joined: Sat Sep 04, 2021 1:47 am

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 12:55 pm

When?
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 1:28 pm

Don't push Mikrotik too hard. Last time I remember people were nagging for RC become stable release was 7.14 IIRC. And we all know this was no good idea. 16MB devices running out of space everywhere and lots of other issues. So better be patient. Mikrotik, take your time to test and fix.
 
wispmikrotik
Member Candidate
Member Candidate
Posts: 142
Joined: Tue Apr 25, 2017 10:43 am

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 2:16 pm

Hi

We are not in a hurry xD, we only saw that in its official documentation and we were surprised to see v7.17 with green markers.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 12425
Joined: Thu Mar 03, 2016 10:23 pm

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 2:23 pm

We are not in a hurry xD, we only saw that in its official documentation and we were surprised to see v7.17 with green markers.

I guess that they are planning to introduce some additional functionality (e.g. "Starting from RouterOS v7.17, DHCP snooping is supported with hardware offloading bonding interfaces.") with 7.17 (which is probably in some alpha stage for internal testing only) and the table already shows that. But that doesn't mean that (stable) 7.17 will be released at any certain date (probably it'll be still in 2024, but I wouldn't bet on exact month). Remember, we're still bitching about bugs in 7.16beta (not stable 7.16) ...
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 2:29 pm

At least I see no advantage of releasing another major stable release with unresolved Intel AX issues.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 12425
Joined: Thu Mar 03, 2016 10:23 pm

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 2:39 pm

It's normal to have software release with known issues (even before releasing it), accompanying documentation just has to mention those clearly. On the other hand it's sometimes good (if not necessary) to release new version due to required new functionality ... while keeping to work on resolving known bugs and issues. If MT would stick to principle you implicitly proposed, then we'd still be in 7.0beta stage because some (borderline) functionality, which was available in v6, still isn't ironed out. Which would likely solve the issue "with unresolved intel AX issues" because we still wouldn't have wifi (wave2) drivers in stable ROS release.

For example, personally I don't have any problems with intel and/or ax, so personally I'm all in for new version with new advanced features (which I won't use, but new and advanced is cool).
 
User avatar
spippan
Member
Member
Posts: 440
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 6:05 pm

v7.16rc4 - DNS VRF does not work.
When setting:
/ip dns set vrf=mgmtvrf
the system always sends DNS queries via the main vrf, regardless of this setting.
issued SUP-160816 on 2024-07-31 with not a single reaction

had the same idea with a mgmt vrf where i needed DNS resolution ... went the "main VRF only it is then.." route
 
User avatar
spippan
Member
Member
Posts: 440
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 6:07 pm

Is there any chance of Multicore Processing of Following in ROS v7.x:

1. MPLS + VPLS
2. PPPOE
3. VXLAN
+1 for VXLAN!

also waiting on MACsec in hw-offload
...and wishing on WireGuard to be available for hw-offload but that is a whole different story
 
infabo
Forum Guru
Forum Guru
Posts: 1258
Joined: Thu Nov 12, 2020 12:07 pm

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 6:36 pm

mkx, you new here? I am not aware of any ROS changelog listing a single known issue. That did not and is not going to happen. Known issues are buried in community (!!) forum release topic in an unstructured manner. That is the reality.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7154
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 7:29 pm

v7.16rc4 - DNS VRF does not work.
When setting:
/ip dns set vrf=mgmtvrf
the system always sends DNS queries via the main vrf, regardless of this setting.
issued SUP-160816 on 2024-07-31 with not a single reaction

had the same idea with a mgmt vrf where i needed DNS resolution ... went the "main VRF only it is then.." route
This parameter means that DNS listens for queries from the clients in a specified VRF. As far as I understand you have DNS servers also reachable from the VRF and you expect that router will send dns queries to those servers on that vrf? If that is the case then you misunderstood what the parameter does and that feature is not even implemented. This feature is in a todo list.
 
merkkg
just joined
Posts: 8
Joined: Thu Jan 19, 2017 11:50 am

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 7:35 pm

Is there any chance of Multicore Processing of Following in ROS v7.x:

1. MPLS + VPLS
2. PPPOE
3. VXLAN
Mmulticore MPLS / MPLS HW Offload
 
rpingar
Long time Member
Long time Member
Posts: 593
Joined: Fri May 28, 2004 2:46 pm
Location: Italy

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 8:33 pm

we discovered that netflows are not generated when they are about inter vlan l3hw accelerated traffic.
observing this on CCR2216 where we had spike of traffic (l3hw) on a vlan on these was not reported on our netflow collector.
SUP-165456 generated
 
wtechlink
just joined
Posts: 16
Joined: Tue Mar 03, 2020 3:09 am

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 8:39 pm

Is there any chance of Multicore Processing of Following in ROS v7.x:

1. MPLS + VPLS
2. PPPOE
3. VXLAN
+1 for PPPOE multicore. We have thousands of customers using PPPOE and want to start rolling out speeds faster than 1Gb but can't do so with single core limitations.
 
User avatar
spippan
Member
Member
Posts: 440
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 9:38 pm

we discovered that netflows are not generated when they are about inter vlan l3hw accelerated traffic.
observing this on CCR2216 where we had spike of traffic (l3hw) on a vlan on these was not reported on our netflow collector.
SUP-165456 generated
OT: (sorry)
@rpingar
what netflow solution do you use to collect and view the data?
 
User avatar
spippan
Member
Member
Posts: 440
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 9:39 pm



issued SUP-160816 on 2024-07-31 with not a single reaction

had the same idea with a mgmt vrf where i needed DNS resolution ... went the "main VRF only it is then.." route
This parameter means that DNS listens for queries from the clients in a specified VRF. As far as I understand you have DNS servers also reachable from the VRF and you expect that router will send dns queries to those servers on that vrf? If that is the case then you misunderstood what the parameter does and that feature is not even implemented. This feature is in a todo list.
so the VRF setting for DNS does not mean, the DNS resolver works in that VRF but rather only listens in that VRF?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7154
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 10:00 pm

Yes, it is like in any other configuration with vrf parameter.
 
User avatar
spippan
Member
Member
Posts: 440
Joined: Wed Nov 12, 2014 1:00 pm

Re: v7.16rc [testing] is released!

Tue Sep 17, 2024 10:51 pm

Yes, it is like in any other configuration with vrf parameter.
is there a possible solution to resolve to upstream dns from e.g. a management VRF?

unfortunately this is not allowed:
/ip dns set servers=1.1.1.2@management
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7154
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 8:50 am

Like I already said it is in a todo list.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 10:24 am

Is it also on the todo list to have the service (and other services, e.g. NTP) on more than one VRF?
(like /ip dns set vrf=vrf1,vrf2,vrf3)
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 3:48 pm

Is it also on the todo list to have the service (and other services, e.g. NTP) on more than one VRF?
In my point of view, this would be better solved using by the concept that uses Juniper.
Al the services in a different namespace by default.
Some kind of linking-bridge between that namespace and the rest of the world.
(like /ip dns set vrf=vrf1,vrf2,vrf3)
In that case, if the services were in vrf=management, to other services reach that service would be obligatory some kind of route-leaking between those vrfs.
What is expected in a true scenario of VRFs.
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 4:03 pm


Yes This is because of Entire load on of PPPoE is getting Processed by Single Core.
When you talk about PPPoE in single thread, you are talking about what case specifically?
PPPoE-Client?
PPPoE-Server with only one customer?

I'm quite sure that PPPoE Server load can be distributed over several threads...
Even on RouterOSv6 it is possible. On older releases you could need some ugly thing as put several listeners on same interface, but it is possible.

But a single PPPoE connection (server or client) cannot be distributed on several threads.
And, maybe I'm mistaken, but it is valid to other PPPoE engines like Accell.
This is relative to the machine-state of PPPoE.

The solution to this is not multithread the PPPoE!
The solution to that, in the specific case of CCR2XXX that has Switch Chip, is Hardware Off-Load the PPPoE forwarding.
 
rpingar
Long time Member
Long time Member
Posts: 593
Joined: Fri May 28, 2004 2:46 pm
Location: Italy

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 4:11 pm

we discovered that netflows are not generated when they are about inter vlan l3hw accelerated traffic.
observing this on CCR2216 where we had spike of traffic (l3hw) on a vlan on these was not reported on our netflow collector.
SUP-165456 generated
OT: (sorry)
@rpingar
what netflow solution do you use to collect and view the data?
kentik
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 4:49 pm

Is there any chance of Multicore Processing of Following in ROS v7.x:

1. MPLS + VPLS
2. PPPOE
3. VXLAN
Your request should change a bit!
Instead of requesting Multithread, request hardware offload to then!

MPLS For example...
CRS can do Label Swapping (P. Router position) in line rate using the hardware offload and a very small CPU!
But the MPLS encapsulation (PE position) even CCR 2116 or a X86/X64 can do it in Line Rate without gaps for large amount of bandwidth and PPS.

So, your efforts with MikroTik team should be directed to convince then to use correctly the SDK of the Marvell Switch Chips.
Saying that considering white papers of Marvell says that those swit chips supports MPLS, and that there are other vendors in market that using that same switch chips can do hardware-based forwarding of MPLS.

The same with VXLAN.
Marvel declares support to VXLAN and GENEVE on their white papers of Prestera, but we do not see it as supported on Hardware off-load docs of MikroTik.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2165
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 4:50 pm

we discovered that netflows are not generated when they are about inter vlan l3hw accelerated traffic.
observing this on CCR2216 where we had spike of traffic (l3hw) on a vlan on these was not reported on our netflow collector.
SUP-165456 generated
This is a known and long standing issue with RouterOS on platforms that make use of L3HW.
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 4:57 pm

An important thin note about VRF and Hardware Off-Load
Your request should change a bit!
Instead of requesting Multithread, request hardware offload to then!
Another thing that needs to be said is that VRF and Hardware Off-Load did not work well together on RouterOS.

A few months ago, I did some Prove of Concepts using VRF on CCR2004 and RouterOSv7.x(In my mind I remember being 7.12 or similar).
When I enabled VRF, it disabled the hardware offload.

Docs of Mikrotik about VRF confirms that, at least by now.
"VRF N/A Only the main routing table gets offloaded."

Hey? What? Only on Main Table?
What about the concept of Underlay and Overlay?
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 5:05 pm

we discovered that netflows are not generated when they are about inter vlan l3hw accelerated traffic.
observing this on CCR2216 where we had spike of traffic (l3hw) on a vlan on these was not reported on our netflow collector.
SUP-165456 generated
Just to confirm...
This happens with a Vlan as a Sub-Interface of a hardware interface, or in a Bridge Vlan scenario?

In my opinion(guess) this is related to the fact that RouterOS allows you to do a fruit salad on L2 and L3 sub-interfaces.
On a full CPU scenario it does not affect much, but in hardware off-load this is problematic.
No other vendor with high hardware performance allows that mix.

What some calls of "magic and flexibility" is what causes the issues.
 
buset1974
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Wed Sep 13, 2006 12:12 pm
Location: Jakarta

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 5:42 pm

polish behavior with new Winbox 4, but - who knows...
Would not make sense to me. Winbox 4 is early beta and that should not be any priority for any stable ROS version right now.
Agree, we are hoping years to get MT v7 stable , the hardware seem promising though
 
User avatar
clambert
Member Candidate
Member Candidate
Posts: 157
Joined: Wed Jun 12, 2019 5:04 am

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 9:35 pm

Your request should change a bit!
Instead of requesting Multithread, request hardware offload to then!
I think it is appropriate to require multithreading for these protocols. Mikrotik currently sells a lot of multicore devices that does not have the ability to support L3 hardware offload.
 
bbs2web
Member Candidate
Member Candidate
Posts: 233
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: v7.16rc [testing] is released!

Wed Sep 18, 2024 11:08 pm

Thank you for sharing your experience, disabling one QSFP at a time results in the problem continuing (tested with only QSFP1-1 and QSFP2-1. I'll try without the peer link being LACP and alternatively with a non bonded SFP+ interface as the peer link.

I have a suspicion that the issue is unique to the CRS354, sometimes works for hours without issues but can be as bad as loosing the peer link 20 times an hour.
@bbs2web: MLAG peerlink

I have 2 x CRS317 with LACP 802.3ad peerlink, connected via 2 x 10g DAC cables. No issues with the peerlink flapping. Zero.
Since you have already tried replacing the DAC cables without success, maybe try moving the peerlink to two SFP+ (10G) ports with suitable DAC cables. Rule out an issue with the Q+ port(s). Alternatively since you said this occurs frequently, unplug one of the Q+ ports (I know it breaks redundancy, but for the testing period hopefully that is acceptable), and see if the flapping continues. Then plug that Q+ port back and unplug the other Q+ port... Trying to determine if this is the peerlink over Q+ failing, or a bad Q+ port, or a bad Q+ cable.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2165
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: v7.16rc [testing] is released!

Thu Sep 19, 2024 1:47 am

Your request should change a bit!
Instead of requesting Multithread, request hardware offload to then!
I think it is appropriate to require multithreading for these protocols. Mikrotik currently sells a lot of multicore devices that does not have the ability to support L3 hardware offload.
This...

Absolutely need software based offloads as well. Whether its Multicore FastPath or some new method, it needs to be done.

A lot of WISP's are using RB4011, RB5009, CCR2004-16G-2S+ in their POP's and would get no benefit from ASIC based offloads, they would however get a huge benefit from better software based offload support.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

Thu Sep 19, 2024 3:19 pm

What is that even supposed to be, "software based offload"?
What we have now is a situation where PPPoE client is handled in software. The ethernet frames are received just like IP, and then the PPPoE header is stripped off in software.
It looks like this causes some load on the CPU limiting the datarate to below 1Gbps on many routers.
Other manufacturers use the same SoC in their routers and do not have that problem, so apparently there is capability in the SoC to offload part of this work to hardware. But MikroTik does not use it because they use standard Linux network handling instead of the dedicated SDK from each SoC manufacturer (understandable because of the many different SoC used in different MikroTik routers).
So now we have to hope that at some point, for the router models that support it and that are most affected by this, this offloading is supported by RouterOS.
But it would still be hardware offloading.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2165
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: v7.16rc [testing] is released!

Thu Sep 19, 2024 3:31 pm

What is that even supposed to be, "software based offload"?
What we have now is a situation where PPPoE client is handled in software. The ethernet frames are received just like IP, and then the PPPoE header is stripped off in software.
It looks like this causes some load on the CPU limiting the datarate to below 1Gbps on many routers.
Other manufacturers use the same SoC in their routers and do not have that problem, so apparently there is capability in the SoC to offload part of this work to hardware. But MikroTik does not use it because they use standard Linux network handling instead of the dedicated SDK from each SoC manufacturer (understandable because of the many different SoC used in different MikroTik routers).
So now we have to hope that at some point, for the router models that support it and that are most affected by this, this offloading is supported by RouterOS.
But it would still be hardware offloading.
I think we may be talking about different use cases.

Which other manufacturers and products are you comparing Mikrotik to ?
 
nmt1900
Frequent Visitor
Frequent Visitor
Posts: 83
Joined: Wed Feb 01, 2017 12:36 am

Re: v7.16rc [testing] is released!

Thu Sep 19, 2024 3:55 pm

This "software based offload" looke like multithreading to me in this case...
 
pe1chl
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

Thu Sep 19, 2024 4:41 pm

I think we may be talking about different use cases.

Which other manufacturers and products are you comparing Mikrotik to ?
All those manufacturers that make the routers that ISPs supply with the 1Gbps+ internet connections they deliver today.
AVM, Arcadyan, Linksys, etc etc etc.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

Thu Sep 19, 2024 4:43 pm

This "software based offload" looke like multithreading to me in this case...
Multithreading is often not useful in these cases because at least a single connection will have to be processed in sequence.
I.e. when you have a single PPPoE client connected to your ISP via a single network interface, there is not much that can be multithreaded.
Of course when you have two ISP each with a PPPoE client, they can be distributed over different cores, at least when the hardware allows it.
(unfortunately in todays routers there often is a switch chip connected to the CPU with only a single connection, and all incoming traffic is handled the same, no matter what interface it arrived on)
 
SystemErrorMessage
Member
Member
Posts: 390
Joined: Sat Dec 22, 2012 9:04 pm

Re: v7.16rc [testing] is released!

Thu Sep 19, 2024 4:55 pm

This "software based offload" looke like multithreading to me in this case...
Multithreading is often not useful in these cases because at least a single connection will have to be processed in sequence.
I.e. when you have a single PPPoE client connected to your ISP via a single network interface, there is not much that can be multithreaded.
Of course when you have two ISP each with a PPPoE client, they can be distributed over different cores, at least when the hardware allows it.
(unfortunately in todays routers there often is a switch chip connected to the CPU with only a single connection, and all incoming traffic is handled the same, no matter what interface it arrived on)
in programming thats not the case. you can have multiple queues bound to a single io. that io can be its own thread, the other queues can be their own threads.
In python it is recommended to thread your IOs/request and multiprocess anything CPU intensive. multi threading is bound to a single process but can better use multiple cores to handle io tasks even if its to a single destination.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10495
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.16rc [testing] is released!

Thu Sep 19, 2024 5:25 pm

The point is that when you use constructs that allow you to process a single stream of information in multiple threads, and also you need to guarantee that the processing is done in sequence, you are only wasting effort on thread synchronization that is not made up for in the increased performance of multiple cores.
Remember the PPPoE processing of data packets is trivial. It is not like processing a web request, or similar.

Who is online

Users browsing this forum: No registered users and 3 guests