v7.14rc [testing] is released!

Mon Feb 12, 2024 9:52 am

RouterOS version 7.14rc 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.14rc4 (2024-Feb-28 13:38):

*) route - use correct routing table for addresses on VRF interface (introduced in v7.14beta3);
*) smb - fixed export with default configuration (introduced in v7.14beta7);

What's new in 7.14rc3 (2024-Feb-27 10:06):

*) lte - improved FG621-EA modem firmware upgrade;
*) ovpn - limit the maximum length for "push-routes" up to 1400 characters;
*) sstp - added support for "aes256-gcm-sha384" encryption;

What's new in 7.14rc2 (2024-Feb-20 12:35):

!) rose-storage - moved SMB service to the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service, compatible with SMB 2.1, SMB 3.0 and SMB 3.1.1);
*) bridge - fixed MLAG connection after peer-link flap (introduced in v7.13);
*) bridge - fixed MLAG connection issues due to STP (introduced in v7.14beta3);
*) bridge - fixed packet forwarding after changing HW offloaded bridge interface settings in certain cases (introduced in v7.13);
*) bridge - fixed port mst-override status (introduced in v7.14beta3);
*) defconf - improved wifi interface detection after upgrade;
*) lte - added redial timer when the MBIM modem fails to register or does not receive APN activation notification;
*) ovpn - improved "push-routes" option handling when large amount of routes is specified;
*) sms - increased SMS read timeout;

What's new in 7.14rc1 (2024-Feb-09 12:32):

!) rose-storage - moved SMB service to the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service, compatible with SMB 2.1, SMB 3.0 and SMB 3.1.1);
*) disk - added global disk "settings" menu;
*) disk - fixed changing settings on some GPT formatted disks;
*) dns - do not close connection with DoH server after query execution (introduced in 7.14beta8);
*) ethernet - fixed issue with default interface names for CRS310-8G+2S+ in rare cases;
*) fetch - added "patch" option for "http-method";
*) fetch - fixed fetch execution when unexpected data is received in HTTP payload;
*) isis - show passive interface active levels;
*) modem - fixed modem firmware-upgrade (introduced in v7.14beta9);
*) sstp - improved system stability for PPC devices;
*) system - expose "lo" and "vrf" interfaces;
*) webfig - fixed showing WireGuard peers;
*) wifi-qcom - improved memory allocating process;

Other changes since v7.13:

*) 6to4 - make "ipsec-secret" sensitive parameter;
*) api - improved REST API stability when processing invalid requests;
*) api - properly return SNMP OIDs when requested;
*) arm - improved system stability when using microSD on RB1100Dx4;
*) arp - added ARP status;
*) bgp - allow to leak routes between local VRFs;
*) bridge - added MLAG support for MSTP bridges;
*) bridge - avoid per-VLAN host flushing on HW offloaded bridge;
*) bridge - fixed auto "path-cost" for bonding interfaces (introduced in v7.13);
*) bridge - fixed host flush on BPDU-guard port disable (introduced in v7.14beta3);
*) bridge - improved bridge VLAN configuration validation;
*) bridge - improved configuration speed on large VLAN setups;
*) bridge - improved protocol-mode MSTP functionality;
*) bridge - improved protocol-mode STP and RSTP functionality;
*) bridge - make "point-to-point=yes" default value for non-wireless bridge ports;
*) bridge - removed "mst-config-digest" from MSTI menu;
*) bridge - try to set wireless bridge ports as edge ports automatically;
*) bth - added simple "Back To Home Users" manager under IP/Cloud menu;
*) calea - improved system stability when adding bridge rule without "calea" package installed;
*) certificate - improved certificate validation performance;
*) console - added ":tolf" and ":tocrlf" commands for converting line break to/from LF or CRLF;
*) console - added "show-at-cli-login" option to display a note before telnet login;
*) console - added missing "where" clause for "/ipv6/firewall/filter" table print command;
*) console - do not accept negative or too large values for ":delay" command;
*) console - do not allow to use out-of-range values for time type fields;
*) console - fix configuration export when user does not have a "sniff" policy;
*) console - fixed delayed output from ":grep" command in certain cases;
*) console - fixed incorrect behavior of ":onerror" command in certain cases;
*) console - hint on reset command help that ".rsc file" is required for "run-after-reset" parameter;
*) console - improved editor functionality in full screen mode;
*) console - improved stability when using autocomplete with "export";
*) console - increased maximum file content length that can be managed through command line to 60 KB;
*) console - updated copyright notice;
*) container - improved VETH interface management responsiveness and reliability;
*) container - restrict "/container/shell" menu for users without "write" permissions;
*) defconf - added log about configuration reset due to pressed reset button;
*) defconf - do not add loopback interface to the bridge ports (introduced in v7.14beta3);
*) defconf - fixed Audience scanning-for-wps-ap timeout;
*) defconf - fixed configuration script on KNOT devices if "ppp-out" interface is removed;
*) defconf - fixed firewall rule for IPv6 UDP traceroute;
*) defconf - fixed wifi configuration if interface MAC address is changed;
*) defconf - increased LTE interface wait time;
*) defconf - updated health settings on configuration revert;
*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;
*) dhcpv6-client - install dynamic IPv6 blackhole routes in corresponding routing-table;
*) dhcpv6-client - updated error logging when multiple prefixes received on renew;
*) disk - added exFAT and NTFS mount/read/write support;
*) disk - properly unmount disk when it is disconnected;
*) dns - do not add new entries to cache if "cache-size" is reached;
*) dns - fixed DNS service crash when DoH used (introduced in v7.14beta4);
*) dns - fixed domain name lookup resolving for internal services;
*) ethernet - improved cable-test reliability for hAP ax3 PoE out port;
*) ethernet - resolved minor memory leak while processing packets;
*) fetch - added "head" option for "http-method";
*) fetch - allow specifying link-local address in FTP mode;
*) fetch - allow to use certificate and check-certificate parameters only in HTTPS mode;
*) fetch - do not require "content-length" for HTTP (introduced in v7.13);
*) fetch - fixed DNS resolving when domain has only AAAA entries (introduced in v7.13);
*) fetch - fixed fetch when using "src-path" with HTTP/HTTPS modes (introduced in v7.13);
*) fetch - fixed fetch when using "src-path" with SFTP mode (introduced in v7.13);
*) fetch - fixed incorrect "src-path" error message when "upload=yes";
*) fetch - fixed IPv4 address logging (introduced in v7.13);
*) fetch - fixed timeout when content-length is 0 (introduced in v7.14beta4);
*) fetch - improved fetch stability in SFTP mode;
*) fetch - improved file download stability with HTTP/HTTPS modes;
*) fetch - less verbose logging;
*) fetch - print all "Set-Cookies" headers in response;
*) fetch - treat any 2xx HTTP return code as success (introduced in v7.13);
*) filesystem - improved filesystem integrity for several RB3011 units with automatic firmware upgrade;
*) firewall - added "creation-time" parameter for IPv6 address list entries;
*) firewall - fixed underlying CAPsMAN tunnel reusing packet marks of encapsulated packets;
*) firewall - fixed underlying VXLAN/EoIP tunnel reusing packet marks of encapsulated packets;
*) firewall - increased default "udp-timeout" value from 10s to 30s;
*) health - added limited manual control over fans for CCR1016r2, CCR1036r2 devices;
*) health - changed default "fan-min-speed-percent" from 0% to 12%;
*) health - improved fan control on CRS3xx and CCR1016-12S-1S+r2;
*) health - show voltage when powering KNOT R through Micro-USB;
*) health - updated health properties for CCR1016r2, CCR1036r2 devices;
*) iot - added bluetooth whitelist wildcard asterisk support;
*) iot - added LoRa CUPs protocol support;
*) iot - fixed modbus partial frame reception issue;
*) iot - improved LoRa LNS;
*) iot - improved modbus Tx/Rx switching behaviour;
*) iot - improvements to GPIO behavior on boot;
*) iot - improvements to LoRa CUPS;
*) iot - removed bluetooth whitelist maximum entry limit of 8;
*) ipv6 - made "valid" and "lifetime" parameters dynamic for SLAAC IPv6 addresses;
*) l3hw - fixed IPv6 host offloading in certain cases;
*) l3hw - fixed neighbor offloading after link flap;
*) l3hw - preserve offloading for VLANs when bridge ports are down;
*) leds - added "dark-mode" functionality for hAP ax3 and Chateau ax series devices;
*) leds - do not show LTE connection state/mode using RGB power LED from configless LTE modems;
*) leds - fixed "type=on" LED behaviour after reboot;
*) leds - fixed default LTE LED configuration for wAPR-2nD;
*) leds - fixed modem LED indication for SXT LTE 3-7;
*) leds - fixed modem signal strength for RBSXTR&R11e-LTE (introduced in v7.14beta6);
*) leds - fixed wireless type of LED triggers for routers using WiFi package;
*) lte - added "at-chat" support for Sierra Wireless EM9293 5G modem;
*) lte - added AT channel support for Quectel EM120K-GL modem;
*) lte - don't duplicate primary band in 5G SA mode for chateau 5G;
*) lte - fixed "use-peer-dns" setting for EC200A modem;
*) lte - fixed an issue for EC200A modem that IPv6 address could be added as IPv4 address;
*) lte - fixed APN authentication for FG621-EA modem;
*) lte - fixed MBIM interface enabling for Quectel EC25 modem (introduced in v7.13);
*) lte - fixed Simcom modem support in 0x9000; 0x9002, 0x9002; 0x901a and 0x901b USB compositions;
*) lte - fixed Simcom modem support in 0x9001 USB composition;
*) lte - fixed support for config-less modem detection (introduced in v7.13);
*) lte - fixed USB mode switch and initialization race condition for configless USB modems;
*) lte - improved modem recovery after failed IPv4 configuration;
*) lte - improved support for "ACER" and "MSFT" branded EM12-G modems;
*) lte - optimized "at-chat" response reading;
*) lte - refactored AT command control for AT modems;
*) modem - fixed SMS removal (introduced in v7.13);
*) modem - improved stability when performing modem FOTA upgrade;
*) mpls - fixed VPN fragmentation when forwarding IP traffic;
*) netinstall-cli - check package and device architecture before formatting;
*) ovpn - added support for pushing routes;
*) ovpn - improved key-renegotiation process;
*) ovpn - improved OVPN configuration file import process;
*) ovpn - improved system stability when using HW encryption on ARM64 devices (introduced in v7.13);
*) package - added "size" property;
*) package - reduced "wireless" package size for ARM, ARM64, MIPSBE, MMIPS devices;
*) package - reduced package size for SMIPS;
*) poe-out - driver optimization for AF/AT controlled boards;
*) poe-out - fixed "power-cycle" for CRS354-48P-4S+2Q+ device (introduced in v7.13);
*) poe-out - improved 802.3at classification and measurement accuracy;
*) poe-out - improved cable test for hAP ac3 and hAP ax3 devices;
*) poe-out - improved PoE out reliability on routers with a single PoE out interface;
*) port - fixed support for USB/serial adapters (introduced in v7.13);
*) port - removed bogus serial port on RB750Gr3, RB760iGS and RBM11G devices;
*) ppp - added support for "WISPr-Session-Terminate-Time" RADIUS attribute;
*) ppp - log an error when IPv6 DHCP pool is exhausted;
*) ptp - added "aes67" and "smpte" profiles;
*) ptp - added configurable "domain" and "priority2" parameters;
*) ptp - added support for Management message forwarding in BC;
*) ptp - fixed "default" and "g8275.1" profiles go into "slave" instead of "uncalibrated" state;
*) ptp - fixed default values for "802.1as" profile;
*) ptp - fixed flags in Announce message;
*) ptp - fixed potential error in packet exchange;
*) ptp - make clock go into grandmaster state if slave port goes down;
*) qos-hw - fixed "tx-queue7-packet" counter;
*) route - fixed gateways of locally imported vpnv4 routes;
*) route - fixed route lockup when loading large amount of routes on ARM64 (introduced in v7.14beta4);
*) route - improved route print "count-only" process speed;
*) route - improved stability on route table lookup;
*) route-filter - added option to set "isis-ext-metric";
*) route-filter - fixed AS path matchers when input and output chains are used;
*) routerboard - added "reset-button" support for RBwAPR-2nD device;
*) sfp - added support for modules requiring single byte I2C read transactions;
*) sfp - fixed corrupted Tx traffic at 10Gbps rate on CCR2004-16G-2S+ in rare cases;
*) sfp - fixed corrupted Tx traffic at 10Gbps rate on RB4011 in rare cases;
*) sfp - improve high-power SFP module initialization;
*) sfp - improved combo-sfp handling for CRS328-4C-20S-4S+;
*) sfp - improved link establishment for RB4011 devices;
*) smb - added option to specify SMB service mode as "auto";
*) smips - improved system stability (introduced in v7.14beta4);
*) sms - fixed SMS inbox for FG621-EA modem (introduced in v7.13);
*) sms - fixed SMS sending from WinBox and WebFig (introduced in v7.13);
*) sms - improved system stability when working with SMS;
*) snmp - added "bgpLocalAs" and "bgpIdentifier" OID reporting;
*) snmp - fixed "bgpPeerFsmEstablishedTime" OID reporting;
*) snmp - hide "MikroTik" in LLDP MIB when branding with hide SNMP option is used;
*) snmp - updated timeout log;
*) ssh - improved SSH performance on ARM, MIPS, MMIPS, SMIPS and TILE devices;
*) ssh - refactored SSH service internal processes;
*) sstp - added support for "aes256-gcm-sha384" encryption;
*) supout - added PTP section;
*) switch - fixed "cpu-flow-control" for RB3011 (introduced in v7.14beta3);
*) switch - fixed "vlan-mode" and "default-vlan-id" property reset after reboot (introduced in v7.14beta3);
*) switch - fixed Atheros switch port configuration export (introduced in v7.14beta3);
*) switch - fixed Atheros-8327 switch rules (introduced in v7.14beta3);
*) switch - fixed Ethernet disable/enable for CRS310-8G+2S+ devices;
*) switch - fixed reserved multicast receive on Atheros-8327, QCA8337 switches for R/STP bridge;
*) switch - improved 100G interface stability for 98DX4310 and 98DX8525 switches;
*) switch - minimise potential packet overflows on CRS354;
*) system - changed build time format according to ISO standard;
*) system - correctly handle HTTP 1xx and 204 response status codes (introduced in v7.14beta6);
*) system - fixed "cpu-frequency" for CRS3xx ARM devices;
*) system - improved memory allocation for ARM64 devices;
*) system - improved RAM allocation for L009UiGS-RM;
*) system - improved system stability when processing packets in FastPath (introduced in v7.13);
*) system - properly assign destination port for HTTP/S connections initiated by the router (introduced in v7.13);
*) system - properly close HTTP/S connections initiated by the router;
*) system - properly start HTTP/S connections initiated by the router if non-default port is used (introduced in v7.14beta3);
*) system - provide more precise "total-memory" value for ARM devices;
*) system - provide more precise "total-memory" value under "System/Resources" menu for L009 and hAP ax lite routers;
*) tftp - improved invalid request processing;
*) timezone - updated timezone information from "tzdata2023d" release;
*) tr069 - don't duplicate cellular info in "X_MIKROTIK_5G" nodes when connected in NR SA mode;
*) tr069 - fixed bandwidth test;
*) tr069-client - show 5G signal info in X_MIKROTIK_5G nodes only for 5G NSA bands;
*) traffic-flow - use 64bit counters for v9 and IPFIX flows;
*) traffic-generator - improved system stability when receiving bogus traffic;
*) usb - show "Supermicro CDC" adapter as Ethernet interface;
*) vlan - fixed non-running VLAN interface after failed MTU change;
*) vrf - prevent VRF interface name collision with interface lists;
*) vxlan - fixed underlying tunnel reusing routing marks of encapsulated packets;
*) webfig - fixed routing table filter under "IP/Routes" menu;
*) webfig - fixed setting the user's password;
*) webfig - improved stability when adding new entries under "IP/Routes" menu;
*) wifi - added "station-pseudobridge" interface mode;
*) wifi - fixed issue with setting country profile (introduced in v7.13.1);
*) wifi - improved handling of CAP connections in dual CAPsMAN scenario;
*) wifi - increased value for SAE retransmit period to 3s to improve WPA3 compatibility with IoT client devices;
*) wifi - use "Latvia" as default value for "country" property;
*) wifi - use correct CAP identity for interface name provisioning after it has been changed by remote-cap/set-identity;
*) wifi-qcom - enable display of regulatory information on L11,L22 devices;
*) wifi-qcom - fixed new connections, when maximum supported number of MAC addresses behind connected station-bridges is reached;
*) wifi-qcom - improve system stability for L11, L22 devices;
*) wifi-qcom - improved system stability when using FastPath (introduced in v7.13);
*) winbox - added "accept-protocol-version" parameter to the L2TP server settings;
*) winbox - added "mode-button" and "switch" menus for L41G-2axD&FG621-EA;
*) winbox - added "Name" parameter under "Tools/Netwatch" menu;
*) winbox - added "page-refresh" setting to the Graphing settings;
*) winbox - added "Port Cost Mode" setting under "Bridge" menu;
*) winbox - added "VRF" parameter under "Tools/Ping" menu;
*) winbox - added "x25519" argument for "DH Group" parameter under "IP/IPsec/Profiles" menu;
*) winbox - added missing "Protocol" arguments under "IPv6/Firewall" menu;
*) winbox - added missing monitoring properties under "WireGuard/Peers" menu;
*) winbox - aded Preboot Etherboot settings to the System/RouterBOARD/Settings menu;
*) winbox - do not show USB settings for CRS devices that does not need it;
*) winbox - fixed "Bridge Cost" range under "Interfaces/VPLS" menu;
*) winbox - fixed "Password" button under "Quick Set" menu;
*) winbox - fixed status under "Bridge/Ports" menu (introduced in v7.14beta3);
*) winbox - improved connection speed and reliability;
*) winbox - improved route table automatic refresh process for static routes;
*) winbox - improved status values under "System/PTP" menu;
*) winbox - improved system stability with large packets;
*) winbox - include "te-tunnel" parameter in VPLS interface monitor;
*) winbox - properly validate "passthrough-subnet-size" in the LTE APN settings;
*) winbox - remove "Root Bridge ID" property under "Bridge/MSTIs" menu;
*) winbox - removed "sfp all" option from combo port settings;
*) winbox - renamed "Wireless Table" menu to "Wifi";
*) winbox - show "routing-table" column under IP/Route menu by default;
*) winbox - show all columns under "Routing/PIM SM/Static RP" menu by default;
*) wireguard - do not allow to use multiple WireGuard interfaces on the same "listen-port";
*) wireguard - optimised and improved WireGuard service logging;
*) x86 - fixed VLAN tagged packet transmit for igb (introduced in v7.12);

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.

