You've reported it, they'll very likely fix it in the next minor version or so.
There's finally an LTS channel for v7, use that if you need stability. Mikrotik's "Stable" is stable enough for many home purposes.
When managing such a huge project like RouterOS and continuously improving and adding features... it's definitely gonna have such stupid mistakes and slip throughs like this. I wouldn't bother criticizing the stable channel, but I'd be somewhat pissed if LTS was affected by such mistakes.
And ofc, if you had RC installed, you could have experienced the issue and reported it before it reached Stable. I know it's not your job, but such a project is heavily dependent on user feedback.
I totally agree with this, i personally don't use wireguard, simply don't have a use for it, but if something like that made it into LTS then we would have problems and issues, because if it made its way into a production setting for something like a big company, then they start to not like mikrotik a whole lot
It was reported in rc phase, but they just scoffed at it stating that it is a known issue (not a typical response for support ticket) - and then knowingly released "stable" without fixing it.
P. S. By knowing how much they do with the amount of people they have it is not that surprising actually.
Just read this thread and you see why you should wait with upgrade, but then if all wait, how should we find the bugs. Wireguard and = in scropt fails. But not for all.
user is aware that initial release into stable (e.g. 7.24 ... as in 7.24.0) might be a bit less stable than the name implies ... so user knows there are risks and he is willing to take them. If anything fails, he opens a ticket with MT support ... and optionally user informs us via this forum about the problems he encountered
user expects any stable release to be stable. When user installs such version on his gear and encounters problems, he comes here and complains loudly ... with focus being on grief about that particular stable version being not so stable after all.
And I'd say that the wisdom about not going for initial stable releases is targeting users from group #2 above ... we definitely want to have users in group #1 above (as many as possible) so that any pending issues get reported (and hopefully fixed) as soon as possible ... but we don't want to see each release topic filled with complaints (instead of reports) about broken things (and definitely not complaints about unfixed regressions which are not even mentioned in release notes).
since some releases ago we started to get the message about HW Table Full (CCR2216) but we have several bank completely free. It is about ipv6 hwl3 because if we disable it the massage goeas away. Also not in all condition we get the message, in fact several other rotuers doesn't have this issue, with a slightly different hwl3 configuration based on prefixes AS origini (support ticket opened SUP-222053) :
Yeah feels like they're investing too much into the bells and whistles, it's not like that can be used on 16 MB devices anyway. Focusing on container, which is a good feature, and let the users run their own compartmentalized app is the way to go
If you have scheduled/long-running scripts that do a lots of output and experience strange crashes, reboots or high memory usage in RouterOS 7.24/7.24.1, this comment might be interesting for you:
