MikroTik

Posted: **Wed Dec 20, 2023 3:01 pm**

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

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

What's new in 7.14beta10 (2024-Feb-06 15:47):

!) rose-storage - moved SMB service in the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service);
*) arp - added ARP status;
*) console - improved stability when using autocomplete with "export";
*) defconf - fixed configuration script on KNOT devices if "ppp-out" interface is removed;
*) defconf - fixed firewall rule for IPv6 UDP traceroute;
*) dhcpv6-client - updated error logging when multiple prefixes received on renew;
*) disk - added global disk "settings" menu (CLI only);
*) l3hw - fixed IPv6 host offloading in certain cases;
*) package - added "size" property;
*) poe-out - improved 802.3at classification and measurement accuracy;
*) poe-out - improved cable test for hAP ac3 and hAP ax3 devices;
*) ptp - added "aes67" and "smpte" profiles;
*) ptp - added configurable "domain" and "priority2" parameters;
*) ptp - added support for Management message forwarding in BC;
*) route - fixed gateways of locally imported vpnv4 routes;
*) route-filter - fixed AS path matchers when input and output chains are used;
*) sfp - fixed corrupted Tx traffic at 10Gbps rate on CCR2004-16G-2S+ in rare cases;
*) smb - added option to specify SMB service mode as "auto";
*) supout - added PTP section;
*) system - expose "lo" and "vrf" interfaces;

What's new in 7.14beta9 (2024-Feb-01 11:09):

!) rose-storage - moved SMB service in the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service);
*) arp - added ARP status;
*) bridge - avoid per-VLAN host flushing on HW offloaded bridge;
*) bridge - fixed host flush on BPDU-guard port disable (introduced in v7.14beta3);
*) bridge - improved protocol-mode MSTP functionality;
*) bridge - removed "mst-config-digest" from MSTI menu;
*) bridge - removed MVRP support, the development will continue in v7.15 "beta";
*) certificate - improved certificate validation performance;
*) console - added "show-at-cli-login" option to display a note before telnet login;
*) console - fixed delayed output from ":grep" command in certain cases;
*) console - fixed incorrect behavior of ":onerror" command in certain cases;
*) defconf - added log about configuration reset due to pressed reset button;
*) defconf - fixed Audience scanning-for-wps-ap timeout;
*) defconf - increased LTE interface wait time;
*) defconf - updated health settings on configuration revert;
*) disk - added exFAT and NTFS mount/read/write support;
*) fetch - allow to use certificate and check-certificate parameters only in HTTPS mode;
*) fetch - fixed incorrect "src-path" error message when "upload=yes";
*) fetch - print all "Set-Cookies" headers in response;
*) health - added limited manual control over fans for CCR1016r2, CCR1036r2 devices;
*) health - changed default "fan-min-speed-percent" from 0% to 12%;
*) health - updated health properties for CCR1016r2, CCR1036r2 devices;
*) leds - added "dark-mode" functionality for hAP ax3 and Chateau ax series devices;
*) leds - fixed modem LED indication for SXT LTE 3-7;
*) lte - fixed APN authentication for FG621-EA modem;
*) lte - fixed Simcom modem support in 0x9000; 0x9002, 0x9002; 0x901a and 0x901b USB compositions;
*) lte - optimized "at-chat" response reading;
*) 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;
*) poe-out - driver optimization for AF/AT controlled boards;
*) 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;
*) sfp - fixed corrupted Tx traffic at 10Gbps rate on RB4011 in rare cases;
*) snmp - added "bgpLocalAs" and "bgpIdentifier" OID reporting;
*) snmp - fixed "bgpPeerFsmEstablishedTime" OID reporting;
*) sstp - added support for "aes256-gcm-sha384" encryption;
*) switch - fixed Atheros-8327 switch rules (introduced in v7.14beta3);
*) switch - fixed reserved multicast receive on Atheros-8327, QCA8337 switches for R/STP bridge;
*) system - correctly handle HTTP 1xx and 204 response status codes (introduced in v7.14beta6);
*) system - fixed "cpu-frequency" for CRS3xx ARM devices;
*) system - properly assign destination port for HTTP/S connections initiated by the router (introduced in v7.13);
*) webfig - fixed routing table filter under "IP/Routes" menu;
*) webfig - improved stability when adding new entries under "IP/Routes" menu;
*) wifi - added "station-pseudobridge" interface mode;
*) wifi-qcom - enable display of regulatory information on L11,L22 devices;
*) wifi-qcom - improve system stability for L11, L22 devices;
*) winbox - fixed status under "Bridge/Ports" menu (introduced in v7.14beta3);
*) winbox - improved status values under "System/PTP" menu;

What's new in 7.14beta8 (2024-Jan-22 21:07):

!) rose-storage - moved SMB service in the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service);
*) bgp - allow to leak routes between local VRFs;
*) bth - added simple "Back To Home Users" manager under IP/Cloud menu;
*) console - added "show-at-cli-login" option to display a note before telnet login (CLI only);
*) defconf - fixed Audience scanning-for-wps-ap timeout;
*) 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);
*) fetch - added "head" option for "http-method";
*) fetch - allow specifying link-local address in FTP mode;
*) fetch - fixed fetch when using "src-path" with SFTP mode (introduced in v7.13);
*) firewall - fixed underlying CAPsMAN tunnel reusing packet marks of encapsulated packets;
*) firewall - fixed underlying VXLAN/EoIP tunnel reusing packet marks of encapsulated packets;
*) health - show voltage when powering KNOT R through Micro-USB;
*) iot - added bluetooth whitelist wildcard asterisk support;
*) 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;
*) leds - fixed modem signal strength for RBSXTR&R11e-LTE (introduced in v7.14beta6);
*) lte - added "at-chat" support for Sierra Wireless EM9293 5G modem;
*) lte - fixed Simcom modem support in 0x9001 USB composition;
*) modem - improved stability when performing modem FOTA upgrade;
*) netinstall-cli - check package and device architecture before formatting;
*) package - reduced "wireless" package size for ARM, ARM64, MIPSBE, MMIPS devices;
*) package - reduced package size for SMIPS;
*) poe-out - fixed "power-cycle" for CRS354-48P-4S+2Q+ device (introduced in v7.13);
*) 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 - updated timeout log;
*) switch - fixed "cpu-flow-control" for RB3011 (introduced in v7.14beta3);
*) switch - fixed Atheros switch port configuration export (introduced in v7.14beta3);
*) switch - fixed Ethernet disable/enable for CRS310-8G+2S+ devices;
*) 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);
*) traffic-flow - use 64bit counters for v9 and IPFIX flows;
*) traffic-generator - improved system stability when receiving bogus traffic;
*) webfig - fixed setting the user's password;
*) wifi - improved handling of CAP connections in dual CAPsMAN scenario;
*) wifi-qcom - improved system stability when using FastPath (introduced in v7.13);

What's new in 7.14beta7 (2024-Jan-15 11:37):

!) rose-storage - moved SMB service in the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service);
*) bth - added simple "Back To Home Users" manager under IP/Cloud menu;
*) iot - improvements to LoRa CUPS;
*) lte - fixed MBIM interface enabling for Quectel EC25 modem (introduced in v7.13);
*) route - fixed route lockup when loading large amount of routes on ARM64 (introduced in v7.14beta4);
*) sms - moved LTE SMS read settings from "/tool/sms" to "/interface/lte" menu and migrate old configuration (CLI only);
*) vlan - fixed non-running VLAN interface after failed MTU change;
*) winbox - show all columns under "Routing/PIM SM/Static RP" menu by default;

What's new in 7.14beta6 (2024-Jan-10 16:21):

*) arp - added ARP status (CLI only);
*) calea - improved system stability when adding bridge rule without "calea" package installed;
*) console - updated copyright notice;
*) defconf - do not add loopback interface to the bridge ports (introduced in v7.14beta3);
*) defconf - fixed wifi configuration if interface MAC address is changed;
*) defconf - increased LTE interface wait time;
*) dhcpv6-client - install dynamic IPv6 blackhole routes in corresponding routing-table;
*) dns - fixed domain name lookup resolving for internal services;
*) fetch - fixed DNS resolving when domain has only AAAA entries (introduced in v7.13);
*) fetch - fixed timeout when content-length is 0 (introduced in v7.14beta4);
*) fetch - improved fetch stability in SFTP mode;
*) fetch - less verbose logging;
*) iot - improved LoRa LNS;
*) l3hw - fixed neighbor offloading after link flap;
*) l3hw - preserve offloading for VLANs when bridge ports are down;
*) leds - fixed default LTE LED configuration for wAPR-2nD;
*) 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 support for config-less modem detection (introduced in v7.13);
*) lte - improved modem recovery after failed IPv4 configuration;
*) mpls - fixed VPN fragmentation when forwarding IP traffic;
*) 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;
*) qos-hw - fixed "tx-queue7-packet" counter;
*) routerboard - added "reset-button" support for RBwAPR-2nD device;
*) sfp - added support for modules requiring single byte I2C read transactions;
*) sfp - improved link establishment for RB4011 devices;
*) smips - improved system stability (introduced in v7.14beta4);
*) sms - improved system stability when working with SMS;
*) snmp - hide "MikroTik" in LLDP MIB when branding with hide SNMP option is used;
*) ssh - improved SSH performance on ARM, MIPS, MMIPS, SMIPS and TILE devices;
*) system - improved system stability when processing packets in FastPath (introduced in v7.13);
*) 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;
*) 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;
*) wifi - fixed issue with setting country profile (introduced in v7.13.1);
*) 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;
*) winbox - added "Name" parameter under "Tools/Netwatch" menu;
*) 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 - fixed "Bridge Cost" range under "Interfaces/VPLS" menu;
*) winbox - fixed "Password" button under "Quick Set" menu;
*) winbox - improved system stability with large packets;
*) winbox - remove "Root Bridge ID" property under "Bridge/MSTIs" menu;

What's new in 7.14beta4 (2023-Dec-29 10:05):

*) bridge - fixed auto "path-cost" for bonding interfaces (introduced in v7.13);
*) bth - added simple "Back To Home Users" manager under IP/Cloud menu;
*) console - increased maximum file content length that can be managed through command line to 60 KB;
*) dns - do not add new entries to cache if "cache-size" is reached;
*) fetch - fixed fetch when using "src-path" with HTTP/HTTPS modes (introduced in v7.13);
*) fetch - improved file download stability with HTTP/HTTPS modes;
*) leds - do not show LTE connection state/mode using RGB power LED from configless LTE modems;
*) lte - fixed USB mode switch and initialization race condition for configless USB modems;
*) lte - improved support for "ACER" and "MSFT" branded EM12-G modems;
*) route-filter - added option to set "isis-ext-metric";
*) sfp - improved combo-sfp handling for CRS328-4C-20S-4S+;
*) switch - fixed "vlan-mode" and "default-vlan-id" property reset after reboot (introduced in v7.14beta3);
*) system - expose "lo" and "vrf" interfaces;
*) system - improved memory allocation for ARM64 devices;
*) tr069 - fixed bandwidth test;
*) usb - show "Supermicro CDC" adapter as Ethernet interface;
*) wifi-qcom - fixed new connections, when maximum supported number of MAC addresses behind connected station-bridges is reached;
*) x86 - fixed VLAN tagged packet transmit for igb (introduced in v7.12);

What's new in 7.14beta3 (2023-Dec-19 13:31):