pe1chl · Mon Feb 12, 2024 10:58 am

No solution for the memory shortage in 15.3MB ARM devices?

Rox169 · Mon Feb 12, 2024 11:04 am

What do you mean? I can not install this RC on ARM with 16 MB?

erlinden · Mon Feb 12, 2024 11:18 am

cAP XL ac and wAP ac upgraded (from 7.13.4) without problems (besides my RB4011).
Only had to suppress Wireguard logging.

massinia · Mon Feb 12, 2024 11:28 am

!) rose-storage - moved SMB service to the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service, compatible with SMB 2.1, SMB 3.0 and SMB 3.1.1);

It still doesn't work for me...
Windows clients see the share but cannot access it.

ivicask · Mon Feb 12, 2024 11:59 am

!) rose-storage - moved SMB service to the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service, compatible with SMB 2.1, SMB 3.0 and SMB 3.1.1);
It still doesn't work for me...
Windows clients see the share but cannot access it.

It works fine for me.

massinia · Mon Feb 12, 2024 12:17 pm

It still doesn't work for me...
Windows clients see the share but cannot access it.

It works fine for me.

Thanks to your help I found the cause!

Doesn't work when the share name is uppercase:
Test - KO
test - OK

Reported with SUP-143577

BrateloSlava · Mon Feb 12, 2024 1:26 pm

*) wifi-qcom - improved memory allocating process;

Is this update only for wifi-qcom or also for wifi-qcom-ac?

kalaposl · Mon Feb 12, 2024 1:30 pm

Also not working for me. Tried with Windows PC and Android. Not uppercase/lowercase issue for me. Share can be seen, but can't access.

!) rose-storage - moved SMB service to the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service, compatible with SMB 2.1, SMB 3.0 and SMB 3.1.1);
It still doesn't work for me...
Windows clients see the share but cannot access it.

bratislav · Mon Feb 12, 2024 2:05 pm

cAP XL ac and wAP ac upgraded (from 7.13.4) without problems (besides my RB4011).
Only had to suppress Wireguard logging.

I presume wAP ac is an arm version not mipsbe...
Was the wifi-qcom-ac package used?
How much HDD space was left free on cAP XL ac and wAP ac after the upgrade?

Mon Feb 12, 2024 2:40 pm

kalaposl post your SMB export please

erlinden · Mon Feb 12, 2024 2:49 pm

I presume wAP ac is an arm version not mipsbe...

Yes

Was the wifi-qcom-ac package used?

Yes

How much HDD space was left free on cAP XL ac and wAP ac after the upgrade?

cAP XL ac: 372 KiB
wAP ac: 356 KiB

This according to /system/resources

JohnTRIVOLTA · Mon Feb 12, 2024 3:41 pm

No solution for the memory shortage in 15.3MB ARM devices?

The solution is simple! Reset the device without def.conf. , after that make upgrade, or make netinstall with new npk version. The occupied space after the procedure is 14.9MB.
Finally new setup based on old config, do not use old backup file.

Mesquite · Mon Feb 12, 2024 4:21 pm

Impressive list of changes, looking forward to 7.14 stable.

pe1chl · Mon Feb 12, 2024 4:30 pm

No solution for the memory shortage in 15.3MB ARM devices?
The solution is simple! Reset the device without def.conf. , after that make upgrade, or make netinstall with new npk version. The occupied space after the procedure is 14.9MB.

Yes, but for me a device with only 350kB free is not viable. Too much risk that it gets corrupted at some time again at an upgrade or when configuring something.
There really has to be more free space.
I have a device I use for some test and when upgrading between two of the 7.14beta versions I again lost 500kB, instead of gaining space.
I have lost the confidence in the future of 15.3MB ARM devices (hAP ac2, LHG5ac and maybe others).

Amm0 · Mon Feb 12, 2024 4:38 pm

*) disk - added global disk "settings" menu;

Is the menu suppose to do something?

/disk settings print           
  auto-smb-sharing: yes
     auto-smb-user: *****

I had only one share before... but checking the "auto share" box does not add other non-shared partitions, or do anything it seems. Docs don't mention it either.

massinia · Mon Feb 12, 2024 8:29 pm

Also not working for me. Tried with Windows PC and Android. Not uppercase/lowercase issue for me. Share can be seen, but can't access.

It still doesn't work for me...
Windows clients see the share but cannot access it.

kalaposl post your SMB export please

There is a bug in the selection of interfaces (Winbox), SMB only works with the first interface in the list.
kalaposl put the bridge as the first interface and try again...

Remove old credentials from windows also if they are the same and use \\routerIP\shareforder URL format

mantouboji · Tue Feb 13, 2024 4:38 am

Call for ed25519 private key.

Ullinator · Tue Feb 13, 2024 11:37 am

After Update from 7.14beta10 to 7.14RC1 the throughput of my fileserver dropped down to only ~80-500KBit!!
Both servers are connected to a CRS326-24S+2Q+ (MIBSBE) to the both QSFP ports with 40GBit.
No errors are shown in the logs and also not in the connection of the QSFP modules. (which are in use since ~2 years with this switch)
After downgrade to 7.14beta10 everything went back to normal.
@MT: nothing in the changelog let assume that this behaviour could happen. Do you have an explanation?

Tue Feb 13, 2024 12:19 pm

Ullinator, we would need to see the full config in the RC1

Ullinator · Tue Feb 13, 2024 12:24 pm

Ullinator, we would need to see the full config in the RC1

Hi Normis,

via Support-Ticket?

Tue Feb 13, 2024 12:47 pm

either a new topic or in a support ticket, yes.
in general the new SMB should be very fast, so curious what is different in your setup

Ullinator · Tue Feb 13, 2024 1:13 pm

either a new topic or in a support ticket, yes.
in general the new SMB should be very fast, so curious what is different in your setup

Hi Normis,
I think this is a misunderstanding. I don´t use the buildin SMB-service.
The fileserver are Windows Server 2022 and use their native fileservices. (SMB 1.3)
The problem is the throuput via the Switch to those both file server afte the update. I assume something with the "ethernet" or the SFP´s, but I don´t have any evidences for that.
The config on that switch is unchanged since many month and since some ROS updates.
I´ll open a ticket with the config and an supout.rif :-)

YO3IPT · Tue Feb 13, 2024 10:47 pm

Also not working for me. Tried with Windows PC and Android. Not uppercase/lowercase issue for me. Share can be seen, but can't access.

kalaposl post your SMB export please
There is a bug in the selection of interfaces (Winbox), SMB only works with the first interface in the list.
kalaposl put the bridge as the first interface and try again...

Remove old credentials from windows also if they are the same and use \\routerIP\shareforder URL format

I had the same issue - not being able to access the smb share. I changed the share name to all lowercase and now i can connect. In my case the order of the interfaces did not matter.

mirolm · Tue Feb 13, 2024 11:24 pm

CVE-2023-52160, Does this affects ROS in any way?

DarkNate · Wed Feb 14, 2024 12:41 am

*) system - expose "lo" and "vrf" interfaces;

Does this mean we can (or should?) delete our "loopback bridge" interfaces and use the native loopback interface of the Linux kernel?

*) bgp - allow to leak routes between local VRFs;

Do we have any configuration example/documentation for this?

Rox169 · Wed Feb 14, 2024 12:58 pm

Hi,
Netwatch is not sending notification thorough Teams...

I use this
:log error "Ping to RAP AX56 1 OK"

/tool fetch http-method=post http-header-field="Content-Type: application/json" http-data="{\"text\": \"Ping to RAP AX56 1 OK\"}" url=https://itwconnect.webhook.office.com/w ... f216e4b7fd

and in the log is: Couldn't start task: cannot open file: permission denied

Do you please know what is wrong?

infabo · Wed Feb 14, 2024 6:11 pm

fetch needs FTP pernission?

Etz · Wed Feb 14, 2024 8:47 pm

CVE-2023-52160, Does this affects ROS in any way?

Did you read it or are you just throwing CVE numbers around?
If you did read that CVE, you would know the answer ;)

nichky · Thu Feb 15, 2024 2:10 am

i hope that the LTE can be fixed on the stable version , as per advised.

Thu Feb 15, 2024 8:18 am

i hope that the LTE can be fixed on the stable version , as per advised.

Can you please clarify exactly what you mean ?

kalaposl · Thu Feb 15, 2024 11:12 am

kalaposl post your SMB export please

[admin@MikroTik] > ip smb export
# 2024-02-15 09:36:21 by RouterOS 7.14rc1
# software id =
#
# model = RB952Ui-5ac2nD
# serial number =
/ip smb users
set [ find default=yes ] read-only=yes
add name=1234
/ip smb
set domain=WORKGROUP enabled=yes
/ip smb shares
set [ find default=yes ] directory=/flash/pub
add directory=flash name=share1 valid-users=1234
add directory=usb1-part1 name=share2 valid-users=1234

Tried with interfaces=all and interfaces=ether3 (that's the only running interface), neither work with 2 Windows 10 PCs and an Android phone.

oeyre · Thu Feb 15, 2024 11:18 am

OSPF SNMP support when?

chojrak11 · Thu Feb 15, 2024 7:05 pm

v7.14rc1 (firmware v7.14rc1) on hAP ax^3 - USB disk handling is totally broken.

I upgraded from 7.13.3 because my new IoT lightbulbs did not connect to Wi-Fi with 7.13 and I saw this in release notes:

*) wifi - increased value for SAE retransmit period to 3s to improve WPA3 compatibility with IoT client devices;

