DHCP-Client script broken or restricted?

schirmherr · Sat Dec 15, 2018 3:47 pm

Hi all

I just bought two MikroTik devices (HAP AC2) to replace my old Asus router. To complete the transition I need to update a DynDNS Server. While reading the documentation I saw the new feature of the dhcp-client lease script. It seems that this would be a better alternative than using one of the many existing dyndns-scripts which use the scheduler for polling.

The script with lots of debug log messages looks like this:

# DynDns afraid.org 
:log info ("UpdateDynDNS: start");
:local UpdateUrl "https://sync.afraid.org/u/xxxxxxxxxxxxxx/";
:log info ("UpdateDynDNS: afterVariable");
:local DynDnsResult [/tool fetch mode=https url="$UpdateUrl" as-value output=user];
:log info ("UpdateDynDNS: afterFetch");
:local ResultData ($DynDnsResult->"data");
:log info ("UpdateDynDNS: $ResultData");
:log info ("UpdateDynDNS: end");

The script works perfectly fine in the console. It also works perfectly fine fine, when I put this code into a script and run the script manually.
But when I put this code into the script part of the dhcp-client it just stops after the line :log info ("UpdateDynDNS: afterVariable"); without any error message. Even when I try to run the script from the dhcp-client indirectly using "/system script run dyndns" it just stops before the fetch.

Is there a known limitation of using fetch in the dhcp-client script? Or is there something wrong with my script? I couldn't find any information on this topic.

Thank you for your help

miked315 · Thu Dec 20, 2018 2:32 am

I'm seeing exactly the same thing, I've been losing my mind trying to get a dhcp client script to update namecheap ddns for me. I'm on a hap ac2 running 6.43.7 and no matter what I do, the script on the dhcp-client fails to execute the fetch. I'm new to mikrotik so I'm at a loss how to debug it any further. Finally I created a standalone script and executed it, and sure enough it worked just fine.

I see numerous other posts about using dhcp client scripts to update ddns using the fetch tool, so it seems to me that this is a bug that has been introduced in 6.43.7 or somewhere around there.

miked315 · Sat Dec 22, 2018 1:10 am

Just tested on 6.43.8 and it's still broken

schirmherr · Sun Dec 23, 2018 1:24 am

Thank you, then it's not just me. I tried it with 6.43.7 and upgraded to 6.43.8. The problem still persists. I will report it to MikroTik.

miked315 · Sun Dec 23, 2018 1:49 am

I know the script itself runs, because it's setup to write some output to the log, it's just executing the fetch tool that does not seem to happen. I played with every permutation of passing the URL to it thinking somehow the ? in the URL wasn't passing or things like that, but then I simplified it down to just retrieving any old URL and outputting to a file and that didn't happen either. The only thing I didn't try was trying to execute a different /tool command to rule out if it's specific to fetch or no tools at all can be executed via the dhcp client script.

schirmherr · Thu Jan 10, 2019 11:37 pm

OK, MikroTik support was friendly but in the end I found the problem myself. The first problem is that the script runs twice when releasing the IP address. You therefore have to make sure that the IP address is bound by checking for $bound=1. The second problem is that the dhcp-client lease script runs when it gets the new IP address but before the system was able to add the new route. That's why the fetch command fails. To prevent this you have to add a delay before the fetch command. 3 seconds was enough for my device. My script now looks like this:

# DynDns afraid.org
:local UpdateUrl "https://sync.afraid.org/u/xxxxxxxxxxxxxxxxxxxxxxxx/";
:log debug ("UpdateDynDNS: start dynDNS script");
:if ($bound=1)  do={
    :log debug ("UpdateDynDNS: bound new IP address");
    #without delay the script fails because of the missing route
    :delay 3s;
    :log debug ("UpdateDynDNS: after delay");
    :do {
        :local DynDnsResult [/tool fetch mode=https url="$UpdateUrl" as-value output=user];
        :log info ("UpdateDynDNS: update of dynDNS completed");
        :local ResultData ($DynDnsResult->"data");
        :log info ("UpdateDynDNS: $ResultData");
    } on-error={
        :log warning ("UpdateDynDNS: fetch Failed");
    }
} else={
    :log debug ("UpdateDynDNS: IP address not bound");
}
:log debug ("UpdateDynDNS: end dynDNS script");

I have to tweak it a bit more but at least it works like this.

miked315 · Fri Jan 11, 2019 5:30 am

Looks like adding the delay of 3s to mine works as well, I guess I should have thought that could be the case but all of the examples I've seen don't use the delay at all so I'm wondering how they worked for others. Maybe other routers behave differently, or on older versions of firmware it worked without the delay. Oh well, thanks for posting this follow up that was extremely helpful.

DHCP-Client script broken or restricted?

DHCP-Client script broken or restricted?

Re: DHCP-Client script broken or restricted?

Re: DHCP-Client script broken or restricted?

Re: DHCP-Client script broken or restricted?

Re: DHCP-Client script broken or restricted?

Re: DHCP-Client script broken or restricted?

Re: DHCP-Client script broken or restricted?

Who is online