Community discussions

MikroTik App
 
ditonet
Forum Veteran
Forum Veteran
Topic Author
Posts: 835
Joined: Mon Oct 19, 2009 12:52 am
Location: Europe/Poland/Konstancin-Jeziorna
Contact:

Possible bug with global variables

Sun Dec 04, 2011 11:19 pm

Hi,

One of my customers got an ADSL line with dynamic IP address.
A script for DynDNS update is scheduled every 15 min and works fine:
# Set needed variables
:local username "user"
:local password "pass"
:local hostname "myhost.dyndns.info"

:global dyndnsForce
:global previousIP

# print some debug info
# :log info ("dyndns-update: username = $username")
# :log info ("dyndns-update: password = $password")
:log info ("dyndns-update: hostname = $hostname")
:log info ("dyndns-update: previousIP = $previousIP")

# get the current IP address from the internet (in case of double-nat)
/tool fetch mode=http address="checkip.dyndns.org" src-path="/" dst-path="/dyndns.checkip.html"
:local result [/file get dyndns.checkip.html contents]

# parse the current IP result
:local resultLen [:len $result]
:local startLoc [:find $result ": " -1]
:set startLoc ($startLoc + 2)
:local endLoc [:find $result "</body>" -1]
:local currentIP [:pick $result $startLoc $endLoc]
:log info "dyndns-update: currentIP = $currentIP"

# Determine if dyndns update is needed
# more dyndns updater request details available at http://www.dyndns.com/developers/specs/syntax.html
:if (($currentIP != $previousIP) || ($dyndnsForce = true)) do={
    :set dyndnsForce false
    :set previousIP $currentIP
    /tool fetch user=$username password=$password mode=http address="members.dyndns.org" src-path="/nic/update?hostname=$hostname&myip=$currentIP" dst-path="/dyndns.txt"
    :local result [/file get dyndns.txt contents]
    :log info ("dyndns-update: Dyndns update needed")
    :log info ("dyndns-update: Dyndns Update Result: ".$result)
} else={
    :log info ("dyndns-update: No dyndns update needed")
}
There is also 'netwatch' set for quick DNS update after ADSL reconnection:
/tool netwatch
add disabled=no down-script="led user-led=no\r\
    \n:log info \"Host 208.67.220.220 unreachable\"\r\
    \n" host=208.67.222.222 interval=1m timeout=1s up-script="led user-led=yes\r\
    \n/system script run dyndns-update\r\
    \n:log info \"Host 208.67.220.220 reachable\"\r\
    \n\r\"
The problem is when the same 'dyndns-update' script is called from 'netwatch' tools,
global variable 'previousIP' seems to be empty instead of containing IP address string.
Below is a log:
21:45:00 script,info dyndns-update: hostname = myhost.dyndns.info 
21:45:00 script,info dyndns-update: previousIP = 183.26.221.45 
21:45:01 info fetch: file "dyndns.checkip.html" created 
21:45:01 script,info dyndns-update: currentIP = 183.26.221.45 
21:45:01 script,info dyndns-update: No dyndns update needed 
21:54:11 system,info netwatch host modified by admin 
21:54:11 script,info dyndns-update: hostname = myhost.dyndns.info 
21:54:11 script,info dyndns-update: previousIP =  
21:54:11 info fetch: file "dyndns.checkip.html" created 
21:54:12 script,info dyndns-update: currentIP = 183.26.221.45 
21:54:13 info fetch: file "dyndns.txt" created 
21:54:13 script,info dyndns-update: Dyndns update needed 
21:54:13 script,info dyndns-update: Dyndns Update Result: nochg 183.26.221.45 
21:54:13 script,info Host 208.67.220.220 reachable 
RB750, ROS 5.8
Does anyone noticed similar problem with global variables?
Or am I doing something wrong?

TIA,
 
fewi
Forum Guru
Forum Guru
Posts: 7717
Joined: Tue Aug 11, 2009 3:19 am