and yes, it helped, but at the same time USB disk has started behaving in a weird way. My container stopped working, recreating it ended with "error".

Trying to format the USB disk does not succeed most of the time. The disk randomly disappears, just like it was ejected by the system. Unfortunately there are no logs regarding formatting or ejecting.

I was able to capture the process of formatting and disappearing of the partition. See the screencast below. Note that the action occurs at the end - the window with partition details automatically disappears, the partition is no more, and the disk is not selectable in dropdown anymore. The LED on the disk suggests it's been ejected.

2024-02-15_17-50-40_winbox.gif

Also, when displaying properties, the UUID of the partition changes while looking at it - a phenomenon that should never occur.

2024-02-15_17-46-48_winbox.gif

I double checked the USB disk in my laptop and it's perfectly okay, got another one with the same symptoms.

nichky · Thu Feb 15, 2024 11:21 pm

Can you please clarify exactly what you mean ?

the LTE usb 4g dongles , since v7.13 are not working.
I've raised a ticket, and i've been advised that on v7.14 stable probably will be fixed.

(im using that fro BTH)

Fri Feb 16, 2024 7:52 am

Ullinator - Did you manage to create a support ticket? We would like to check out what is going on here for you, since the issue clearly is caused by an upgrade.

Njumaen · Fri Feb 16, 2024 9:27 am

As I cannot open a new topic I post my request here, in hope to be heard... ;-)

Feature Request: Wireguard client config: configurable "AllowedIPs"

As 0.0.0.0/0, ::0 is not always the right choice, this should be configurable.

Most of the time I do not want to route all traffic through wireguard as I use split-tunneling, so i beg you: please! :-)

Ralf.

jhbarrantes · Fri Feb 16, 2024 10:11 am

I think you can define whatever you want on the client side to do this split-tunneling behavior you mention. What you point out is just a reference.

Regards.

roggles · Fri Feb 16, 2024 10:28 am

Hello folks,

If I use the rest API extensively for getting stats etc, the user list gets spammed with active users.
Please fix this or what am I doing wrong?

Greetings

/user/active/print
36 2024-02-15 13:48:28 api 10.10.0.5 (unknown)
37 2024-02-15 13:58:30 api 10.10.0.5 (unknown)
38 2024-02-15 14:08:31 api 10.10.0.5 (unknown)
40 2024-02-15 14:28:32 api 10.10.0.5 (unknown)
41 2024-02-15 14:38:33 api 10.10.0.5 (unknown)
42 2024-02-15 14:48:34 api 10.10.0.5 (unknown)
43 2024-02-15 14:58:36 api 10.10.0.5 (unknown)
44 2024-02-15 15:08:36 api 10.10.0.5 (unknown)
45 2024-02-15 15:18:37 api 10.10.0.5 (unknown)
46 2024-02-15 15:28:38 api 10.10.0.5 (unknown)
47 2024-02-15 15:38:39 api 10.10.0.5 (unknown)
48 2024-02-15 15:48:39 api 10.10.0.5 (unknown)
49 2024-02-15 15:58:40 api 10.10.0.5 (unknown)
50 2024-02-15 16:08:40 api 10.10.0.5 (unknown)
51 2024-02-15 16:18:41 api 10.10.0.5 (unknown)
52 2024-02-16 08:01:50 api 10.10.0.5 (unknown)
53 2024-02-16 08:11:50 api 10.10.0.5 (unknown)
58 2024-02-16 08:21:54 api 10.10.0.5 (unknown)
59 2024-02-16 08:21:54 api api

erlinden · Fri Feb 16, 2024 10:36 am

If I use the rest API extensively for getting stats etc, the user list gets spammed with active users.

Looks like you are using a new connection for every request. Is the list cleared after some time?

roggles · Fri Feb 16, 2024 10:54 am

yes, i use a new connection course it's http...
I have not found any session cookie or something for auth reuse.

nodejs/javascript sample

const axios = require('axios');
...
const res = await axios.get(`${this.host}:${this.port}/rest/interface`, {
'headers': { },
timeout: this.timeout,
auth: {
username: this.user,
password: this.password
}
});

Kevdevon · Fri Feb 16, 2024 12:04 pm

*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;

What difference does this make in practice? My assumption would be that it only has an impact when the ethernet port is maxed out, but the likelihood is that the LTE will be maxed out first.

Ullinator · Fri Feb 16, 2024 12:30 pm

Ullinator - Did you manage to create a support ticket? We would like to check out what is going on here for you, since the issue clearly is caused by an upgrade.

Hi strods,
no, I didn´t, because, like I wrote in my first post, I did a downgrade to 7.14Beta10 after the issue and everything was good.
As a preparation for the config-files and the supout.sif I´ve upgraded the device once again to 7.14RC1 and after this second upgrade the problem didn´t exist anymore.
I have no explanation for this. :-/
During the first issue with 7.14RC1 and the bad performance I´ve rebooted my server to exclude an error with them. But nothing helped, the performanmce even between the two servers (both 40GBit connection to the CRS) was only ~500kBit/s. What I didn´t do was a second reboot of the switch itself at that time.
Long speak, shot summary: the issue has gone after the second update to 7.14RC1. :-)

Njumaen · Fri Feb 16, 2024 2:42 pm

I think you can define whatever you want on the client side to do this split-tunneling behavior you mention. What you point out is just a reference.

Regards.

Sure, I could do it on the client side, but with this additional field I can create a complete config file or QRcode on the server side.

Cheers.

Fri Feb 16, 2024 6:40 pm

v7.14rc1 (firmware v7.14rc1) on hAP ax^3 - USB disk handling is totally broken.

Also, when displaying properties, the UUID of the partition changes while looking at it - a phenomenon that should never occur.

I double checked the USB disk in my laptop and it's perfectly okay, got another one with the same symptoms.

UUID will change that is how it supposed to be.
I can't recreate disk disappearance on my machine.

pe1chl · Fri Feb 16, 2024 7:42 pm

*) bgp - allow to leak routes between local VRFs;

For those that do not use VRF but use manually created route tables, it would be very convenient when there would be an option to import Connected routes into a newly created table (so they can be distributed using BGP).
E.g.: add an option to /routing/table/add which specifies an interface list. All connected routes to interfaces in that list are imported into that routing table, similar to what happens in a VRF.

Amm0 · Fri Feb 16, 2024 8:00 pm

*) bgp - allow to leak routes between local VRFs;
For those that do not use VRF but use manually created route tables, it would be very convenient when there would be an option to import Connected routes into a newly created table (so they can be distributed using BGP).
E.g.: add an option to /routing/table/add which specifies an interface list. All connected routes to interfaces in that list are imported into that routing table, similar to what happens in a VRF.

Good one! I'd never thought about that way, but simplify PBR rules too. Today, you have to force local subnets going to main, or statically configure each route table with local/connected routes.

chojrak11 · Fri Feb 16, 2024 8:35 pm

I can't recreate disk disappearance on my machine.

I was able to do it even by simple file upload operation. Please see the screencast. Note it has approx. 75 seconds and the issue is near the end. Pay attention when the upload counter shows 400 MiB. As you can see the disk is different than in the previous screencast (Patriot USB 2.0 vs SMI USB 3.0) but the issue persists.

(The mouse position is weird due to DPI difference between my main and the second monitor).

2024-02-16_19-25-52_winbox.gif

jhbarrantes · Sat Feb 17, 2024 10:48 am

*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;

What difference does this make in practice? My assumption would be that it only has an impact when the ethernet port is maxed out, but the likelihood is that the LTE will be maxed out first.

Can you see this actually updated on queue menu? I have updated an LtAP-mini to 7.14rc1 and there are no changes on this menu: no new queue on queue types menu, and ether1 is still on "only-hardware-queue" in tab "Interface Queues".

Thanks.

ips · Sat Feb 17, 2024 11:26 am

Changes in defconf are not applied on upgrades, AFAIK.

pe1chl · Sat Feb 17, 2024 12:08 pm

Changes in defconf are not applied on upgrades, AFAIK.

That is correct, you need to reset the device to defaults to see such changes.
Or you can do /system/default-configuration/print and selectively cut/paste from that.
(it is also possible to use file=filename with that, and download the file, for easier examination)

pe1chl · Sat Feb 17, 2024 12:12 pm

For those that do not use VRF but use manually created route tables, it would be very convenient when there would be an option to import Connected routes into a newly created table (so they can be distributed using BGP).
E.g.: add an option to /routing/table/add which specifies an interface list. All connected routes to interfaces in that list are imported into that routing table, similar to what happens in a VRF.
Good one! I'd never thought about that way, but simplify PBR rules too. Today, you have to force local subnets going to main, or statically configure each route table with local/connected routes.

Yes, and with routes only present as PBR rules you cannot advertise them on BGP anymore, they really have to be in that routing table.
So you need to manually open each connected route, copy it, and save it in the appropriate routing table.
It would be much more convenient when there could be an automatic import, like there is with VRF.

