Errors are returned since RouterOS 7.21beta2.
We keep the current logic for now, as we want to support older
RouterOS versions. This is something to be reworked later...
This branch is a follow-up on 9ceed0926a
with clean solution. Read on for details...
The data type `ip6-prefix` used to hold what it was named for - an IPv6
prefix:
[user@mikrotik] > :put 2001:db8::dead:beef/32
2001:db8::/32
This changed with RouterOS 6.21beta2, which now allows that exact same
data type to hold something like "address with prefix length attached":
[user@mikrotik] > :put 2001:db8::dead:beef/32
2001:db8::dead:beef/32
My scripts (namely `fw-addr-lists`) relied on the old behaviour and broke.
The commit mentioned above was just a quick workaround, with rough edges,
and it could still fail.
Sadly RouterOS does not support bit shifting on IPv6 data types, so a
(completely) mathematical solution is out of scope.
This branch implements a new and better workaround, see the first commit
of branch (6ad6f9aa08) for details.
I opened a support ticket / feature request on this topic, let's see
what results it brings...
https://help.mikrotik.com/servicedesk/servicedesk/customer/portal/1/SUP-201881
The calculation is quite complex for something that needs to be done
frequently, for example by `fw-addr-lists`. The number of possible
netmasks is limited, so let's cache the results that were calculated
already.
RouterOS does not support bit shifting on IPv6 data types, so we have to
split the problem:
* each 16 bit block is calculated separately, as number
* the complete netmask is assembled in a loop, as string
* the final string is casted to correct data type
Chances are that messages have been queued before system was fully up or
connected. Thus the certificate may be missing, and it should be checked
again for on flush.
This should reduce the number of addresses in list by aggregating them,
and also fix addresses with host part set (like 2001:470:1:fb5::2a0/64,
which should be 2001:470:1:fb5::/64 really).
The latter caused new warnings with RouterOS 7.21beta2.
With RouterOS 7.21beta2 the user SSH keys "key-owner" field was
renamed to "info".
Either of both is displayed in red by syntax highlighting, but it
works anyway.
This is not a proof, but a line also ending with a curly bracket
has higher probability of being valid JSON.
Better safe than sorry... We are suffering a CVE in RouterOS:
https://www.cve.org/CVERecord?id=CVE-2025-10948