Re: Possible bug with global variables

Mon Dec 05, 2011 12:40 am

I don't know if this might be related:
http://forum.mikrotik.com/viewtopic.php ... l+variable

Netwatch executes the script, so it might run with different owner permissions and have the same scoping issue.

As a workaround maybe write the global variable value into a file in the scheduled task script, and have a second version that Netwatch runs that slurps that in?
 
ditonet
Forum Veteran
Forum Veteran
Topic Author
Posts: 835
Joined: Mon Oct 19, 2009 12:52 am
Location: Europe/Poland/Konstancin-Jeziorna
Contact:

Re: Possible bug with global variables

Mon Dec 05, 2011 2:02 am

Thanks fewi,

I missed topic mentioned by You, probably because it was during summer/holidays time.
It's not good that global variable is not 'global' as in every programming/scripting language :(
Storing variables in files is a painful task, and this also writes NAND too frequently, RAM is a better place for variables.
According to mrz response from mentioned topic:
Owner of the script executed from scheduler is "sys" so it is not possible to access varaibles defined in terminal by for example "admin"
I'm courious who, if not 'sys', is owner of the script executed from 'netwatch'?
Netwatch runs even if no one is logged to router, so IMHO is similar to system scheduler.
 
fewi
Forum Guru
Forum Guru
Posts: 7717
Joined: Tue Aug 11, 2009 3:19 am

Re: Possible bug with global variables

Mon Dec 05, 2011 2:51 am

Maybe write to support to clarify and post the results back here. I'm curious about it, too, and would be interested to know.
 
psamsig
Member Candidate
Member Candidate
Posts: 161
Joined: Sun Dec 06, 2009 1:36 pm
Location: Denmark

Re: Possible bug with global variables

Mon Dec 05, 2011 8:39 am

I have had the same problem, I solved it by moving the up-/down-script lines to two named scripts and call them instead:
/tool netwatch
add comment="" disabled=no down-script="Netwatch VPN down" host=10.0.11.1 interval=1m timeout=1s up-script=\
    "Netwatch VPN up"
 
ditonet
Forum Veteran
Forum Veteran
Topic Author
Posts: 835
Joined: Mon Oct 19, 2009 12:52 am
Location: Europe/Poland/Konstancin-Jeziorna
Contact:

Re: Possible bug with global variables

Mon Dec 05, 2011 10:15 am

@psamsig

Thanks for info, but this workaround isn't solution in my case.
My script is called from different places, scheduler and netwatch.

Regards,
 
psamsig
Member Candidate
Member Candidate
Posts: 161
Joined: Sun Dec 06, 2009 1:36 pm
Location: Denmark

Re: Possible bug with global variables

Mon Dec 05, 2011 10:52 am

My script is called from different places, scheduler and netwatch.
And all you have to do is make a script that contains all you otherwise would have in NetWatch and call that sctipt instead.
but this workaround isn't solution in my case.
Did you try?
 
ditonet
Forum Veteran
Forum Veteran
Topic Author
Posts: 835
Joined: Mon Oct 19, 2009 12:52 am
Location: Europe/Poland/Konstancin-Jeziorna
Contact:

Re: Possible bug with global variables

Mon Dec 05, 2011 11:19 am

OK, I know that I can define two scripts which does the same task.
But it is always workaround, because global variable is not 'global'.
I reported this to MT support and have opened ticket for this bug/problem.

Regards,
 
ditonet
Forum Veteran
Forum Veteran
Topic Author
Posts: 835
Joined: Mon Oct 19, 2009 12:52 am
Location: Europe/Poland/Konstancin-Jeziorna
Contact:

Re: Possible bug with global variables

Mon Dec 05, 2011 2:15 pm

Here is an official response from MT support:
Hello,

netwatch and schedulers are executed by "sys" user, and global variables should be
accessible by both netwatch and scheduler. We will fix this problem in future
versions.

Regards,
Maris
We all must wait for fix.

Regards,
 