Reason I bring it up again: yesterday I found a bug in a router config that was caused by the changed behavior of routing rules on v7 (changed from v6) which has been present ever since I changed the router from a CCR1009 to a CCR2004 and was thus forced to migrate to v7. I have been searching for this problem for more than half a year... :-(
While it of course is my own responsibility to configure the router correctly, this problem would not have occurred when I could have those connected routes automatically imported.

jhbarrantes · Sat Feb 17, 2024 9:22 pm

Changes in defconf are not applied on upgrades, AFAIK.
That is correct, you need to reset the device to defaults to see such changes.
Or you can do /system/default-configuration/print and selectively cut/paste from that.
(it is also possible to use file=filename with that, and download the file, for easier examination)

Is this in relation to my comment? It is weird because, even when that is true, I spect to see at least the definition of the new queue in queue > queue types, isn't it? I cannot see fq_codel defined there.

Kind regards.

pe1chl · Sun Feb 18, 2024 12:29 am

You can use the /system/default-configuration/print to see what is in defconf and find out how it relates to your expectations or wishes.

sergiobeltrao · Sun Feb 18, 2024 3:02 am

v7.14rc1 (firmware v7.14rc1) on hAP ax^3 - USB disk handling is totally broken.

Also, when displaying properties, the UUID of the partition changes while looking at it - a phenomenon that should never occur.

I double checked the USB disk in my laptop and it's perfectly okay, got another one with the same symptoms.
UUID will change that is how it supposed to be.
I can't recreate disk disappearance on my machine.

I'm sorry, why is the UUID supposed to change? The whole idea behind it isn't that it will not change, since it's unique? I don't get it.

pekr · Sun Feb 18, 2024 8:27 am

You can use the /system/default-configuration/print to see what is in defconf and find out how it relates to your expectations or wishes.

OP clearly stated the obvious and you seem not to understand nor answer his question? So once again - how is something as queue-types related to the defconf or resetting the router? It has imo nothing to do with anyone expectations, nor wishes.

Paternot · Sun Feb 18, 2024 8:57 am

OP clearly stated the obvious and you seem not to understand nor answer his question? So once again - how is something as queue-types related to the defconf or resetting the router? It has imo nothing to do with anyone expectations, nor wishes.

Because this is a NEW queue type in RoS. Since it's new, it wasn't set in the 7.13.x series. Now it is the new default - but RoS doesn't change configurations already made: this is by design. It's too risky to change something that the user already uses.

So. Devices upgraded from 7.13.x to 7.14.x keep the old default. Devices that are netinstalled get the new default. The user can change this, of course - but only after the upgrade.

mozerd · Sun Feb 18, 2024 11:05 am

CCR1009 LAB Testing v7.14rc

A new log entry appears that I have never seen before:

Download from api.ipify.org FINISHED

Is this injected by MikroTik in THIS RC and for what reason ?

api.ipify[.]org and similar domains have long been used by malware to look up an infected device’s public IP. In research on malicious artifacts published by SANS, Jay Yanza detected api.ipify[.]org used as a third-party external IP lookup in 205 of 7747 unique file hashes. Other IP lookup sites totaled over 2000. Of all malware types, ransomware utilizes external IP lookups most often as it is generally a location-based threat. While an external IP lookup is not in and of itself malicious, it may be an unexpected occurrence that requires further investigation.

I reverted my LAB CCR1009 back to v7.13.4 and no such log enty was made ...

DarkNate · Sun Feb 18, 2024 11:07 am

CCR1009 LAB Testing v7.14rc

A new log entry appears that I have never seen before:
Download from api.ipify.org FINISHED
Is this injected by MikroTik in THIS RC and for what reason ?

api.ipify[.]org and similar domains have long been used by malware to look up an infected device’s public IP. In research on malicious artifacts published by SANS, Jay Yanza detected api.ipify[.]org used as a third-party external IP lookup in 205 of 7747 unique file hashes. Other IP lookup sites totaled over 2000. Of all malware types, ransomware utilizes external IP lookups most often as it is generally a location-based threat. While an external IP lookup is not in and of itself malicious, it may be an unexpected occurrence that requires further investigation.
I reverted my LAB CCR1009 back to v7.13.4 and no such log enty was made ...

Malware infected box. Do a clean netinstall and null config, then configure from scratch.

jhbarrantes · Sun Feb 18, 2024 11:24 am

OP clearly stated the obvious and you seem not to understand nor answer his question? So once again - how is something as queue-types related to the defconf or resetting the router? It has imo nothing to do with anyone expectations, nor wishes.
Because this is a NEW queue type in RoS. Since it's new, it wasn't set in the 7.13.x series. Now it is the new default - but RoS doesn't change configurations already made: this is by design. It's too risky to change something that the user already uses.

So. Devices upgraded from 7.13.x to 7.14.x keep the old default. Devices that are netinstalled get the new default. The user can change this, of course - but only after the upgrade.

I do agree your point, but adding a new default queue type to the queue type list (the ones with the start simbol << * >> at begining) doesn't break anything. I expected to see the queue there, but no association with the Interface queue type, as you said, for not breaking backward compatibility.

But yes, as @pe1chl mention, the default configuration script shows the new queue definition + assignment:

/queue type add name=fq-codel-ethernet-default kind=fq-codel fq-codel-ecn=no
/queue interface set [find default-queue=only-hardware-queue] queue=fq-codel-ethernet-default

In my opinion, still pretty werid not to see the queue defined as another default queue type.

mozerd · Sun Feb 18, 2024 11:30 am

Malware infected box. Do a clean netinstall and null config, then configure from scratch.

Thanks for your feedback but I do not agree just yet ... I am monitrring the LAB CCR1009 with wireshark and so far I do not see any activity from api.ipify.org under v7.13.4 [stable]

Sun Feb 18, 2024 11:33 am

FWIW, I am NOT seeing those log entries on Hex and mAP running latest 7.14. Why only on CCR then ?
I even downloaded the complete default script, nothing to be found in there related to this api.ipify.org (or anything with "api" in it, for that matter).
But it "could" be CCR only ...

Upgrade again to 7.14rc and check default script (which might already be pretty empty, I guess ?).

mozerd · Sun Feb 18, 2024 11:42 am

But it "could" be CCR only ...

Upgrade again to 7.14rc and check default script (which might already be pretty empty, I guess ?).

What do you mean by "check default script" ?

If this api is not appearing on your devices when running v7.14rc THEN its tied to something else and I suspect a Google Chrome extension ...

But I am curiouse by that "check default script"

pe1chl · Sun Feb 18, 2024 12:14 pm

You can use the /system/default-configuration/print to see what is in defconf and find out how it relates to your expectations or wishes.
OP clearly stated the obvious and you seem not to understand nor answer his question? So once again - how is something as queue-types related to the defconf or resetting the router? It has imo nothing to do with anyone expectations, nor wishes.

The changelog indicates that there is a change labeled "defconf". You DO NOT see those changes on an existing router that you are upgrading, unless you reset the router to defaults. "defconf" = "default configuration".
Sure enough it has happened several times in the past that very useful changes were made in defconf that never made it to customer routers because they were not in defconf at the time the router was shipped, but that is how it is and I doubt that will ever change.
(e.g. the recent new 6.49.13 release only changed defconf, if we have to believe the changelog. that is totally useless because a 6.49.13 release will only be installed as an upgrade, and an upgrade does not apply defconf)

About the "it is not a default queue type": that has been explained by others. You (and defconf) can add new queue types.

mozerd · Sun Feb 18, 2024 1:00 pm

But I am curiouse by that "check default script"

api.ipify.org Mystery SOLVED ....

I have a script that checks my WAN IP Address for changes ... in that script a call is made to api.ipify.org .... For some reason v7.14rc is now showing log info from this script that I have not seen before .... in fact since v7.13+ MikroTik has made quite a few changes to how stuff now reports in the log file.

/system script add dont-require-permissions=no name=Dynu owner=aaaa policy=read,write,policy,test source=":local ddnsuser \"mmmmm\"\
\n:local ddnspass \"^XxXxXxXxXxXXXXxxx\"\
\n:local ddnshost \"zzzzzzzzzz.myddns.rocks\"\
\n\
\n:local currentIP ([/tool fetch url=\"http://api.ipify.org\" as-value output=user]->\"data\")\
\n:local dnsIP [:resolve \$ddnshost]\
\n:if (\$currentIP != \$dnsIP) do={\
\n :local update \"https://api.dynu.com/nic/update\?userna ... $currentIP\"\
\n /tool fetch url=\$update keep-result=no\
\n :log info \"DYNU \$ddnshost updated: old IP was \$dnsIP and new IP is \$currentIP\"\
\n}\
\n"

Sun Feb 18, 2024 1:56 pm

There you have it.
Self inflicted issue

kreb · Sun Feb 18, 2024 3:28 pm

CCR2116, OSPFv3 has a problem on 7.14rc, downgrading to 7.13.4 solved the issue.

baragoon · Sun Feb 18, 2024 4:21 pm

CCR2116, OSPFv3 has a problem on 7.14rc, downgrading to 7.13.4 solved the issue.

What problem? Any details? I don’t see any problems with OSPF (both versions) at my CHRs with RC.

kreb · Sun Feb 18, 2024 4:53 pm

CCR2116 is connected to 3810m, bonded connection LACP, OSPFv3 state is stuck on LOADING'
7.14rc1
CCR2116

/routing/ospf/neighbor> print
Flags: V - virtual; D - dynamic
 0  D instance=ospf-instance-ipv4 area=ospf-area-ipv4 address=10.255.1.2 router-id=10.255.255.2 state="Full"
      state-changes=5 adjacency=9m12s timeout=33s

 1  D instance=ospf-instance-ipv6 area=ospf-area-ipv6 address=fe80::bccc:ecdd:fe98:6600%bonding1 router-id=10.255.255.2
      state="Full" state-changes=5 adjacency=5m29s timeout=31s

Aruba 3810m

core# show ipv6 ospf3 neighbor

 OSPFv3 Neighbor Information


 Interface   Router ID       Pri   State      Rxmt QLen  Events
 ----------- --------------- ----- ---------- ---------- ----------
 vlan-510    10.0.0.1        n/a   LOADING    0          8
 vlan-520    10.255.255.3    n/a   FULL       0          5

Downgrading to 7.13.4 solves the problem,

core# show ipv6 ospf3 neighbor

 OSPFv3 Neighbor Information


 Interface   Router ID       Pri   State      Rxmt QLen  Events
 ----------- --------------- ----- ---------- ---------- ----------
 vlan-510    10.0.0.1        n/a   FULL       0          4
 vlan-520    10.255.255.3    n/a   FULL       0          5

baragoon · Sun Feb 18, 2024 5:45 pm

@kreb, thanks for the info, my infra is MikroTik only and everything is ok with OSPF.

bajodel · Sun Feb 18, 2024 7:44 pm

/queue type add name=fq-codel-ethernet-default kind=fq-codel fq-codel-ecn=no
/queue interface set [find default-queue=only-hardware-queue] queue=fq-codel-ethernet-default

Hey guys, what boards have this as default?
I was looking for those lines in a RB4011 default but it seems to me they are not there.

ips · Sun Feb 18, 2024 9:57 pm

Change log says:
*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;

DarkNate · Mon Feb 19, 2024 7:36 am

Change log says:
*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;

They failed to add BQL:
viewtopic.php?p=1046881&hilit=bql#p1046881

jookraw · Mon Feb 19, 2024 10:58 am

After upgrading my RB5009, I noticed that I lost one of my WAN's, could not get IP address via DHCP.
After some investigation I noticed that packets on port eth1 (member of bridge with the PVID set) still comes out with tagged packets on that vlan.
rolling back to 7.13.4 solves the issue.

SUP-144218

chojrak11 · Mon Feb 19, 2024 10:04 pm

I can't recreate disk disappearance on my machine.
I was able to do it even by simple file upload operation. Please see the screencast. Note it has approx. 75 seconds and the issue is near the end. Pay attention when the upload counter shows 400 MiB. As you can see the disk is different than in the previous screencast (Patriot USB 2.0 vs SMI USB 3.0) but the issue persists.

Rollback to v7.13.5 resolved the issue. This same Patriot USB stick formatted to ext4 and I was able to create a container on it.
So there definitely _is_ an issue with USB disks on hAP ax^3 in 7.14rc1.

Thanks in advance for fixing it!

massinia · Tue Feb 20, 2024 10:24 am

So there definitely _is_ an issue with USB disks on hAP ax^3 in 7.14rc1.

Mine works perfectly, maybe it's just a compatibility problem with your hdd

Tue Feb 20, 2024 11:20 am

So there definitely _is_ an issue with USB disks on hAP ax^3 in 7.14rc1.

Could you please reach out to me through support system? I cant recreate disk disappear issue. I will also give you modified version with different formatting tools, that will fix other mentioned problems.

chojrak11 · Tue Feb 20, 2024 2:40 pm

So there definitely _is_ an issue with USB disks on hAP ax^3 in 7.14rc1.
Could you please reach out to me through support system? I cant recreate disk disappear issue. I will also give you modified version with different formatting tools, that will fix other mentioned problems.

Done! SUP-144400

Rox169 · Tue Feb 20, 2024 2:47 pm

Hi,

Im not able to get work Netwatch/ fetch to send any notification. I had fetch thorough Teams I did not touch the config but it is not working anymore. Today I tried set it up with Telegram and there is info Fetch failed with status 400 or Mode not specify.

Is here anyone with working Netwatch/Fetch?

pe1chl · Tue Feb 20, 2024 3:34 pm

Anything that requires fetch now requires FTP permission. Netwatch doesn't have that, I think.
So you need to use special tricks and they are barely documented. Probably someone here knows what to do.

noradtux · Tue Feb 20, 2024 4:51 pm

Change log says:
*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;
They failed to add BQL:
viewtopic.php?p=1046881&hilit=bql#p1046881

Did you open a feature request for that? This forum is not the right place to do that ..

noradtux · Tue Feb 20, 2024 4:54 pm

Anyone else having issues with 10GBaseT SFP+ on CRS317? Mine stops working after update to 7.14. Like, link is up, but cannot reach other side. (SUP-144396)

Solution:
Had the affected bridge port set to edge=no. Setting it to edge=auto makes it work again. Mikrotik support was quick to help :)

Wed Feb 21, 2024 8:22 am

Hey guys, what boards have this as default?
I was looking for those lines in a RB4011 default but it seems to me they are not there.

The defaults only change things on new routers, or if you do a factory reset. Also, like the changelog says, the specific change is for LTE devices, which does not include RB4011

Wed Feb 21, 2024 10:14 am

What's new in 7.14rc2 (2024-Feb-20 12:35):

!) rose-storage - moved SMB service to the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service, compatible with SMB 2.1, SMB 3.0 and SMB 3.1.1);
*) bridge - fixed MLAG connection after peer-link flap (introduced in v7.13);
*) bridge - fixed MLAG connection issues due to STP (introduced in v7.14beta3);
*) bridge - fixed packet forwarding after changing HW offloaded bridge interface settings in certain cases (introduced in v7.13);
*) bridge - fixed port mst-override status (introduced in v7.14beta3);
*) defconf - improved wifi interface detection after upgrade;
*) lte - added redial timer when the MBIM modem fails to register or does not receive APN activation notification;
*) ovpn - improved "push-routes" option handling when large amount of routes is specified;
*) sms - increased SMS read timeout;

Wed Feb 21, 2024 10:26 am

*) lte - added redial timer when the MBIM modem fails to register or does not receive APN activation notification;

Does this solve the current issues with Fibocom FG621-EA FW version 05 (Ax Lite LTE) ?

nichky · Wed Feb 21, 2024 11:40 am

the LTE still no fixed!

nichky · Wed Feb 21, 2024 11:41 am

also ovpn between MTs is extremely unstable, unlike MT-->win

CTassisF · Wed Feb 21, 2024 3:31 pm

I'm also having problems with USB stick disappearing on RB5009.

I use the USB stick as storage for my containers, and after 3~4 days of uptime the usb1-part1 disk disappears from /file and garbage is shown in /disk.

The weird part is that all containers continue to work, but after a while this seems to corrupt data in the USB stick.

I thought this problem was related to my USB stick, so I didn't report the problem before. I will wait until it happens again and then open a ticket with support.

fl4co · Wed Feb 21, 2024 3:46 pm

v7.14rc1 (firmware v7.14rc1) on hAP ax^3 - USB disk handling is totally broken.

I upgraded from 7.13.3 because my new IoT lightbulbs did not connect to Wi-Fi with 7.13 and I saw this in release notes:
Code: Select all
*) wifi - increased value for SAE retransmit period to 3s to improve WPA3 compatibility with IoT client devices;
and yes, it helped, but at the same time USB disk has started behaving in a weird way. My container stopped working, recreating it ended with "error".

Trying to format the USB disk does not succeed most of the time. The disk randomly disappears, just like it was ejected by the system. Unfortunately there are no logs regarding formatting or ejecting.

I was able to capture the process of formatting and disappearing of the partition. See the screencast below. Note that the action occurs at the end - the window with partition details automatically disappears, the partition is no more, and the disk is not selectable in dropdown anymore. The LED on the disk suggests it's been ejected.

2024-02-15_17-50-40_winbox.gif

Also, when displaying properties, the UUID of the partition changes while looking at it - a phenomenon that should never occur.

2024-02-15_17-46-48_winbox.gif

I double checked the USB disk in my laptop and it's perfectly okay, got another one with the same symptoms.

Same for me with hap ax3, USB drive will cause a kernel panic and reboot after a few minutes in RC1. Will test on RC2.
EDIT: still kernel panic and reboot on RC2. Also formating seems broken, and when it actually works my PC sees the partition as ext3 and not as ext4 (this happened even before 7.14).

Miracles · Wed Feb 21, 2024 8:18 pm

v7.14rc1 (firmware v7.14rc1) on hAP ax^3 - USB disk handling is totally broken.

I upgraded from 7.13.3 because my new IoT lightbulbs did not connect to Wi-Fi with 7.13 and I saw this in release notes:
Code: Select all
*) wifi - increased value for SAE retransmit period to 3s to improve WPA3 compatibility with IoT client devices;
and yes, it helped, but at the same time USB disk has started behaving in a weird way. My container stopped working, recreating it ended with "error".

Trying to format the USB disk does not succeed most of the time. The disk randomly disappears, just like it was ejected by the system. Unfortunately there are no logs regarding formatting or ejecting.

I was able to capture the process of formatting and disappearing of the partition. See the screencast below. Note that the action occurs at the end - the window with partition details automatically disappears, the partition is no more, and the disk is not selectable in dropdown anymore. The LED on the disk suggests it's been ejected.

2024-02-15_17-50-40_winbox.gif

Also, when displaying properties, the UUID of the partition changes while looking at it - a phenomenon that should never occur.

2024-02-15_17-46-48_winbox.gif

I double checked the USB disk in my laptop and it's perfectly okay, got another one with the same symptoms.
Same for me with hap ax3, USB drive will cause a kernel panic and reboot after a few minutes in RC1. Will test on RC2.
EDIT: still kernel panic and reboot on RC2. Also formating seems broken, and when it actually works my PC sees the partition as ext3 and not as ext4 (this happened even before 7.14).

Can confirm, having the same kernel panic issue with RB5009 and USB stick, but only when SMB is enabled. RC4.

FIPTech · Thu Feb 22, 2024 3:55 am

