Community discussions

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

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

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

Mon Feb 12, 2024 10:58 am

No solution for the memory shortage in 15.3MB ARM devices?
 
Rox169
Member
Member
Posts: 434
Joined: Sat Sep 04, 2021 1:47 am

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

Mon Feb 12, 2024 11:04 am

What do you mean? I can not install this RC on ARM with 16 MB?
 
erlinden
Forum Guru
Forum Guru
Posts: 1939
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

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

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
Member Candidate
Member Candidate
Posts: 160
Joined: Thu Jun 09, 2022 7:20 pm

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

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

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

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.
Image
It works fine for me.
 
massinia
Member Candidate
Member Candidate
Posts: 160
Joined: Thu Jun 09, 2022 7:20 pm

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

Mon Feb 12, 2024 12:17 pm



It still doesn't work for me...
Windows clients see the share but cannot access it.
Image
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
 
User avatar
BrateloSlava
Member Candidate
Member Candidate
Posts: 168
Joined: Mon Aug 09, 2021 10:33 am
Location: Ukraine, Kharkiv

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

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
Trainer
Trainer
Posts: 11
Joined: Fri Apr 23, 2010 3:41 pm

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

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

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

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

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

Mon Feb 12, 2024 2:40 pm

kalaposl post your SMB export please
 
erlinden
Forum Guru
Forum Guru
Posts: 1939
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

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

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
 
User avatar
JohnTRIVOLTA
Member
Member
Posts: 345
Joined: Sun Dec 25, 2016 2:05 pm
Location: BG/Sofia

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

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
Member
Member
Posts: 420
Joined: Tue Jan 23, 2024 9:16 pm

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

Mon Feb 12, 2024 4:21 pm

Impressive list of changes, looking forward to 7.14 stable.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10213
Joined: Mon Jun 08, 2015 12:09 pm

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

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).
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3407
Joined: Sun May 01, 2016 7:12 pm
Location: California

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

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
Member Candidate
Member Candidate
Posts: 160
Joined: Thu Jun 09, 2022 7:20 pm

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

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

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

Tue Feb 13, 2024 4:38 am

Call for ed25519 private key.
 
User avatar
Ullinator
just joined
Posts: 8
Joined: Tue Jun 08, 2021 12:53 pm
Location: North-West Germany

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

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

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

Tue Feb 13, 2024 12:19 pm

Ullinator, we would need to see the full config in the RC1
 
User avatar
Ullinator
just joined
Posts: 8
Joined: Tue Jun 08, 2021 12:53 pm
Location: North-West Germany

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

Tue Feb 13, 2024 12:24 pm

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

via Support-Ticket?
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26363
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

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

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
 
User avatar
Ullinator
just joined
Posts: 8
Joined: Tue Jun 08, 2021 12:53 pm
Location: North-West Germany

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

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
just joined
Posts: 5
Joined: Fri Sep 11, 2020 12:37 am

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

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
just joined
Posts: 9
Joined: Mon Apr 27, 2015 8:35 pm

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

Tue Feb 13, 2024 11:24 pm

CVE-2023-52160, Does this affects ROS in any way?
 
DarkNate
Forum Guru
Forum Guru
Posts: 1009
Joined: Fri Jun 26, 2020 4:37 pm

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

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
Member
Member
Posts: 434
Joined: Sat Sep 04, 2021 1:47 am

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

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
Long time Member
Long time Member
Posts: 661
Joined: Thu Nov 12, 2020 12:07 pm

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

Wed Feb 14, 2024 6:11 pm

fetch needs FTP pernission?
 
User avatar
Etz
Member Candidate
Member Candidate
Posts: 178
Joined: Thu Mar 27, 2014 10:09 am
Location: Estonia

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

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 ;)
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1278
Joined: Tue Jun 23, 2015 2:35 pm

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

Thu Feb 15, 2024 2:10 am

i hope that the LTE can be fixed on the stable version , as per advised.
 