Antz
just joined
Posts: 10
Joined: Tue Aug 18, 2009 10:31 am

Re: Possible bug with global variables

Mon Aug 13, 2012 3:42 pm

Is anyone able to confirm that this issue is resolved? I'm having the same issue on ROS v5.16
I have also tried having the Netwatch call a script which updates the global variable but it fails to do so (no error, but no update either).
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7216
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Possible bug with global variables

Mon Aug 13, 2012 3:50 pm

Problem is not yet fixed. I would suggest to do a workaround by writing to file for now or instead of netwatch use scheduled ping script which does exactly the same but executed from correct user.
 
Antz
just joined
Posts: 10
Joined: Tue Aug 18, 2009 10:31 am

Re: Possible bug with global variables

Mon Aug 13, 2012 4:03 pm

Thank you for your speedy reply mrz. I will move to using a schedules script in place of the Netwatch as you suggest. This does however render the Netwatch tool useless in general for launching any scripts which are interdependent on the results of other scripts. Is there any indication of which version of ROS this will be fixed in?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7216
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Possible bug with global variables

Mon Aug 13, 2012 4:07 pm

Depends on priorities. Most likely in v6
 
thantoldo
just joined
Posts: 22
Joined: Tue Apr 10, 2012 10:08 pm

Re: Possible bug with global variables

Thu May 16, 2013 2:31 pm

Same netwatch problem happens when global variables are accessed via hotspot userprofile onlogin and onlogout scripts (actual scripts there or external scripts). Tested at version 5 and 6.

Any news?
 
jarda
Forum Guru
Forum Guru
Posts: 7756
Joined: Mon Oct 22, 2012 4:46 pm

Re: Possible bug with global variables

Thu Sep 25, 2014 7:19 pm

Hi, seems this error still persist even in 6.18. Yes I know that 6.19 is the latest these days... Anyway, where on to-do list is the solution of the sharing of "global" variables between the scripts and netwatches?
Will be there any really global variables usable without any restrictions?
 
User avatar
otgooneo
Trainer
Trainer
Posts: 589
Joined: Tue Dec 01, 2009 3:24 am
Location: Mongolia
Contact:

Re: Possible bug with global variables

Wed Jun 07, 2017 7:52 am

This problem still exist in v6.38.5 :-(
 
jarda
Forum Guru
Forum Guru
Posts: 7756
Joined: Mon Oct 22, 2012 4:46 pm

Re: Possible bug with global variables

Wed Jun 07, 2017 8:52 am

Have you tried to run all the scripts with the same user and with the corresponding rights?
 
User avatar
otgooneo
Trainer
Trainer
Posts: 589
Joined: Tue Dec 01, 2009 3:24 am
Location: Mongolia
Contact:

Re: Possible bug with global variables

Mon Jun 19, 2017 5:56 pm

Have you tried to run all the scripts with the same user and with the corresponding rights?
Yes. Tried with several options using full admin user on both scripting, scheduler. All same. No success. Instead of global variable, I use DNS record. Somehow works :-)
 
crsenrico
just joined
Posts: 8
Joined: Wed Oct 05, 2016 1:37 pm

Re: Possible bug with global variables

Fri Jun 23, 2017 10:25 am

just re-declare the variable without initializing it.

script1
:global previousIP "1.2.3.4"
:put $previousIP
will display 1.2.3.4

script2
:global previousIP
:put $previousIP
will display 1.2.3.4
 
User avatar
rushlife
Member Candidate
Member Candidate
Posts: 254
Joined: Thu Nov 05, 2015 12:30 pm

Re: Possible bug with global variables

Thu Aug 31, 2017 9:01 am

hi guys
I also have some problem with global variable.
I have already two script, one reading "default routes" (given by dhcp server) and these IP addressis storing as global variable. One for each WAN interface ( I have two wans ).
But when i run another script, which need these variables (ip addresses) for editing existing routes, these global variables (saved, It is also visible in / system script environment) cant be used.
Script do not "see" see these variables. It is there somoe solution ? I am using "stable" 6.38.5, rb2011.