I keep having the MTU reseting from 1700 to 1500 on a VLAN interface. 7.14 RC1. RB5009.

The VLAN interface is on a VLAN aware Bridge (L2MTU = 1704 on the bridge interface). MTU = 1700 is accepted, then strangely revert to 1500 without any reported error.

It's very annoying. I loose connectivity because this larger 1700 MTU is needed for an IPIPv6 tunnel.

In the meantime i would need a script to regularly check this value and reset it to 1700 if it did change.

I would be grateful if someone has such a similar script that i could use as a template.

7.14 RC2 does not seem to solve the problem. After upgrading from 7.14RC1 to 7.14RC2, the MTU was again at 1500.

Kevo · Thu Feb 22, 2024 4:11 am

I keep having the MTU reseting from 1700 to 1500 on a VLAN interface. 7.14 RC1. RB5009.

The VLAN interface is on a VLAN aware Bridge (L2MTU = 1704 on the bridge interface). MTU = 1700 is accepted, then strangely revert to 1500 without any reported error.

Is there another interface on the bridge that has a lower MTU? I feel like I ran into this kind of thing using bridged tunnels at some point in the past and I think it was an interface that I missed updating the MTU on somewhere.

Thu Feb 22, 2024 8:36 am

*) lte - added redial timer when the MBIM modem fails to register or does not receive APN activation notification;
Does this solve the current issues with Fibocom FG621-EA FW version 05 (Ax Lite LTE) ?

Unfortunately no, we have found a regression in the 05 FW that would lead to the lte interface to not show up in some cases, for now the version is removed from the upgrade server and a downgrade to 04 is recommended.

Thu Feb 22, 2024 8:38 am

the LTE still no fixed!

What issue are you referring to? Do you have a support ticket already open for this issue?

Thu Feb 22, 2024 8:53 am

... for now the version is removed from the upgrade server and a downgrade to 04 is recommended.

Thank you for the feedback but how is a normal user supposed to do this downgrade ? It's only possible via support, I believe ?

eworm · Thu Feb 22, 2024 8:57 am

You can do a usual "upgrade", that results in a downgrade as 05 has been pulled from servers and 04 is latest.

Thu Feb 22, 2024 9:16 am

I keep having the MTU reseting from 1700 to 1500 on a VLAN interface. 7.14 RC1. RB5009.

The VLAN interface is on a VLAN aware Bridge (L2MTU = 1704 on the bridge interface). MTU = 1700 is accepted, then strangely revert to 1500 without any reported error.

It's very annoying. I loose connectivity because this larger 1700 MTU is needed for an IPIPv6 tunnel.

In the meantime i would need a script to regularly check this value and reset it to 1700 if it did change.

I would be grateful if someone has such a similar script that i could use as a template.

7.14 RC2 does not seem to solve the problem. After upgrading from 7.14RC1 to 7.14RC2, the MTU was again at 1500.

Hi, what is the bridge interface's MTU (not L2MTU)? And what MTU values have bridge members? If any VLAN member (e.g., a bridge port with the respective pvid value) has a lower MTU (like 1500), the entire bridge resets MTU to the lowest value.

Bridges operate on Layer 2, where packet fragmentation is not possible. In other words, a bridge cannot forward a 1700-byte packet to an MTU=1500 port. Hence, the bridge selects the lowest MTU of the bridged interfaces (ports).

Please share your "/interface print" and "/interface export" output for further analysis.

pe1chl · Thu Feb 22, 2024 10:55 am

Thank you for the feedback but how is a normal user supposed to do this downgrade ? It's only possible via support, I believe ?

I think you are confused with stuff from another manufacturer here. It has never been a problem to downgrade on MikroTik,
only you cannot downgrade below the version that was installed at the factory. When you have upgraded it yourself, you can
always downgrade to the previous version.

eworm · Thu Feb 22, 2024 11:02 am

Thank you for the feedback but how is a normal user supposed to do this downgrade ? It's only possible via support, I believe ?
I think you are confused with stuff from another manufacturer here. It has never been a problem to downgrade on MikroTik,
only you cannot downgrade below the version that was installed at the factory. When you have upgraded it yourself, you can
always downgrade to the previous version.

This was about LTE firmware for hAP ax lite LTE6's modem, so actually this is not possible under normal conditions. In this case it is.

nichky · Thu Feb 22, 2024 12:21 pm

@emilst

What issue are you referring to? Do you have a support ticket already open for this issue?

support #[SUP-138649]:

FIPTech · Thu Feb 22, 2024 12:31 pm

I keep having the MTU reseting from 1700 to 1500 on a VLAN interface. 7.14 RC1. RB5009.

The VLAN interface is on a VLAN aware Bridge (L2MTU = 1704 on the bridge interface). MTU = 1700 is accepted, then strangely revert to 1500 without any reported error.

It's very annoying. I loose connectivity because this larger 1700 MTU is needed for an IPIPv6 tunnel.

In the meantime i would need a script to regularly check this value and reset it to 1700 if it did change.

I would be grateful if someone has such a similar script that i could use as a template.

7.14 RC2 does not seem to solve the problem. After upgrading from 7.14RC1 to 7.14RC2, the MTU was again at 1500.

Hi, what is the bridge interface's MTU (not L2MTU)? And what MTU values have bridge members? If any VLAN member (e.g., a bridge port with the respective pvid value) has a lower MTU (like 1500), the entire bridge resets MTU to the lowest value.

Bridges operate on Layer 2, where packet fragmentation is not possible. In other words, a bridge cannot forward a 1700-byte packet to an MTU=1500 port. Hence, the bridge selects the lowest MTU of the bridged interfaces (ports).

Please share your "/interface print" and "/interface export" output for further analysis.

The bridge interface MTU is 1700 (L2MTU 1704). Bridge ports members have a 1500 MTU except for the WAN SFP interface that have a 1704 MTU (1704 L2MTU).

Then i have VLANs interfaces on the Bridge interface, for WAN and LANs. They all have a 1500 MTU (1700 L2MTU), except for the WAN VLAN that have a 1700 MTU (1700 L2MTU). The WAN port is the SFP physical interface.

The MTU values are accepted without problems at setup. But the VLAN WAN interface, after setting it to MTU = 1700, reset silently to MTU = 1500 probably a few hours later, difficult to say when exactly because there is no error report. It could be reset when changing routes or firewall rules.

I need a 1700 MTU on the WAN VLAN because it is my provider setup for an IPIPv6 tunnel. When the MTU reset to 1500 silently on this interface, i loose connectivity. Then i put it back to 1700 again, and it is ok but only for a few hours.

Something seems wrong in the code, i do not think that it is a setup problem. If it where a setup problem, i think that the MTU value would be rejected during setup, not silently after a random time.

I'll need to create a report if you need it.

massinia · Thu Feb 22, 2024 12:33 pm

It works fine for me.
Thanks to your help I found the cause!

Doesn't work when the share name is uppercase:
Test - KO
test - OK

Reported with SUP-143577

With rc2 if the folder begins with a capital letter there is a double SMB share with the same name: one with a capital initial and one with a lowercase initial.

Thu Feb 22, 2024 12:41 pm

... for now the version is removed from the upgrade server and a downgrade to 04 is recommended.
Thank you for the feedback but how is a normal user supposed to do this downgrade ? It's only possible via support, I believe ?

As eworm already pointed out, you can just issue the same upgrade command which will now downgrade it back to 04, as 04 is now the "latest version".
[admin@MikroTik] > interface/lte/firmware-upgrade lte1
installed: 16121.1034.00.01.01.05
latest: 16121.1034.00.01.01.04

/interface/lte/firmware-upgrade lte1 upgrade=yes

CTassisF · Thu Feb 22, 2024 1:53 pm

I'm also having problems with USB stick disappearing on RB5009.

I use the USB stick as storage for my containers, and after 3~4 days of uptime the usb1-part1 disk disappears from /file and garbage is shown in /disk.

The weird part is that all containers continue to work, but after a while this seems to corrupt data in the USB stick.

I thought this problem was related to my USB stick, so I didn't report the problem before. I will wait until it happens again and then open a ticket with support.

It happened again. SUP-144626

rysiekg · Thu Feb 22, 2024 1:56 pm

We use CRS326-24S+2Q+ as Boundary Clock with smpte profile
When IGMP Snooping is disabled PTP works almost fine (but we cant use it that way because video mcast kills CPU of the CRS326 and floods ports - even though it was just smpte2110-20 720-50p and our scenario base on high bandwidth mcast 4K-60p, unicast is working fully fine but its not right way for normal multimedia scenarios).

When we are using IGMP Snooping and PTPv2 (SMPTE2110 use case) PTP Delay Resp never emitted by the CRS326

       	PTP GM
       	|
       CRS326 (BoundaryClock)
       	|		|
       Receiver1	Receiver2

When I check tcpdump/wireshark - I do see PTP Delay Req being sent (tcpdump on Receiver1 and Receiver2 sees both - own and the second receiver PTP Delay Req).
When I check with PacketSniffer streaming from used iface port by Receiver1/2 I do not see also PTP Delay Req

Both Receiver1/2 we see as registered in ptp mcast goups in CRS326 (and both are getting PTP Announce, Followup, Sync)

Is it known limitation/issue or its our config issue, do you have any advice?

Thank you in advance

Miracles · Thu Feb 22, 2024 2:07 pm