holvoetn
Forum Guru
Forum Guru
Posts: 5442
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

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

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
Trainer
Trainer
Posts: 11
Joined: Fri Apr 23, 2010 3:41 pm

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

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
Member Candidate
Member Candidate
Posts: 137
Joined: Wed May 27, 2009 12:48 pm

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

Thu Feb 15, 2024 11:18 am

OSPF SNMP support when?
You do not have the required permissions to view the files attached to this post.
 
chojrak11
Member Candidate
Member Candidate
Posts: 131
Joined: Sun Apr 05, 2009 10:37 am

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

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.
You do not have the required permissions to view the files attached to this post.
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1278
Joined: Tue Jun 23, 2015 2:35 pm

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

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

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

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
Frequent Visitor
Frequent Visitor
Posts: 77
Joined: Wed Feb 24, 2016 8:41 pm
Location: Bielefeld, Germany
Contact:

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

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.

Image
 
jhbarrantes
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Wed Aug 21, 2019 2:56 pm

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

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.
Last edited by BartoszP on Fri Feb 16, 2024 10:40 am, edited 1 time in total.
Reason: removed quote of previous mail with oversized picture
 
roggles
just joined
Posts: 9
Joined: Wed Mar 06, 2019 4:54 pm

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

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

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

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
just joined
Posts: 9
Joined: Wed Mar 06, 2019 4:54 pm

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

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
just joined
Posts: 13
Joined: Fri Jul 07, 2023 12:55 pm

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

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.
 
User avatar
Ullinator
just joined
Posts: 8
Joined: Tue Jun 08, 2021 12:53 pm
Location: North-West Germany

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

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
Frequent Visitor
Frequent Visitor
Posts: 77
Joined: Wed Feb 24, 2016 8:41 pm
Location: Bielefeld, Germany
Contact:

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

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.
 
User avatar
antonsb
MikroTik Support
MikroTik Support
Posts: 387
Joined: Sun Jul 24, 2016 3:12 pm
Location: Riga, Latvia

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

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

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

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.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3407
Joined: Sun May 01, 2016 7:12 pm
Location: California

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

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
Member Candidate
Member Candidate
Posts: 131
Joined: Sun Apr 05, 2009 10:37 am

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

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
You do not have the required permissions to view the files attached to this post.
 
jhbarrantes
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Wed Aug 21, 2019 2:56 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 67
Joined: Mon Oct 09, 2023 6:48 pm
Location: Italy

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

Sat Feb 17, 2024 11:26 am

Changes in defconf are not applied on upgrades, AFAIK.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10213
Joined: Mon Jun 08, 2015 12:09 pm

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

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

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

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
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Wed Aug 21, 2019 2:56 pm

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

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

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

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.
 
User avatar
sergiobeltrao
just joined
Posts: 1
Joined: Sat Jan 21, 2023 4:53 am
Location: Brazil

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

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.
 
User avatar
pekr
Member Candidate
Member Candidate
Posts: 169
Joined: Tue Feb 22, 2005 9:05 pm
Location: Czech Republic
Contact:

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

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.
 
User avatar
Paternot
Forum Veteran
Forum Veteran
Posts: 953
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

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

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.
 
User avatar
mozerd
Forum Veteran
Forum Veteran
Posts: 882
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

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

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
Forum Guru
Forum Guru
Posts: 1009
Joined: Fri Jun 26, 2020 4:37 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Wed Aug 21, 2019 2:56 pm

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

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.
 
User avatar
mozerd
Forum Veteran
Forum Veteran
Posts: 882
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

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

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]
 
holvoetn
Forum Guru
Forum Guru
Posts: 5442
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

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

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 ?).
 
User avatar
mozerd
Forum Veteran
Forum Veteran
Posts: 882
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

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

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

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

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.
 
User avatar
mozerd
Forum Veteran
Forum Veteran
Posts: 882
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

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

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"
Last edited by mozerd on Sun Feb 18, 2024 2:24 pm, edited 1 time in total.
 
