We found a bug in recent RouterOS versions (> 6.38) where sometimes disabled objects are not found by Winbox or Scripts.
As you can see in the attached print, sometimes when you try to enable a disabled tunnel you get a “object doesn’t exist” message. After two or three attemps it’s successfully enabled.
The same happens on scripts. But the message is slight different (no such item(4)). Again, we had to put a retry logic on theses steps in order to avoid these errors.
Hi, I’ve experienced the same issue after update to 6.42.6 from 6.40.4. It seems I’ve found a way to get rid of that bug.
What did I do:
disabled and renamed ppp interace in question
created the new one with exactly the same config and original name
got a current config in text (export file=test)
carefully searched for all references to renamed interface inside text config (by means of find) and replaced corresponding configuration items
to new interface with original name in winbox. That includes filter, nat, routing, led and traffic flow settings for me.
enabled new interface and removed renamed one.
Not that much time passed since I do that, but for now I’ve never seen that problem again.
Those are dynamic interfaces, IDs will change on reconnect, if your script tries to edit interface that is at the same time reconnected you will get an error that item does not exist.
Hello.
Thanks for the answer.
I tried to edit interfaces at the time when they run and not using scripts.
Could you please clarify is this bug or not?
[admin@MikroTik-Aggregator] /routing ospf interface> /interface print
Flags: D - dynamic, X - disabled, R - running, S - slave
0 D 10 1 point-to-point none
1 DP Loopback-Backbone 10 1 broadcast none
2 D 10 1 point-to-point none
[admin@MikroTik-Aggregator] > /routing ospf interface set cost=100 0
no such item (4)
[admin@MikroTik-Aggregator] > /routing ospf interface set cost=100 1
no such item (4)
[admin@MikroTik-Aggregator] > /routing ospf interface set cost=100 2
no such item (4)
[admin@MikroTik-Aggregator] > /routing ospf interface print
Flags: X - disabled, I - inactive, D - dynamic, P - passive
I’ve repeatedly seen cases where order of parameters did matter, so the ID had to follow the set immediately, although in most cases it is identified by context.
So try the following:
/routing ospf interface set 0 cost=100
/routing ospf interface set 1 cost=100
/routing ospf interface set 2 cost=100
Another point is that if the list changes in the meantime between print and issuing the command, the “user IDs” assigned to the internal references by the print lose validity (this is best visible with the /ip firewall connection elements)