That should really end up in the API docs… https://help.mikrotik.com/docs/spaces/ROS/pages/47579160/API#API-Replyword
And, there reports that it breaks the Terraform provider, since it’s Go API library isn’t expecting the !empty:
http://forum.mikrotik.com/t/router-os-7-18-beta-6-terraform-provider-v1-76-3-error-unknown-routeros-reply-word-empty/181984/1
Thanks so much, I completely missed this!
Breaking changes like these should come with bold warning signs. It’s also a typical sign that Mikrotik’s developers and managers still don’t get their business customers. Mikrotik could at least try by adding a section called ‘Breaking changes’ in the release notes. Disappointing.
MikroTik staff often argues that the importance of each changelog entry varies from person to person, so users should read the entire changelog.
In most of the software world, there is a clear distinction between breaking changes (incompatible), bug fixes, and new features. However, we have to be fair - MikroTik still uses terms like alpha, beta, and stable, which feels somewhat outdated in modern software development.
Let’s help MikriTik get better and better!
I went back to the 7.14 release topic and I see that user “jimmer” at that time posted about the same problem. But he got no reply.
The message is not issued every time, I have upgraded the router to beta6 and the message was not printed.
When you expect us to know all the time to what particular release a newly occurring problem is related, please point out the release notes line in 7.14 that is related to this new message so we could have known it is related to 7.14 and not 7.18beta!
I have suggested possible improvements to the whole changlog thing but they are ignored.
Changelog lines are too cryptic (you first have to learn a number of code words) and lack enough context and pointers to documentation.
I would think work could be saved with some more integration to internal processes and links to the documentation system.
E.g. I have been looking for the changelog line in 7.14 that is related to the “optimal nand stability” message discussed above, but I have been unable to find it… but that does not mean it is not there…
This beta behaves strange. I have a script, that checks amount of files in 3 directories and notifies me if something has changed. It works fine by itself, but sometimes, 2-3 times per day, it crashes with error “script error: invalid request”. A crash happens right after reading the file count. I’m not 100% sure, that it happens only in beta, but I wasn’t observing this earlier.
# ...
:do {
:set filesCount1 [/file print count where name~"dir1/"]
:set filesCount2 [/file print count where name~"dir2/"]
:set filesCount3 [/file print count where name~"dir3/"]
# crashes here
:if ($filesCount1 < $somevalue1) do={
# ...
}
:if ($filesCount2 < $somevalue2) do={
# ...
}
:if ($filesCount3 < $somevalue3) do={
# ...
}
# ...
:delay 10s
} while=(true)
Yes, the file handling breakage is known and acknowledged by Mikrotik. They reproduced it and are working on a fix.
I saw your issue, but wasn’t sure if it has something common with my issue. Hope, both will be fixed.
@pe1chl IMO repeating suggestions from time to time is worthwhile to demonstrate continued interest and need to MikroTik along with educating new and old forum users which may lead to community consensus formation with more voices advocating their common interests.
When will you solve the route leaking problem, or describe in normal how to bypass it? We have a leakage problem between the main array and another VRF, and it still hasn’t been fixed. It is not possible to use the microtoken normally, and support responds laconically.
Ticket: SUP-175103
Help me please
It’s nice to see the eSIM “Confirmation Code” parameter already added to the public beta. As I mentioned the new 5ber SIMS no longer works only the old ones for fun I just put my newer 5ber SIM to a windows laptop and that is picked up instantly and it was ready to provision eSIM. Any chance for supporting the the new 5ber SIM cards as well with their customAid? As the solution already available just need to adopt it.
Please add DHCPv6 /64 ia_na support. Industry standard for client router wan is /64 for ia_na wan address. I see that “address-pool” was added in v7.17, but it doesn’t accept anything other than /128 prefix length pool, which is ok for end user hosts, but it doesn’t work for ISP side of things with customer routers requiring ia_na /64 for wan, and it makes a mess with internal subnetting. ia_pd works ok, but without ia_na things tend to break. Maybe allowing /128 and /64 prefix length for address-pool so it can be also used as ia_na pool?
Thanks!!
When will you solve the route leaking problem, or describe in normal how to bypass it? We have a leakage problem between the main array and another VRF, and it still hasn’t been fixed. It is not possible to use the microtoken normally, and support responds laconically.
Ticket: SUP-175103
in which perspective?
How you topology looks like.
As per my testing:
vrf to vrf---------works
main to vrf-----works
vrf-to-main-----does not work
*) ovpn - disable hardware accelerator for GCM on Alpine CPUs (introduced in v7.17);
I’m not complaining, just asking why? 
You can read the reported problems when you look for GCM on this page https://forum.mikrotik.com/viewtopic.php?t=213941&start=300
testing on CRS317-1G-16S+ with 7.18beta6 trying to change wred-threshold on
/interface/ethernet/switch/qos/settings>
dos not make anything, it stays on medium , does not apply low or high value change
Has something happened where v7.18 broke PIM-SM? Everything is currently a blank slate but trying to run the commands
/routing/pimsm/instance add name=pimsm-instance-1
will hang forever, same obviously happens if done via WinBox.
Checked my logs and this is being spammed (Log spam persists even after a reboot)
Latest Beta is working well with R11e-LTE-US. 
from this road map,
https://help.mikrotik.com/docs/spaces/ROS/pages/28606515/Routing+Protocol+Overview
any ETA or which version 6vpe & 6PE will be implemented?
thx