holvoetn
Forum Guru
Forum Guru
Posts: 5442
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

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

Sun Feb 18, 2024 1:56 pm

There you have it.
Self inflicted issue :lol:
 
kreb
just joined
Posts: 9
Joined: Fri Mar 10, 2023 8:35 pm

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

Sun Feb 18, 2024 3:28 pm

CCR2116, OSPFv3 has a problem on 7.14rc, downgrading to 7.13.4 solved the issue.
 
User avatar
baragoon
Member
Member
Posts: 303
Joined: Thu Jan 05, 2017 10:38 am
Location: Kyiv, UA
Contact:

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

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
just joined
Posts: 9
Joined: Fri Mar 10, 2023 8:35 pm

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

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
 
User avatar
baragoon
Member
Member
Posts: 303
Joined: Thu Jan 05, 2017 10:38 am
Location: Kyiv, UA
Contact:

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

Sun Feb 18, 2024 5:45 pm

@kreb, thanks for the info, my infra is MikroTik only and everything is ok with OSPF.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 551
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

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
Frequent Visitor
Frequent Visitor
Posts: 67
Joined: Mon Oct 09, 2023 6:48 pm
Location: Italy

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

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
Forum Guru
Forum Guru
Posts: 1009
Joined: Fri Jun 26, 2020 4:37 pm

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

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
Member Candidate
Member Candidate
Posts: 143
Joined: Mon Aug 19, 2019 3:06 pm

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

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
Member Candidate
Member Candidate
Posts: 131
Joined: Sun Apr 05, 2009 10:37 am

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

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
Member Candidate
Member Candidate
Posts: 160
Joined: Thu Jun 09, 2022 7:20 pm

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

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
Image
 
User avatar
antonsb
MikroTik Support
MikroTik Support
Posts: 387
Joined: Sun Jul 24, 2016 3:12 pm
Location: Riga, Latvia

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

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
Member Candidate
Member Candidate
Posts: 131
Joined: Sun Apr 05, 2009 10:37 am

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

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
Member
Member
Posts: 434
Joined: Sat Sep 04, 2021 1:47 am

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

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?
Last edited by Rox169 on Tue Feb 20, 2024 3:44 pm, edited 1 time in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10213
Joined: Mon Jun 08, 2015 12:09 pm

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

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
newbie
Posts: 39
Joined: Mon May 24, 2021 6:33 pm

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

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
newbie
Posts: 39
Joined: Mon May 24, 2021 6:33 pm

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

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

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

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

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

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;
 
holvoetn
Forum Guru
Forum Guru
Posts: 5442
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

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

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) ?
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1278
Joined: Tue Jun 23, 2015 2:35 pm

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

Wed Feb 21, 2024 11:40 am

the LTE still no fixed!
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1278
Joined: Tue Jun 23, 2015 2:35 pm

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

Wed Feb 21, 2024 11:41 am

also ovpn between MTs is extremely unstable, unlike MT-->win
 
User avatar
CTassisF
newbie
Posts: 35
Joined: Thu Jun 11, 2020 10:26 pm
Location: São Paulo, Brazil
Contact:

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

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
just joined
Posts: 4
Joined: Sun Jan 22, 2023 3:04 pm

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

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:
*) 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
just joined
Posts: 11
Joined: Fri Apr 14, 2023 2:28 pm

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

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:
*) 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
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

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

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
Frequent Visitor
Frequent Visitor
Posts: 67
Joined: Wed Oct 12, 2011 1:38 am

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

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.
 
emilst
MikroTik Support
MikroTik Support
Posts: 19
Joined: Mon Oct 22, 2018 3:25 pm

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

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.
 
emilst
MikroTik Support
MikroTik Support
Posts: 19
Joined: Mon Oct 22, 2018 3:25 pm

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

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?
 