*) 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;
*) bridge - added MLAG support for MSTP bridges;
*) bridge - added MVRP support (CLI only);
*) 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 - try to set wireless bridge ports as edge ports automatically;
*) bth - added simple "Back To Home Users" manager under IP/Cloud menu;
*) console - added missing "where" clause for "/ipv6/firewall/filter" table print command;
*) console - added ":tolf" and ":tocrlf" commands for converting line break to/from LF or CRLF;
*) 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 - hint on reset command help that ".rsc file" is required for "run-after-reset" parameter;
*) console - improved editor functionality in full screen mode;
*) console - increased maximum file content length that can be managed through command line to 60 KB;
*) container - improved VETH interface management responsiveness and reliability;
*) container - restrict "/container/shell" menu for users without "write" permissions;
*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;
*) disk - added exFAT and NTFS mount/read/write support (CLI only);
*) disk - properly unmount disk when it is disconnected;
*) ethernet - improved cable-test reliability for hAP ax3 PoE out port;
*) ethernet - resolved minor memory leak while processing packets;
*) fetch - do not require "content-length" for HTTP (introduced in v7.13);
*) fetch - fixed IPv4 address logging (introduced in v7.13);
*) 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 - increased default "udp-timeout" value from 10s to 30s;
*) health - improved fan control on CRS3xx and CCR1016-12S-1S+r2;
*) iot - added LoRa CUPs protocol support;
*) iot - fixed modbus partial frame reception issue;
*) iot - improved modbus Tx/Rx switching behaviour;
*) leds - fixed "type=on" LED behaviour after reboot;
*) leds - fixed wireless type of LED triggers for routers using WiFi package;
*) lte - refactored AT command control for AT modems;
*) modem - fixed SMS removal (introduced in v7.13);
*) ovpn - added support for pushing routes;
*) ovpn - improved OVPN configuration file import process;
*) ovpn - improved key-renegotiation process;
*) poe-out - improved PoE out reliability on routers with a single PoE out interface;
*) ppp - log an error when IPv6 DHCP pool is exhausted;
*) route - improved route print "count-only" process speed;
*) route - improved stability on route table lookup;
*) sfp - improve high-power SFP module initialization;
*) ssh - improved SSH performance on ARM and MIPS devices;
*) ssh - refactored SSH service internal processes;
*) 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 - expose "lo" interface;
*) system - improved RAM allocation for L009UiGS-RM;
*) system - improved system stability when processing packets in FastPath (introduced in v7.13);
*) 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;
*) tr069-client - show 5G signal info in X_MIKROTIK_5G nodes only for 5G NSA bands;
*) wifi - added "station-pseudobridge" interface mode (CLI only);
*) wifi - use correct CAP identity for interface name provisioning after it has been changed by remote-cap/set-identity;
*) 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 "page-refresh" setting to the Graphing settings;
*) 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 - improved connection speed and reliability;
*) winbox - improved route table automatic refresh process for static routes;
*) winbox - include "te-tunnel" parameter in VPLS interface monitor;
*) winbox - properly validate "passthrough-subnet-size" in the LTE APN settings;
*) 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;
*) wireguard - do not allow to use multiple WireGuard interfaces on the same "listen-port";
*) wireguard - optimised and improved WireGuard service logging;

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

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

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

Posted: **Wed Dec 20, 2023 3:30 pm**

*) bridge - added MLAG support for MSTP bridges;
*) bridge - added MVRP support (CLI only);
*) 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;
*) ovpn - added support for pushing routes;

nice stuff way to go MT

Posted: **Wed Dec 20, 2023 3:42 pm**

*) system - expose "lo" interface;

no more fake loopback bridges required for ospf :)

Posted: **Wed Dec 20, 2023 3:42 pm**

*) bridge - try to set wireless bridge ports as edge ports automatically;

Nice, thank you!

Posted: **Wed Dec 20, 2023 3:47 pm**

Just notice push route is in the ovpn server setting not per secret/user basis? I hope MT would make it more flexible

Posted: **Wed Dec 20, 2023 4:10 pm**

ethernet - resolved minor memory leak while processing packets;

I'm sure you guys already expected this question to come: under what circunstances does this minor memory leak occur? Who should be concerned? To what degree?

Posted: **Wed Dec 20, 2023 4:30 pm**

Code: Select all
*) system - expose "lo" interface;
no more fake loopback bridges required for ospf :)

did you test it yet? currious if it really works

Posted: **Wed Dec 20, 2023 4:32 pm**

I'll try it in GNS3 later today.
Edit: seems to work fine in initial testing

Posted: **Wed Dec 20, 2023 5:31 pm**

*) system - expose "lo" interface;

Nice

Regards,

Posted: **Wed Dec 20, 2023 6:03 pm**

hmm, since we already have Loopback interfaces, maybe "soon" we will also see VTI interfaces :p

Posted: **Wed Dec 20, 2023 6:40 pm**

After updating to v7.14beta3, I noticed that my hAP ac3 is reverting vlan-mode settings in /interface/ethernet/switch/port to vlan-mode=disabled instead of the vlan-mode=fallback that was set before. This is happening on every reboot, even after setting to vlan-mode=fallback again.

Posted: **Wed Dec 20, 2023 7:03 pm**

next to loopback interfaces tab, we have also vrf interfaces tab .. ?! what the heck ? ;-)

Posted: **Wed Dec 20, 2023 7:10 pm**

This is something I've wanted to do before — use fq_codel on an interface queue — but it's never allowed:

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

And AFAIK it still cannot be applied "by hand" in 7.14, but trying to fq_codel on an interface returns same as previous versions:
failure: non rate limit queues are useless on this interface

Any reason why the "defconf" can do it, but the CLI cannot?

Maybe I just don't not understand "wired port on LTE devices" since I'm not sure what a that means (e.g. passthrough port or the LAN/bridge interface)?

Posted: **Wed Dec 20, 2023 7:15 pm**

I think the "failure: non rate limit queues are useless on this interface" warning is just if you try to assign a queue to the bridge, as opposed to just one of the ethernet ports.

Posted: **Wed Dec 20, 2023 8:47 pm**

Seams the problem with VPLS have got better. I have a RB962 in the lab on 6.13 it rebooted after 2 min now it have been up for 15min...
Grate work.

Sorry to erly rebooted after 20min so a bitt better but not solved

Posted: **Wed Dec 20, 2023 8:54 pm**

Hope IS-IS ipv6 come with 7.14 stable.

Posted: **Wed Dec 20, 2023 9:11 pm**

If only one loopback interface is supported, adding and deleting it should be impossible.

Posted: **Wed Dec 20, 2023 9:16 pm**

Code: Select all
*) system - expose "lo" interface;
no more fake loopback bridges required for ospf :)
did you test it yet? currious if it really works

Tested and it works

Posted: **Wed Dec 20, 2023 9:19 pm**

I think the "failure: non rate limit queues are useless on this interface" warning is just if you try to assign a queue to the bridge, as opposed to just one of the ethernet ports.

That's true, physically ports can use "non rate limit" queues.

But still not sure what the change does...

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

e.g. what does "wired port" mean in the context of an LTE device's defconf...as the default configuration of an LTE device uses a bridge...

Posted: **Wed Dec 20, 2023 9:31 pm**

Any plans for:

- L3HW offload enabled when using MLAG?
- Virtual Switch Stacking (VSS) capabilities? or at least Active / Standby switches with replicated configuration for true high availability?

I am looking for these features!

Posted: **Wed Dec 20, 2023 9:45 pm**

The fq_codel type is set for wired (Ethernet, SFP) interfaces in order to reduce bufferbloat. No interface queue for LTE interface itself.

I think the "failure: non rate limit queues are useless on this interface" warning is just if you try to assign a queue to the bridge, as opposed to just one of the ethernet ports.
That's true, physically ports can use "non rate limit" queues.

But still not sure what the change does...

*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;
e.g. what does "wired port" mean in the context of an LTE device's defconf...as the default configuration of an LTE device uses a bridge...

Posted: **Wed Dec 20, 2023 9:54 pm**

Can't find corresponding lines in /system/default-configuration/print

Posted: **Wed Dec 20, 2023 10:16 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

Posted: **Wed Dec 20, 2023 10:51 pm**

thanks!

Posted: **Thu Dec 21, 2023 12:12 am**

hmm, since we already have Loopback interfaces, maybe "soon" we will also see VTI interfaces :p

I don't want to get my hopes up. I've only been requesting VTI since 2009....

Posted: **Thu Dec 21, 2023 3:58 am**

next to loopback interfaces tab, we have also vrf interfaces tab .. ?! what the heck ?

VRF HW forwarding support for CRS3xx/5xx and CCR2116/2216 incoming ?

Posted: **Thu Dec 21, 2023 8:26 am**

There's a bug in bridge where a port role is blank in CHR and hapac2 in my limited testing at least

Posted: **Thu Dec 21, 2023 9:30 am**

Tell me please, what are the advantages of a "exposed lo" interface over the old way?

Posted: **Thu Dec 21, 2023 9:37 am**

Tell me please, what are the advantages of a "exposed lo" interface over the old way?

One example is you don't need to create a dummy bridge interface when terminating an EoIP tunnel at the router. Or anything that needs an IP set on a non-physical interface on the router itself. Correct me if I'm wrong.

Posted: **Thu Dec 21, 2023 9:42 am**

Tell me please, what are the advantages of a "exposed lo" interface over the old way?

I seen mention that it potentially can fix issue with MPLS VPN4 security firewall bug.

Posted: **Thu Dec 21, 2023 10:49 am**

After updating to v7.14beta3, I noticed that my hAP ac3 is reverting vlan-mode settings in /interface/ethernet/switch/port to vlan-mode=disabled instead of the vlan-mode=fallback that was set before. This is happening on every reboot, even after setting to vlan-mode=fallback again.

Hi and thanks for the feedback! We have reproduced the issue and will fix it in the next version.

Posted: **Thu Dec 21, 2023 2:11 pm**

Just notice push route is in the ovpn server setting not per secret/user basis? I hope MT would make it more flexible

Yes, openvpn in Linux is still far more flexible, with CCD and the ability to push any configuration, not only routes. Still it's progressing quite fast on Mikrotik, so I hope it will become as complete and flexible as it's in Linux.

Posted: **Thu Dec 21, 2023 3:07 pm**

Since RouterOS 7.7 we can use diffie-hellmann group 31:

*) ike2 - added support for DH Group 31 (EC25519) (CLI only);

The support is limited to ike2 / phase-1, could you please also bring this to ipsec / phase-2?

Is your crypto stack already able to support DH-32 (Curve448)? This would also be a great addition.

Posted: **Thu Dec 21, 2023 3:11 pm**

viewtopic.php?p=1042343#p1042343 / SUP-137799
Not fixed in this build.

Posted: **Thu Dec 21, 2023 5:13 pm**

*) api - improved REST API stability when processing invalid requests;

This type of changes line usually involves a security or availability problem. What is the CVE ID?

Posted: **Thu Dec 21, 2023 5:22 pm**

Suggestion: can the 4 "FP" counters be removed from the default colums shown in winbox?
These were probably added when someone was very proud of having Fast Path, but they are not very relevant anymore.
And those who want to see them can always use the column selector to enable them again...

Posted: **Thu Dec 21, 2023 5:29 pm**

next to loopback interfaces tab, we have also vrf interfaces tab .. ?! what the heck ? ;-)

And both are spelled in lowercase, while other interface types have a capital first letter and VRF is spelled all-caps in other places.
That can be improved...

Posted: **Thu Dec 21, 2023 5:31 pm**

*) ssh - refactored SSH service internal processes;

Does this include fixes for CVE-2023-48795 - or is RouterOS already not vulnerable?

Posted: **Thu Dec 21, 2023 6:37 pm**

*) iot - fixed modbus partial frame reception issue;
*) iot - improved modbus Tx/Rx switching behaviour;

Upgraded KNOT working as Modbus TCP-to-RTU gateway, fingers crossed...
Still seeing some occasional timing issue when Modbus TCP requests arrive too fast after the previous one - worked around for now by adding usleep(10000) before making a new request in my application using libmodbus. Just 10ms is sufficient, when reduced to 3ms the issue occurs very rarely which seems consistent with the 3-character delay (at 9600 bps) Modbus RTU uses to detect end of frame, 1ms is clearly not sufficient. Most often this occurs when there is a write and then a read, write succeeds but the subsequent read fails as if there was RS485 bus contention when started too early.

Posted: **Thu Dec 21, 2023 7:50 pm**

Suggestion: can the 4 "FP" counters be removed from the default colums shown in winbox?
These were probably added when someone was very proud of having Fast Path, but they are not very relevant anymore.
And those who want to see them can always use the column selector to enable them again...

I do agree. That would be the right thing to do. I always hide them. And now I know that FP in the column name stands for FastPath :) Thanks.

Posted: **Thu Dec 21, 2023 7:56 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

Why turning off ECN?

Thx!

Posted: **Thu Dec 21, 2023 8:15 pm**

The fq_codel type is set for wired (Ethernet, SFP) interfaces in order to reduce bufferbloat. No interface queue for LTE interface itself.

That's true, physically ports can use "non rate limit" queues.

But still not sure what the change does...

e.g. what does "wired port" mean in the context of an LTE device's defconf...as the default configuration of an LTE device uses a bridge...

I was curious about the setup of this new queue and I upgraded a LtAP-mini to v7.14beta3. However, no new queue was created or applied to any interface. Am I doing something wrong?

Captura de pantalla 2023-12-21 a las 19.14.04.png

Thanks.

Posted: **Thu Dec 21, 2023 8:30 pm**

Why turning off ECN?