Upgraded from 7.13 stable to 7.14RC4, started having kernel panics. Downgraded to 7.13.5 stable and still having the kernel panics (full system reboot, log not displaying anything except for that a power supply interruption might've happened). RB5009UPr.

Paternot · Thu Feb 22, 2024 3:20 pm

Thank you for the feedback but how is a normal user supposed to do this downgrade ? It's only possible via support, I believe ?

Why would a normal user run an RC version?
One can always download the package for the older version, put it on the router and reboot. It should work.

donkeyKong · Thu Feb 22, 2024 3:24 pm

Using CAKE queues (as an Interface Queue or Queue Trees) on a CCR2004-16G-2S-PC results in a router crash when saturating a link.

Ticket SUP-139556

BillyVan · Thu Feb 22, 2024 3:25 pm

He talking about modem firmware version and not for ros version

Thu Feb 22, 2024 4:10 pm

Thank you for the feedback but how is a normal user supposed to do this downgrade ? It's only possible via support, I believe ?
Why would a normal user run an RC version?
One can always download the package for the older version, put it on the router and reboot. It should work.

Again ...
this comment was about Fibocom LTE FW version 05 used on Ax Lite LTE.
Normally a user CAN NOT downgrade such a FW (or for any LTE FW version).
But because now they have removed 05 from their servers, you can.

fl4co · Thu Feb 22, 2024 4:18 pm

Upgraded from 7.13 stable to 7.14RC4, started having kernel panics. Downgraded to 7.13.5 stable and still having the kernel panics (full system reboot, log not displaying anything except for that a power supply interruption might've happened). RB5009UPr.

Are you using a USB drive?

Thu Feb 22, 2024 4:37 pm

Hi, what is the bridge interface's MTU (not L2MTU)? And what MTU values have bridge members? If any VLAN member (e.g., a bridge port with the respective pvid value) has a lower MTU (like 1500), the entire bridge resets MTU to the lowest value.

Bridges operate on Layer 2, where packet fragmentation is not possible. In other words, a bridge cannot forward a 1700-byte packet to an MTU=1500 port. Hence, the bridge selects the lowest MTU of the bridged interfaces (ports).

Please share your "/interface print" and "/interface export" output for further analysis.
The bridge interface MTU is 1700 (L2MTU 1704). Bridge ports members have a 1500 MTU except for the WAN SFP interface that have a 1704 MTU (1704 L2MTU).

Then i have VLANs interfaces on the Bridge interface, for WAN and LANs. They all have a 1500 MTU (1700 L2MTU), except for the WAN VLAN that have a 1700 MTU (1700 L2MTU). The WAN port is the SFP physical interface.

The MTU values are accepted without problems at setup. But the VLAN WAN interface, after setting it to MTU = 1700, reset silently to MTU = 1500 probably a few hours later, difficult to say when exactly because there is no error report. It could be reset when changing routes or firewall rules.

I need a 1700 MTU on the WAN VLAN because it is my provider setup for an IPIPv6 tunnel. When the MTU reset to 1500 silently on this interface, i loose connectivity. Then i put it back to 1700 again, and it is ok but only for a few hours.

Something seems wrong in the code, i do not think that it is a setup problem. If it where a setup problem, i think that the MTU value would be rejected during setup, not silently after a random time.

I'll need to create a report if you need it.

Create a report, please, and we will try to reproduce it on our end.

Why do you need to put the WAN interface under the bridge in the first place? You can create a VLAN interface directly on top of an SFP port.

Amm0 · Thu Feb 22, 2024 5:33 pm

Why do you need to put the WAN interface under the bridge in the first place?

Well now that's more a philosophical question... The illusion of order?

blacksnow · Thu Feb 22, 2024 5:51 pm

Why do you need to put the WAN interface under the bridge in the first place? You can create a VLAN interface directly on top of an SFP port.

Isn't it recommended by Mikrotik documentation in the L3HW docs and the basic VLAN docs to not place a VLAN directly on top of a physical interface? That the new/improved/recommended method is to always use the bridge? Obviously this is the only way to take advantage of L3HW inter-vlan routing and some other features but I thought in general for v7 it was discouraged to do it the other way.

mkx · Thu Feb 22, 2024 6:43 pm

Isn't it recommended by Mikrotik documentation in the L3HW docs and the basic VLAN docs to not place a VLAN directly on top of a physical interface?

It is. But that's only true for devices supporting L3HW (which RB5009 doesn't). Which in turn only works for "plain" VLANs ... but we're discussing IPIPv6 tunnel, which is exclusively CPU-bound.

Alas, I agree that it should be possible to have different MTUs on different VLANs (L2MTU permitting). I'm not sure if this is possible for linux bridge though.

blacksnow · Thu Feb 22, 2024 6:57 pm

It is possible, just keep in mind you have to set all underlying connected physical interfaces that are plugged into the bridge to the highest minimum MTU you want. For example, I set all my physical interfaces at 9000 MTU and then on the VLANs themselves I set individual requirements, but all VLAN MTUs have to be less than 9000 obviously. TLDR, the bridge takes the lowest attached physical interface MTU as the maximum.

Thu Feb 22, 2024 7:18 pm

Isn't it recommended by Mikrotik documentation in the L3HW docs and the basic VLAN docs to not place a VLAN directly on top of a physical interface?

Only if that physical interface is a bridge port.

sirbryan · Thu Feb 22, 2024 7:50 pm

Something seems wrong in the code, i do not think that it is a setup problem. If it where a setup problem, i think that the MTU value would be rejected during setup, not silently after a random time.

I've seen this on a number of releases over the past year or so, but in my case it can take weeks or months to happen.

DarkNate · Fri Feb 23, 2024 9:42 am

Isn't it recommended by Mikrotik documentation in the L3HW docs and the basic VLAN docs to not place a VLAN directly on top of a physical interface? That the new/improved/recommended method is to always use the bridge? Obviously this is the only way to take advantage of L3HW inter-vlan routing and some other features but I thought in general for v7 it was discouraged to do it the other way.

IP WAN ports (like eBGP Transit, IXP port, PNI port, residential broadband DHCP, PPPoE etc) are meant to be independent PHY ports outside any bridge, if they need VLAN tagging on egress, you directly create layer 3 sub-interface VLAN on top of the port.

The bridge is for LAN-facing and intra-as facing ports with the usual single VLAN-aware aware Linux bridge principle.

bratislav · Fri Feb 23, 2024 12:42 pm

Upgraded from 7.13 stable to 7.14RC4, started having kernel panics. Downgraded to 7.13.5 stable and still having the kernel panics (full system reboot, log not displaying anything except for that a power supply interruption might've happened). RB5009UPr.

Are you sure that it isn't actually a power supply issue?
Maybe try a different one...

Miracles · Fri Feb 23, 2024 1:07 pm

Upgraded from 7.13 stable to 7.14RC4, started having kernel panics. Downgraded to 7.13.5 stable and still having the kernel panics (full system reboot, log not displaying anything except for that a power supply interruption might've happened). RB5009UPr.
Are you using a USB drive?

I removed it after I saw comments explaining USB stick might've caused all the trouble, but the issue persisted. Solved it by downgrading to 7.13.5 AND(!) removing `wireless`, `rose` and `container` images.

Miracles · Fri Feb 23, 2024 1:09 pm

Upgraded from 7.13 stable to 7.14RC4, started having kernel panics. Downgraded to 7.13.5 stable and still having the kernel panics (full system reboot, log not displaying anything except for that a power supply interruption might've happened). RB5009UPr.
Are you sure that it isn't actually a power supply issue?
Maybe try a different one...

Most definitely was not a power supply issue. I monitor the draw of the devices connected to my UPS.
I solved the problem by downgrading to 7.13.5 AND removing `wireless`, `rose` and `container` packages.

FIPTech · Fri Feb 23, 2024 1:41 pm

The bridge interface MTU is 1700 (L2MTU 1704). Bridge ports members have a 1500 MTU except for the WAN SFP interface that have a 1704 MTU (1704 L2MTU).

Then i have VLANs interfaces on the Bridge interface, for WAN and LANs. They all have a 1500 MTU (1700 L2MTU), except for the WAN VLAN that have a 1700 MTU (1700 L2MTU). The WAN port is the SFP physical interface.

The MTU values are accepted without problems at setup. But the VLAN WAN interface, after setting it to MTU = 1700, reset silently to MTU = 1500 probably a few hours later, difficult to say when exactly because there is no error report. It could be reset when changing routes or firewall rules.

I need a 1700 MTU on the WAN VLAN because it is my provider setup for an IPIPv6 tunnel. When the MTU reset to 1500 silently on this interface, i loose connectivity. Then i put it back to 1700 again, and it is ok but only for a few hours.

Something seems wrong in the code, i do not think that it is a setup problem. If it where a setup problem, i think that the MTU value would be rejected during setup, not silently after a random time.

I'll need to create a report if you need it.

Create a report, please, and we will try to reproduce it on our end.

Why do you need to put the WAN interface under the bridge in the first place? You can create a VLAN interface directly on top of an SFP port.

Ok i've found when the MTU reset occur : it is occurring simply after a router reboot.

In the meantime i'm going to use a start script to set it at 1700 after router reboot :

delay 15
/interface vlan set VLAN-WAN-DATA mtu=1600
delay 4
/interface vlan set VLAN-WAN-DATA mtu=1700

Strangely i need both lines and those long delays. I cannot set the MTU directly to 1700.

I'll try to find the time to make a report. Let me know if you find the cause. Perhaps you'll find it quite easily with this indication.

Why do you need to put the WAN interface under the bridge in the first place? You can create a VLAN interface directly on top of an SFP port.

I need to put the WAN SFP in the bridge because i need to bridge a VLAN from the provider in a LAN side VLAN (without routing here, direct bridging). There is no VLAN interface on the bridge for this WAN VLAN, it is just a VLAN L2 bridging from a WAN VLAN to a LAN VLAN that is located inside a trunk port (a bridge port too) that goes to a managed switch for LAN VLAN distribution.

Another point : putting the WAN interface in the main bridge is simpler and do allow to bridge some VLANs between WAN and LAN side with L2 hardware acceleration or even L3 acceleration for some high end Mirkotik routers.

This is the setup when you want to replace a provider triple play box by a router, but put back the box behind the router for TV and telephony services that are difficult to manage without the box. You need to bridge the triple play VLANs to the box.

blacksnow · Fri Feb 23, 2024 2:18 pm

Isn't it recommended by Mikrotik documentation in the L3HW docs and the basic VLAN docs to not place a VLAN directly on top of a physical interface? That the new/improved/recommended method is to always use the bridge? Obviously this is the only way to take advantage of L3HW inter-vlan routing and some other features but I thought in general for v7 it was discouraged to do it the other way.
IP WAN ports (like eBGP Transit, IXP port, PNI port, residential broadband DHCP, PPPoE etc) are meant to be independent PHY ports outside any bridge, if they need VLAN tagging on egress, you directly create layer 3 sub-interface VLAN on top of the port.

The bridge is for LAN-facing and intra-as facing ports with the usual single VLAN-aware aware Linux bridge principle.

I don't think this is 100% correct. WAN is a network just like any other, there isn't anything special about it except for understanding how NAT comes into play on either side of the imaginary boundary. When you look at it from an ipv6 perspective it becomes even clearer, there is no difference they are just two seperate networks and you may or may not want certain traffic going between the networks. With regards to the bridge, if you want to offload any traffic to the switch chip or make use of the l3hw capabilities while having things like VLAN, Bonding etc then you need to put everything into a single bridge (which includes the WAN port). Now we can say that not everything can be offloaded and in those cases there won't be any performance benefit of putting it in the bridge. But it is incorrect to say that WAN ports should not be on the bridge. Basically my point is, yes there are some situations where you cannot offload the traffic so it doesn't matter what approach you choose, but if you want to have a simple configuration then you can put everything on the bridge and it will work just as well.

DarkNate · Fri Feb 23, 2024 3:15 pm

I don't think this is 100% correct. WAN is a network just like any other, there isn't anything special about it except for understanding how NAT comes into play on either side of the imaginary boundary. When you look at it from an ipv6 perspective it becomes even clearer, there is no difference they are just two seperate networks and you may or may not want certain traffic going between the networks. With regards to the bridge, if you want to offload any traffic to the switch chip or make use of the l3hw capabilities while having things like VLAN, Bonding etc. Now we can say that not everything can be offloaded and in those cases there won't be any performance benefit of putting it in the bridge. But it is incorrect to say that WAN ports should not be on the bridge. Basically my point is, yes there are some situations where you cannot offload the traffic so it doesn't matter what approach you choose, but if you want to have a simple configuration then you can put everything on the bridge and it will work just as well.

I've only seen this weird bridge problem only on MikroTik to begin with.

See this thread for details:
viewtopic.php?t=204023

sirbryan · Fri Feb 23, 2024 3:24 pm

IP WAN ports (like eBGP Transit, IXP port, PNI port, residential broadband DHCP, PPPoE etc) are meant to be independent PHY ports outside any bridge, if they need VLAN tagging on egress, you directly create layer 3 sub-interface VLAN on top of the port.

This has been discussed ad nauseam. In all of the current documentation regarding bridges and switch chips for recent software versions, MikroTik emphasizes the requirement for a single bridge with all VLANs in it in order for any of the device's hardware offloading to work properly. Otherwise it's punted to the CPU, or worse yet, causes unsupported/undefined behavior.

What you suggest works fine for older v6 versions, in v7 for routers without offload capabilities, such as the CCR1000 series, and may be best practices for other hardware vendors. But for L2/L3HW-offload to work properly/most efficiently in v7, especially on Marvell chips, there is to be but one bridge.

FIPTech · Fri Feb 23, 2024 3:38 pm

IP WAN ports (like eBGP Transit, IXP port, PNI port, residential broadband DHCP, PPPoE etc) are meant to be independent PHY ports outside any bridge, if they need VLAN tagging on egress, you directly create layer 3 sub-interface VLAN on top of the port.

This has been discussed ad nauseam. In all of the current documentation regarding bridges and switch chips for recent software versions, MikroTik emphasizes the requirement for a single bridge with all VLANs in it in order for any of the device's hardware offloading to work properly. Otherwise it's punted to the CPU, or worse yet, causes unsupported/undefined behavior.

What you suggest works fine for older v6 versions, in v7 for routers without offload capabilities, such as the CCR1000 series, and may be best practices for other hardware vendors. But for L2/L3HW-offload to work properly/most efficiently in v7, especially on Marvell chips, there is to be but one bridge.

Yes, if not VLAN aware bridges would not have been implemented in a first place.

This is the tendency, if you watch at the RB5009 design, a high end Soho router, even here the SFP port (generally used for the WAN side) is part of the hardware chip for offloading. If you do not put the SFP inside the main bridge, then there is no L2 hardware offloading and the setup become more complex, you'll eventually need another old-style bridge with VLAN interfaces inside it if you need to bridge some VLANs between WAN and LAN. This is not the recommended setup specially with RouterOS 7.

DarkNate · Fri Feb 23, 2024 3:46 pm

This has been discussed ad nauseam. In all of the current documentation regarding bridges and switch chips for recent software versions, MikroTik emphasizes the requirement for a single bridge with all VLANs in it in order for any of the device's hardware offloading to work properly. Otherwise it's punted to the CPU, or worse yet, causes unsupported/undefined behavior.

What you suggest works fine for older v6 versions, in v7 for routers without offload capabilities, such as the CCR1000 series, and may be best practices for other hardware vendors. But for L2/L3HW-offload to work properly/most efficiently in v7, especially on Marvell chips, there is to be but one bridge.

You're preaching to the choir. I'm one of the users on this forum who pushes for SINGLE bridge config all the god-damn time.

FIPTech · Fri Feb 23, 2024 3:55 pm

I've only seen this weird bridge problem only on MikroTik to begin with.

See this thread for details:
viewtopic.php?t=204023

If you like Mikrotik prices, but would like an even better price / performance ratio, then use your experience, advanced knowledge, speed and smartness to make some detailed reports to help to speed up the corrections. :)

dzievamarcos · Fri Feb 23, 2024 9:04 pm

Could anyone help me with IS-IS in 7.14rc?
I'm doing some laboratory tests, but it seems to me that not all parameters are behaving as they should, metric, filter, have no effect on my tests.
Is the IS-IS incomplete?

merkkg · Sat Feb 24, 2024 1:01 pm

Hello folks,

If I use the rest API extensively for getting stats etc, the user list gets spammed with active users.
Please fix this or what am I doing wrong?

Greetings

/user/active/print
36 2024-02-15 13:48:28 api 10.10.0.5 (unknown)
37 2024-02-15 13:58:30 api 10.10.0.5 (unknown)
38 2024-02-15 14:08:31 api 10.10.0.5 (unknown)
40 2024-02-15 14:28:32 api 10.10.0.5 (unknown)
41 2024-02-15 14:38:33 api 10.10.0.5 (unknown)
42 2024-02-15 14:48:34 api 10.10.0.5 (unknown)
43 2024-02-15 14:58:36 api 10.10.0.5 (unknown)
44 2024-02-15 15:08:36 api 10.10.0.5 (unknown)
45 2024-02-15 15:18:37 api 10.10.0.5 (unknown)
46 2024-02-15 15:28:38 api 10.10.0.5 (unknown)
47 2024-02-15 15:38:39 api 10.10.0.5 (unknown)
48 2024-02-15 15:48:39 api 10.10.0.5 (unknown)
49 2024-02-15 15:58:40 api 10.10.0.5 (unknown)
50 2024-02-15 16:08:40 api 10.10.0.5 (unknown)
51 2024-02-15 16:18:41 api 10.10.0.5 (unknown)
52 2024-02-16 08:01:50 api 10.10.0.5 (unknown)
53 2024-02-16 08:11:50 api 10.10.0.5 (unknown)
58 2024-02-16 08:21:54 api 10.10.0.5 (unknown)
59 2024-02-16 08:21:54 api api

Has this been fixed yet, seems still open on my system? seems no one commenting on it

bajodel · Sat Feb 24, 2024 1:36 pm

..[CUT] .. Is the IS-IS incomplete?

in the routing protocol status page it says "Initial support" - see https://help.mikrotik.com/docs/display/ ... l+Overview
It's now more than that, but probably still incomplete.

FIPTech · Sat Feb 24, 2024 2:16 pm

Is there a correction for LLDP-MED ? In the beta it was missing Ieee 802.3 - MAC/PHY Configuration/Status.

Without this option, LLDP-MED does not work, it is rejected by phones. The LLDP-MED standard (ansi-tia-1057) is asking for a mandatory MAC/PHY Configuration/Status TLV.

The consequence is that the phones Ethernet interfaces do not switch to the right tagged VLAN. It stays on untagged traffic.

9.2.2 IEEE 802.3 MAC/PHY Configuration/Status TLV
IEEE 802.1AB-2005 [1] Annex G.2, defines the MAC/PHY configuration/status TLV that identifies:
a) The duplex and bit-rate capability of the sending 802.3 LAN node;
b) The current duplex and bit-rate settings of the sending 802.3 LAN node;
c) Whether theses settings are the result of auto-negotiation during the initialization of the link, or
of manual set override actions.
All LLDP-MED Devices shall include this TLV in outgoing LLDP-MED LLDPDUs.

