2020-09-18 09:00:27 +00:00
|
|
|
#!rsc by RouterOS
|
2018-07-05 13:29:26 +00:00
|
|
|
# RouterOS script: global-config
|
2022-01-01 20:38:15 +00:00
|
|
|
# Copyright (c) 2013-2022 Christian Hesse <mail@eworm.de>
|
2020-06-19 20:17:42 +00:00
|
|
|
# https://git.eworm.de/cgit/routeros-scripts/about/COPYING.md
|
2018-07-05 13:29:26 +00:00
|
|
|
#
|
|
|
|
# global configuration
|
2020-03-27 20:54:00 +00:00
|
|
|
# https://git.eworm.de/cgit/routeros-scripts/about/
|
2018-07-05 13:29:26 +00:00
|
|
|
|
2019-01-03 14:36:26 +00:00
|
|
|
# Make sure all configuration properties are up to date and this
|
|
|
|
# value is in sync with value in script 'global-functions'!
|
2022-03-30 16:03:50 +00:00
|
|
|
:global GlobalConfigVersion 79;
|
2019-01-03 14:36:26 +00:00
|
|
|
|
2018-07-05 13:29:26 +00:00
|
|
|
# This is used for DNS and backup file.
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global Domain "example.com";
|
|
|
|
:global HostNameInZone true;
|
2020-07-03 06:08:04 +00:00
|
|
|
:global PrefixInZone true;
|
2020-08-02 21:31:21 +00:00
|
|
|
:global ServerNameInZone false;
|
2018-07-05 13:29:26 +00:00
|
|
|
|
2019-07-08 15:30:39 +00:00
|
|
|
# These addresses are used to send e-mails to. The to-address needs
|
|
|
|
# to be filled; cc-address can be empty, one address or a comma
|
2018-07-05 13:29:26 +00:00
|
|
|
# separated list of addresses.
|
2020-10-15 20:45:27 +00:00
|
|
|
:global EmailGeneralTo "";
|
|
|
|
:global EmailGeneralCc "";
|
|
|
|
#:global EmailGeneralTo "mail@example.com";
|
|
|
|
#:global EmailGeneralCc "another@example.com,third@example.com";
|
2018-07-05 13:29:26 +00:00
|
|
|
|
2018-10-09 13:46:39 +00:00
|
|
|
# You can send Telegram notifications. Register a bot
|
2021-06-02 20:53:43 +00:00
|
|
|
# and add the token and chat ids here, then install the module:
|
2021-11-15 19:22:56 +00:00
|
|
|
# $ScriptInstallUpdate mod/notification-telegram
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global TelegramTokenId "";
|
|
|
|
:global TelegramChatId "";
|
|
|
|
#:global TelegramTokenId "123456:ABCDEF-GHI";
|
|
|
|
#:global TelegramChatId "12345678";
|
2020-10-12 21:58:20 +00:00
|
|
|
# This is whether or not to send Telegram messages with fixed-width font.
|
|
|
|
:global TelegramFixedWidthFont true;
|
2018-10-09 13:46:39 +00:00
|
|
|
|
2021-05-28 15:30:37 +00:00
|
|
|
# You can send Matrix notifications. Configure these settings and
|
|
|
|
# install the module:
|
2021-11-15 19:22:56 +00:00
|
|
|
# $ScriptInstallUpdate mod/notification-matrix
|
2021-05-28 15:30:37 +00:00
|
|
|
:global MatrixHomeServer "";
|
|
|
|
:global MatrixAccessToken "";
|
|
|
|
:global MatrixRoom "";
|
|
|
|
#:global MatrixHomeServer "matrix.org";
|
|
|
|
#:global MatrixAccessToken "123456ABCDEFGHI...";
|
|
|
|
#:global MatrixRoom "!example:matrix.org";
|
|
|
|
|
|
|
|
# It is possible to override e-mail, Telegram and Matrix setting for every
|
|
|
|
# script. This is done in arrays, where 'Override' is appended to the
|
|
|
|
# variable name, like this:
|
2021-04-28 13:11:08 +00:00
|
|
|
#:global EmailGeneralToOverride {
|
|
|
|
# "check-certificates"="override@example.com";
|
2022-01-05 21:37:35 +00:00
|
|
|
# "backup-email"="backup@example.com";
|
2021-04-28 13:11:08 +00:00
|
|
|
#}
|
|
|
|
|
2020-07-17 06:07:12 +00:00
|
|
|
# Toggle this to disable symbols in notifications.
|
|
|
|
:global NotificationsWithSymbols true;
|
2021-01-22 08:20:49 +00:00
|
|
|
# Toggle this to disable color output in terminal/cli.
|
|
|
|
:global TerminalColorOutput true;
|
2020-07-17 06:07:12 +00:00
|
|
|
|
2018-07-05 13:29:26 +00:00
|
|
|
# This defines what backups to generate and what password to use.
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global BackupSendBinary false;
|
|
|
|
:global BackupSendExport true;
|
|
|
|
:global BackupPassword "v3ry-s3cr3t";
|
2021-02-23 08:55:14 +00:00
|
|
|
:global BackupRandomDelay 0;
|
2019-07-08 15:48:55 +00:00
|
|
|
# These credentials are used to upload backup and config export files.
|
|
|
|
# SFTP authentication is tricky, you may have to limit authentication
|
|
|
|
# methods for your SSH server.
|
|
|
|
:global BackupUploadUrl "sftp://example.com/backup/";
|
|
|
|
:global BackupUploadUser "mikrotik";
|
|
|
|
:global BackupUploadPass "v3ry-s3cr3t";
|
2018-07-05 13:29:26 +00:00
|
|
|
|
2021-06-09 12:32:52 +00:00
|
|
|
# This defines what log messages to filter or include by topic or message
|
2021-06-09 12:25:58 +00:00
|
|
|
# text. Regular expressions are supported. Do *NOT* set an empty string,
|
2021-06-09 12:32:52 +00:00
|
|
|
# that will filter or include everything!
|
2021-06-09 12:25:58 +00:00
|
|
|
# These are filters, so excluding messages from forwarding.
|
2020-11-13 21:46:26 +00:00
|
|
|
:global LogForwardFilter "(debug|info)";
|
2021-03-14 23:48:38 +00:00
|
|
|
:global LogForwardFilterMessage [];
|
|
|
|
#:global LogForwardFilterMessage "message text";
|
|
|
|
#:global LogForwardFilterMessage "(message text|another text|...)";
|
2021-06-09 12:32:52 +00:00
|
|
|
# ... and another setting with reverse logic. This includes messages even
|
|
|
|
# if filtered above.
|
|
|
|
:global LogForwardInclude [];
|
|
|
|
:global LogForwardIncludeMessage [];
|
|
|
|
#:global LogForwardInclude "account";
|
|
|
|
#:global LogForwardIncludeMessage "message text";
|
2020-07-15 10:22:55 +00:00
|
|
|
|
2018-08-30 09:26:47 +00:00
|
|
|
# Specify an address to enable auto update to version assumed safe.
|
|
|
|
# The configured channel (bugfix, current, release-candidate) is appended.
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global SafeUpdateUrl "";
|
|
|
|
#:global SafeUpdateUrl "https://example.com/ros/safe-update/";
|
2020-07-06 22:21:47 +00:00
|
|
|
# Allow to install patch updates automatically.
|
|
|
|
:global SafeUpdatePatch false;
|
2020-11-01 20:48:03 +00:00
|
|
|
# Allow to install updates automatically if seen in neighbor list.
|
|
|
|
:global SafeUpdateNeighbor false;
|
2021-06-28 16:00:25 +00:00
|
|
|
# Allow to install updates even if device is managed by CAPsMAN.
|
|
|
|
:global SafeUpdateOnCap false;
|
2018-08-30 09:26:47 +00:00
|
|
|
|
2019-10-14 17:06:21 +00:00
|
|
|
# These thresholds control when to send health notification
|
|
|
|
# on temperature and voltage.
|
2019-08-27 08:35:53 +00:00
|
|
|
:global CheckHealthTemperature {
|
|
|
|
temperature=50;
|
|
|
|
cpu-temperature=70;
|
|
|
|
board-temperature1=50;
|
|
|
|
board-temperature2=50;
|
|
|
|
}
|
2020-10-16 20:51:51 +00:00
|
|
|
# This is deviation on recovery threshold against notification flooding.
|
|
|
|
:global CheckHealthTemperatureDeviation 2;
|
2021-11-13 20:29:33 +00:00
|
|
|
:global CheckHealthVoltageLow 115;
|
2019-10-22 13:03:52 +00:00
|
|
|
:global CheckHealthVoltagePercent 10;
|
2019-08-27 08:35:53 +00:00
|
|
|
|
2018-10-09 12:12:38 +00:00
|
|
|
# Access-list entries matching this comment are updated
|
|
|
|
# with daily pseudo-random PSK.
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global DailyPskMatchComment "Daily PSK";
|
|
|
|
:global DailyPskSecrets {
|
2018-10-09 12:12:38 +00:00
|
|
|
{ "Abusive"; "Aggressive"; "Bored"; "Chemical"; "Cold";
|
|
|
|
"Cruel"; "Curved"; "Delightful"; "Discreet"; "Elite";
|
|
|
|
"Evasive"; "Faded"; "Flat"; "Future"; "Grandiose";
|
|
|
|
"Hanging"; "Humorous"; "Interesting"; "Magenta";
|
|
|
|
"Magnificent"; "Numerous"; "Optimal"; "Pathetic";
|
|
|
|
"Possessive"; "Remarkable"; "Rightful"; "Ruthless";
|
|
|
|
"Stale"; "Unusual"; "Useless"; "Various" };
|
|
|
|
{ "Adhesive"; "Amusing"; "Astonishing"; "Frantic";
|
|
|
|
"Kindhearted"; "Limping"; "Roasted"; "Robust";
|
2019-04-05 05:56:50 +00:00
|
|
|
"Staking"; "Thundering"; "Ultra"; "Unreal" };
|
2018-10-09 12:12:38 +00:00
|
|
|
{ "Belief"; "Button"; "Curtain"; "Edge"; "Jewel";
|
|
|
|
"String"; "Whistle" }
|
|
|
|
}
|
2018-07-05 13:29:26 +00:00
|
|
|
|
2018-09-10 20:15:54 +00:00
|
|
|
# Run different commands with multiple mode-button presses.
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global ModeButton {
|
2022-05-10 12:54:25 +00:00
|
|
|
1="/system/script/run leds-toggle-mode;";
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
2=":global SendNotification; :global Identity; \$SendNotification (\"Hello...\") (\"Hello world, \" . \$Identity . \" calling!\");";
|
2022-05-10 12:54:25 +00:00
|
|
|
3="/system/shutdown;";
|
|
|
|
4="/system/reboot;";
|
2021-11-12 13:10:13 +00:00
|
|
|
5=":global BridgePortVlan; \$BridgePortVlan alt;";
|
2018-09-13 20:25:38 +00:00
|
|
|
# add more here...
|
2018-09-10 20:15:54 +00:00
|
|
|
};
|
2020-10-23 19:33:38 +00:00
|
|
|
# This led gives visual feedback if type is 'on' or 'off'.
|
|
|
|
:global ModeButtonLED "user-led";
|
2018-09-10 20:15:54 +00:00
|
|
|
|
2018-09-13 20:05:36 +00:00
|
|
|
# Run commands on SMS action.
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global SmsAction {
|
2021-11-12 13:10:13 +00:00
|
|
|
bridge-port-vlan-alt=":global BridgePortVlan; \$BridgePortVlan alt;";
|
2022-05-10 12:54:25 +00:00
|
|
|
reboot="/system/reboot;";
|
|
|
|
shutdown="/system/shutdown;";
|
2018-09-13 20:05:36 +00:00
|
|
|
# add more here...
|
2018-10-04 11:32:21 +00:00
|
|
|
};
|
2018-09-13 20:05:36 +00:00
|
|
|
|
2018-07-05 13:29:26 +00:00
|
|
|
# This address should resolve ntp servers and is used to update
|
|
|
|
# ntp settings. A pool can rotate servers.
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global NtpPool "pool.ntp.org";
|
2018-07-05 13:29:26 +00:00
|
|
|
|
2018-08-06 12:21:55 +00:00
|
|
|
# This is the address used to send gps data to.
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global GpsTrackUrl "https://example.com/index.php";
|
2018-08-06 12:21:55 +00:00
|
|
|
|
2018-07-09 14:05:04 +00:00
|
|
|
# Enable this to fetch scripts from given url.
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global ScriptUpdatesFetch true;
|
2019-08-30 11:28:14 +00:00
|
|
|
:global ScriptUpdatesBaseUrl "https://git.eworm.de/cgit/routeros-scripts/plain/";
|
2021-02-25 10:13:35 +00:00
|
|
|
# alternative urls - main: stable code - next: currently in development
|
2021-02-23 09:14:09 +00:00
|
|
|
#:global ScriptUpdatesBaseUrl "https://raw.githubusercontent.com/eworm-de/routeros-scripts/main/";
|
2021-02-25 10:13:35 +00:00
|
|
|
#:global ScriptUpdatesBaseUrl "https://raw.githubusercontent.com/eworm-de/routeros-scripts/next/";
|
2021-02-23 09:14:09 +00:00
|
|
|
#:global ScriptUpdatesBaseUrl "https://gitlab.com/eworm-de/routeros-scripts/raw/main/";
|
2021-02-25 10:13:35 +00:00
|
|
|
#:global ScriptUpdatesBaseUrl "https://gitlab.com/eworm-de/routeros-scripts/raw/next/";
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global ScriptUpdatesUrlSuffix "";
|
2021-12-14 15:44:01 +00:00
|
|
|
# use next branch with default url (git.eworm.de)
|
2021-02-25 10:13:35 +00:00
|
|
|
#:global ScriptUpdatesUrlSuffix "\?h=next";
|
2020-07-14 14:32:17 +00:00
|
|
|
|
2021-07-09 20:05:45 +00:00
|
|
|
# Use this for defaults with $ScriptRunOnce
|
2021-09-17 14:32:59 +00:00
|
|
|
# Install module with:
|
2021-11-15 19:22:56 +00:00
|
|
|
# $ScriptInstallUpdate mod/scriptrunonce
|
2021-07-09 20:05:45 +00:00
|
|
|
:global ScriptRunOnceBaseUrl "";
|
|
|
|
:global ScriptRunOnceUrlSuffix "";
|
|
|
|
|
2019-08-30 11:41:20 +00:00
|
|
|
# This project is developed in private spare time and usage is free of charge
|
|
|
|
# for you. If you like the scripts and think this is of value for you or your
|
|
|
|
# business please consider a donation:
|
|
|
|
# https://git.eworm.de/cgit/routeros-scripts/about/#donate
|
|
|
|
# Enable this to silence donation hint.
|
|
|
|
:global IDonate false;
|
2018-07-09 14:05:04 +00:00
|
|
|
|
2018-12-20 14:55:40 +00:00
|
|
|
# Use this for certificate auto-renew
|
global: variable names are CamelCase
___ _ ___ __
/ _ )(_)__ _ / _/__ _/ /_
/ _ / / _ `/ / _/ _ `/ __/
/____/_/\_, / /_/ \_,_/\__/
_ __ /___/ _ __
| | / /___ __________ (_)___ ____ _/ /
| | /| / / __ `/ ___/ __ \/ / __ \/ __ `/ /
| |/ |/ / /_/ / / / / / / / / / / /_/ /_/
|__/|__/\__,_/_/ /_/ /_/_/_/ /_/\__, (_)
/____/
RouterOS has some odd behavior when it comes to variable names. Let's
have a look at the interfaces:
[admin@MikroTik] > / interface print where name=en1
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
That looks ok. Now we use a script:
{ :local interface "en1";
/ interface print where name=$interface; }
And the result...
[admin@MikroTik] > { :local interface "en1";
{... / interface print where name=$interface; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
... still looks ok.
We make a little modification to the script:
{ :local name "en1";
/ interface print where name=$name; }
And the result:
[admin@MikroTik] > { :local name "en1";
{... / interface print where name=$name; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 RS en1 ether 1500 1598
1 S en2 ether 1500 1598
2 S en3 ether 1500 1598
3 S en4 ether 1500 1598
4 S en5 ether 1500 1598
5 R br-local bridge 1500 1598
Ups! The filter has no effect!
That happens whenever the variable name ($name) matches the property
name (name=).
And another modification:
{ :local type "en1";
/ interface print where name=$type; }
And the result:
[admin@MikroTik] > { :local type "en1";
{... / interface print where name=$type; }
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
Ups! Nothing?
Even if the variable name ($type) matches whatever property name (type=)
things go wrong.
The answer from MikroTik support (in Ticket#2019010222000454):
> This is how scripting works in RouterOS and we will not fix it.
To get around this we use variable names in CamelCase. Let's hope
Mikrotik never ever introduces property names in CamelCase...
*fingers crossed*
2019-01-03 16:45:43 +00:00
|
|
|
:global CertRenewUrl "";
|
|
|
|
#:global CertRenewUrl "https://example.com/certificates/";
|
2020-12-18 15:02:31 +00:00
|
|
|
:global CertRenewTime 3w;
|
2019-04-01 20:45:38 +00:00
|
|
|
:global CertRenewPass {
|
|
|
|
"v3ry-s3cr3t";
|
|
|
|
"4n0th3r-s3cr3t";
|
|
|
|
}
|
2020-03-20 07:49:09 +00:00
|
|
|
:global CertIssuedExportPass {
|
|
|
|
"cert1-cn"="v3ry-s3cr3t";
|
|
|
|
"cert2-cn"="4n0th3r-s3cr3t";
|
|
|
|
}
|
2021-12-07 14:40:14 +00:00
|
|
|
|
|
|
|
# load custom settings from overlay
|
|
|
|
# Warning: Do *NOT* copy this code to overlay!
|
|
|
|
:do {
|
2022-05-10 12:54:25 +00:00
|
|
|
/system/script/run global-config-overlay;
|
2021-12-07 14:40:14 +00:00
|
|
|
} on-error={
|
|
|
|
:log error ("Loading configuration from overlay failed!");
|
|
|
|
}
|