I'm not an expert, but I think @dtaht said somewhere that ECN off is a safer default as it can cause conflicts at times when it doesn't get what it expects?

I reset my RB5009 to the default config to see if it auto put fq_codel on the interfaces, and it did not for me. I just used the reset config in Webfig, though... perhaps it needs to be hard reset? I just ended up putting fq_codel on all the interfaces manually to see how it does... so far so good.

Posted: **Thu Dec 21, 2023 9:42 pm**

Good news everyone... Regarding the broken bonding interface in 7.13 - got a response on the ticket and the nightly snapshot build for 7.14 (routeros-7.14alpha119-arm64.npk) seems to have solved the issue, at least on ccr2004. Hope it will be a part of the 7.14 build in the following days/weeks...

Posted: **Thu Dec 21, 2023 9:56 pm**

I was curious about the setup of this new queue and I upgraded a LtAP-mini to v7.14beta3. However, no new queue was created or applied to any interface. Am I doing something wrong?

Default config is not applied when you upgrade. You can reset to defaults or add the new config manually.

Posted: **Thu Dec 21, 2023 10:58 pm**

how about if i need two lo?

Posted: **Fri Dec 22, 2023 12:16 am**

What would be an "interface vrf"?

MikroTik_RouterOSv7.14beta3_interface-vrf-remove-Error.png

I created one just for fun, and I'm not able to remove it!
When I click remove, I receive the message "Couldn't remove interface <TESTE> - vrf devices cannot be removed directly (6).
Undo also gives me the same error.
Even with the safe-mode activated and quitting without disabling removed that "vrf interface".

I created an /ip/vrf and it appeard on interface vrf also.
But when I removed the /ip/vrf, it disappeared from /interface/vrf.

P.S.: It smells like Mikrotik guys are working on a subterfugie to allow route-leaking and its traffic.

Posted: **Fri Dec 22, 2023 6:52 am**

Any chance of adding rtl8156 or fixing RB5009 2,5Gbe issues this time?

Posted: **Fri Dec 22, 2023 7:49 am**

Question does MVRP implementation will be vendor neutral? Once it become stable?

Posted: **Fri Dec 22, 2023 12:06 pm**

ovpn - MT<-->MT is totally broken, unlike MT--->windows.

i wish if my config to be not happy , so i can play around.

Anyone can add something?

Posted: **Fri Dec 22, 2023 1:36 pm**

ovpn - MT<-->MT is totally broken, unlike MT--->windows.

Why would you ever use OVPN between MikroTik routers?
There are so many good alternatives!

Posted: **Fri Dec 22, 2023 2:25 pm**

Why is MikroTik loading wireless package into CCR models? Please explain WHY! This makes ABSOLUTLY no sense to me ...

Posted: **Fri Dec 22, 2023 2:28 pm**

Why is there always OVPN ? IPSEC ? MPLS ? BGP ? ...
Same question. Not everyone needs it everywhere.

It's part of the main package. Don't use what you don't want to use.

Posted: **Fri Dec 22, 2023 2:29 pm**

Why is MikroTik loading wireless package into CCR models? Please explain WHY! This makes ABSOLUTLY no sense to me ...

Legacy capsman is packed in (optional) wireless npk since 7.13. New wave2/wifi capsman is part of base package since 7.13. If you don't need to run legacy capsman, then you're free to remove wireless package.

Posted: **Fri Dec 22, 2023 3:31 pm**

Why is there always OVPN ? IPSEC ? MPLS ? BGP ? ...
Same question. Not everyone needs it everywhere.

It's part of the main package. Don't use what you don't want to use.

Well, I certainly consider it a step backward that almost all functionality is now in a single "routeros" package.
I can fully understand why packages like "DHCP", "PPP", "ipv6", "security" were merged with the system package! They often have nasty cross-dependencies and certain functions could fail to work when they are not installed.
But MPLS, BGP (and OSPF, IS-IS etc), CAPsMAN, Wireless, QuickSet and applications like proxy, SMB, should be in separate packages.
With a more user-friendly way to load/unload optional packages of course.
It would make devices like hAP ac2 and wAP ac become stable again. In most usage scenarios you don't need many of those packages and there would be breathing room in the flash again.

Posted: **Fri Dec 22, 2023 7:54 pm**

Is there any upgrade restriction for 7.14 beta like 7.13?

1. When upgrading by using "check-for-updates", all versions earlier than 7.12 will display 7.12 as the latest available version. Upgrade from v7.12 to v7.13 or later versions must be done through 7.12 in order to convert wireless packages automatically. Fresh installation with Netinstall or manual package installation works in the same manner as always.

Posted: **Fri Dec 22, 2023 8:23 pm**

Of course! That is not going away... always first upgrade to 7.12 or 7.12.1

Posted: **Fri Dec 22, 2023 10:30 pm**

Of course! That is not going away... always first upgrade to 7.12 or 7.12.1

7.13 should be called 8.
Versioning a mikrotik is so cumbersome:
- "stable" means "no more fixes" :we moved on to new features
- point release are "blocking" paths in upgrades

Posted: **Fri Dec 22, 2023 11:03 pm**

If MT would use semver they would indeed need to increase the major version here. While they try to keep BC by installing the wireless package automatically, this still has drawbacks. Less available flash for extra packages like container/zerotier and others. So this could really be a breaking change for some users.

But to summorize: First digit (7) is Just some marketing number. The second part/number (13) is what usually would be a major-version. They release "major versions" every few months and people keep complaining about not being able to "fire update button and forget" without issues. Sorry, dear IT professionals, major version upgrades need to be tested. Just don't blame MT.

Posted: **Fri Dec 22, 2023 11:07 pm**

- "stable" means "no more fixes" :we moved on to new features

Rather the opposite, "no new features", but fixes may still come (with the third version number increasing).

- point release are "blocking" paths in upgrades

Mikrotik is not the only vendor doing this. GitLab is doing a similar thing (making minor versions a mandatory stop on the upgrade path) from time to time, if you wish an example.

Posted: **Fri Dec 22, 2023 11:13 pm**

Well, I certainly consider it a step backward that almost all functionality is now in a single "routeros" package.

The selling point of ROS 7 was: "we merged everything into a single ROS bundle."

Now, 2023, download the extra-packages zip and count the packages in there. I guess we'll see even more in the future.

Posted: **Fri Dec 22, 2023 11:52 pm**

Of course! That is not going away... always first upgrade to 7.12 or 7.12.1

That I do understand :)
But for new user reading this thread and are not used to how stuff works, it should be written that to upgrade to 7.13 or later, you need first go to 7.12.x

My point was that MT has forgot to add that info. So obvious for us multiposters, but not for all other.

Posted: **Sat Dec 23, 2023 1:55 am**

*) bridge - added MVRP support (CLI only);

Please post small example...

figured it out by self:
/interface/bridge/port/set mvrp=yes and number=port - correct?

Thank's

Posted: **Sat Dec 23, 2023 10:41 am**

But for new user reading this thread and are not used to how stuff works, it should be written that to upgrade to 7.13 or later, you need first go to 7.12.x

Oh common, new user interested in beta versions is either full of adrenaline or plain stupid. For all the rest, the release announcement for 7.13 has a few highlited warnings and the first item is talking about upgrade path with mandatory step of 7.12. I expect that such warning will be repeated in future announcements for stable releases for quite some versions to come.

The only place such clarification is missing is the download section of mikrotik website ... but anyone doing upgrades by manually downloading packages shoukd have some experience, it's only too easy to miss something (like not using the right architecture or not uploading all the necessary extra packages or ...).

Posted: **Sat Dec 23, 2023 11:18 am**

Well, I certainly consider it a step backward that almost all functionality is now in a single "routeros" package.
I can fully understand why packages like "DHCP", "PPP", "ipv6", "security" were merged with the system package! They often have nasty cross-dependencies and certain functions could fail to work when they are not installed.
But MPLS, BGP (and OSPF, IS-IS etc), CAPsMAN, Wireless, QuickSet and applications like proxy, SMB, should be in separate packages.
With a more user-friendly way to load/unload optional packages of course.
It would make devices like hAP ac2 and wAP ac become stable again. In most usage scenarios you don't need many of those packages and there would be breathing room in the flash again.

I couldn't agree more on this, we have close to 340ish pieces of this hapAC2 as a CPE in the field that needs this wifi-qcom-ac + zerotier, if only we can remove some packages/components at will that will be awesome for now we stick to 7.12.1 for this reason

Posted: **Sat Dec 23, 2023 11:23 am**

Oh common, new user interested in beta versions is either full of adrenaline or plain stupid. For all the rest, the release announcement for 7.13 has a few highlited warnings and the first item is talking about upgrade path with mandatory step of 7.12. I expect that such warning will be repeated in future announcements for stable releases for quite some versions to come.

I do agree some, but this Information was posted in both 7.13 beta and 7.13 rc, so no reason not to hva the same information in 7.14 beta, since its importante to understand why you do not see 7.14 beta if you are no older version than 7.12 and try to upgrade from GUI. It may be a new function that are in 7.14 that you like to test out and hence has skipped allot of other version.

Posted: **Sat Dec 23, 2023 11:33 am**

I couldn't agree more on this, we have close to 340ish pieces of this hapAC2 as a CPE in the field that needs this wifi-qcom-ac + zerotier, if only we can remove some packages/components at will that will be awesome for now we stick to 7.12.1 for this reason

I do understand the frustration but that device has been released from the start with not enough flash storage.
I do not understand the need all of a sudden.
When it was released, there was no mentioning yet of wave2 drivers for that device. You were happy with it as it was at that point in time ?
Otherwise you wouldn't have purchased 340ish pieces (and probably some spare) ?
Currently since 7.13 you have the unexpected bonus option to add qcom-ac packages, something which always has been said would NOT be done.
You can now use wave2 drivers, for free !

But you can not have it all together as it is now. Not AND qcom-ac AND zerotier on AC2.
So you need to choose or upgrade to a device with more capabilities.

Or ... ditch zerotier and use wireguard. That's also an option.

Posted: **Sat Dec 23, 2023 12:49 pm**

Yeah that's why we might stay indefinitely in 7.12.1 because we can't eat our cake and have it too :) unfortunately wireguard is not an option for us :p

Posted: **Sat Dec 23, 2023 1:33 pm**

@pe1chl

Why would you ever use OVPN between MikroTik routers?
There are so many good alternatives!

100% agree ,this is old set up, and we are using vlans over ovpn, but the question is why is that still not fixed?

Posted: **Sat Dec 23, 2023 3:52 pm**

Yeah that's why we might stay indefinitely in 7.12.1 because we can't eat our cake and have it too :) unfortunately wireguard is not an option for us :p

LOL, you can upgrade beyond 7.12.1 and still have zerotier. What is your point?

Posted: **Sat Dec 23, 2023 7:31 pm**

I couldn't agree more on this, we have close to 340ish pieces of this hapAC2 as a CPE in the field that needs this wifi-qcom-ac + zerotier, if only we can remove some packages/components at will that will be awesome for now we stick to 7.12.1 for this reason
I do understand the frustration but that device has been released from the start with not enough flash storage.
I do not understand the need all of a sudden.
When it was released, there was no mentioning yet of wave2 drivers for that device. You were happy with it as it was at that point in time ?

Even with routeros+wireless+zerotier the hAP ac2 will probably run into trouble.
The new wifi architecture means that those who want to continue using the device with the drivers they got when they bought it now ALSO have the management for the new wireless (which they do not use), and as the flash was already almost completely full that will certainly cause issues.

That is why I am for splitting into different packages again, so users of wireless do not get the management part of wifi-qcom, and users that want extra packages like zerotier can drop some other things the do not need (like autorouting, mpls, proxy, SMB, hotspot, CAPSman, wireguard, ...)

Of course this should remain limited to application-like units that do not depend on other optional parts.

Posted: **Sat Dec 23, 2023 8:35 pm**

LOL, you can upgrade beyond 7.12.1 and still have zerotier. What is your point?

I can't upgrade to past/beyond 7.12.1 because this is the last version I can have a wireless + zerotier on this device, I'm just wondering why some people here is very apprehensive if all you want is to get the last ounce of $ you paid for the device, to give you proper context in home settings I might agree with most of you to upgrade to a next higher device and throw hapac2 in the bin, but when you are in business settings you can't just dump it and call it a day. there's no wrong if you are hoping one of these days that MT decided to break their monolithic approach to package and let the user choose whatever he/she wants to the device they already paid for, what pe1chl saying about breaking the package per feature is sane, coming from a sane mindset

