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:
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?
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.
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.
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.
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).
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.
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?
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.
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?
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
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..