lldp-med-mac-phy.png

Here is a Mikrotik LLDPDU announcement (missing MAC/PHY TLV) :

Link Layer Discovery Protocol
Chassis Subtype = MAC address, Id: 70:fc:8f:xx:xx:xx
Port Subtype = Interface name, Id: Bridge-LANs/ether5
Time To Live = 120 sec
System Name = MikroTik
System Description = MikroTik RouterOS 7.14beta7 (development) 2024-01-15 09:37:08 RB5009UPr+S+
Management Address
0001 000. .... .... = TLV Type: Management Address (8)
.... ...0 0000 1100 = TLV Length: 12
Address String Length: 5
Address Subtype: IPv4 (1)
Management Address: 192.168.88.1
Interface Subtype: ifIndex (2)
Interface Number: 5
OID String Length: 0
Management Address
0001 000. .... .... = TLV Type: Management Address (8)
.... ...0 0001 1000 = TLV Length: 24
Address String Length: 17
Address Subtype: IPv6 (2)
Management Address: fe80::7a9a:18ff:xxxx:xxxx
Interface Subtype: ifIndex (2)
Interface Number: 5
OID String Length: 0
Capabilities
Telecommunications Industry Association TR-41 Committee - Media Capabilities
Telecommunications Industry Association TR-41 Committee - Network Policy
1111 111. .... .... = TLV Type: Organization Specific (127)
.... ...0 0000 1000 = TLV Length: 8
Organization Unique Code: 00:12:bb (Telecommunications In
Media Subtype: Network Policy (0x02)
Application Type: Voice (1)
0... .... .... .... .... .... = Policy: Defined
.1.. .... .... .... .... .... = Tagged: Yes
...1 1111 0100 000. .... .... = VLAN Id: 4000
.... .... .... ...0 00.. .... = L2 Priority: 0
.... .... .... .... ..00 0000 = DSCP Priority: 0
End of LLDPDU

Here is an example of the missing TLV (from a Procurve switch announcement, packet capture) :

Ieee 802.3 - MAC/PHY Configuration/Status
Telecommunications Industry Association TR-41 Committee - Media Capabilities
Telecommunications Industry Association TR-41 Committee - Network Policy
1111 111. .... .... = TLV Type: Organization Specific (127)
.... ...0 0000 1000 = TLV Length: 8
Organization Unique Code: 00:12:bb (Telecommunications In
Media Subtype: Network Policy (0x02)
Application Type: Voice (1)
0... .... .... .... .... .... = Policy: Defined
.1.. .... .... .... .... .... = Tagged: Yes
...1 1111 0100 000. .... .... = VLAN Id: 500
.... .... .... ...1 10.. .... = L2 Priority: 6
.... .... .... .... ..10 1110 = DSCP Priority: 46

Injecting correct packets every 2 seconds solve the problem, for example :

/tool/traffic-generator/inject-pcap pcap-file=lldp-ros-lin-and-dscp-and-phy2.pcap interface=ether3 once       
/tool/traffic-generator/inject-pcap pcap-file=lldp-ros-lin-and-dscp-and-phy2.pcap interface=ether4 once       
/tool/traffic-generator/inject-pcap pcap-file=lldp-ros-lin-and-dscp-and-phy2.pcap interface=ether5 once

Sun Feb 25, 2024 1:11 am

As usual, there's new configuration flotsam in this release. Removal methods for the ones affecting this release begin here, but I'm stuck on one:

/interface sstp-server server set ciphers=aes256-sha

That can take only one other value, but setting it to aes256-gcm-sha384 doesn't make the line go away. I don't use SSTP here, so there is no value in having this in my configuration backups.

Any ideas for how to squish this noise?

eworm · Sun Feb 25, 2024 11:05 am

I think you have to set both, with comma in between.

Sun Feb 25, 2024 6:46 pm

I think you have to set both, with comma in between.

Indeed; thank you! I've updated the article.

Reinis · Mon Feb 26, 2024 6:38 am

Is there a correction for LLDP-MED ? In the beta it was missing Ieee 802.3 - MAC/PHY Configuration/Status.

Next beta (7.15) will have support for it

dzievamarcos · Tue Feb 27, 2024 4:50 am

Is there a correction for LLDP-MED ? In the beta it was missing Ieee 802.3 - MAC/PHY Configuration/Status.
Next beta (7.15) will have support for it

Hey Reinis,
What can you tell me about IS-IS?
Is it already finished?

Jotne · Tue Feb 27, 2024 7:36 am

Is it already finished?

Finished??? 7.15 beta is not even released. It may be in alpha.

Tue Feb 27, 2024 9:13 am

7.15 beta what? IS-IS is already in v7.14

Tue Feb 27, 2024 2:12 pm

WAN under the Bridge (or not)
The debate about putting a WAN interface under the VLAN-filtered bridge or leaving it standalone is getting hot, so let's clarify the subject.

Technically, RouterOS v7 allows putting a WAN interface under the VLAN-filtered bridge in any case (into a separate VLAN, of course).
However, it complicates the user config and CPU processing. In other words, it will be harder for humans to understand such a configuration, and it will take slightly longer for the device CPU to walk through the device tree to find an egress port for a packet. While it is not a big deal (we're talking about a few extra nanoseconds), you can still avoid it unless hardware requirements force you.
Speaking about hardware requirements, the famous one is L3HW. Hardware routing requires hardware bridge for VLAN tagging, so the only way apply L3HW on a VLAN-tagged WAN interface is putting it under the bridge. Still, it applies to L3HW-capable devices only (CRS3xx, CRS5xx, and CCR2x16) and only if the WAN interface requires VLAN-tagging (or bridging multiple WAN interfaces). For instance, if CCR2216 has a standalone untagged WAN interface, you can keep it outside the bridge.
None of RB* devices support L3HW. Hence, you can keep the WAN interface outside the bridge even if it requires VLAN tagging. You may put an /interface/vlan straightly on top of the WAN port.
UPDATE: If a WAN port requires some bridge features (e.g., bridge firewall, VLAN traffic filtering, etc.), then, of course, you need a bridge.

VLAN MTU Issue
We have reproduced multiple issues regarding VLAN MTU not applying correctly or resetting to default after reboot. Unfortunately, it is too late to incorporate the fixes into 7.14, so those will be available in the upcoming 7.15beta.

Thanks for the feedback!

nonolk · Tue Feb 27, 2024 2:46 pm

@raimondsp, there is also I think the case where you need bridge filter rules, for instance my provider Orange in France require to set the COS to 6 for DHCP request, therefore I need to use a bridge port to set it on my rb5009 as the new-vlan-priority is not supported on this device as a switch rule.

Tue Feb 27, 2024 2:51 pm

@raimondsp, there is also I think the case where you need bridge filter rules, for instance my provider Orange in France require to set the COS to 6 for DHCP request, therefore I need to use a bridge port to set it on my rb5009 as the new-vlan-priority is not supported on this device as a switch rule.

Good point! If you need a bridge firewall, then, of course, you need a bridge in the first place.

Tue Feb 27, 2024 4:07 pm

What's new in 7.14rc3 (2024-Feb-27 10:06):

*) lte - improved FG621-EA modem firmware upgrade;
*) ovpn - limit the maximum length for "push-routes" up to 1400 characters;
*) sstp - added support for "aes256-gcm-sha384" encryption;

blacksnow · Tue Feb 27, 2024 4:22 pm

Technically, RouterOS v7 allows putting a WAN interface under the VLAN-filtered bridge in any case (into a separate VLAN, of course).

However, it complicates the user config and CPU processing. In other words, it will be harder for humans to understand such a configuration, and it will take slightly longer for the device CPU to walk through the device tree to find an egress port for a packet. While it is not a big deal (we're talking about a few extra microseconds per packet), you can still avoid it unless hardware requirements force you.

Speaking about hardware requirements, the famous one is L3HW. Hardware routing requires hardware bridge for VLAN tagging, so the only way apply L3HW on a VLAN-tagged WAN interface is putting it under the bridge. Still, it applies to L3HW-capable devices only (CRS3xx, CRS5xx, and CCR2x16) and only if the WAN interface requires VLAN-tagging (or bridging multiple WAN interfaces). For instance, if CCR2216 has a standalone untagged WAN interface, you can keep it outside the bridge (and win a few nanoseconds of hardware-processing time per packet).

So with a WAN that requires VLAN that is in the bridge, once the NAT rule is in the switch chip how much additional latency are we talking about? Is the latency cost just for the first couple of packets for a new connection or is it on all packets? Are you essentially saying that L3HW regardless of implementation adds an additional X of latency? If so is X microseconds or nanoseconds? Also when you mention it complicates the user config doesn't that apply to any network that is connected with a VLAN into the bridge? I mean there is nothing special about a WAN network it's just another network. If I have 10 VLAN networks plugged into a trunk port (sfp1) and attached to the bridge does that mean all of those are suffering additional latency rather than if they were all individual physical ports like (sfp1-sfp10) each with an individual vlan directly on the interface?

FIPTech · Tue Feb 27, 2024 4:44 pm

@raimondsp, there is also I think the case where you need bridge filter rules, for instance my provider Orange in France require to set the COS to 6 for DHCP request, therefore I need to use a bridge port to set it on my rb5009 as the new-vlan-priority is not supported on this device as a switch rule.

yes, has been said by raimondsp.

Another use case is when you need to route some WAN vlans, and bridge other ones. Typically to replace a triple play provider box by a custom router setup. The RB5009 is perfect for that and do allow to keep the full provider speeed, around 900 mbps, regardless the IPIPv6 tunnel that is almost saturating a processor core for IPv4. I did it successfully for the Free french provider. With previous RB routers, it was not possible to get this speed. In this regard Orange is probably faster, because they deliver a dual stack traffic if i'm right, no need for a costly IPIPv6 tunnel for IPv4. The advantage of Free is that you can have two IPIPv6 tunnels, and get two IPv4 WAN addresses (a full stack and a 1/4 shared one), quite interesting for some experimentation.

Tue Feb 27, 2024 5:41 pm

So with a WAN that requires VLAN that is in the bridge, once the NAT rule is in the switch chip how much additional latency are we talking about? Is the latency cost just for the first couple of packets for a new connection or is it on all packets? Are you essentially saying that L3HW regardless of implementation adds an additional X of latency? If so is X microseconds or nanoseconds? Also when you mention it complicates the user config doesn't that apply to any network that is connected with a VLAN into the bridge? I mean there is nothing special about a WAN network it's just another network. If I have 10 VLAN networks plugged into a trunk port (sfp1) and attached to the bridge does that mean all of those are suffering additional latency rather than if they were all individual physical ports like (sfp1-sfp10) each with an individual vlan directly on the interface?

Sorry if my post sounded misleading regarding the latency. I edited it for clarification. Once the NAT rule is offloaded to the switch chip, it has no additional latency, regardless of whether the WAN port is under the bridge. The delay may happen only on the CPU while traversing the interface stack: the packet goes from the VLAN interface handler straight to the port handler vs. entering the bridge in between (which, in turn, performs port lookup by VLAN ID). As I mentioned, it is not a big deal as those are just nanoseconds (depending on the CPU) or even less for FastPath.

The question of "A trunk port of 10 VLAN networks" vs. "10 standalone ports" is purely theoretical because connecting two devices with ten cables is impractical. Two devices get connected with multiple lines to ensure redundancy and/or load balancing rather than saving a few CPU cycles on bridge VLAN table lookup.

ivn · Tue Feb 27, 2024 6:42 pm

*) ovpn - improved system stability when using HW encryption on ARM64 devices (introduced in v7.13);

Any chance you will implement HW encryption for SSTP too? Pleeease :)

blacksnow · Tue Feb 27, 2024 7:37 pm

Sorry if my post sounded misleading regarding the latency. I edited it for clarification. Once the NAT rule is offloaded to the switch chip, it has no additional latency, regardless of whether the WAN port is under the bridge. The delay may happen only on the CPU while traversing the interface stack: the packet goes from the VLAN interface handler straight to the port handler vs. entering the bridge in between (which, in turn, performs port lookup by VLAN ID). As I mentioned, it is not a big deal as those are just nanoseconds (depending on the CPU) or even less for FastPath.

The question of "A trunk port of 10 VLAN networks" vs. "10 standalone ports" is purely theoretical because connecting two devices with ten cables is impractical. Two devices get connected with multiple lines to ensure redundancy and/or load balancing rather than saving a few CPU cycles on bridge VLAN table lookup.

I appreciate the clarification, this was my understanding as well but wanted to confirm!

FIPTech · Tue Feb 27, 2024 8:38 pm

Here is a bridge filter NAT problem with Ros7.14RC2, RB5009.

The following setup is a simple layer 2 NAT, to masquerade the MAC address of a client device.
There are two rules for layer 2 src and dest NAT, and two rules to make an ARP fixer. One more rule to filter anything except IPv4 traffic from client.

This is needed because my provider is checking the client MAC address and on some devices it is not possible to change the MAC address.
Layer 3 NAT is not possible because the upper layer 5 protocol is not NAT friendly and there is no NAT helper for this protocol inside RouterOS.

Here is a working setup on a RB450G with Ros 6.38.5. Only two Ethernet interfaces inside a bridge.

# ether4 is client port
# ether5 is provider port

# by RouterOS 6.38.5
# RB450G
#
/interface bridge nat
add action=arp-reply arp-dst-address=15.20.25.254/32 arp-opcode=request \
    chain=dstnat comment="ARP Reply - MAC Provider" in-interface=\
    ether4 mac-protocol=arp to-arp-reply-mac-address=00:05:AA:20:05:32
add action=arp-reply arp-dst-address=15.20.25.55/32 arp-gratuitous=no chain=\
    dstnat comment="ARP Reply - MAC Client" in-interface=ether5 \
    mac-protocol=arp to-arp-reply-mac-address=65:AB:55:99:1F:42