Posted: **Sat Dec 23, 2023 8:38 pm**

Hoping that something will happen doesn't sound like good business practice IMHO.

Posted: **Sat Dec 23, 2023 8:53 pm**

wifi-qcom-ac is already out of the door a year ago who have thought this is possible?, who knows? maybe just maybe they break again the taboo and make v7 semi modular again like what we have in v6 where you can uninstall something at some extent to free up some space or resource.

Posted: **Sat Dec 23, 2023 8:55 pm**

The latest versions of 6 were all bundled.

Posted: **Sat Dec 23, 2023 8:58 pm**

Ok i stand corrected back to the v6 version where it was still not bundled :)

Posted: **Sat Dec 23, 2023 10:12 pm**

The latest versions of 6 were all bundled.

No. Even on the very latest v6 (6.49.11 as of this writing) you can still install individual packages in place of a bundle, leaving anything you don't really need out. v7 is very different in this regard.

Posted: **Sat Dec 23, 2023 10:48 pm**

Correct. For a long time the first thing I did on newly bought devices is to upgrade them to current version not by using "system->package->upgrade" but by uploading only the required packages for that device.
So that would never include mpls (I don't use it), not include wireless and hotspot packages on RB750 and CCR routers, etc.
That worked well until it caused issues with upgrading to v7. Once I knew that this was coming, I stopped doing it.

Posted: **Sat Dec 23, 2023 10:59 pm**

Exactly what I did. 😜

Posted: **Sun Dec 24, 2023 1:44 am**

The fq_codel type is set for wired (Ethernet, SFP) interfaces in order to reduce bufferbloat. No interface queue for LTE interface itself.

That's true, physically ports can use "non rate limit" queues.

But still not sure what the change does...

e.g. what does "wired port" mean in the context of an LTE device's defconf...as the default configuration of an LTE device uses a bridge...

I too am a little confused. My hope was, like openwrt did in 2013, mikrotik would get bql working as universally as possible, and make fq_codel the universal default on wired interfaces, and one day wifi, and another day LTE. Run unshaped - native mode - with just bql backpressure - fq_codel by itself is really lightweight and automatically optimizes for any underlying speed, pause frames, and even to some extent cpu overloads coming from elsewhere in the system. Is that what this is? :-P :-P :-P

Otherwise, applying fq_codel on top of an overbuffered LTE device helps, a little, but it would be best if LTE´s underlying buffering was managed a little better. I have seen 25 seconds of buffering in an LTE device. If that can be managed well, fq-codel on top is an excellent choice.

Posted: **Mon Dec 25, 2023 10:30 am**

*) disk - added exFAT and NTFS mount/read/write support (CLI only);
Is that using new kernel driver NTFS3?

Posted: **Mon Dec 25, 2023 5:26 pm**

If only the hapac2 could run clouflare zerotrust tunnel...... oh wait, its an arm device, it already can, but why not a package for all devices!!! C'mon MT be diverse and non-discriminatory for a change, this ARM favouritism is annoying. :-) ( shedding no tears for hapac2 )

Posted: **Tue Dec 26, 2023 2:23 pm**

That is why I am for splitting into different packages again, so users of wireless do not get the management part of wifi-qcom

my post to this: viewtopic.php?p=1036269#p1036269

MT, please overthink your decision. Userbase is going mad about having a wifi config section even on a plain router without wireless. Just because now they could make use of capsman? 😂

Posted: **Tue Dec 26, 2023 5:11 pm**

*) wifi - added "station-pseudobridge" interface mode (CLI only);

What is this functionality doing?

Posted: **Tue Dec 26, 2023 5:20 pm**

https://help.mikrotik.com/docs/display/ ... tion+Modes

Posted: **Wed Dec 27, 2023 4:28 pm**

Just reporting, once again, some minor problems I found on previous RouterOS versions, and weren't fixed to this date:
1) still can't disable some "Interfaces/Add New" interface types, first reported on the v7.2.1 release post
viewtopic.php?p=927171#p927171

I can remove using Skin Editor, it actually works on that session, but as soon as I logoff and login, some options are still there and cannot be disabled in a persistent fashion whatsoever.

1) using Design Skin, I disable some Interface/Add New interfaces, and it kind of works ..

mk1.png

.
2) but as soon as I logoff and login again, the "disabled" options are there again, nothing is actually saved on the skin json file, and I cannot permanently disable those interface types

mk2.png

.

My first report on this on v7.2.1 thread:
viewtopic.php?p=927171#p927171
.
3) some wrong TX/RX information is shown in every page, on webfig, first reported on 7.12rc, still happening on 7.14beta
viewtopic.php?p=1033124#p1030885

mk3.png

Posted: **Wed Dec 27, 2023 6:53 pm**

It looks like your problems are not actually bugs, but you misunderstand how it works or what is meant.
1/2. you need to actually save it. either as "default" or as another name, which you then assign to a user group.
3. it is the traffic of the webfig session, the traffic of the webpage you are viewing.

Posted: **Wed Dec 27, 2023 8:19 pm**

Upgrading a RB951G (mipsbe) to 7.14 beta, I've seen this in the logs:

2023.12.27-1913-RB951G-mipsbe-logs.png

This is the link mentioned in the logs: https://wiki.mikrotik.com/wiki/Manual:R ... D_settings

I don't get it :-(

Posted: **Wed Dec 27, 2023 10:26 pm**

It looks like your problems are not actually bugs, but you misunderstand how it works or what is meant.
1/2. you need to actually save it. either as "default" or as another name, which you then assign to a user group.
3. it is the traffic of the webfig session, the traffic of the webpage you are viewing.

1/2) yes, I tried saving it on a skin different than default, have tried that several times, and nothing is actually saved (json file timestamp is unchanged). That's really not the case. Since my first report, the skin is not 'default' and saved on a different name, applied to the admin group.

3) hmmmm never thought on that one, as we never had any changelog regarding that. That being said, I'm seeing Mbit/s of traffic on a screen with no updating info whatsoever, so it really doesn't seem to be "the screen i'm viewing" related at all. I would really insist it's a bug while we don't have any confirmation it's a new feature (showing traffic on the actual session). If that's the case, it's buggy anyawy, as I'm seeing VERY high traffic on completly stale screens (no entries updating counters, something like that)

Posted: **Wed Dec 27, 2023 10:30 pm**

next to loopback interfaces tab, we have also vrf interfaces tab .. ?! what the heck ? ;-)

added a "vrf" interface for testing, now I cannot delete it. It doesn't even show up in the terminal if you export the config... looks like a bug to me

as per "loopback" I could delete and re add it, but I cannot have more than one... this looks strange too, other vendors support having multiple loopbacks

Posted: **Wed Dec 27, 2023 10:58 pm**

added a "vrf" interface for testing, now I cannot delete it. It doesn't even show up in the terminal if you export the config... looks like a bug to me

The bug is probably that you're able to add them at all. These interfaces are the previously hidden ones that are automatically created when you create VRF (in /ip/vrf). See VRF and hidden interfaces for a bit about that.

Posted: **Wed Dec 27, 2023 11:00 pm**

RB5009 was unresponsive for Winbox.
Connection refused.
I could get in using SSH or HHTPS.

Disable and enable of Winbox service and back online.

Never saw that prior to 7.14beta...

Posted: **Wed Dec 27, 2023 11:06 pm**

And again ?!?

Posted: **Wed Dec 27, 2023 11:18 pm**

Also seen on AX Lite LTE running 7.14b3.

Ticket SUP-138816 created with supout.rif.

Posted: **Thu Dec 28, 2023 12:48 pm**

added a "vrf" interface for testing, now I cannot delete it. It doesn't even show up in the terminal if you export the config... looks like a bug to me
The bug is probably that you're able to add them at all. These interfaces are the previously hidden ones that are automatically created when you create VRF (in /ip/vrf). See VRF and hidden interfaces for a bit about that.

You are right. I created a new VRF and added the previously created "vrf interface" to it, then I managed to delete the interface via deleting the whole VRF.

Posted: **Thu Dec 28, 2023 2:21 pm**

I am still having a lot of errors on my two LR8 Lorawan gateways.
I don't know what happened with those products but for 6 months it seems to be a real mess.

Capture d’écran du 2023-12-28 13-23-41.png

Capture d’écran du 2023-12-28 13-27-50.png

The LR8 is equipped with a 7 Dbi Mikrotik antenna it used to receive very well.
I don't understand why RSSI went so bad so quickly.

The same happened suddenly on my two Lora LR8 gateways in two separate locations and I suspect a firmware issue.

Posted: **Thu Dec 28, 2023 2:25 pm**

I am still having a lot of errors on my two LR8 Lorawan gateways.
I don't know what happened with those products but for 6 months it seems to be a real mess.

You have provided so many details that they are sure to find a solution!!!
(At the time of this post there were no images or other details, but are little changes...)

Posted: **Thu Dec 28, 2023 2:29 pm**

Okay, sorry for the confusion. The signal is below -65 dbm and the information was confirmed up.
It is only the message CRC status "Error", which seems to be confusing.

Is everything Okay?

Posted: **Fri Dec 29, 2023 11:42 am**

Please add the capability of ZeroTier controller to use private roots/moons

Like zerotier-cli orbit on linux

Posted: **Fri Dec 29, 2023 11:53 am**

You should already be able to do that using containers.

Posted: **Fri Dec 29, 2023 3:18 pm**

What's new in 7.14beta4 (2023-Dec-29 10:05):

*) bridge - fixed auto "path-cost" for bonding interfaces (introduced in v7.13);
*) bth - added simple "Back To Home Users" manager under IP/Cloud menu;
*) console - increased maximum file content length that can be managed through command line to 60 KB;
*) dns - do not add new entries to cache if "cache-size" is reached;
*) fetch - fixed fetch when using "src-path" with HTTP/HTTPS modes (introduced in v7.13);
*) fetch - improved file download stability with HTTP/HTTPS modes;
*) leds - do not show LTE connection state/mode using RGB power LED from configless LTE modems;
*) lte - fixed USB mode switch and initialization race condition for configless USB modems;
*) lte - improved support for "ACER" and "MSFT" branded EM12-G modems;
*) route-filter - added option to set "isis-ext-metric";
*) sfp - improved combo-sfp handling for CRS328-4C-20S-4S+;
*) switch - fixed "vlan-mode" and "default-vlan-id" property reset after reboot (introduced in v7.14beta3);
*) system - expose "lo" and "vrf" interfaces;
*) system - improved memory allocation for ARM64 devices;
*) tr069 - fixed bandwidth test;
*) usb - show "Supermicro CDC" adapter as Ethernet interface;
*) wifi-qcom - fixed new connections, when maximum supported number of MAC addresses behind connected station-bridges is reached;
*) x86 - fixed VLAN tagged packet transmit for igb (introduced in v7.12);

Posted: **Fri Dec 29, 2023 3:37 pm**

What's new in 7.14beta4 (2023-Dec-29 10:05):

*) leds - do not show LTE connection state/mode using RGB power LED from configless LTE modems;

Thank you, now its back to normal.

*) system - improved memory allocation for ARM64 devices;

~100MB more free RAM on hAP ax^3

Posted: **Fri Dec 29, 2023 3:49 pm**

What's new in 7.14beta4 (2023-Dec-29 10:05):

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

good. now please make VRF import/export (local inter-VRF route leaking) finally work ( viewtopic.php?p=1045062#p1045062 )
BTW: is BGP even under active patching/development in rOSv7 at mikrotik atm.?

Posted: **Fri Dec 29, 2023 3:52 pm**

You should already be able to do that using containers.

Rather having the capability natively from the zerotier package, instead of just another workaround

Posted: **Fri Dec 29, 2023 8:05 pm**

*) bridge - fixed auto "path-cost" for bonding interfaces (introduced in v7.13);

Can confirm... The bug that broke bonding in 7.13 is fixed.

Posted: **Fri Dec 29, 2023 8:43 pm**

What's new in 7.14beta4 (2023-Dec-29 10:05):

*) leds - do not show LTE connection state/mode using RGB power LED from configless LTE modems;
Thank you, now its back to normal.
*) system - improved memory allocation for ARM64 devices;
~100MB more free RAM on hAP ax^3

200mb more free for me also on AX3, this is awesome @mikrotik .

Posted: **Sat Dec 30, 2023 1:41 pm**

BUG? -- filenaming partially corrupted in saving
as oversimplified char replacement used now:

e.g. file="sometextA(sometextB).rsc"

was working perfectly with no brackets replacement,
BUT now there is unnecessary replacement with warning:

Warning: file was corrected to sometextA_sometextB_

Expected:
No replacement for any chars compatible with Win+Lix+Mac filesystems.

Or is there any reason or explanation I missed?

Posted: **Sat Dec 30, 2023 1:49 pm**

Or is there any reason

Yes. Brackets are special characters in ROS and using them in file names calls for ambiguity and problems.

It's time to learn that using plain ASCII alphabet (a-z and A-Z) for file names is sane thing to do.
And before anybody puts forward MS practices: they are allowing lower and upper case characters in fike names but they don't make them case sensitive. Which makes file name interpretation locale-dependant ... not a very nice thing to do either.

Posted: **Sat Dec 30, 2023 3:24 pm**

Hi,

When installing the latest beta 7.14beta4 I got these messages on a wireguard road warrior connection, with the stable 7.13 (and earlier) it didn't happen:

wg-rw: XN58CdM6ppiSQpDaQT0bh1IMYgUP0czYYY92N1IBwE3c=: Handshake for peer did not complete after 5 seconds, retrying (try 2).

When I connect from my mobile it doesn't appear anymore but when I disconnect it keeps popping up this message.

What can happen?

Posted: **Sat Dec 30, 2023 4:16 pm**

Did /tool/graphing/resource stop recording container memory usage? Or has there actually been some serious reduction in memory usage on ARM64 devices?

I'm seeing a lot more free memory in both my RB5009 and hAP ax3. Both run containers, and no settings have been changed.

RB5009.png

hAP ax3.png

Posted: **Sat Dec 30, 2023 4:24 pm**

Read change log

*) system - improved memory allocation for ARM64 devices;

Posted: **Sat Dec 30, 2023 4:35 pm**

OK, so avoiding simple brackets () in filenames is the desired result of the 7.13 change log item:

*) console - replace reserved characters in file and script names with underscores;

So the result/change is now per ROS version e.g.:

/export file="FileNameChars_in_ROS_X.xx.x_can_also_be_!@#%^&()-=[]{}~|,.;"  
/file print
1 FileNameChars_in_ROS_7.12.1_can_also_be_!@#%^&()-=[]{}~|,.;.rsc
2 FileNameChars_in_ROS_7.13.x_can_also_be_!@#%^&__-_____~__._.rsc
3 FileNameChars_in_ROS_7.14.x_can_also_be_!@#%^&__-_____~__._.rsc

Makes sense, thanks for the info.

Posted: **Sat Dec 30, 2023 4:51 pm**

*) bth - added simple "Back To Home Users" manager under IP/Cloud menu;

There is a lot going on now in /ip/cloud. Perhaps the key/QR code should just be a function in the "BTH Users" dialog box for the user now... instead of the kinda odd "BTH VPN Wireguard" tab. While I get the need/difference... having two tabs (using dorky acronyms) & now a button for BTH is kinda confusing. Basically using only one tab that said explicitly "Back To Home" be a lot cleaner.

Posted: **Sat Dec 30, 2023 4:54 pm**

Hi,

When installing the latest beta 7.14beta4 I got these messages on a wireguard road warrior connection, with the stable 7.13 (and earlier) it didn't happen:
Code: Select all
wg-rw: XN58CdM6ppiSQpDaQT0bh1IMYgUP0czYYY92N1IBwE3c=: Handshake for peer did not complete after 5 seconds, retrying (try 2).
When I connect from my mobile it doesn't appear anymore but when I disconnect it keeps popping up this message.

What can happen?

do you have a persistent-keepalive configured? that may trigger that log msg
also, maybe the logging became more verbose. means, the message always has "been there" but never popped up in the log. cannot verify

Posted: **Sat Dec 30, 2023 5:07 pm**

do you have a persistent-keepalive configured? that may trigger that log msg
also, maybe the logging became more verbose. means, the message always has "been there" but never popped up in the log. cannot verify

a) Persistent-keepalive is not configured.
b) With "fetch" new messages started to appear that didn't appear before, it could be as you say that RouterOS is more "vebose" with wireguard.

I'm going to filter the !wireguard topic in /system/logging

Thanks.

Posted: **Sat Dec 30, 2023 5:35 pm**

Wireguard logging is more verbose now.
It's in the release notes...

Posted: **Sat Dec 30, 2023 8:28 pm**

Ok, thanks.

Posted: **Sun Dec 31, 2023 3:56 pm**

Are these logs normal? Will I have something else configured? If it is normal, how can I filter them so that they do not appear?
thank you

logs3.png

Posted: **Sun Dec 31, 2023 4:04 pm**

info !wireguard

Posted: **Sun Dec 31, 2023 5:06 pm**

Excuse my ignorance, could you be more specific or put the complete scripts?

Posted: **Sun Dec 31, 2023 5:35 pm**

Excuse my ignorance, could you be more specific or put the complete scripts?

/system logging set [find where topics="info"] topics=info,!wireguard

Posted: **Sun Dec 31, 2023 5:59 pm**

Thank you, and happy end of the year everyone

Posted: **Mon Jan 01, 2024 7:47 pm**

*) bth - added simple "Back To Home Users" manager under IP/Cloud menu;
There is a lot going on now in /ip/cloud. Perhaps the key/QR code should just be a function in the "BTH Users" dialog box for the user now... instead of the kinda odd "BTH VPN Wireguard" tab. While I get the need/difference... having two tabs (using dorky acronyms) & now a button for BTH is kinda confusing. Basically using only one tab that said explicitly "Back To Home" be a lot cleaner.

Or perhaps, a "Status" tab in /ip/cloud to show BTH tunnel things (and ideally last DDNS/time update)

Posted: **Tue Jan 02, 2024 7:16 am**

we tested 7.14beta4 on CCR2216 as a bgp border router and it is useless because as soon as you activate a bgp session the cpus go to 100% and stay there indefinitely.

7.14beta3 is working good.

Posted: **Tue Jan 02, 2024 2:30 pm**

@rpingar I hope if you don't mind asking hpw's all your ticket related to BGP issues? did MT respond or fix most of your issues? we are going to retry again to put MT in IX scenario and i just feared we are going to pull it again and replace it with Juniper platform inadvertly due to instability

I've seen in your previous post you are one of the users who has larger peers i've seen here, thanks in advance

Posted: **Tue Jan 02, 2024 3:10 pm**

@rpingar I hope if you don't mind asking hpw's all your ticket related to BGP issues? did MT respond or fix most of your issues? we are going to retry again to put MT in IX scenario and i just feared we are going to pull it again and replace it with Juniper platform inadvertly due to instability

I've seen in your previous post you are one of the users who has larger peers i've seen here, thanks in advance

since 7.13 it is pretty stable with fastpath disabled and L3HW offload enabled. A lot of issue were fixed and some yet to fix but pretty close to a stable enviroment.
They wrote me that have identfied also the issue I reported this morning and going to fix in next beta.
Now I am running 7.14beta3 to check if the case were one cpu is locked to 100% for ever with slow rotuing table update and conseguently bgp advertisment is fixed.

regards

Posted: **Tue Jan 02, 2024 3:23 pm**

Probably first you need to make sure that it is actually using 100% "for ever". When you have a full BGP feed and you also have created route filters that can take long to evaluate, it sure can take a long time to complete the first pass over the entire table.

Posted: **Tue Jan 02, 2024 3:27 pm**

Probably first you need to make sure that it is actually using 100% "for ever". When you have a full BGP feed and you also have created route filters that can take long to evaluate, it sure can take a long time to complete the first pass over the entire table.

not it is a bug.
a case is a ip/route/print command run while any cli or winbox windows is closed.............
but there are also other case were some job on routing table never end.

Posted: **Tue Jan 02, 2024 3:31 pm**

Hmm.... that's reassuring but we need to test this thoroughly specially rpki validation this will surely a showstopper to us, BFD is working properly glad it was sorted out.

Posted: **Tue Jan 02, 2024 3:35 pm**

Hmm.... that's reassuring but we need to test this thoroughly specially rpki validation this will surely a showstopper to us, BFD is working properly glad it was sorted out.

rpki is working in my design with routinator in a vm not docker, BFD is not present in my config.

regards

Posted: **Tue Jan 02, 2024 3:40 pm**

yeah we have our own instance of routinator too, that's good to hear that it was working well, you are in 2216 i'm on 1072 this is what really scare me now :)

Posted: **Tue Jan 02, 2024 3:47 pm**

yeah we have our own instance of routinator too, that's good to hear that it was working well, you are in 2216 i'm on 1072 this is what really scare me now :)

CCR1072 (tile) is more stable then CCR2216 (arm64) [latest is affected about fastpath stability and implementation of l3hw], in one nap we have two 1072 and the one cpu locked at 100% is the only issue we are experiencing with 7.13 (hope 7.14beta3 passed it, now they are running since 4days ago and the issue is not araising).

regards

Posted: **Tue Jan 02, 2024 4:09 pm**

ok thanks a ton, really excited to put this in the field next week

BR

Posted: **Tue Jan 02, 2024 4:19 pm**

Probably first you need to make sure that it is actually using 100% "for ever". When you have a full BGP feed and you also have created route filters that can take long to evaluate, it sure can take a long time to complete the first pass over the entire table.
not it is a bug.
a case is a ip/route/print command run while any cli or winbox windows is closed.............
but there are also other case were some job on routing table never end.

Well, I am using BGP in private networks so there are not so many routes, and I do not see this bug.
So my guess is that it is something that takes (too) long when you have internet full BGP feed, but not forever.

Posted: **Wed Jan 03, 2024 12:19 am**

Please add the capability of ZeroTier controller to use private roots/moons

Like zerotier-cli orbit on linux

+1 for this request!!
Or, a way to change planet file! :)

Posted: **Thu Jan 04, 2024 4:19 pm**

for those how use Mikrotik on a large bgp design and use Hwl3-offload there is still instability if you add also fastpath to the mix on CCR2216
7.14beta3 crashed today with any log or supout after 20hours of operation.
With fastpath disabled it was stable for a week.

Posted: **Fri Jan 05, 2024 8:18 pm**

This image continues to appear when closing the session, despite having made and saved a copy of the BackUp both on the desktop and on the external

Posted: **Sat Jan 06, 2024 3:32 am**

where is "lo" interface on 7.14beta4?

Posted: **Sat Jan 06, 2024 4:23 am**

where is "lo" interface on 7.14beta4?

It's no longer a separate tab in winbox AFAIK (it was in prev. beta). It's on the main interface tab only in winbox (and CLI).

This seems right... there should be only one loopback interface.

Posted: **Sat Jan 06, 2024 4:34 am**

clear, it is just added by default
Thx Amm0

Posted: **Sat Jan 06, 2024 4:47 am**

also i've noticed that from time to time im not able to log on the the router , since i upgrade to v7.14, and reboot fixes it the issues

Posted: **Sat Jan 06, 2024 8:16 am**

I've seen that too.
Ssh and romon will work though.
Mighty inconvenient !

Disable and enable winbox service helps, for a while.

Posted: **Sat Jan 06, 2024 10:23 am**

Can confirm that, RB5009, ax3 same thing. They are shown in winbox but sometimes can't connect to them without a reboot, after that works for a while.

Posted: **Sat Jan 06, 2024 12:31 pm**

This seems right... there should be only one loopback interface.

Not necessarily, there are cases, where having multiple lo’s is completely valid usecase.

Posted: **Sat Jan 06, 2024 12:38 pm**

Not necessarily, there are cases, where having multiple lo’s is completely valid usecase.

I guess for those usecases you can still use the existing workaround in RouterOS: a bridge without ports.

Posted: **Sat Jan 06, 2024 1:19 pm**

still is beta, as long as MT guys are aware of

Posted: **Sun Jan 07, 2024 12:26 pm**

I am with 7.14beta4 for 6 days now and there must be still any memory leak(-s). I have started with 150 MiB free memory and now I am bellow 100 Mib. Quite easy configuration with PPPoE xDSL, DHCP, DNS, WiFi, dualstack IPv6&4, BackToHome VPN and WireGuard but with QoS mangle marking and hierarchical Queue Tree. HW hAP ac^2 with (fortunately) 256 MiB memory.

Posted: **Mon Jan 08, 2024 7:16 am**

The fq_codel type is set for wired (Ethernet, SFP) interfaces in order to reduce bufferbloat. No interface queue for LTE interface itself.

@MikroTik staff. Yes, this is good news, this is a massive step forward in the industry (Yes, I am serious). But there's a problem.

MikroTik RouterOS Linux queuing doesn't support BQL:

https://lwn.net/Articles/469652/