holvoetn
Forum Guru
Forum Guru
Posts: 5442
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

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

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

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

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.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 270
Joined: Mon Apr 27, 2020 10:14 am

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

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

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

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

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

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.
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1278
Joined: Tue Jun 23, 2015 2:35 pm

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

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
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

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

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.
Last edited by FIPTech on Thu Feb 22, 2024 12:55 pm, edited 2 times in total.
 
massinia
Member Candidate
Member Candidate
Posts: 160
Joined: Thu Jun 09, 2022 7:20 pm

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

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.
 
emilst
MikroTik Support
MikroTik Support
Posts: 19
Joined: Mon Oct 22, 2018 3:25 pm

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

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
 
User avatar
CTassisF
newbie
Posts: 35
Joined: Thu Jun 11, 2020 10:26 pm
Location: São Paulo, Brazil
Contact:

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

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
just joined
Posts: 2
Joined: Wed Feb 14, 2024 7:48 am

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

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
Last edited by rysiekg on Thu Feb 22, 2024 2:23 pm, edited 1 time in total.
 
Miracles
just joined
Posts: 11
Joined: Fri Apr 14, 2023 2:28 pm

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

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.
 
User avatar
Paternot
Forum Veteran
Forum Veteran
Posts: 953
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

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

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
just joined
Posts: 6
Joined: Sat Aug 13, 2022 1:13 am

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

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
newbie
Posts: 36
Joined: Tue Sep 04, 2018 10:29 pm
Location: Greece

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

Thu Feb 22, 2024 3:25 pm

He talking about modem firmware version and not for ros version
 
holvoetn
Forum Guru
Forum Guru
Posts: 5442
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

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

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
just joined
Posts: 4
Joined: Sun Jan 22, 2023 3:04 pm

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

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?
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 270
Joined: Mon Apr 27, 2020 10:14 am

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

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.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3407
Joined: Sun May 01, 2016 7:12 pm
Location: California

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

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

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

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

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

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

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

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.
 
andriys
Forum Guru
Forum Guru
Posts: 1526
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

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

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

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

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
Forum Guru
Forum Guru
Posts: 1009
Joined: Fri Jun 26, 2020 4:37 pm

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

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

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

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
just joined
Posts: 11
Joined: Fri Apr 14, 2023 2:28 pm

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

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
just joined
Posts: 11
Joined: Fri Apr 14, 2023 2:28 pm

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

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
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

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

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.
Last edited by FIPTech on Fri Feb 23, 2024 3:14 pm, edited 3 times in total.
 
blacksnow
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Wed Feb 15, 2023 4:46 pm

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

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.
Last edited by blacksnow on Fri Feb 23, 2024 6:59 pm, edited 1 time in total.
 
DarkNate
Forum Guru
Forum Guru
Posts: 1009
Joined: Fri Jun 26, 2020 4:37 pm

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

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

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

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
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

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

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
Forum Guru
Forum Guru
Posts: 1009
Joined: Fri Jun 26, 2020 4:37 pm

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

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
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

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

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. :)
 
User avatar
dzievamarcos
just joined
Posts: 4
Joined: Tue Jan 30, 2024 10:22 pm
Location: Iguazu Falls, Brazil

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

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
just joined
Posts: 5
Joined: Thu Jan 19, 2017 11:50 am

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

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
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 551
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

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

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
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

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

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 
You do not have the required permissions to view the files attached to this post.
 
tangent
Forum Guru
Forum Guru
Posts: 1379
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

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

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

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

Sun Feb 25, 2024 11:05 am

I think you have to set both, with comma in between.
 
tangent
Forum Guru
Forum Guru
Posts: 1379
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

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

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
MikroTik Support
MikroTik Support
Posts: 87
Joined: Wed Jan 02, 2019 12:14 pm
Location: Latvia
Contact:

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

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
 
User avatar
dzievamarcos
just joined
Posts: 4
Joined: Tue Jan 30, 2024 10:22 pm
Location: Iguazu Falls, Brazil

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

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

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

