RouterOS version 7.4rc1 has been released “v7 testing” channel!
Before an upgrade:
Remember to make backup/export files before an upgrade and save them on another storage device;
Make sure the device will not lose power during upgrade process;
Device has enough free storage space for all RouterOS packages to be downloaded.
What’s new in 7.4rc1 (2022-Jul-04 11:18):
*) certificate - fixed new CRL updating;
*) mqtt - fixed log flooding with disconnect messages;
*) netwatch - added support for more advanced probing;
*) ntp - added VRF support for client and server;
*) ntp - fixed manycast server support;
*) ntp - improved “debug” log level logging;
*) ovpn - added “AUTH_FAILED” control message sending;
*) radius - added VRF support for RADIUS client;
*) route - expose all valid routes to route select filter from BGP;
*) route - fixed log messages when changing routing configuration;
*) rpki - fix potential memory leak;
*) system - added “shutdown” parameter for reset-configuration (CLI only);
*) vpls - improved system stability with enabled connection tracking;
*) w60g - fixed interface “reset-configuration” on Cube 60 devices;
*) w60g - improved system stability when using mismatched L2MTU between station and AP;
*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;
*) wifiwave2 - improved WPA3 support stability;
*) winbox - added “VRF” parameter under “Tools/E-mail” menu;
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. File must be generated while router is not working as suspected or after some problem has appeared on device
Please keep this forum topic strictly related to this particular RouterOS release.
This is specific version 7.4rc1 release topic. Please keep the topic version related. If you have suggestions, questions, feedback related to the overall changelog scheme or new version release trends, please feel free to make a new topic. All non related information in this topic will be deleted and users warned/banned.
It looks like the VRF is defined globally for the NTP client, of which there can be only one instance. @vrf notation per individual server address is not accepted. Is that right?
I very much welcome the addition of VRF setting to the different local clients, but I am a bit confused about the design decisions and implementation.
E.g. in the radius client (which also receives VRF support), of which there already are multiple instances, you are supposed to know to add @vrf to the address and it is supported. There is no VRF pulldown in the client definition.
But in the NTP client there is a global VRF pulldown which sets the VRF for all servers. While in this place I would more expect the @vrf construct allowing me to set a separate VRF for each server item.
seems 7.4beta and 7.4rc1 has issue on CCR2216 and 100G modules by FS.COM
upgrading from 7.3.1 to 7.4rc1 we lost the interface because they flap continuosly, I changed the modules to anpther vendor and they workd, I reverted back to 7.3.1 and FS:COm modules worked!
‘Local’ in this case means interfaces using radios of a single routerboard. In practice, this means that fast BSS transition is supported between the 2.4GHz and 5GHz interfaces of dual band APs.
Support for fast BSS transitions between multiple boards will be added in the future.
Any device that has multiple radios and all are run off compatible wireless chip(s). One example is Audience (3 radios, 2 WiFi chips, both compatible with wifiwave2 driver; HW resources enough to run wifiwave2 driver). hAP ac3 as well (two radios, one compatible wireless chip; HW resources enough to run wifiwave2 driver). hAP ac2 is not compatible (tiny flash drive, marginal amount of RAM for all but earliest units).
The new netwatch has a name property, that is not shown on print. Is that expected?
And repeating my question from beta thread… Is there any way to use type=http-get probes to check https? Checking unencrypted http is of little use as everything is moved to encrypted https.
Also giving an url with document uri could be of great help.
this problem exists since 7.3 (last working version was 7.2.3) - i reported it already several times since weeks to mt support (SUP-85544, SUP-84244), but no reaction till now.
