Has :resolve 'failure' been fixed yet?

RouterOS Scripting
1

Hi folks,

I’m writing a script that needs to work with situations where :resolve is allowed to fail. However, all my tik’s are at ROS v3.23 and a failed :resolve kills the script (this is a known issue). I’m also unable to redirect my DNS resolution to OpenDNS (which seems to be the preferred work-around) due to corporate policy.

There have been two releases of ROS since my last update and even though the Changelog doesn’t mention it, I was wondering if it had been fixed ‘in passing’? Unfortunately, I am unable to check this myself as all my tik’s are in production environments and unless I can indicate that this has been fixed (even obliquely) I’m not able to upgrade the existing tik’s. :frowning:

TIA.

– Bosco

2

i doubt anyone opened a ticket to get it resolved - you should open a bug report. in the meantime, maybe you can use a second script that only resolves something, sets a variable and exits.

3

Ah! OK. Is there a bug reporting site? Our tik’s are out of the 30-day support period so unless they accept bug reports without a support contract, I’m SOL. :frowning:

… in the meantime, maybe you can use a second script that only resolves something, sets a variable and exits.

I’ll try that. I assume the ‘failure’ only terminates the called script and not the calling script? I guess I’ll find out. :wink:

Thx.

– Bosco

4

It’s as I feared, the ‘failure’ is bubbling up to the caller like an unhandled exception (and I tried two levels of indirect calling).

I set up the following script:

/system script add name=xresolve \
    source=":global xresName ; :global xresIP \"bad\" ; :set xresIP [:resolve \$xresName]"

And simply using that via ‘run’ caused a failure in the script that called it, no matter how far removed it was:

:global xresName name.to.resolve
:local xxx [/system script run xresolve]
failure

I was able to do something using ‘:execute’ that really stinks but gets around the exception problem. The main issue with this approach is that it essentially runs the ‘:resolve’ asynchronously, so you need to put in an unconditional delay so that the ‘:resolve’ command gets a chance to run. :frowning:

:global xresName name.to.resolve
:execute xresolve
:delay 1s
:if ($xresIP = "bad") do={ :put "Resolve failed!"; } else={ :put "Resolved to: $xresIP"; }

The major problem with this approach is that if the resolution takes too long you’ll get a false negative. And if you make the delay too long it becomes untenable.

This is not a very good solution, IMO. :frowning:

Any idea where I can log that bug report?

–Bosco

5

send to support@mikrotik.com… bug reports always welcome, just include your version, platform, and some good details about it.

6

So…The response from Mikrotik support condenses down to:

  1. It’s a known problem
  2. No plans to fix it in ROS 3.x
  3. It’s on the ToDo list for ROS 4.x

How unfortunate. :frowning:

– Bosco