Tue Feb 27, 2024 7:36 am

Is it already finished?
Finished??? 7.15 beta is not even released. It may be in alpha.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7050
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Tue Feb 27, 2024 9:13 am

7.15 beta what? IS-IS is already in v7.14
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 270
Joined: Mon Apr 27, 2020 10:14 am

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

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
just joined
Posts: 23
Joined: Fri Jun 11, 2021 4:56 pm

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

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.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 270
Joined: Mon Apr 27, 2020 10:14 am

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

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

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

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

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

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
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

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

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.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 270
Joined: Mon Apr 27, 2020 10:14 am

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

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.
 
User avatar
ivn
just joined
Posts: 14
Joined: Sun Mar 11, 2018 3:37 pm

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

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

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

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
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

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

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
just joined
Posts: 6
Joined: Wed Jan 20, 2010 2:30 am
Location: Germany

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

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
just joined
Posts: 7
Joined: Tue Nov 20, 2012 11:26 pm

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

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
just joined
Posts: 5
Joined: Fri Jan 20, 2023 6:28 pm

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

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

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

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
Forum Guru
Forum Guru
Posts: 1185
Joined: Fri Dec 31, 2021 11:44 am
Location: Croatia

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

Wed Feb 28, 2024 7:08 pm

Seems that 7.14 stable is near...
 
S8T8
Frequent Visitor
Frequent Visitor
Posts: 81
Joined: Thu Sep 15, 2022 7:15 pm

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

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
Member
Member
Posts: 331
Joined: Mon Dec 28, 2020 12:30 pm
Location: Earth

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

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
Frequent Visitor
Frequent Visitor
Posts: 81
Joined: Thu Sep 15, 2022 7:15 pm

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

Wed Feb 28, 2024 10:09 pm

since 7.13 not 7.13.5
 
gabacho4
Member
Member
Posts: 331
Joined: Mon Dec 28, 2020 12:30 pm
Location: Earth

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

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.
 
User avatar
jbl42
Member Candidate
Member Candidate
Posts: 215
Joined: Sun Jun 21, 2020 12:58 pm

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

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
Member
Member
Posts: 331
Joined: Mon Dec 28, 2020 12:30 pm
Location: Earth

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

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
Member Candidate
Member Candidate
Posts: 137
Joined: Wed May 27, 2009 12:48 pm

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

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?
 
User avatar
jbl42
Member Candidate
Member Candidate
Posts: 215
Joined: Sun Jun 21, 2020 12:58 pm

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

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
Member Candidate
Member Candidate
Posts: 137
Joined: Wed May 27, 2009 12:48 pm

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

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

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

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
just joined
Posts: 2
Joined: Fri Oct 06, 2023 7:43 pm

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

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
Long time Member
Long time Member
Posts: 661
Joined: Thu Nov 12, 2020 12:07 pm

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

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
just joined
Posts: 2
Joined: Fri Oct 06, 2023 7:43 pm

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

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

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

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
just joined
Posts: 2
Joined: Fri Oct 06, 2023 7:43 pm

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

Thu Feb 29, 2024 10:14 am

I mean I did that but I didn´t find something about loopback
 
CGGXANNX
Frequent Visitor
Frequent Visitor
Posts: 55
Joined: Thu Dec 21, 2023 6:45 pm

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

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?
You do not have the required permissions to view the files attached to this post.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

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

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
just joined
Posts: 2
Joined: Fri Oct 06, 2023 7:43 pm

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

Thu Feb 29, 2024 11:11 am

I know what a loopback interface is but it was suddenly there in the interface list 😅
 
onnoossendrijver
Member
Member
Posts: 487
Joined: Mon Jul 14, 2008 11:10 am
Location: The Netherlands

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

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

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

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

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

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

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

Thu Feb 29, 2024 4:59 pm

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

Who is online

Users browsing this forum: LabarH and 7 guests