container - improve host isolation when container is set to "privileged=yes";
l3hw - fix stability issue on IPv6 offload enable;
l3hw - fix VRF offload on bond interface remove;
leds - fix "interface-status" trigger;
snmp - properly validate password length when applying configuration;
ssh - refactor SSH service internal processes;
switch - fix possible Rx traffic stall on CPU for devices with Marvell Prestera switch chip;
switch - fix stability issue during L2 loop for 98DX224S, 98DX226S, 98DX2528, and 98DX3236 switch chips;
switch - fix stability issue on RB3011 (introduced in v7.22);
system - improve handling of invalid SSL/TLS requests;
wifi - fix stability issue for hAP be lite;
wireguard - fix peer disable/enable state handling, which could leave the tunnel non-functional (introduced in v7.24);
wireguard - fix private key handling, including empty private keys;
www - improve service responsiveness when receiving malformed packets;
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.
It's a valid concern. I know of at least one heap buffer overflow (attacker controlled) that was never disclosed as CVE and simply brushed under with "improved system stability" :> Wouldn't be surprised if they're doing it to other researchers too.
Every single topic and CVE conspiracy theory starts up again,
and then the same complaints start up again, cyclically, about how poorly written the "improved system stability" changelogs are.
What a drag!
Then, if there's a new issue reported, no one understands anything,
and probably not even the staff understands anything when they read it, getting lost in the off-topic posts.
Normally I would agree and ask everyone to take off their tinfoil hat but based on how the market with CVE looks and what is happening + how MT has tried to brush these things under the carpet before or handled critical CVE's I do not trust this. Will it help that chat to reittirate this? No it will not but in the end we as customers should have this information to see how we are affected and I feel like we are not getting the full picutre based on current market.
Also to be fair I feel like this is true to a lot of companies now that are trying to keep up with AI and code review.
I have an ax3 as main router, an ax2 as CAP, and 2 remote ac2 connected through wireguard sts and eoip tunnels.
I am more than 600 kilometers away from home, in my parents house, where I have one of these remote ac2.
Connected through RoMon to my main ax3, updated from 7.23.3 to 7.24.1, and after the connection lost due to reboot, I have no connection with it again.
I tried to connect using BTH in my phone but no response.
I updated to the v7.24.1 and have run into an issue with an automated backup script that was working flawlessly right before the upgrade v7.23.3. The script is designed to export the configuration, upload it via SFTP, and trigger a remote Git commit via SSH.
Since the update, the script systematically fails at the /tool fetch SFTP step.
Device & Software Details:
Device: RB3011UiAS-RM
RouterOS Version: v7.24.1
In the terminal / log output, I am receiving the following errors:
fetch, info Upload to 192.168.10.53 FAILED: authentication failure (6)
script error File upload failed. Check SFTP credentials, connectivity, and directory permissions.
The credentials on the destination have not been modified.
The Full Script Code:
# Configuration parameters - these can be modified as needed
:local sftpAddr "192.168.xx.xx"
:local sftpUser "xxxx"
:local sftpDirectory "/home/xxxx/mikrotik-config-backup"
:local sftpPort "22"
:local deviceName [/system identity get name]
:local config ("config_" . $deviceName)
:log info "Starting configuration backup to Git repository"
:log info "Exporting full configuration"
:do {
/export file=$config show-sensitive
:log info "Configuration exported successfully"
} on-error={
:log error "Configuration export failed"
}
# Check if the exported file exists before proceeding
:if ([/file find name=($config . ".rsc")] != "") do={
:local sftpUrl ("sftp://" . $sftpAddr . ":" . $sftpPort . $sftpDirectory . "/")
:do {
:log info "Uploading configuration to $sftpUrl"
# Upload the configuration file using SFTP
/tool fetch url=($sftpUrl . "configs/" . $config . ".rsc") \
src-path=($config . ".rsc") \
user=$sftpUser \
upload=yes
:log info "Configuration file uploaded successfully"
# Remove the local config file after successful upload
/file remove ($config . ".rsc")
:log info "Local configuration file removed"
# Perform Git operations on the remote server via SSH
:do {
:log info "Executing Git operations on remote repository"
:local gitCommand ("cd " . $sftpDirectory . "; git pull; git add configs/" . $config . ".rsc; ./ai-tools/git-commit.sh; git push")
/system ssh-exec address=$sftpAddr user=$sftpUser command=$gitCommand
:log info "Git operations completed successfully"
} on-error={
:log error "Git operations failed. Check SSH connectivity and Git repository configuration."
}
} on-error={
:log error "File upload failed. Check SFTP credentials, connectivity, and directory permissions."
}
} else={
:log error "Configuration export file not found, skipping upload and Git operations"
}
:log info "Configuration backup process completed"
Has anyone else noticed issues with /tool fetch upload=yes via SFTP or general SSH key handling changes in this specific build? Any troubleshooting pointers or syntax corrections would be greatly appreciated.
Small WebFig display bug on 7.24.1, RB5009. I have not checked whether 7.24 does the same.
Under IPv6 > Addresses the Valid and Preferred columns show the router uptime rather than the address lifetimes. Same value on every row, ticking up in real time, identical for an address created seconds earlier and for fe80:: link-locals.
WinBox 4.3 reads forever on those same entries on the same router at the same moment, which is what the 7.24 changelog entry describes, so the data itself is fine and it is only the WebFig rendering. The fields are not exposed in the CLI at all, /ipv6/address/get returns just a boolean deprecated.