https://www.bufferbloat.net/projects/bl ... d_drivers/

viewtopic.php?t=196068#p1035377

Artificial bufferbloat shows up in bufferbloat tests when we use fq_codel on MikroTik RouterOS on physical wired interfaces, the same problem doesn't happen on Debian for example with BQL.

Solution for MikroTik:
Please add BQL support.

Once you add BQL support, we get performance boost (CPU usage will drop) + long-term viability of fq_codel for service provider networks and also enterprise.

Next step is industry adoption of fq_codel on ASICs, I don't know if this is possible or not with Marvell ASICs though.

Regarding ECN, in my testing in production networks, leaving ECN marking enabled by default works better in the long run, assuming BQL is well-supported by the underlying platform. Overall, I would suggest leaving ECN enabled.

Posted: **Mon Jan 08, 2024 1:16 pm**

Solution for MikroTik:
Please add BQL support.

Once you add BQL support, we get performance boost (CPU usage will drop) + long-term viability of fq_codel for service provider networks and also enterprise.

Next step is industry adoption of fq_codel on ASICs, I don't know if this is possible or not with Marvell ASICs though.

Regarding ECN, in my testing in production networks, leaving ECN marking enabled by default works better in the long run, assuming BQL is well-supported by the underlying platform. Overall, I would suggest leaving ECN enabled.

YES - please add BQL to MikroTik RouterOS.

Posted: **Tue Jan 09, 2024 8:08 am**

pppoe server crash on x86 platform is still present.
ticket SUP-136050 updated with autosupout generated on crash of 7.14alpha155

Posted: **Tue Jan 09, 2024 10:24 am**

ticket SUP-136050 updated with autosupout generated on crash of 7.14alpha155

Is 7.14aplpha155 newer than 7.14beta? If not the test should be run on 7.14beta.

If 7.14aplpha155 is newer than 7.14beta, then I do not understand Mikrotiks version naming, since alpha should come before beta.

Posted: **Tue Jan 09, 2024 10:43 am**

Actually alpha and beta are built side by side, you can not tell which one is newer just by looking at the version number. The beta release are pushed to testing channel, alpha releases are for internal testing or are given to specific people for testing.

Posted: **Tue Jan 09, 2024 5:44 pm**

The fq_codel type is set for wired (Ethernet, SFP) interfaces in order to reduce bufferbloat. No interface queue for LTE interface itself.
@MikroTik staff. Yes, this is good news, this is a massive step forward in the industry (Yes, I am serious). But there's a problem.

MikroTik RouterOS Linux queuing doesn't support BQL:
https://lwn.net/Articles/469652/

https://www.bufferbloat.net/projects/bl ... d_drivers/

viewtopic.php?t=196068#p1035377
Artificial bufferbloat shows up in bufferbloat tests when we use fq_codel on MikroTik RouterOS on physical wired interfaces, the same problem doesn't happen on Debian for example with BQL.

I am very curious as to observed bufferbloat at line (not shaped) rate with fq_codel on various mikrotik devices. I have generally assumed that at least some have BQL support already, but did find at least one that didn´t, and told mikrotik about the patch, as per your third link above. It is fairly straightforward to test for bloat with a lack of bql at line rate, just send data from two ports into an fq_codeled one with a bunch of iperfs or flent and measure the latency with ping. Anything greater than 1ms at 100mbit or 2ms at 1gbit line rates indicates an overlarge device ring that bql would otherwise be managing for you. flent´s rtt_fair_* tests will do this for you and generate a nice plot.

I generally assume that none of their wifi actually has any of the airtime-fairness patches? and would do badly on the rtt_fair test described here:
https://www.cs.kau.se/tohojo/airtime-fairness/

I had hoped that the principles in that wifi codebase would be being rigorously applied not just to wifi, but to multiple p2mp stacks by now, and far more folk publish results from that test suite.

I will repeat that getting BQL implemented in any given ethernet driver is about an afternoon´s work with the device in front of you. http://www.taht.net/~d/broadcom_aug9_2018.pdf and viewtopic.php?t=186545 - you can see if your driver has it (if you have source) by grepping for netdev_sent_queue. You can monitor it with bqlmon, which is a nifty tool.

Some chips (like the mt76) have the ability to tie the shaper to BQL, and thus shape (egress-only), essentially in hardware.

Posted: **Tue Jan 09, 2024 6:36 pm**

Regarding airtimefairness patches:

The patch has been accepted into mainline Linux (along with Felix Fietkau’s follow-up fix for a power save-related crash bug) and was released as part of Linux 4.11. The code is also in the LEDE project firmware from version 17.01.

ROS uses Kernel 5.x IIRC. So these patches should be in ROS?

Posted: **Tue Jan 09, 2024 10:30 pm**

Regarding airtimefairness patches:

The patch has been accepted into mainline Linux (along with Felix Fietkau’s follow-up fix for a power save-related crash bug) and was released as part of Linux 4.11. The code is also in the LEDE project firmware from version 17.01.
ROS uses Kernel 5.x IIRC. So these patches should be in ROS?

Not necessarily if you compile Kernel yourself, you have “options”… :)

Posted: **Wed Jan 10, 2024 12:12 pm**

In many cases people are still using the factory, out of tree, wifi device driver supplied by the manufacturer, and their UI tightly tied to those APIs. Some of the factory drivers have features that are needed, also, like txop reduction in the beacon. We tried to make all the wifi manufacturers aware of https://www.cs.kau.se/tohojo/airtime-fairness/ back in 2016 in the hope they would improve their factory drivers also. Codel and fq_codel were breakthroughs in packet theory, and few to this day understand them. A lot of time I just rely on competition for the vendors to upgrade...

It was fun, recently, to demo to ubnt´s CEO how much better we made one of their products: https://blog.cerowrt.org/post/fq-codel-unifi6/
Somewhere around my office are similar benchmarks for a couple mikrotiks (the hap ac-lite in particular), but the best I can do is just recommend that the main vendor pay attention, or their customers, reflash to openwrt, usually.

If mikrotik would like any help in at least getting BQL going, or our benchmark suite, or these newer wifi drivers, all they have to do is drop the make-wifi-fast team a line. We have an open mailing list, going back over a decade now, at lists.bufferbloat.net

I am very pleased overall with all the progress mikrotik updating routeros to version 7, and am willing to wait until they get it more right, and just kibitz as I do about adding 6 lines of great code here or there. In my world, linux kernel version 5.7 is totally obsolete and i am hoping most of all that they start a version 8 running linux 6.1 or later. Particularly our mt76 and mt79 drivers evolved a lot since even 6.1!

Posted: **Wed Jan 10, 2024 12:22 pm**

Offtopic here but: I tried OpenWRT on a Linksys WRT3200ACM with CAKE enabled. Connected my Mikrotik Chateau LTE12 on WAN-port (all ROS queues disabled). It did not perform any better and bufferbloat was still evident. Then I tried https://github.com/lynxthecat/cake-autorate and I did not know why, but with that cake-autorate enabled my LTE speeds dropped to like 5mbit down, 1mbit up. And i usually have varying 20-90mbit up and 10-25mbit up. Very disappointed by the OpenWRT defaults of CAKE and with cake-autorate addon even more. I really loved and used OpenWRT for many years, but my experience with the WRT3200ACM (and WRT1200 before) were really unstable and bogged (because I used a davidc502 custom builds) - compared to the stability of ROS and Chateau LTE12.

Posted: **Wed Jan 10, 2024 12:28 pm**

infabo, please make a new topic about bufferbloat and cake testing.
dtaht, thank you very much for your offer and continuous support on this forum. we will see what we can do and will let you know if we have any questions

Posted: **Wed Jan 10, 2024 12:58 pm**

In my world, linux kernel version 5.7 is totally obsolete and i am hoping most of all that they start a version 8 running linux 6.1 or later. Particularly our mt76 and mt79 drivers evolved a lot since even 6.1!

MikroTik is probably the only network vendor on the planet that commercially uses the Linux kernel for the data plane, which means, they have good reason to keep up with the latest kernel tree/versions. But for some reason, they do not. Other vendors use Linux only on the control plane, data plane will be merchant silicon SDK or some custom code.

There's always good reasons to use latest Kernel version for networking, one of the recent ones:
https://www.phoronix.com/news/Linux-6.8-Networking

Posted: **Wed Jan 10, 2024 12:59 pm**

dtaht, thank you very much for your offer and continuous support on this forum. we will see what we can do and will let you know if we have any questions

I hope we see step 1: BQL support RouterOS-wide, MikroTik hardware-wide sooner than later.

The Wi-Fi related patches, IMO — You're better off opting for latest versions of the Linux kernel as suggested by dtaht.

Posted: **Wed Jan 10, 2024 1:11 pm**

From the messaging we’ve seen on this forum and in notes, it sounds like ROS 7 was a massive shift for MikroTik away from a lot of custom engineered work so they could track upstream more closely. I suspect once they finish getting all of the table stakes stuff implemented and mostly bug free they will start following the upstream kernel more closely. That’s my hope, at least. It’s one of the reasons 7 is exciting, even if it’s taking a while for it to actually stabilize with all of the core functionality people want. It’s a huge step in the right direction. I’m going off topic so will move on.

Posted: **Wed Jan 10, 2024 1:29 pm**

Offtopic here but: I tried OpenWRT on a Linksys WRT3200ACM with CAKE enabled. Connected my Mikrotik Chateau LTE12 on WAN-port (all ROS queues disabled). It did not perform any better and bufferbloat was still evident. Then I tried https://github.com/lynxthecat/cake-autorate and I did not know why, but with that cake-autorate enabled my LTE speeds dropped to like 5mbit down, 1mbit up. And i usually have varying 20-90mbit up and 10-25mbit up. Very disappointed by the OpenWRT defaults of CAKE and with cake-autorate addon even more. I really loved and used OpenWRT for many years, but my experience with the WRT3200ACM (and WRT1200 before) were really unstable and bogged (because I used a davidc502 custom builds) - compared to the stability of ROS and Chateau LTE12.

I think you are conflating three things. The underlying LTE buffers in the device(s) are huge. I have seen 25 seconds of it on one device, tested recently. (and they still shipped it!) LTE/5g/etc itself throughout its entire stack has major bufferbloat problems, for which multiple fixes for the enode-bs, rans, and clients have been proposed, none, implemented. https://scholar.google.com/scholar?hl=e ... erbloat+5g - for some papers on it. There are three proposals in that list that I like a lot. Fixing the underlying buffering on cell phones and routers actually requires changes to the signalling in the (chipset specific) lte/5g driver stack to essentially have a completion interrupt for a BQL like interface, or better reports of underlying buffering to the overlying driver. Might be happening in a few phones soon, can´t tell, but only works on the uplink side. There are zillions of other things LTE operators do wrong today, like have a lousy performance setting on the uplink scheduler. 1 number, changed in their operations, would make online gaming for 5G fwa work a lot better. There´s a really great paper on that, too, that I cannot find right now.

2) cake-autorate is a *research* project that attempts to use active measurements to manage a LTE connections more tolerable. It is the *Wrong thing* compared to actually fixing the underlying drivers, but without access to those drivers, they are trying to manage the buffering better. The team is very enthusiastic about their work as are those that have been willing to tweak and fiddle. I am sorry you only achieved 5/1 with your settings, please check the very active forum thread for help. https://forum.openwrt.org/t/cake-w-adap ... 15?u=dtaht

They are crazy, but my kind of crazy. In particular, I LOVE all the analysis tools they have developed to gain insights into this very thorny problem.

I see that you saw no difference between cake and the mikrotik product? Mikrotik is in a market position to improve drivers (or at least work with their chipset vendor to do so), and pick on the cellular folk, better than I am. The downstream and upstream schedulers can be improved greatly in addition to attempting to address the buffering.

3) In general, you do have to choose what device you put openwrt on carefully. I like the A/B test out of reflashing the hap ac-lite, for example. I LIKE (and need) ROUTEROS for all the features!! and want to see it improve to have the least bufferbloat in the industry.

To summarize, LTE and to an even greater extent 5G, is insanely bufferbloated, and without the big cellular providers understanding it, stepping in, and making it a priority to fix, it cannot be fixed well with 3rd party patches or active measurement. PLEASE pester your cellular providers about fixing their !@#! bufferbloat. My community has done all it can. Someone strapping the CEO of T-Mobile or Verizon in a chair and saying, "if you fix your bufferbloat, you will take another 5+ million FWA customers next year..." might work. It worked for me on musk: https://www.youtube.com/watch?v=c9gLo6Xrwgw

