bridge - synchronize only local bridge MAC addresses for MLAG (introduced in v7.22);
console - rename "cpu-used-per-cpu" to "cpe-used-per-core" in "/system/resource/monitor";
container - fixed losing container after reboot;
ethernet - fixed false excessive broadcast warning (introduced in v7.20);
firewall - improved system stability;
ipsec - fixed expired SA handling to prevent “no such item” errors during listing;
ipv6,ra - use received prefix when RA on-link flag is 0 (introduced in v7.22);
isis - improved stability with fragmented CSNP;
leds - fixed default LED configuration for CCR2004-1G-12S+2XS;
leds - fixed LED dark mode for RB5009;
lte - fixed missing automatic redial when cellular connectivity is lost for R11e-LTE;
ospf - improved stability on configuration change;
ovpn - fixed OVPN push routes;
poe-out - firmware update for 802.3at capable boards (the update will cause a brief power interruption to poe-out interfaces);
poe-out - fixed occasional detection issue when using auto-on mode;
ptp - allow manual domain configuration for 802.1AS profile;
ptp - set DSCP (EF) for the default profile when using IPv4;
route - improved service stability when removing routes;
routerboard - fixed applying settings via WinBox on devices with fixed CPU frequency;
system - added FCC Part 15 Compliance label to "System/Regulatory" menu;
system - improved stability for internal RouterOS service communication;
system - improved system stability;
system - included full certificate chain to Windows executables;
usb - fixed crash when using Ethernet adapter (introduced in v7.22);
vrrp - fixed packet drop in CHR (introduced in v7.22);
wifi - improved authentication stability for WiFi 7 access points;
wifi-mediatek - fixed communication issues on 802.11ax access points with Intel clients;
wifi-mediatek - fixed HE capabilities IE on 2GHz band;
wifi-qcom-be - fixed forwarding of 4-address data from station to station;
winbox - added option to configure built-in trust store for all services;
www - improved service stability when cancelling REST API sessions;
To upgrade, click Check For Updates under System/Packages menu and select the stable Channel in RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download
Everything went smoothly
I encountered an issue after the update (please post about the device, configuration, and unexpected symptoms)
I encountered an issue, but solved it (please post the solution)
0voters
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.
hAP ax^3
After upgrading to version 7.22.2, I noticed a significant increase in CPU usage, specifically in the routing process, when receiving IPv6 FullView routes from two uplinks. This behavior was not observed in version 7.22.1.
I do hope this is just test equipment. Upgrading to a new release in production should be done:
If testing
If needed
After some weeks
After reading the forum
I appreciate the concern, but I like to live on the edge. I don't have dedicated lab equipment for testing, and frankly, the current changelog doesn't show any disruptive changes that justify a long wait. Besides, if things go south, a rollback is always an option. High risk, high reward and fast updates.
Technical Report: Connectivity issue after upgrade to RouterOS v7.22.2
Environment:
Main Router: CCR1009-8G-1S upgraded to v7.22.2 (stable).
Station: RB411AH running v6.49.19.
Configuration: Static IP setup on the same subnet (192.168.28.0/24). The RB411AH uses a PPTP tunnel for specific routing.
The Problem:
Following the upgrade of the CCR1009 to v7.22.2, the RB411AH experienced a total loss of internet connectivity.
Diagnostic Facts:
Layer 2 connectivity: arping from RB411AH to the Gateway (CCR1009) was successful. The MAC address was resolved correctly.
Firewall Conflict: The RB411AH had a long-standing firewall rule:
/ip firewall filter add action=drop chain=input protocol=icmp.
The Trigger: With this rule enabled, the RB411AH could not ping its Gateway and lost all internet access.
The Resolution: Disabling this specific ICMP drop rule immediately restored the ping to the Gateway and restored internet functionality.
Observations:
Although both routers previously ran on their respective major versions (v7 and v6) without this issue, the v7.22.2 release introduced a change that makes the internet connectivity on the v6 device dependent on unblocked ICMP communication with the Gateway. Blocking ICMP on the v6 side now results in a complete routing failure, which was not the case in previous v7.x releases.
While the question remains om how it worked before: If I'm not missing something, dropping incoming ICMP causing ping based connectivity checks to fail is not surprising.
In general, and despite popular believe, blocking incoming ICMP does not improve security. But might interfere with path MTU discovery and suppress important ICMP router error messages like "host/network not reachable" and similar. ICMP is much more than just ping.
Sometimes I had "Cybersecurity Experts" with there wonder-tools flagging hosts responding to ping request as red. And because not having red entries in their wonder-tools is all they know about security, I ended the discussions by blocking only incoming ICMP echo requests and letting the rest pass. This make the wonder-tool and the "expert" happy, but keeps important ICMP functionality working.