add action=src-nat chain=srcnat comment=\
    "Source NAT Layer 2 - IP traffic from Client" mac-protocol=ip \
    out-interface=ether5 to-src-mac-address=65:AB:55:99:1F:42
add action=dst-nat chain=dstnat comment=\
    "Dest NAT Layer 2 - IP traffic to Client" in-interface=ether5 \
    mac-protocol=ip to-dst-mac-address=15:DC:21:14:B5:81

/interface bridge filter
add action=drop chain=forward comment="Drop not IP from client" in-interface=\
    ether4 mac-protocol=!ip

The same setup on RB5009 with Ros7.14RC2 does not work.

On the RB5009 there are a couple problems : ARP matcher does not work, VLAN matcher does not work (on the RB5009 i use a VLAN aware bridge). Perhaps a couple more problems that will ask for more investigations.

The same setup on a RB3011 with Ros 6.49.13 does not work.

Seems like the new VLAN aware bridge code did introduce a couple problems for matching ARP and VLANs inside the bridge filter NAT chains.

In the meantime, i'm using an external RB450G just to masquerade a client device MAC address.

gze100 · Wed Feb 28, 2024 4:22 am

I use the mikrotik CHR router under xcp-ng 8.2.1 (xenserver) and up to and including version 7.4rc1 it works fine. With the update to 7.14rc2 or 7.14rc3 the ethernet interfaces in the system are no longer recognized. xcp-ng also no longer recognizes a management agent with both releases, previously the management agent 6.6.80-71 was recognized. A rollback via snapshot to 7.14rc1 leads to a functioning system again. The problem is deterministic and reproducible.

pyfgcrl · Wed Feb 28, 2024 7:48 am

802.3ad bonding interfaces created with a pair of MLAG switches according to help pages work fine with two CRS518-16XS-2XQ in MSTP bridge mode, but they don't on CRS326-24S+2Q+ with the same configuration.

On the CRS518-16XS-2XQ MLAG bond, when you look at the remote peer, you see something like

/interface/bonding/monitor-slaves bond-bgp-rr1 
Flags: A - active; P - partner 
 AP port=sfp28-1 key=21 flags="A-GSCD--" partner-sys-id=XX:XX:XX:XX:62:F0 partner-sys-priority=65535 
     partner-key=21 partner-flags="A-GSCD--" 

 AP port=sfp28-2 key=21 flags="A-GSCD--" partner-sys-id=XX:XX:XX:XX:62:F0 partner-sys-priority=65535 
     partner-key=21 partner-flags="A-GSCD--"

where the partner-sys-id advertised from both CRS518 in the MLAG group match up.

If you do the same thing on CRS326-24S+2Q+, sometimes the first unit creates what seems like a completely random system-id (MAC) but when you create both bonding interfaces, add both to bridge, etc on both CRS326-24S+2Q+ units, you then look at the remote peer's monitor-slaves and only one port is active because there are two different partner-sys-ids coming in from each of the CRS326 — sometimes what's been created on the secondary as listed in /interface/bonding/print, but the primary can be an out-of-left-field MAC (not even close to the one listed in its /interface/bonding/print) or sometimes it is. But they don't synchronize/settle on reporting the same ID to the remote peer and so only one port comes up and the actual MLAG LACP bonding therefore isn't working properly.

Anyway, in short, works on the one device (CRS518-16XS-2XQ) and doesn't on the other (CRS326-24S+2Q+) fairly default configuration settings, equal in every way, both with MSTP bridges.

AdHocCZ1 · Wed Feb 28, 2024 3:19 pm

@MKTK_staff

Is there any chance for adding permanently present section in announcements:

"Functions removed or postponed to future betas"
*) none (if it is the case)
or e.g. as was in a past
*) BTH ....

It would be timesaver for some decisions about upgrading when testing new versions...

Wed Feb 28, 2024 5:05 pm

What's new in 7.14rc4 (2024-Feb-28 13:38):

*) route - use correct routing table for addresses on VRF interface (introduced in v7.14beta3);
*) smb - fixed export with default configuration (introduced in v7.14beta7);

gigabyte091 · Wed Feb 28, 2024 7:08 pm

Seems that 7.14 stable is near...

S8T8 · Wed Feb 28, 2024 9:45 pm

It would be nice to know what's new in 7.14rc4 from 7.13.5, any chance to know it before the stable release?
Thanks

gabacho4 · Wed Feb 28, 2024 10:01 pm

Yes, read the initial posting announcing the beta and they tell you everything that is new since 7.13 as well as improvements made with each revision.

S8T8 · Wed Feb 28, 2024 10:09 pm

since 7.13 not 7.13.5

gabacho4 · Wed Feb 28, 2024 10:16 pm

Go back up to the very top and read the section clearly labeled "Other changes since v7.13"

Edit. Then aggregate all the 7.14 RC changes and there is your list.

jbl42 · Wed Feb 28, 2024 10:41 pm

But many change descriptions are pretty useless: "Improve something with something"
No description of the actual problem solved, no description of potential impact on existing configs, backward compatibility, no updates of related documentation etc.
We need more details to assess for our setups if the issue at hand is worth to risk an upgrade or if we can wait until other users have tested it.

gabacho4 · Wed Feb 28, 2024 11:18 pm

1. You shouldn't be running RC or beta in production else you assume the risk.

2. Rushing to upgrade latest stable on day 1 of release is equally as insane.

Mikrotik cannot possibly tailor their release notes to every set up and configuration. So they hit high points and it is on the responsibile network admin or home enthusiast to consider and test on their configuration.

oeyre · Wed Feb 28, 2024 11:51 pm

Mikrotik cannot possibly tailor their release notes to every set up and configuration. So they hit high points and it is on the responsibile network admin or home enthusiast to consider and test on their configuration.

That is why we see so many responsible admins asking questions for elaboration on these terse and often cryptic release notes, is it not? Or sharing their experience on the new software so that other responsible admins can discuss and share knowledge?

jbl42 · Thu Feb 29, 2024 12:29 am

I'm not sure what's meant with "tailor".
It's just about the usual release notes. Something like limitations, resolved issues, known issues, precautions (for ex a warning for configs with non default bridge port MTU in 7.14 to wait for 7.15).
With issues having unique IDs so they can be tracked among versions and can be referenced in communication with support and also here.

Nowadays, this is usually mostly auto generated from the SW release/bug/feature tracking and planning system. Gittea, JIRA, TFS, private github or whatever MT is using.

oeyre · Thu Feb 29, 2024 3:42 am

Nowadays, this is usually mostly auto generated from the SW release/bug/feature tracking and planning system. Gittea, JIRA, TFS, private github or whatever MT is using.

Yes, hopefully EdPa isn't typing these out every time with his(?) poor little fingers.

Obviously they have JIRA for individual user support, and you wouldn't want all of that exposed to the internet, but is there some kind of middleware or feature already in JIRA that could act as a public bug tracker where more detail than just 1 line could be placed?

Thu Feb 29, 2024 7:42 am

It is impossible to provide precise release notes for everyone's needs. As we have described in many topics before - we do write in release notes what did we fix, not how the problem might have appeared for the user. We do write what was changed under the hood, not on "user experience".

In most cases, "improved stability" means that some service (or router itself) will not crash under specific circumstances or simply some code was re-written to be more "faster/better/modern/etc.".

From our point of view, changelog should tell you either you should or should not upgrade. So, if you do not have any problems at all, there is no need for an upgrade, if there are no new features or security fixes for your needs. If you have, for example, issues with OVPN and you see changes in changelog about OVPN or PPP generic service, then you should try the upgrade.

However, of course, non-stable versions should be used only if you are willing to risk that you might experience some issues due to new features introduced since testing releases are indeed - "testing releases".

melectronics · Thu Feb 29, 2024 9:33 am

Hello to the community,

I´ve updated some of my Lab MPLS BGP-free core routers to v7.14rc1 and now rc4. Because in v7.14rc1 or maybe before that were introduced route-leaking between local VRFs -> The route leaking itself works but in this version v7.14rc1 the connected routes of interfaces in a VRF don´t install in the routing table of the VRF. Now in v7.14rc4 there stands something of "route - use correct routing table for addresses on VRF interfaces (introduced in v7.14beta3)" in the release notes. So I think I update to rc4 and then it will work. But it still doesn´t work.
Can someone of you help me with that and can explain me why advertised fixes aren´t there?

infabo · Thu Feb 29, 2024 9:38 am

VLAN MTU Issue
We have reproduced multiple issues regarding VLAN MTU not applying correctly or resetting to default after reboot. Unfortunately, it is too late to incorporate the fixes into 7.14, so those will be available in the upcoming 7.15beta.

Is this an issue introduced in 7.14? I see heavy discussion in this thread but no mention in 7.13 topic.

melectronics · Thu Feb 29, 2024 9:39 am

And something more: I don´t found in any release notes the introduction of a default loopback interface on the mikrotiks? In which version that came in ROS?

Thu Feb 29, 2024 9:57 am

*) system - expose "lo" interface;
To filter through changelogs easily, you can go here: https://mikrotik.com/download/changelog ... lease-tree press expand and then use "ctrl+f"

melectronics · Thu Feb 29, 2024 10:14 am

I mean I did that but I didn´t find something about loopback

CGGXANNX · Thu Feb 29, 2024 10:19 am

WAN under the Bridge (or not)
The debate about putting a WAN interface under the VLAN-filtered bridge or leaving it standalone is getting hot, so let's clarify the subject.

Technically, RouterOS v7 allows putting a WAN interface under the VLAN-filtered bridge in any case (into a separate VLAN, of course).

However, it complicates the user config and CPU processing. In other words, it will be harder for humans to understand such a configuration, and it will take slightly longer for the device CPU to walk through the device tree to find an egress port for a packet. While it is not a big deal (we're talking about a few extra nanoseconds), you can still avoid it unless hardware requirements force you.

Speaking about hardware requirements, the famous one is L3HW. Hardware routing requires hardware bridge for VLAN tagging, so the only way apply L3HW on a VLAN-tagged WAN interface is putting it under the bridge. Still, it applies to L3HW-capable devices only (CRS3xx, CRS5xx, and CCR2x16) and only if the WAN interface requires VLAN-tagging (or bridging multiple WAN interfaces). For instance, if CCR2216 has a standalone untagged WAN interface, you can keep it outside the bridge.

None of RB* devices support L3HW. Hence, you can keep the WAN interface outside the bridge even if it requires VLAN tagging. You may put an /interface/vlan straightly on top of the WAN port.

UPDATE: If a WAN port requires some bridge features (e.g., bridge firewall, VLAN traffic filtering, etc.), then, of course, you need a bridge.

In my case, I've experimented with the "WAN under Bridge" configuration in the past week on my RB5009. My WAN is a PPPoE connection over a SFP GPON module, which requires no VLAN tagging, so when I put sfp-sfpplus1 under the Bridge I set a dummy PVID 1000 for it with frame-types=admit-only-untagged-and-priority-tagged and configured th PPPoE connection to use the interface vlan1000 under bridge, everything seems to work fine. The bridge ports are all shown with the H-flag active and bridge-fast-path-active is on. My LAN only uses VLAN, the bridge interface with PVID 1 is not used (no IP address and DHCP). The router has no problem with WAN speedtest around 2-2.2Gbps (the limit of my line) for both IPv4 and IPv6.

However, I noticed that IPv4 Fasttrack doesn't work anymore. All the dummy fasttrack rules are still listed under the tabs of the IPv4 firewall window in WinBox, but they all have counter == 0. Most of the IPv4 connections listed under the Connections tab do have the F flag active (fasttrack not greyed out in the status bar). But the counters are all 0:

fasttrack.png

fasttrack2.png

Using "Profile" I could see that the "firewall" task now use about 3-4x more CPU, but the RB5009 can still handle everything without a problem. If I pull sfp-sfpplus1 out of the bridge and set PPPoE to use it, the fasttrack counters increase normally and the CPU usage for "firewall" drops.

Is this the Fasttrack inactive the intended behavior? According to viewtopic.php?t=182658 FastPath should be supported with VLAN filtering since 7.2 so this condition should still be met for Fasttrack, shouldn't it?

FIPTech · Thu Feb 29, 2024 10:26 am

I mean I did that but I didn´t find something about loopback

Loopback is a word frequently used for those virtual interfaces, but it is not really meaningful. Because those interfaces are not really used for loopback but more to simplify routing or setup (router address, unnumbered IP, some IPsec setup, and so on).

It is "lo" in the Mikrotik world.

melectronics · Thu Feb 29, 2024 11:11 am

I know what a loopback interface is but it was suddenly there in the interface list 😅

onnoossendrijver · Thu Feb 29, 2024 12:55 pm

Is this an issue introduced in 7.14? I see heavy discussion in this thread but no mention in 7.13 topic.

I have VLAN/MTU/Bridge related problems since 7.13

sirbryan · Thu Feb 29, 2024 4:32 pm

VLAN MTU Issue
We have reproduced multiple issues regarding VLAN MTU not applying correctly or resetting to default after reboot. Unfortunately, it is too late to incorporate the fixes into 7.14, so those will be available in the upcoming 7.15beta.
Is this an issue introduced in 7.14? I see heavy discussion in this thread but no mention in 7.13 topic.

This has been a problem for me for a long time; it's not recent. I reported this back with 7.10, and then again with 7.12/7.13 in just the last couple of weeks. Both times I was told it would be fixed in a future release, but it sounds like they finally have enough data to put a fix into 7.15 (as mentioned above).

sirbryan · Thu Feb 29, 2024 4:36 pm

Is this the Fasttrack inactive the intended behavior? According to viewtopic.php?t=182658 FastPath should be supported with VLAN filtering since 7.2 so this condition should still be met for Fasttrack, shouldn't it?

RB5009 doesn't qualify for hardware-offloaded routing, just bridging/switching. Since you're adding PPPoE and firewall rules, it's all punted to the CPU anyway.

Keeping your WAN interface out of the LAN bridge is best practice for non-L3HW-offloaded devices (anything that's not a CRS3xx, CRS5xx, or CCR2x16), unless you're passing VLANs through from the WAN to the LAN.

Thu Feb 29, 2024 4:59 pm

RouterOS v7.14 has been released
viewtopic.php?t=205097