The whole starlink team is now aiming for 20ms of consistent latency, but they have a lot of their stack left to fix even after 2 years of trying, and a few ¨minor" problems like orbital mechanics getting in the way. Their gen2 router got a lot better recently, as did the gen3...

Posted: **Wed Jan 10, 2024 2:46 pm**

Someone strapping the CEO of T-Mobile or Verizon in a chair and saying, "if you fix your bufferbloat, you will take another 5+ million FWA customers next year..." might work. It worked for me on musk: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Won't work for me. I would like to know how to get beyond 1st-level ISP support to someone who would understand the topic. Not actively taking measures - just understand what bufferbloat means.

Posted: **Wed Jan 10, 2024 2:50 pm**

infabo, please make a new topic about bufferbloat and cake testing.
dtaht, thank you very much for your offer and continuous support on this forum. we will see what we can do and will let you know if we have any questions

Thanks @normis to pay attention to all these messages!

Posted: **Wed Jan 10, 2024 4:43 pm**

Someone strapping the CEO of T-Mobile or Verizon in a chair and saying, "if you fix your bufferbloat, you will take another 5+ million FWA customers next year..." might work. It worked for me on musk: https://www.youtube.com/watch?v=c9gLo6Xrwgw
Won't work for me. I would like to know how to get beyond 1st-level ISP support to someone who would understand the topic. Not actively taking measures - just understand what bufferbloat means.

It's not LTE carriers that are the problem per se. They follow the 3GPP/etc specs. LTE is a shared media, so speed changes with other's usage, sometime rapidly. It's the modem manufacturers that are the issue IMO. e.g. none that I know report the current bandwidth assigned (which should be deterministic with RBs assigned), which prevents using current channel capacity to set the max-bandwidth in CAKE/etc. Mikrotik could ask their modem vendors for some way to extract the current bandwidth from the modem, because that's what missing for LTE and queues.

Posted: **Wed Jan 10, 2024 5:38 pm**

In my world, linux kernel version 5.7 is totally obsolete and i am hoping most of all that they start a version 8 running linux 6.1 or later. Particularly our mt76 and mt79 drivers evolved a lot since even 6.1!
MikroTik is probably the only network vendor on the planet that commercially uses the Linux kernel for the data plane, which means, they have good reason to keep up with the latest kernel tree/versions. But for some reason, they do not. Other vendors use Linux only on the control plane, data plane will be merchant silicon SDK or some custom code.

There's always good reasons to use latest Kernel version for networking, one of the recent ones:
https://www.phoronix.com/news/Linux-6.8-Networking

I don't completely agree.
Mikrotik linux kernel is a control plane if you use L3HW....

regards

Posted: **Thu Jan 11, 2024 10:25 am**

What's new in 7.14beta6 (2024-Jan-10 16:21):

*) arp - added ARP status (CLI only);
*) calea - improved system stability when adding bridge rule without "calea" package installed;
*) console - updated copyright notice;
*) defconf - do not add loopback interface to the bridge ports (introduced in v7.14beta3);
*) defconf - fixed wifi configuration if interface MAC address is changed;
*) defconf - increased LTE interface wait time;
*) dhcpv6-client - install dynamic IPv6 blackhole routes in corresponding routing-table;
*) dns - fixed domain name lookup resolving for internal services;
*) fetch - fixed DNS resolving when domain has only AAAA entries (introduced in v7.13);
*) fetch - fixed timeout when content-length is 0 (introduced in v7.14beta4);
*) fetch - improved fetch stability in SFTP mode;
*) fetch - less verbose logging;
*) iot - improved LoRa LNS;
*) l3hw - fixed neighbor offloading after link flap;
*) l3hw - preserve offloading for VLANs when bridge ports are down;
*) leds - fixed default LTE LED configuration for wAPR-2nD;
*) 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 support for config-less modem detection (introduced in v7.13);
*) lte - improved modem recovery after failed IPv4 configuration;
*) mpls - fixed VPN fragmentation when forwarding IP traffic;
*) 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;
*) qos-hw - fixed "tx-queue7-packet" counter;
*) routerboard - added "reset-button" support for RBwAPR-2nD device;
*) sfp - added support for modules requiring single byte I2C read transactions;
*) sfp - improved link establishment for RB4011 devices;
*) smips - improved system stability (introduced in v7.14beta4);
*) sms - improved system stability when working with SMS;
*) snmp - hide "MikroTik" in LLDP MIB when branding with hide SNMP option is used;
*) ssh - improved SSH performance on ARM, MIPS, MMIPS, SMIPS and TILE devices;
*) system - improved system stability when processing packets in FastPath (introduced in v7.13);
*) 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;
*) 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;
*) wifi - fixed issue with setting country profile (introduced in v7.13.1);
*) 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;
*) winbox - added "Name" parameter under "Tools/Netwatch" menu;
*) 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 - fixed "Bridge Cost" range under "Interfaces/VPLS" menu;
*) winbox - fixed "Password" button under "Quick Set" menu;
*) winbox - improved system stability with large packets;
*) winbox - remove "Root Bridge ID" property under "Bridge/MSTIs" menu;

Posted: **Thu Jan 11, 2024 11:14 am**

*) mpls - fixed VPN fragmentation when forwarding IP traffic

Can u explain more?

Thx

Posted: **Thu Jan 11, 2024 11:42 am**

I don't completely agree.
Mikrotik linux kernel is a control plane if you use L3HW....
regards

Not all features/data plane functionality is 100% L3HW. This is MikroTik, not Juniper MX/PTX.

Take Wi-Fi/Wireless for instance, that's all Linux data plane.

They should upgrade to Linux Kernel 6.8, read this for why:
https://www.phoronix.com/news/Linux-6.8-Networking

Posted: **Thu Jan 11, 2024 2:03 pm**

If it were that simple...

Posted: **Thu Jan 11, 2024 2:55 pm**

They should upgrade to Linux Kernel 6.8, read this for why:
https://www.phoronix.com/news/Linux-6.8-Networking

I fail to see how that may be relevant for a router.

Posted: **Thu Jan 11, 2024 4:24 pm**

I fail to see how that may be relevant for a router.

Which part of

Not all features/data plane functionality is 100% L3HW. This is MikroTik, not Juniper MX/PTX.

is unclear?

CCR1k models, older RBs, or even CCR2k and newer CRSes have data plane features/config scenarios/situations where packets/Ethernet frames gets punted to the CPU, and for that MikroTik uses the Linux kernel Netfilter framework, not the Marvell switching SDK nor even DPDK/VPP for the punted CPU-traffic.

Are you new to MikroTik? This is not Juniper MX304, where all data-plane is 100% custom SDK/Code offloaded 24/7 to the ASIC.

Posted: **Thu Jan 11, 2024 4:39 pm**

Updated wAP ac LTE from 7.14beta3 to 7.14beta6. Modem model and firmware information is now gone from the LTE interface overview.
Firmware upgrade tool can't check current modem firmware either:

[admin@tik] /interface/lte> firmware-upgrade lte1
  status: unknown current version

The LTE interface has a permanent red comment saying 'A newer version of modem firmware is available!'.

Posted: **Thu Jan 11, 2024 5:11 pm**

Which part of
Not all features/data plane functionality is 100% L3HW. This is MikroTik, not Juniper MX/PTX.
is unclear?

I specifically quoted the part that is unclear. You posted a link to an articles that talks specifically about a TCP end-point optimization to prove your point that the kernel on routers absolutely must be upgraded. How does one relate to the other?

Posted: **Thu Jan 11, 2024 9:17 pm**

Which part of is unclear?
I specifically quoted the part that is unclear. You posted a link to an articles that talks specifically about a TCP end-point optimization to prove your point that the kernel on routers absolutely must be upgraded. How does one relate to the other?

It is definitely not related only to "end-points". If you go into pull request, the patch is really huge.. But engineers from Mikrotik should say, if they use Linux TCP/IP network stack or Qualcomm SDK (especially for WiFi - what I expect).

Networking changes for 6.8.

Core & protocols
----------------

- Analyze and reorganize core networking structs (socks, netdev, netns, mibs) to optimize cacheline consumption and set up build time warnings to safeguard against future header changes.This improves TCP performances with many concurrent connections up to 40%.

- Add page-pool netlink-based introspection, exposing the memory usage and recycling stats. This helps indentify bad PP users and possible leaks.

- Refine TCP/DCCP source port selection to no longer favor even source port at connect() time when IP_LOCAL_PORT_RANGE is set. This lowers the time taken by connect() for hosts having many active connections to the same destination.

- Refactor the TCP bind conflict code, shrinking related socket structs.

- Refactor TCP SYN-Cookie handling, as a preparation step to allow arbitrary SYN-Cookie processing via eBPF.

- Tune optmem_max for 0-copy usage, increasing the default value to 128KB and namespecifying it.

- Allow coalescing for cloned skbs coming from page pools, improving RX performances with some common configurations.

- Reduce extension header parsing overhead at GRO time.

- Add bridge MDB bulk deletion support, allowing user-space to request the deletion of matching entries.

- Reorder nftables struct members, to keep data accessed by the datapath first.

- Introduce TC block ports tracking and use. This allows supporting multicast-like behavior at the TC layer.

- Remove UAPI support for retired TC qdiscs (dsmark, CBQ and ATM) and classifiers (RSVP and tcindex).

- More data-race annotations.

- Extend the diag interface to dump TCP bound-only sockets.

- Conditional notification of events for TC qdisc class and actions.

- Support for WPAN dynamic associations with nearby devices, to form a sub-network using a specific PAN ID.

- Implement SMCv2.1 virtual ISM device support.

- Add support for Batman-avd mulicast packet type.

Posted: **Thu Jan 11, 2024 9:30 pm**

@FezzFest

[admin@tik] /interface/lte> firmware-upgrade lte1 status: unknown current versio

This has been reported, and i've been adviced that will be fixe in 7.14 stable

Posted: **Thu Jan 11, 2024 9:33 pm**

There is at least one change from 7.14beta4 to 7.14beta6 that is left out from the published changelog however it affects clients with Intel Wireless-AC 8265 (at least Windows 10 ones having the latest driver, version 20.70.32.1) when connecting to cAP ax. While these clients were able to connect with

/interface/wifi/security set management-protection=required

setting up till 7.14beta4 (and 7.13.0) after the upgrade to 7.14beta6 in order to be able to connect the said parameter has to be changed to

/interface/wifi/security set management-protection=allowed

While we are at the less than complete documentation:

IPIPv6 available in the CLI only is completely missing from the current documentation, only IPIP(v4) is included.
In case of PIM-SM
- RP Candidate is completely missing documentation and and missing from the CLI (WinBox only currently).
- Candidate is completely missing documentation and and missing from the CLI (WinBox only currently).
- Intterface Template join-prune-period and source-addresses parameters are missing documentation.
- Interface designated-router, dr, dynamic, join-tracking, override-interval, priority and propagation-delay parameters are missing documentation.
- Upstream Information Base source-specific multicast (
  Code: Select all
```
/routing/pimsm/uib-sg
```
  ) keepalive and register properties are missing documentation
Firewall Mangle IPv6 (
Code: Select all
```
/ipv6firewall/mangle
```
) is completely missing documentation as it is clear from the description of the very first property (action) since:
- the description of the following actions are missing:
  - change-hop-limit
  - dnpt
  - snpt
- while the following IPv4 only actions are in the description
  - change-ttl
  - clear-df
  - fasttrack-connection
  - route
  - strip-ipv4-options .

Posted: **Fri Jan 12, 2024 9:51 am**

I specifically quoted the part that is unclear. You posted a link to an articles that talks specifically about a TCP end-point optimization to prove your point that the kernel on routers absolutely must be upgraded. How does one relate to the other?

Someone else already explained here:
viewtopic.php?t=202612&sid=4728d6439ac3 ... e#p1047935

RouterOS v7 I believe is running kernel version 5.6. Since 5.6 release date, to current-day 6.8, A LOT OF THINGS HAVE CHANGED IN THE NETWORKING STACK of the Linux Kernel since 5.6.

Do you want me to look up each kernel change log and flood this forum post with 500+ lines of networking stack change log? I think not. Do you know how to Google yourself to find the network stack changelogs? Surely as an engineer, you know how to, right?

MikroTik should just adopt latest LTS 6.6.x.

Posted: **Fri Jan 12, 2024 12:06 pm**

Do you want me to look up each kernel change log and flood this forum post with 500+ lines of networking stack change log?

No, of course I don't! But I want you to validate specific pieces of evidence you post before actually posting them.

