At least try a netinstall and refrain from trying to do advanced things on the router when you also use the wifi.
This is the single most problematic device released by MikroTik, w.r.t. flash space. It can be a home NAT router or WiFi bridge, but not much else.
As an unsuspecting and new user who just bought a hAP ax S, I read the manual carefully. It clearly says:
We recommend clicking the "Check for updates" button and updating your RouterOS software to the latest version to ensure the best performance and stability.
By upgrading your RouterOS software to the latest version, you can ensure optimal performance
If I followed this official recommendation and then discovered that WebFig no longer works properly after the update, I would feel quite misled.
I would expect that a recommended update from the manufacturer - already available for weeks - should not break basic functionality.
will there be version 7.20.5, or will 7.21 be the next stable release?
Only Mikrotik knows…
I think he doesn't know either. . .
Maybe LTS version(s) could be a solution where the focus is on stability not features.
RouterOS v7 does not yet have a long-term release. Please use Stable release channel instead
… and live with the fact that the webfig no longer works in the stable channel… for 3 weeks, already.
just downgrade to .2
Hi!
OpenVPN still doesn't work on firmware version 7.20.4 (and 7.21beta11).
I ran some tests and discovered that the problem occurs when I initiate push routes from the OpenVPN server (Linux) to the client, and the OpenVPN client simply freezes during the connection process.
If I disable push routes on the OpenVPN server (Linux), the connection succeeds. Therefore, all routes must be entered manually.
When I check the box:
Don't pull routes, it doesn't affect the freeze.
Only the error appears in the log:
warning - received OVPN option length exceeds limit
Perhaps this will give the developers some insight.
I created a support ticket #[SUP-200620] - 2025/10/03
This was the issue on some older OpenVPN versions on Windows with improper line ending handling, it did not recognised LF line ending as sent from Linux but only CR/LF pair...
Version 7.20.5 has been released:
But everything worked up to and including ROS 7.19.
Are you suggesting I need to change LF to CR/LF in the routes file?
You cannot change how Linux OpenVPN server sends push "route a.b.c.d x.y.z...", it will always send the string delimited in the same way regardless of white space in ccd file.
The issue is probably how MT own implementation (they are not using the standard one as far as I know) decodes the pulled string, there could be an issue in delimiter interpretation or the receive buffer is too short with delimiter cut of, anyways it looks mostly as they have changed something that introduced this bug.