Now I am solving these problems with global variables with "all-in-one" type of scripts, where everithing what i needed is whole in one script, so I can "see" global and local variables without any problem..

Thanks guys.
 
User avatar
strods
MikroTik Support
MikroTik Support
Posts: 1698
Joined: Wed Jul 16, 2014 7:22 am
Location: Riga, Latvia

Re: Possible bug with global variables

Thu Aug 31, 2017 9:36 am

It does not matter that variable is global until you do not define it in another facility in which you want to use it. There is no need to specify value - just define variable.
Here is an example:
viewtopic.php?f=9&t=125044#p615767
 
User avatar
otgooneo
Trainer
Trainer
Posts: 589
Joined: Tue Dec 01, 2009 3:24 am
Location: Mongolia
Contact:

Re: Possible bug with global variables

Mon Oct 16, 2017 1:48 pm

Hi strods. This is not an option when we have many separate scripts that need to call one scrip another. This is useful when scripts has different time stamps need to run. So only the way is to make Global variable as real Global, which is possible to use between separate scripts. Please consider real life cases! Please listen your customers!
 
gotsprings
Forum Guru
Forum Guru
Posts: 2343
Joined: Mon May 14, 2012 9:30 pm

Re: Possible bug with global variables

Sat Jul 14, 2018 3:23 pm

Is this the same problem I am having?

I have a global variable that is a function. I need to pull the function into my script.
($timetest>09:00:00)and($timetest<17:00:00)
 
User avatar
doneware
Trainer
Trainer
Posts: 647
Joined: Mon Oct 08, 2012 8:39 pm
Location: Hungary

Re: Possible bug with global variables

Sat Jul 14, 2018 4:47 pm

I have a global variable that is a function. I need to pull the function into my script.
($timetest>09:00:00)and($timetest<17:00:00)
global variables are not accessible inside the scripts you run by scheduler, unless you explicitly declare them as ":global VariableName;" somewhere in the topmost section (e.g. not inside a loop or condition) of your script.

this makes no difference, regardless your global var is just a number, string, array or a "function". with regards to functions, they're just strings eval'ed strings:
[me@router] /system logging> :local testvar [:parse ":put testingvar"]; :put "running it"; $testvar; :put "showing the value"; :put $testvar          
running it
testingvar
showing the value
(eval /putmessage=testingvar)
but they're always accessible from CLI. just check under "/environment print" - you shall see all the global variables there. but printing or editing your script source will show all undeclared variables as red anyway. this is a good way to check whether they will be correctly interpreted. declared global vars are always shown in light blue.
 
gotsprings
Forum Guru
Forum Guru
Posts: 2343
Joined: Mon May 14, 2012 9:30 pm

Re: Possible bug with global variables

Sat Jul 14, 2018 5:12 pm

It is defined in my script.

I actually log the output to make sure it's there.

But when it comes into the script as $GuestSchedule
It is not processed. Error comes back as "not bolen"
 
User avatar
doneware
Trainer
Trainer
Posts: 647
Joined: Mon Oct 08, 2012 8:39 pm
Location: Hungary

Re: Possible bug with global variables

Sat Jul 14, 2018 5:21 pm

It is defined in my script.
can you post your script?
 
gotsprings
Forum Guru
Forum Guru
Posts: 2343
Joined: Mon May 14, 2012 9:30 pm

Re: Possible bug with global variables

Sat Jul 14, 2018 5:57 pm

Here is the relevant stuff.
:local timetest [/system clock get time]
:local GST
:global GuestSchedule

:if ($GuestSchedule) do={set $GST "1"} else= {set $GST "0"}
:log info "GST Status = $GST"
Confirming the value is correct in my environment.

[admin@MikroTik] /system script environment> print
# NAME VALUE
0 GuestSchedule ($timetest>09:00:00)and($timetest<17:00:00)