Please note that I, personally, do not argue against the need to upgrade to the later/latest kernel, nor do I argue in favor of. You posted a link presumably describing some changes in a specific kernel version that should have explain why Mikrotik should upgrade their kernels to at least 6.8. I was curious, so I opened the link and read that articles, but failed to find anything really relevant for the routers in there, hence replied accordingly. Should I were wrong in my conclusions, do you think you (as an engineer) could have replied in a more constructive manner?

Posted: **Fri Jan 12, 2024 2:38 pm**

Please note that I, personally, do not argue against the need to upgrade to the later/latest kernel, nor do I argue in favor of. You posted a link presumably describing some changes in a specific kernel version that should have explain why Mikrotik should upgrade their kernels to at least 6.8. I was curious, so I opened the link and read that articles, but failed to find anything really relevant for the routers in there, hence replied accordingly. Should I were wrong in my conclusions, do you think you (as an engineer) could have replied in a more constructive manner?

I will admit, that I generally don't “elaborate” in depth and just assume the other user gets it based on their potential to do their homework (as I always share sources).

In this case, one user did do his homework, and they shared the change logs here.

If I do NOT share sources — Generally, I do elaborate.

Anywho, RouterOS v7 is due for a kernel upgrade, more important, I want root access to the underlying shell to tweak network parameters.

Posted: **Fri Jan 12, 2024 2:42 pm**

Latest 7.14beta6 changed something in RB4011 relating to the SFP+ port.
The XS+DA0001 DAC cable stopped working for me, it's flapping the connection with a TP-LINK TL-SX3008F.
I reverted back to 7.13.1 and everything works again.

Edit: created SUP-140307 and provided supout.rif. Seems that 7.14alpha152 fixed the problem for me. I'm hoping Mikrotik will incorporate fix in stable 7.14.

Posted: **Fri Jan 12, 2024 6:12 pm**

Latest 7.14beta6 changed something in RB4011 relating to the SFP+ port.
The XS+DA0001 DAC cable stopped working for me, it's flapping the connection with a TP-LINK TL-SX3008F.
I reverted back to 7.13.1 and everything works again.

oooo I have the same problem on 7.13.1 between RB5009 and hAP ac.
I didn't think it could be a software fault...

Posted: **Fri Jan 12, 2024 9:59 pm**

Having a problem with fetch and response with content-length: 0, the behaviour is different from 7.13.1 but does not work.
reported as SUP-140354

on 7.13.1 got : failure: ERROR parsing http: there was no content-length or transfer-encoding
on 7.14beta6 got : failure: ERROR parsing http: content-length overflow

Posted: **Sat Jan 13, 2024 3:39 am**

MikroTik should just adopt latest LTS 6.6.x.

Linux LTS kernels have quite a short lifespan, the risk averse way is using the SLTS kernels maintained as part of the Civil Infrastructure Platform (CIP), of which the latest is the v6.1(-rt) series. Just to put the length of support in perspective: the oldest kernel series maintained as part of the CIP namely the v4.4(-rt) ones has later EOL date than the newest LTS (v6.6 series) Linux).

Posted: **Sat Jan 13, 2024 5:49 am**

Wireguard configuration should add an "Client MTU" parameter.

Posted: **Sat Jan 13, 2024 11:18 am**

Wireguard configuration should add an "Client MTU" parameter.

WireGuard is a Peer-to-Peer protocol with built-in 4in6/6in4 mechanisms for easy encapsulation. There's no such thing as “server” or “client” in WireGuard protocol. There are only peers.

Set MTU to 1420 on all peers and problem solved, if underlay is less than overlay, the underlay (such as LTE/5G networks that failed to deploy jumbo frames) will fragment the UDP encap, the overlay inside the tunnel will remain clean PMTUD end to end.

Jason A. Donenfeld created the WireGuard protocol, he knows better than you, me and anyone else on how the packet header was designed:
https://lists.zx2c4.com/pipermail/wireg ... 02201.html

Posted: **Sat Jan 13, 2024 11:22 am**

Linux LTS kernels have quite a short lifespan, the risk averse way is using the SLTS kernels maintained as part of the Civil Infrastructure Platform (CIP), of which the latest is the v6.1(-rt) series. Just to put the length of support in perspective: the oldest kernel series maintained as part of the CIP namely the v4.4(-rt) ones has later EOL date than the newest LTS (v6.6 series) Linux).

MikroTik can afford to just stick with latest stable kernel (upgrade once every 4–6 months) directly, though, ditch the LTS approach completely.

Posted: **Sat Jan 13, 2024 12:17 pm**

WireGuard is a Peer-to-Peer protocol with built-in 4in6/6in4 mechanisms for easy encapsulation. There's no such thing as “server” or “client” in WireGuard protocol. There are only peers.

You are 100% correct. But unfortunately many people [including so called gurus] on this forum refuse to accept that important FACT because they are mired in the client/server model ...

Posted: **Sat Jan 13, 2024 1:38 pm**

Newbie beta testing question:

When there are changes listed that include "*) defconf - ..." does that mean that changes have been made to the initial "default configuration," and if so, is it suggested that testers run the "system > reset configuration" process after updating to pick up any of these "defconf" changes/fixes in the release?

Posted: **Sat Jan 13, 2024 1:51 pm**

When you want to volunteer to test such things, you can always do so.
A bit of a weak point in RouterOS is that changes in the default config are never applied to existing routers, not even when the configuration of those routers still was at default settings.
So the typical scenario is: router is unpacked and has old RouterOS on it, on first power-on default configuration is applied, then the RouterOS is updated (only when the user knows to do that) and the newer default configuration is never applied, unless at that point the user knows that it is best to reset to defaults again.

Procedure after receiving new router should be:
- power on and accept default config
- apply minimum config to get internet connectivity
- do RouterOS upgrade (including reboot)
- do Routerboard firmware upgrade (reboot will come later)
- do a reset to defaults (again does a reboot)
- re-apply minimum config for internet connectivity
- then, other custom configuration can be done.

But of course many new users skip one or more of those steps.
It also does not help that these steps are not shown on the screen, along those terms and conditions texts.

It could help when RouterOS would be clever enough to recognize that configuration is still at defaults (no additional user config done) and to a reset-to-new-defaults silently.
It would also help when RouterOS by default would upgrade itself automatically, at least initially but preferably also using some scheduled job in the default config that can always be deleted when the user does not like that.

Posted: **Sat Jan 13, 2024 2:01 pm**

Wireguard configuration should add an "Client MTU" parameter.
WireGuard is a Peer-to-Peer protocol with built-in 4in6/6in4 mechanisms for easy encapsulation. There's no such thing as “server” or “client” in WireGuard protocol. There are only peers.

Set MTU to 1420 on all peers and problem solved, if underlay is less than overlay, the underlay (such as LTE/5G networks that failed to deploy jumbo frames) will fragment the UDP encap, the overlay inside the tunnel will remain clean PMTUD end to end.

You're so humor .

What are these options start with "Client" :

WireGuard MTU = low level MTU - 80
for Ethernet, we use 1500-80=1420.
for PPPoE. use 1500 - 8 - 80 = 1412.
for my ISP, must use 1442 - 80 = 1362.

Posted: **Sat Jan 13, 2024 2:11 pm**

Applying new defaults for everyone who did not change defaults in the past can still be dangerous.To avoid problems ROS converts old "default" configuration to explicit configuration. Happened lately with the changes to bridge port cost.

The alternative approach would be to intentionally introduce breaking changes and MT write upgrade guides. While this would be the better approach for professionals, you can't do that for "home users".

Posted: **Sat Jan 13, 2024 5:52 pm**

I think "home users" are best served with automatic upgrades and configuration updates.
Many home routers will be running with default config and have changed only things like admin password, wifi ssid+password, and internet connection parameters (like PPPoE client).
When not any other change has been made, and RouterOS is (automatically) upgraded, new defaults can be installed, preserving the above changes.
When it is detected that other config has been done, of course it should not blindly apply new default config.

Posted: **Sat Jan 13, 2024 6:18 pm**

I think "home users" are best served with automatic upgrades and configuration updates.
Many home routers will be running with default config and have changed only things like admin password, wifi ssid+password, and internet connection parameters (like PPPoE client).
When not any other change has been made, and RouterOS is (automatically) upgraded, new defaults can be installed, preserving the above changes.
When it is detected that other config has been done, of course it should not blindly apply new default config.

Now that I think about it, I've never seen too many “default changes” as often as MikroTik on Juniper, Huawei, Arista etc.

How do other vendors tackle this problem?

Posted: **Sat Jan 13, 2024 6:20 pm**

You are 100% correct. But unfortunately many people [including so called gurus] on this forum refuse to accept that important FACT because they are mired in the client/server model ...

I've seen the same stupidity on Cisco and Juniper community forums as well, so definitely not MikroTik community-specific on this one.

Posted: **Sat Jan 13, 2024 6:53 pm**

Wireguard configuration should add an "Client MTU" parameter.
WireGuard is a Peer-to-Peer protocol with built-in 4in6/6in4 mechanisms for easy encapsulation. There's no such thing as “server” or “client” in WireGuard protocol. There are only peers.

Set MTU to 1420 on all peers and problem solved, if underlay is less than overlay, the underlay (such as LTE/5G networks that failed to deploy jumbo frames) will fragment the UDP encap, the overlay inside the tunnel will remain clean PMTUD end to end.

Jason A. Donenfeld created the WireGuard protocol, he knows better than you, me and anyone else on how the packet header was designed:
https://lists.zx2c4.com/pipermail/wireg ... 02201.html

He was probably referring to this MikroTik feature:

Screenshot 2024-01-13 185154.png

Adding an MTU field in there can be done, so the exported peer config includes MTU too.

But sure, be a s̶m̶a̶r̶t̶ass about it.

Posted: **Sat Jan 13, 2024 6:56 pm**

You are 100% correct. But unfortunately many people [including so called gurus] on this forum refuse to accept that important FACT because they are mired in the client/server model ...
I've seen the same stupidity on Cisco and Juniper community forums as well, so definitely not MikroTik community-specific on this one.

I feel like it's a necessary evil to help the so called "home users" understand what they're setting up, the types of people that don't immediately spot the problem with copying private keys around to other devices etc. In the way those users are going to use WireGuard they are setting it up in a pseudo client-server regime anyway.

I don't agree with it, but it makes sense. We just have to ignore all those extra settings that now make the Winbox form much larger than it needs to be :)

At least they are separated by that line in Winbox.

Posted: **Sat Jan 13, 2024 8:09 pm**

MikroTik can afford to just stick with latest stable kernel (upgrade once every 4–6 months) directly, though, ditch the LTS approach completely.

I strongly disagree on this as MikroTik simply does not have the required engineering resources to make the necessary validation every six month. One can come to this conclusion just by considering the followings:

Test results were not updated using v7 not even for products that were originally shipped with v6 than along the way were switched over to v7 as the minimum.
There are still undocumented features (some of which I've noted a few posts earlier).
The documentation is not kept in sync with the RouterOS version. It is not just that quite some of the provided examples are using v6 CLI style instead of v7 however also that the documentation still refers to long gone RouterOS versions. For example the Bridge IGMP/MLD snooping part of the documentation in the IGMP snooping configuration with VLANs section refers to
a VLAN interface and configure a PIM interface on VLAN
a document that at its beginning stated as it
[a]pplies to RouterOS: v3.x, v4.x
Even the more detailed part of the documentation such as the one for Spanning Tree Protocol is taciturn compared to Cisco's one covering the same topic.

By the way even the hyperscaler focused SONiC does not do what you have proposed despite being intended to be deployed on switches using 51.2 Tb/s silicon (to put it in perspective: MikroTik's top of the line is at 0.44 Tb/s).

Posted: **Sat Jan 13, 2024 10:53 pm**

Not only for difference between versions, also in other areas the documentation is sometimes extremely lacking.
See for example "/queue simple". There is no documentation AT ALL, its manual section has only an example that uses only 1/5 of the available parameters. What the other parameters do and how the entire concept is working is not explained at all.
It does not even tell you how it is mapped to typical Linux shaping, so that you could find out in Linux documentation how it probably works.
I made a support ticket about that, nearly a year ago, but it hasn't changed the situation. It does not look like they have some employees specifically for documentation, it is likely done by the programmers who have other things to do.

Posted: **Sun Jan 14, 2024 12:10 am**

It is likely not written by developers nor network engineers. Most changes are probably from support or testing department.

MikroTik

v7.14beta [testing] is released!

v7.14beta [testing] is released!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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