Miguel
/
Obsidean_VM
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Obsidean_VM/01-Documentation/Vetromeccanica/Sacomea/Sacomea Help.md

2194 lines
175 KiB
Markdown
Raw Normal View History

Initial commit: Obsidian vault
2025-02-18 05:37:27 -03:00
## About SiteManager 3339
### Copyright
Copyright 2019, Secomea A/S, Denmark. All rights reserved.
This product is protected by U.S. and international copyright law.
You may not rent, lease, sell, modify, decompile or reverse engineer this product.
### Terms of Use
By installing or using this product, you are agreeing to become bound by these general terms of use for the solution and purposes for which this product is designed: [http://info.secomea.com/terms-of-use](http://info.secomea.com/terms-of-use).
### Secomea Limited Warranty and Liability
The subject matter of the following is the program(s) stored in this product, its documentation, as well as any other written material belonging to it or them, hereinafter also called "software".
The following provisions do not apply to any country or state where such provisions are inconsistent with local law. Some authorities do not allow disclaimer of express or implied warranties in certain transactions; therefore, the following may not apply to you.
Secomea A/S makes no representation or warranty regarding the content of this software. For example, Secomea A/S does not warrant that the software is "error-free" or will meet the needs and requirements of a particular user. All information in the software is subject to change without notice.
All other warranties, representations, conditions, express or implied, including any implied warranty or condition of merchantability or fitness for a particular purpose are disclaimed by Secomea A/S. All other implied terms are excluded. Secomea A/S disclaims any liability for damages arising from the use of this product or any other damages, including (though not limited to) lost profits or data, special, incidental, or other claims, even if Secomea A/S has been specifically advised of the possibility of such claims.
### Third-party Credits
This product contains Free Source and Open Source components, which are used in accordance with their respective licenses. By using this product you accept and acknowledge the copyright and terms of use of these components.
Click [here](https://10.1.30.1/AE3X/credits.html) for a full list of components and associated copyrights.
---
## System
These pages let you configure basic settings of the SiteManager.
_Note: If you want to reset the settings to factory default, use the Maintenance menu group.
_
### System > General: Device Identity
**Syntax**
Create designations that are meaningful, but use as few characters as possible; maximum is 127 per field.
- **Device Name**
Each SiteManager **must** have a unique name which can function as a host name. It is recommended to use a fully qualified host name (the name does not need to be officially registered on a DNS server), e.g. "gw.company.com". The name is used in several different ways, and in some of the most important ones the name is **case-sensitive**, so using upper case letters is not recommended.
_Note: A device name must include only letters a to z and A to Z, digits 0 to 9, hyphen (-), and dot (but not as first or last character). All other characters, including space and underscore, are forbidden._
- **Configuration via USB**
You can (re-)configure this SiteManager simply by inserting (hotplug) a suitable USB flash stick into a vacant USB port.
The USB flash must have the usual FAT32 format, and it must contain a file named SECOMEA.CFG (see below) in the root of the USB file system; this file must contain a valid (full or partial) configuration for the SiteManager -- like the XML format used when importing or exporting the SiteManager configuration.
When the configuration has been updated (typically in a few seconds), the SiteManager will reboot automatically (Status LED blinks RED) - and you should now unplug the USB flash.
Accepted file names are SECOMEA.CFG, SITEMANAGER.CFG, v_XXXX_.CFG (_XXXX_ is SiteManager product id), and _XXXXXXXXXXXX_.CFG (_XX...XX_ is the serial number); only the file with the most specific filename is used. The following file suffixes can be used instead of .CFG: .XML, .XMLCFG, .CFG.TXT, .XML.TXT, and .XMLCFG.TXT.
_Notice: When enabled, this feature allows anyone with physical access to the SiteManager to change its configuration - including the admin password. If you have concerns about this, you should disable this feature._
Specifically, if you only want to use this feature for a one-time initial setup of, e.g. GateManager parameters, you can set this parameter to disabled state in the USB configuration file - effectively disabling any future attempts to reconfigure the SiteManager via USB.
- **Management via Uplink**
Here you can disable access to the management GUI from the UPLINK interfaces.
When disabled, you can still access the management GUI locally from the DEV1 interface, and remotely from a GateManager or LinkManager Console (provided that "Go To Appliance" is allowed).
The **following 3 fields** are "just" information, but if you want to avoid problems, restrict your choice of characters to the subset of the 7-bit US-ASCII Character Set shown in [Appendix A](https://10.1.30.1/AE3X/help.html#appendix.a). Using a mix of upper and lower cases can make your entries easier to read. If you decide you want to expand your choice, avoid using characters used by operating systems, especially characters used by GNU/Linux or Unix (e.g. the pipe symbol - "|").
- **SysAdmin**
Enter the email address of the administrator of the SiteManager (optional but highly recommended).
- **Location**
Enter the location of the SiteManager (optional). Do not use special symbols or extended character sets (above Hex 7E (decimal 126)).
- **Organization**
Enter your organization name (optional but very highly recommended). Do not use special symbols or extended character sets (above Hex 7E (decimal 126)).
- **GUI Timeout**
Enter the time (in minutes) after which the GUI session will be automatically logged out due to inactivity.
A zero value will disable inactivity timeout. For security reasons, it is strongly discouraged to disable the timeout or set it too high.
_Note: GTA sesssions are not subject to inactivity timeout._
### System > Time
Accurate date and time settings are very important. A new time setting takes effect when you Save the configuration page; no reboot is required.
- **Auto update via NTP**
If you choose no (default), you must enter the time and date in fields provided.
If you choose yes (recommended), you must specify a Network Time Protocol server. The NTP server will automatically set the time and keep it updated (every 12 hours).
- **NTP Server**
Specify a DNS host name or an IP address.
_Tip: If your ISP does not offer its own NTP server, search the Internet to find an appropriate time server. A commonly used list is found at [http://www.pool.ntp.org](http://www.pool.ntp.org/)._
- **Time (HH:MM:SS)**
If you use manual time-setting, enter the current UTC time (24-hour clock). UTC is (for all practical purposes) the same as Greenwich Mean Time (GMT).
- **Date (YYYY-MM-DD)**
If you use manual time-setting, enter the current UTC date using the ISO format (YYYY-MM-DD). Alternatively you can use the US format MM/DD/YYYY(Month/Day/Year), but note that the ISO format is used on status pages and as informational text on certain GUI panels.
- **Time Zone Offset** and **Daylight Saving Time**
Here you can specify the local time zone as the number of hours east of UTC (a negative number means west of UTC), and whether daylight savings time is currently in effect.
_Note: At present, these settings are used only for localizing GateManager Alert Schedules._
- **Automatic Reboot**
If you want the SiteManager to be automatically rebooted daily at a specific time of day, you can specify the time here (in UTC). The actual reboot time is selected randomly at the specified time +/- 30 minutes to avoid multiple SiteManagers rebooting at exactly the same time.
### System > DEV1
The IP address for the DEV1 interface must be a fixed address. It is practically always a private address. The default address from the factory is 10.0.0.1 / 255.255.255.0
- **Auto Subnet Agent:**
The _Subnet Agent_ makes the entire DEV1 subnet available to LinkManagers connecting to this SiteManager with support for TCP, UDP, and ICMP ECHO protocols.
When **Disabled**, the subnet agent is never started for the DEV1 subnet.
When **Enabled** (the default), the DEV1 subnet agent is _automatically_ started provided that _no active device agents_ have a target address in the DEV1 subnet.
When **Always**, the DEV1 subnet agent is always started, even if there are device agents associated with the DEV1 subnet.
When **Always + Static Routes**, the DEV1 subnet agent is always started, and in addition, it enables forwarding to the subnets specified in [Static Routes](https://10.1.30.1/AE3X/help.html#route.static) which have a gateway on DEV1.
- **Proxy ARP:** If you enable this, the SiteManager will answer ARP requests on the DEV1 network for addresses to which it has a route, if that route itself doesn't use the DEV1 interface.
- **WiFi SSID:** Enter the WiFi SSID (network name) for wireless clients on the DEV1 network.
If this field is left blank, the device name of the SiteManager will be used.
- **WiFi Key:** Enter the WPA2 key (pass phrase) for wireless clients on the DEV1 network.
It must be between 8 and 63 characters in length, and it must contain at least one non-alphabetic character.
If this field is left blank, WiFi operation is disabled for the DEV1 network.
- **WiFi Mode:** When set to "Client", the WiFi interface is set for UPLINK operation; the relevant client settings are configured on the System > UPLINK2 page.
When set to "Access Point", wireless computers can connect using the above SSID/Key and appear as if they were directly connected to the DEV1 network through a switch.
Note that a DHCP server will usually be needed on the DEV1 network - you can use either an external server, or the one built into this SiteManager.
- **802.11 Mode:** Select 802.11b (11 Mbps), 802.11g (54 Mpbs), or 802.11n (150 Mbps) mode.
- **Channel:** Enter a radio channel on which to operate.
To avoid interference, you should pick one that is 4-5 (or more) channels away from channels used by other nearby devices, if possible. Note that other kinds of devices (such as Bluetooth devices, cordless phones, microwave ovens, baby monitors) operate in the same frequency band; you may have to experiment to find the best channel to use.
_Note: some countries may forbid the use of particular channels. Eg. channel 12 and 13 are forbidden in the USA._
- : Use this button to open the [DHCP Server on DEV1 configuration panel](https://10.1.30.1/AE3X/help.html#system.landhcp).
- : Use this button to open the [DNS Server on DEV1 configuration panel](https://10.1.30.1/AE3X/help.html#system.dns).
### System > DEV1 > DHCP
- **DHCP Server Mode**
Select if (and how) the SiteManager should act as a DHCP server for clients on DEV1 .
The following DHCP Server Mode settings are available:
- **Disabled.** DHCP Server is disabled.
- **Enabled.** DHCP Server is enabled.
_Note: Do not activate the DHCP server on a segment that includes another DHCP server_
- **Pool Start** and **Pool Stop**
Use one of the following methods to register the first and last IP address of the pool of IP addresses to allocate to DHCP clients on DEV1.
- **Manual allocation**: Enter the first and last IP address of the pool of IP addresses to assign to DHCP clients on DEV1.
_Note: These must be valid addresses within the subnet assigned to the DEV1 interface._
- **Automatic allocation:** This can be used in two alternative ways.
- Leave pool start and pool stop at the default setting of 0.0.0.0. This setting will automatically select a suitable pool of addresses from the DEV1 subnet for the DHCP server.
- Specify the network part of these addresses as zeroes, e.g. 0.0.0.10 and 0.0.0.20, to use a specific range of IP addresses in the DEV1 subnet. This will automatically set the network part of the range according to the DEV1 subnet.
The configuration panel includes a message showing the currently active DHCP Pool Range (you can also see this information on Status > Extended).
- **Domain Name**
Here you can enter a domain name to append to computer names of DHCP clients, to form a fully qualified DNS name. Example: "company.com"
- **WINS Server**
If you use a WINS server for resolution of NetBios names (Windows computer names), enter its IP address here.
- **WINS Secondary**
If your organization has more than one WINS server, you can enter the IP address of a secondary WINS server here.
- **Cisco CallManager**
If you have a Cisco IP phone, you can configure it using DHCP by entering the IP address of the CallManager here.
- : Use this button to open the [DHCP Server Leases configuration panel](https://10.1.30.1/AE3X/help.html#system.staticdhcp).
### System > DEV1 > DHCP > Static DHCP Entries
This configuration panel can be reached from the System > DEV1 > DHCP page. This configuration panel can be reached from any of the System > ... > DHCP configuration pages. Use the 
 button to enter the **DHCP Server Leases** page, where you can view and manage static address allocations in the DHCP server. In addition to the static leases, this page also shows the currently allocated dynamic leases from the DHCP address pools, with the ability to _Lock_ one or more of the corresponding clients to use a static lease.
**The first part of the list shows the static leases (if any):**
- **Disable**
You can disable (rather than remove) a static lease if you are implementing a new address allocation scheme, or you are troubleshooting address allocation problems.
- **IP Address**
The IP address allocated to this client. Note that the IP address must be a valid address in the subnet of the specified interface.
- **MAC Address**
The MAC address which _uniquely_ identifies this client.
- **Hostname**
An optional hostname for the client, in case the client requests a hostname from the DHCP server. Note that Windows clients are configured with a hostname (the _Windows ID_), so they do not request a hostname.
- **Comment**
You can enter a comment further identifying this client (e.g. _Color Printer_), or you can add a note describing why a specific entry has been disabled.
- ![](https://10.1.30.1/wastebin.gif) **[Wastebin icon]**
Press this icon to delete this static lease entry.
_**Important note:** Even though you delete a static lease, the client will continue to use the same IP address until the client tries to renew the allocated IP address, typically within the next 12 hours. You should be aware that the client's valid lease will not appear on the dynamic leases list -- not even if the IP address belongs to the dynamic address pool. It is therefore recommended that you reboot the client (or by other means causes it to renew it's DHCP lease) after removing its static lease._
**The second part of the list shows the currently allocated dynamic leases (if any) from the DHCP pools:**
- **Lock**
You can create a static lease for this client (with the listed MAC address) by checking this checkbox, edit the **IP Address** field, and press the 
 button.
_Note that if you change the IP address (recommended), the old dynamic lease is still listed, since the client will continue to use the old IP address until it tries to renew that lease (typically within the next 12 hours). On the other hand, if you do not change the IP Address (i.e. the client is statically allocated the current address from the DHCP address pool), the lease information will be discarded from the dynamic lease list. It is therefore recommended that you force the client to release and renew its DHCP lease if you create a static mapping for it._
- **Interface**
This is the interface where this client is connected, and from which DHCP address pool it has been assigned a dynamic IP address.
- **IP Address**
The IP address allocated to this client. If you want to make a static lease for this client, it is recommended that you change it's address to an address outside the current DHCP address pool for this interface.
- **Hostname**
The hostname of this client, provided that the client has sent this information to the DHCP server. Note that Windows clients will send their configured hostname (the _Windows ID_) to the DHCP server.
- **Expires**
This shows the date and time when the lease expires.
The following buttons are available:
- : Insert a new static lease entry at the bottom of the static leases list. The Interface and IP address fields are automatically filled with settings from the interface configuration page from which you entered the static lease page.
- : Save and activate the changes made on this page.
- : Refresh the dynamic lease information on the page.
- : Return to the DHCP Server on the interface configuration page from where this page was entered.
### System > DEV1 > DNS
- **Use ISP-Assigned DNS**
Select "Yes" to forward DNS queries to DNS servers automatically assigned by the ISP.
If UPLINK mode is "Static", the ISP cannot assign any DNS servers, and "Yes" will have no effect.
- **Primary DNS**
If you selected "No" above, you must enter the IP address of a DNS server to forward DNS queries to.
_Note: When you use ISP-Assigned DNS servers, this parameter is automatically updated with the Primary DNS server from the ISP._
- **Secondary DNS**
IP address of a secondary DNS server, to be used when the Primary DNS server cannot resolve queries.
_Note: When you use ISP-Assigned DNS servers, this parameter is automatically updated with the Secondary DNS server from the ISP._
- **[UPLINK2] Primary DNS**
IP address of the Primary DNS server to be used by UPLINK2.
Some ISPs' DNS servers reject queries from sources other than their own customers. So if you use different ISPs for the UPLINK interfaces, you will likely need to use different DNS servers too.
_Note: If you leave the [UPLINK2] DNS server fields at 0.0.0.0, the ordinary Primary and Secondary DNS servers will be used by UPLINK2 also._
- **[UPLINK2] Secondary DNS**
IP address of the Secondary DNS server to be used by UPLINK2.
- **DNS Proxy**
Default is "enabled", which enables clients on DEV1 to use the SiteManager as a normal DNS server (query only).
_Note: In order for this to actually work, you must either enter at least one DNS IP address or select the ISP-assigned DNS in the fields above.
In addition, you must either enable System > DEV1 > DHCP: DHCP Server Mode or enter the IP address of the DEV1 interface to each client machine's own list of DNS servers._
- : Use this button to open the [Static DNS configuration panel](https://10.1.30.1/AE3X/help.html#system.staticdns).
### System > DEV1 > DNS > Static DNS Entries
This configuration panel can be reached from the System > DEV1 > DNS page. Use the 
 button to enter the **Static DNS Entries** page, where you can view and manage static DNS entries in the DNS Proxy.
- **Disable**
You can disable (rather than remove) a static entry if you are implementing a new hostname or address allocation scheme, or you are troubleshooting DNS-related problems.
- **Hostname**
The DNS hostname for the static DNS entry.
- **IP Address**
The IP address associated with the hostname of this static entry. This may be any valid IP address, internal or external.
- **Comment**
You can enter a comment further identifying this entry (e.g. _Color Printer_), or you can add a note describing why a specific entry has been disabled.
- ![](https://10.1.30.1/wastebin.gif) **[Wastebin icon]**
Press this icon to delete this static DNS entry.
_**Note:** If you create multiple entries for the same hostname, all entries will be included in each response in a round robin order.
__**Important note:** Even though you delete or change a static DNS entry, clients that have already requested that entry may continue to use the information for up to 60 minutes due to internal caching in the client._
### System > DEV2 - DEV0
By default, all 0 device ports are bridged together to form a single device network controlled by the DEV1 configuration.
However, upto 0 separate device networks can be created by changing the mode of any of the DEV2 - DEV0 ports, which can be operated in either "Bridge" mode (default) or "Separation" mode:
- In **Bridge** mode, the port is bridged together with the previous device port operating in separation mode (or DEV1).
- In **Separation** mode, the port has its own network configuration (like the DEV1 port) and operates as a completely separated LAN segment together with any immediately following device ports operating in bridge mode.
No data can be exchanged between devices on separate device networks.
### System > UPLINK, UPLINK2
- **Mode**
Select mode of the UPLINK interface. Possible choices depend on the interface type.
In SMS Only mode, the mobile broadband modem will only be used for sending and receiving SMS messages; no data connection will be made.
_Note: In SMS Wakeup mode, you must also enter SMS Wakeup Parameters below._
_Note: If you use PPPoE, you must also enter ISP settings below._
- **IP Address**
Enter the IP address of the UPLINK interface.
_Note : This is retrieved automatically for Mobile broadband interfaces and for Ethernet interfaces in DHCP or PPPoE mode._
- **Subnet Mask**
Enter the subnet mask of the UPLINK interface.
_Note : This is retrieved automatically for Mobile broadband interfaces and for Ethernet interfaces in DHCP or PPPoE mode._
- **Default Gateway**
Enter the default gateway. This is the IP address of the next router towards the Internet.
_Note : This is retrieved automatically for Mobile broadband interfaces and for Ethernet interfaces in DHCP or PPPoE mode._
- **Ethernet Settings**
Force ethernet link speed and duplex settings. This may be necessary if autonegotiation isn't supported by the attached equipment, or if the negotiated setting doesn't work reliably, e.g. because of noise or a mediocre cable. If you force the setting, you must make sure that the attached equipment runs with the same settings, of course.
- **MTU Mode**
Normally you should leave this at the default "Auto" setting in order to obtain best performance. However, in rare cases, some networks may require that you force a lower Ethernet packet size; in such a case, set this to "Manual" and enter the desired max packet size in the "MTU" field below.
- **Priority**
Set the priority of this UPLINK interface relative to the other UPLINK interface(s).
As long as its Internet link is up, an interface with "First" priority will be used for outgoing connections. If the Internet link goes down, the SiteManager will fail-over to using the interface with "Second" priority until the link of the "First" priority interface is back up.
In case both interfaces are set at the same priority (and both are up), the UPLINK interface will be used.
- **Probe Type**
Specify which probe methods to use to verify that the Internet link for this interface is working.
By default, a positive response to any of the Ping and TCP probes will be taken as indication of a working connection.
You may select to use only Ping or TCP for probing - or no probing at all.
- **Probe Hosts**
Enter one or preferably more IP addresses (separated by space) of hosts that the SiteManager should probe in turn (until the first one responds) to verify that the Internet link for this interface is working.
_Note: If you leave this field empty, the GateManager Server will be used as probe host._
- **Probe Port (TCP)**
Specify a port number to use for the TCP probe (if enabled).
_Note: No data will be transferred on the connection; it will only be attempted established and then immediately closed again.
Also note that proxy servers may cause the connection attempt to be interpreted incorrectly (either as a false negative or a false positive)._
- **Probe Interval A/B**
This specifies how often probes are sent to determine if the Internet link is working.
Intervals are specified in seconds (in steps of 10), where 0 means never.
Interval A is used when the priority of this interface is higher than, or equal to, the priority of the currently default interface (in the sense that "First" is higher priority than "Second").
Interval B is used when the priority of this interface is lower than the priority of the currently default interface.
- **Dynamic DNS Service**
Often the UPLINK link does not have a fixed IP address, making it impossible to access the SiteManager on its UPLINK interface. This limitation can be removed if you can assign a publicly accessible hostname to the UPLINK interface. If you register the SiteManager with a so-called _dynamic DNS service_, the current UPLINK IP address is kept dynamically associated with the fixed name (its dynamic-DNS hostname). The items in the pull-down list show the services currently supported by the SiteManager.
_Note 1: If you use a dynamic DNS service for a given UPLINK interface, and connectivity to the internet is lost for that interface, the SiteManager will automatically associate the IP address of the other UPLINK interface to the dynamic-DNS hostname of the failing interface.
Note 2: You may use a dynamic DNS service for each UPLINK interface. If you do so, each interface must have its own dynamic-DNS hostname. Multiple IP addresses for the same dynamic-DNS hostname (aka Round Robin DNS) is not supported._
- **Detect NAT Presence**
If this is set to "Yes", the SiteManager will attempt to detect if it is located behind a NAT router, and in that case register the public IP address of that NAT router, rather than its own private address, with the dynamic DNS service.
- **Dynamic-DNS Hostname**
The hostname must be a fully qualified DNS host name (FQDN).
- **Dynamic-DNS Userid**
Enter the account name for the Dynamic DNS service provider where you have registered the hostname.
- **Dynamic-DNS Password**
Enter the password for the the Dynamic DNS service account. _Note: The password is not hidden._
- **SIM PIN code** (Mobile broadband interface only)
If the SIM card is protected by a PIN code, enter it in this field.
_Note: If you enter an invalid PIN code, this field will automatically get cleared after the first try._
- **APN** (Access Point Name, Mobile broadband interface only)
Your SIM card provider will inform you which value to enter here.
If you leave this field empty (or if the entered value doesn't work), all publicly known APNs for the provider of the installed SIM card will be tried (one at a time).
To avoid using any other APN than the configured one (even in case it doesn't appear to work), you can prefix the APN with = (equal sign).
- **SMS Wakeup Parameters** (Mobile broadband interface only)
You must enter at least the mobile number of the inserted SIM card here when SMS-Wakeup mode is enabled. In this mode, the Mobile broadband interface will normally be offline, but it will go online and connect to the GateManager when it receives an SMS starting with the wakeup _secret_ (see below). The SiteManager stays online as long as there is any activity from a GateManager or LinkManager, and then go offline until the next SMS wakeup is received.
When the interface is offline it will have a 0.0.0.0 IP address and the UPLINK2 LED will show a "blink twice and pause" pattern.
Note: After a reboot, the SiteManager must get an operational GateManager connection (via any interface) before it will enter the SMS-Wakeup mode.
The mobile number must start with a **+** and the country prefix. It may be followed by optional parameters like this:
    _**+**number_[**/**_secret_][**;**_id_**=**_value_]...
The following optionals parameters can be used:
- **t=_timeout_** (default 30 minutes)
The _timeout_ specifies the max time (in minutes) for the Mobile broadband interface to stay connected after any actual data traffic has been exchanged with a remote GateManager or LinkManager.
- **c=_number_** (default empty)
The _number_ specifies the Service Center Address (mobile number) for sending SMS acknowledgement back to callers. This number is usually already stored in the SIM card by the provider, so there's normally no need to specify this.
- **a=_ack_** (default _on-demand_)
The _ack_ specifies whether an acknowledgement SMS should be sent back to the sender of the wakeup SMS.
Possible values are **yes** to always send an acknowledgement SMS, **no** to never send acknowledgement SMS, and **on-demand** which will only send an acknowledgement SMS if the wakeup secret is immediately followed by a question mark (?) or the word _ack_ (for example: "Wakeup?" or "Wakeup ack").
- **/_secret_** [backwards compatibility only]
If used, the secret is moved into (overwrites) the _SMS Wakeup Secret_ field.Example: A value of "+4512345678;c=+4530405060;a=y;t=10" specifies that the SMS number to call is +4512345678 (country code +45 is Denmark), an acknowledgement SMS is always sent (via Service Center at +4530405060), and the idle timeout is set to 10 minutes.
- **SMS Wakeup Secret** (default "Wakeup")
An SMS message will only activate the Mobile broadband interface if the beginning of the SMS text matches the _secret_ (case is ignored).
Notice that received SMS messages which matches the secret are automatically deleted; consequently, they are not readable by agents via the serial port or TCP requests. If an empty secret is used, any SMS will activate the Mobile broadband interface, and automatically deleted.
- **Init String** (Mobile broadband interface only)
If your Mobile broadband adapter needs a special initialization command, you can enter the string here (including the AT command prefix).
Normally this field should be left blank, but some adapters and/or mobile network operators may require special commands for proper operation.
- **Speed** (Mobile broadband interface only)
If you experience an unstable Mobile broadband connection, it may be that the signal in your area is weak; normally the modem will automatically switch to another network technology (2G, 3G, ...) if it finds one that appears stronger - and back when the original signal becomes available again. This may cause a lot of disruptions to the connection. By setting this option, you can force the modem to stay on a particular speed (typically 2G signals are stronger and thus more stable than 3G).
_Warning: If you force the modem to a particular speed, but that speed is not available in your area, you will lose connectivity altogether, as it will not fall back to other speed signals. Please use [System > UPLINK2 > Diagnostics](https://10.1.30.1/AE3X/help.html#status.diagnostics) to scan for available signals before changing._
- **Roaming** (Mobile broadband interface only)
Setting the Romaing option to disabled might prevent you from receiving additional roaming charges.
_Again, be aware that disabling roaming might cause loss of connectivity if your ISP's own signal isn't available in the area._
- **Operator ID** (Mobile broadband interface only)
If you want to roam with a particular operator only, you can enter the short numeric ID of that operator here.
_Again, be aware that configuring an operator might cause loss of connectivity if that operator's signal isn't available in the area._
- **User Name**
Enter the user name (login name) for authenticating this SiteManager to the mobile broadband provider.
_Note: Most mobile broadband providers don't require authentication (other than possession of the SIM card), so usually you can just leave this field (and the Password field below) blank._
- **Password**
Enter the password for authenticating this SiteManager to the mobile broadband provider.
_Note: The CHAP authentication protocol is tried first. If the mobile broadband provider doesn't support CHAP, PAP is automatically used instead._
### System > UPLINK, UPLINK2: WiFi Settings
The WiFi settings are only available when a Secomea WiFi USB adapter is inserted into a free USB port of this SiteManager. A WiFi adapter will take precedence over broadband uplink, so if the WiFi adapter is installed into a SiteManager with integrated mobile broadband modem, or if installed together with a mobile broadband USB modem, the WiFi adapter will be used as UPLINK2. For SiteManagers where the physical USB ports are in use, you can share a USB port using a standard USB hub. Note that although this SiteManager supports a great variety of USB hubs, there may be models that are not recognized. WiFi settings are only relevant when WiFi Mode (on System > DEV1 page) is set to "Client".
- **WiFi SSID**:
Wireless Network Name also called SSID. The SSID must match that of the access point (AP) that this SiteManager should connect to. If both SSID and WiFi Key are left blank, the SiteManager will attempt to connect to the default SSID "sitemanager".
- **WiFi Key**:
Enter the Key as an ASCII string from 8 to 63 of length. WPA/TKIP or WPA2/AES-CCMP will be tried for negotiation. If both SSID and WiFi Key are left blank, the SiteManager will automatically try using its DEV1 MAC address as key (in lower case, no colons; e.g. 00c0a2123456).
- : The Scan function will show the access points in range, and will also indicate if the WiFi Adapter was successful in connecting to the configured SSID, and if the WiFi Key was accepted.
_Hint:_ The default SSID and WiFi Key allows you to quickly make the SiteManager get Internet access using your smartphone as hotspot, without having to configure these WiFi settings. Just enter the tethering menu (aka. Internet Sharing or Mobile Hotspot) of your smartphone and configure "sitemanager" as SSID and the SiteManager's DEV1 MAC address as WiFi Key.
**Troubleshooting:** The result of the Scan action may indicate "Connected", even if the key is wrong. To firmly determine if the connection was successful, enter the Status > Network menu and verify that the UPLINK2 interface has received an IP address. If not, check your WiFi settings and try rebooting the SiteManager. Also check that the signal quality (SQ) is acceptable. If not try relocate the SiteManager relative to the access point. Also note that SiteManager will connect to 2.4GHz WiFi networks only.
### System > UPLINK, UPLINK2: ISP Settings
This section of the System > UPLINK/UPLINK2 page provides settings for connecting to the ISP (Internet Service Provider).
_These settings are only relevant for PPPoE mode._
- **User Name**
Enter the user name (login name) for authenticating this SiteManager to the ISP.
- **Password**
Enter the password for authenticating this SiteManager to the ISP.
_Note: The CHAP authentication protocol is tried first. If the ISP doesn't support CHAP, PAP is automatically used instead._
- **ISP Authentication**
Select how the ISP is to be authenticated to this SiteManager. Possible choices are "None", "PAP" and "CHAP".
- **ISP User Name**
Enter the user name used by the ISP to authenticate itself to this SiteManager (if applicable).
- **ISP Password**
Enter the password used by the ISP to authenticate itself to this SiteManager (if applicable).
_Note: If both the (local) User Name and the ISP User Name are identical, the two passwords must also be identical, because the system is unable to distinguish between the two names._
### System > UPLINK2 > Diagnostics
This page gives you the possibility to run diagnostics.
#### Mobile SMS test
This page gives you the possibility to test sending and receiving of text messages (SMS).
A typical first test could be sending a text message (SMS) to your own mobile phone. Test the SiteManager's ability to receive text messages by responding to the received text message on your mobile phone.
If you know the mobile number of the SIM card in the SiteManager, you can enter that and thereby automatically test the SiteManager's ability to receive text messages.
The test first sends the selected number of messages without intermediate delay, and then waits for incoming text messages.
NOTE: During mobile SMS test, normal SMS operation is suspended
##### Important information on the text message (SMS) functionality
Sending/receiving efficiency of text messages is highly dependent of your cellular network operator. You may carefully select your subscription based on quality surveys of the network operator in the region where the SiteManager should be installed.
Our experience is that you can expect that transmission of a text message can take from 1 to 10 seconds depending on the network.
Outgoing text messages are currently queued and stored in the SiteManager for 200 seconds. If a text message could not be delivered to the network within this time, the message is discarded and a log entry is created in the SiteManager.
Incoming text messages are queued at the network operator until the SiteManager can receive the message. The storage time is network operator dependent and you may experience that message are discarded by the network provider after certain conditions of failed delivery.
The SiteManager can store up to 10 text messages. If more text messages are received, the oldest messages will be discarded based on a FIFO principle. All messages are deleted when the SiteManager is rebooted.
Note that text messages are not automatically deleted when read from the SiteManager TCP port or from a Web browser, unless the status is explicetly changed to DELETE. (For more info, refer to the application note "Working with SMS alerts", found on the Secomea website)
Summary: Text message services by nature provide no guarantee of delivery. Both the network operator and the SiteManager may discard messages. Therefore make sure that delayed or discarded text messages will not have mission critical influence on your production and processes.
#### Mobile Diagnostics Trouble Shooting
1. Check that your home network is shown in Test 1 and 2. (If you do not know the name you can compare the Network number with the first digits of your IMSI)
2. Check the supported modes (2G/3G etc.)
- If you cannot find your home network you could be out of range from your operator.
- If you only see a 2G signal you may experience decreased performance.
3. Check the registration status in Test 3:
- Is it registered on the home network? In normal operation you should be registered on the home network.
- If it is registered with roaming, you could be subject to roaming charges. (Maybe you should change SIM/provider)
- If it is not registered, check Test 4, 5, and 6 for registration status. If no registrations are shown, try to move or change the antenna and try scan again.
- If you still have problems, check Test 1 and 2 for other networks. (Maybe another SIM/provider will work)
4. Check the mode in Test 3 (2G/3G etc.):
- If you only see 2G you may experience decreased performance.
5. Check the signal level in Test 3:
- For a 3G connection, it should be 7 or higher for good reception.
- If the signal level is low, try to move or change the antenna.
6. If you see problems in Test 3, check Test 4 and 5.
7. Check the registration status in Test 4:
- Is it registered on the home network? In normal operation you should be registered on the home network.
- If it is registered with roaming, you could be subject to roaming charges. (Maybe you should change SIM/provider)
- If there is still no registration you could be out of coverage. It could help to move or change the antenna.
8. Check the mode in Test 4:
- The mode should always be 2G in this test.
9. Check the signal level in Test 4:
- It should be higher than 5 for good reception.
- If the signal level is low, try to move or change the antenna.
10. Check the registration status in Test 5:
- Is it registered on the home network? In normal operation you should be registered on the home network.
- If it is registered with roaming, you could be subject to roaming charges. (Maybe you should change SIM/provider)
- If it is not registered, check Test 3 and 4. If you have a registration in Test 4 the area might be without 3G coverage.
11. Check the mode in Test 5:
- The mode should always be 3G in this test.
12. Check the signal level in Test 5
- For a 3G connection, it should be 7 or higher for a good reception.
- If the signal level is low try to move or change the antenna.
13. Check the registration status in Test 6:
_Note: This test will fail if the modem or SIM does not provide 4G support._
- Is it registered on the home network? In normal operation you should be registered on the home network.
- If it is registered with roaming, you could be subject to roaming charges. (Maybe you should change SIM/provider)
- If it is not registered, check Test 3, 4 and 5. If you have a registration in Test 5 the area might be without 4G coverage.
14. Check the mode in Test 6:
- The mode should always be 4G in this test.
15. Check the signal level in Test 6:
- For a 4G connection, it should be 7 or higher for a good reception.
- If the signal level is low try to move or change the antenna.
#### Mobile Diagnostics parameters
- **HW information**
This section gives information about the modem
- **SIM card information**
This section gives information about:
- IMSI ("SIM serial number")
- SMS Service Center ("SMS post office")
- **Mobile networks** (Test 1 and 2)
This section shows a scan after available networks.
- Network name
- Network number
- Short name
- Mode
The technology that the network supports. The following modes are known:
- 2G
- 3G
- 3G HSDPA
- 3G HSUPA
- 3G HSPA
- 4G
- Status (roaming)
Is it allowed to connect (roam) to the network? The following values are known:
- unknown
- available
- current
- forbidden
- **Mobile network and cell ID tests** (Test 3-7)
This section shows status for the connected network for each 5 seconds.
- Network name
- Network number
- Registration status
This column shows if the unit is connected to the network. The following values are known:
- Not registered, not searching
- Registered, home network
- Not registered, searching
- Registration denied
- Unknown status
- Registered, roaming
- Registered for SMS only, home network
- Registered for SMS only, roaming
- Emergency services only
- Registered, CSFB not preferred, home network
- Registered, CSFB not preferred, roaming
- Location Area
This is the identifier for cell towers in the area. (Several towers share the same Location Area Code)
- Cell ID
This is the identifier for the cell tower. It can be used together with Network and Location Area to find the position
- Mode
The technology that the network supports. The following modes are known:
- 2G
- 3G
- 3G HSDPA
- 3G HSUPA
- 3G HSPA
- 4G
- Signal (0-31)
This is the signal level of the cell tower
0: Very low signal (-113 dBm or less)
31: Very high signal (-51 dBm or greater)
### System > Serial (Networked Serial Port)
Normally, the serial port is automatically configured by a suitable **vendor-specific serial device agent** (see [Appendix F](https://10.1.30.1/AE3X/help.html#agent.vendor) for details), or if no such agent is active, it works as a management console to a terminal connnected to this port. Using this configuration page, you can enable remote serial port access through the **custom serial agent** instead.
The remote access makes it possible for a remote client to connect to the serial port using the Telnet protocol so data can be directly transmitted and received on this port. Optionally, the baud rate and other settings of the serial port may also be controlled remotely (according to RFC 2217).
A final general note: If the Serial Port "Protocol" parameter is set to "Vendor Agent Controlled" the Management console mode is automatically reenabled even though the SiteManager is CONMUTE-enabled. See [Escape Character](https://10.1.30.1/AE3X/help.html#serial.escapechar) for information on how temporarily reenable the Management console mode without disabling the Serial Port "Protocol" parameter.
**Serial port configuration (on this SiteManager)**
- **Protocol**
This is where you enable remote use of the serial port by selecting a protocol. Settings:
- **Vendor Agent Controlled** - Remote use of the serial port is controlled by activating a vendor-specific serial agent; in this case, the rest of the fields on this page reflect the actual serial port settings. If no vendor-specific agent is active, the port is used by the SiteManager management console.
- **SMS Modem** - Serial Port operates as an SMS Modem.
- **Telnet** - Standard telnet protocol with fixed serial port settings.
- **Telnet (RFC2217)** - Telnet protocol with RFC2217 extensions to allow remote control over serial port settings.
- **Raw** - No higher level protocol; all bytes are forwarded without further interpretation.
- **Raw+Telnet** - Opens two ports, one with Raw protocol, and another with Telnet protocol.
- **Raw+Telnet(2217)** - Opens two ports, one with Raw protocol, and another with RFC2217 enabled Telnet protocol.
- **Serial Driver**
This parameter selects the basic low-level operating mode for the serial port.
- **Standard** - The serial port is configured as unidirectional (telnet to serial only) with no modem signalling.
- **Bidir (DTE)** - The serial port is configured as a bi-directional port with DTE-compatible modem signalling.
- **Bidir (DCE)** - The serial port is configured as a bi-directional port with DCE-compatible modem signalling.
- **Auto-Relay (DTE)** - Like Bidir (DTE), with automatically out-going connection via server relay.
- **Auto-Relay (DCE)** - Like Bidir (DCE), with automatically out-going connection via server relay.
The bi-directional operating modes allow the equipment attached to the serial port to initiate out-going Telnet connections. These modes typically need special protocol support in the attached equipment, as well as using the correct serial cables, so you should consult with your point of purchase before using them.
The auto-relay operating modes are like the corresponding bi-directional modes, but the SiteManager will automatically try to connect to the internal address 127.0.0.1:123 - assuming that there is a suitable static server relay with this Server Virtual Address forwarding the traffic to a central service (or via a device relay to another SiteManager's serial port).
- **Serial Driver Frame Size**
- **Serial Driver Frame Timeout**
When data is received on the serial port, the SiteManager attempts to group multiple bytes into each packet sent over the network, partially to limit network overhead, and to deliver data in packets suitable for the remote peer. The grouping is based on reading a minimum number of bytes from the serial port, and/or waiting a specified number of milli-seconds _after_ the last received byte to detect an inter-frame gap.
These parameters can be set to a non-zero value to override the default framing parameters on the serial port. Valid sizes are 1 to 255 bytes and valid timeouts are 10 to 2550 milli-seconds.
- **Send Break on Connect**
- **Send Break on Disconnect**
When an incoming connection is opened or closed, it is possible to send a break signal on the serial line to notify the attached serial device; these settings specify the duration of the break signal in milli-seconds; a zero value (default) means no break signal is sent to the device.
- **Port Number**
This is the TCP port number used by the remote client to access the serial port. If both Raw and Telnet protocols are opened, the Raw protocol uses this port number, while the Telnet protocol uses this port number plus one.
- **Interface**
Normally the serial port can only be accessed from a LinkManager. If you select the "Any" option, you can also connect directly to the serial port by making a TCP connection to the specified port number via any interface; this includes the UPLINK ports, so be very careful if you use this option.
- **Inactivity Timeout**
Here you specify the timeout for automatic disconnection of the remote client when there is no activity on the serial port. The timeout is the number of seconds to wait after the last byte is received or transmitted on the serial port. A value of 0 disables the automatic disconnect function, so the connection will never timeout.
- **Baud Rate**, **Parity**, **Data Bits**, **Stop Bits**
These parameters specify the corresponding settings on the serial port; if RFC2217 is allowed, they specify the initial settings on the port.
- **Flow Control**
This parameter specifies the flow control method used on the serial port. The default is no flow control, but depending on the device you attach to the serial port, you can choose to use XON/XOFF software handshake or RTS/CTS hardware handshake to guard against data loss on the serial port.
- **Escape Character**
When you the enable remote serial port access, the normal management console on the serial port will be disabled, but if you need to use the management console, you can enable it temporarily by:
1. connecting a terminal (or PC) to the serial port,
2. setting the communication parameters of the terminal to match those of the serial port (typically 19200 baud, no parity, 8 data bits, 1 stop bit, no flow control, and no modem control - see note (*) below), and
3. quickly type the Escape Character (default Ctrl-K) exactly three times (e.g. press K three times while holding down the Ctrl-key).
The management console is automatically deactivated if you don't enter any commands within one minute.
**(*)** If you have set the Serial Driver to Bidir mode DTE or DCE you will have to match the baud rate and all other port settings exactly as you have configured them on the SiteManager.
To configure the Ctrl-K value in the Escape Character field on the Serial Port page, type "^k" (don't include the quotation marks).
Leave the Escape Character field blank to completely disable the ability to use the serial port for management.
- **Monitor Buffer Size**
Here you can specify the size of a trace buffer which records the most recent bytes sent and received on the serial port. The value specifies the number of kilo-bytes to store in the buffer; the maximum size of the monitor buffer is 8 KB. A value of 0 disables the line monitor function.
_Note: Only bytes related to an active remote client session are logged in the monitor buffer._
_Warning: If the remote client exchanges passwords or other sensitive information with the attached device, that information is also logged in the monitor buffer._
- **AT Command{Response}...**
When using the serial port as a SMS modem, the connected device may issue certain AT commands which are not supported by the SiteManager. In that case, you can specify those commands and the expected response in this field, in the format (without the AT prefix): CMD1{RSP1}CMD2{RSP2}....
For example, if the device uses the following commands (with expected results):
AT+ABC?
+ABC: READY
OK
AT+DEF="111"
+DEF: ONLINE
OK
In this case, you can use the following specification:
+ABC?{+ABC: READY}+DEF="111"{+DEF: ONLINE}
Normally each response is followed by a CR NL sequence, and terminated by a separate OK response. If this is not wanted, you can inhibit the CRNL and/or OK by adding \N and/or \O to the response.
You can also add a CR or NL with the \r and \n escapes. Finally, if you need a \ or } in the response, use \\ and \}.
- : Use this button to save any changes to the above parameters.
- : Use this button to view the current port status, and when the monitor buffer is enabled, the most recently recorded data transmitted and received on the serial port.
### System > I/O (Input/Output Ports)
This page lets you view Input port status and manually toggle Output ports.
**Input Ports**
The Input Ports table shows the current state of the input ports, and the actions currently enabled for the ports.
Input port states can be one of ON (input is LOW, 0V) or OFF (input is unconnected or HIGH, 5V).
_Local Alert actions_ (e.g. send an SMS) are defined under GateManager > Alerts.
_GateManager actions_ (e.g. trigger a GateManager Alert) are defined under GateManager > General > [More>>].
By default, the **IN 1** _GateManager action_ controls whether remote management is enabled (OFF) or disabled (ON).
This allows a simple external on/off switch to be used to control remote management access.
Note: Both Local Alert and GateManager actions can be active at the same time for each Input port.
Refer to the external document "Working with I/O Ports" for more details and application notes for different usage scenarios.
**Output Ports**
An output port may have one of two states: ON or OFF. Depending on the SiteManager model, output ports may be "single pin" or "dual pin".
A "single pin" port (like Out2) is a digital port which is pulled towards GND when ON, and is high-impedance when OFF.
For a "dual pin" port (like Out1a/Out1b), both pins are isolated when OFF and short-circuited when ON.
Current output port states are restored after a reboot or power-on, but will be OFF during reboot cycle and power-off.
Output ports can be manually toggled ON and OFF via the "Toggle" button, but you can configure them for one of these actions:
- **GateManager Connected**: the port is forced ON whenever the SiteManager is connected to the GateManager and for instance control an external status light that tells local service people whether a GateManager connection is operational or not.
- **LinkManager Connected**: the port is forced ON whenever a connection is made to the SiteManager from LinkManager and when connecting with Go To Appliance from GateManager, LinkManager Mobile, or LinkManager's domain view.
By default, OUT 1 is configured for the LinkManager Connected action.
You can configure these features under GateManager > General > [More>>].
---
## GateManager
These pages let you configure GateManager related settings of the SiteManager.
_Note: The following instructions are **for the SiteManager administrator**; this is the person who is responsible for configuring and monitoring the SiteManager. It is, of course, possible that the GateManager Administrator is also the SiteManager administrator._
### GateManager > General: GateManager Settings
_Notice that fields marked [hidden] below are only shown if their value is different from the default setting, or if you press the "More" button._
- **Remote Management**
Controls whether this SiteManager (and any Agents and Relays defined on the SiteManagers) connects to the central GateManager. You can choose the following options:
- _Enabled_: Connect to the GateManager and provide remote access to the SiteManager (if **Go To Appliance** setting below allows it) and attached devices.
- _Heartbeat Only_: Connect to the GateManager, but only to deliver periodic status information.
- _Relays and Heartbeat Only_: Like _Heartbeat Only_, but it also allows data through configured Device/Server relays and LogTunnel connections.
- _Disabled_: Do not connect to the GateManager, disabling **all** remote monitoring and management capabilities (similar to powering off this SiteManager).
- **Go To Appliance** [hidden]
This option specifies if and how a GateManager administrator or LinkManager User can use the "Go To Appliance" function to connect to the User Interface of this SiteManager. It can not be set via Appliance Launcher.
- _Disabled_: Access to "Go To Appliance" is blocked.
- _Manual Login_: When you use "Go To Appliance", you must enter the SiteManager's normal user and password credentials in order to log into the SiteManager.
- _Automatic Login_ (default): When you use "Go To Appliance" in GateManager Portal or LinkManager Console's domain view, you will be allowed to use the dynamic password generated by GateManager. If your GateManager Console is configured for Automatic Login, the credentials are presented automatically to the SiteManager. If your GateManager Console is configured for Manual Login, you will be presented with the login dialog; consult the GateManager Reference Manual for instructions.
- _Manual/Automatic login, not LinkManager_: As above, but "Go To Appliance" from LinkManager Console's domain view is not possible.
- **Input 1 Action** [hidden]
This parameter defines the action performed based on Input port 1:
- **None**
Input port 1 is ignored.
- **Control Remote Management** (default setting)
Input port 1 controls whether Remote Management access enabled or disabled, by _inverting_ the value of the Remote Management parameter above:
|INPUT 1|Remote Management Parameter| | | |
|:-:|:-:|:-:|:-:|:-:|
|Disabled|HB Only|Relays/HB Only|Enabled|
|OFF|Disconnected|HB only|Relays/HB Only|Full Remote Management|
|ON|Full Remote Management| | |Disconnected|
This means that setting Input 1 to (constant) ON will **enable** full remote management if the Remote Management parameter is _Disabled_ or _Relay/Heartbeat only_, and **disable** remote management if the parameter is _Enabled_.
- **Trigger Alert INPUT1 if ON**
Trigger an "INPUT1" alert on the remote GateManager when input state changes from OFF to ON. Cancel alert when state changes back to OFF.
- **Trigger Alert INPUT1 if OFF**
Trigger an "INPUT1" alert on the remote GateManager when input state changes from ON to OFF. Cancel alert when state changes back to ON.
- **Input 2 Action** [hidden]
This parameter defines the action performed based on Input port 2:
- **None**
Input port 2 is ignored.
- **Trigger Alert INPUT2 if ON**
Trigger an "INPUT2" alert on the remote GateManager when input state changes from OFF to ON. Cancel alert when state changes back to OFF.
- **Trigger Alert INPUT2 if OFF**
Trigger an "INPUT2" alert on the remote GateManager when input state changes from ON to OFF. Cancel alert when state changes back to ON.
- **Output 1 Signal** [hidden]
This parameter defines an internal signal which may trigger Output port 1 to go ON:
- **None**
Output port 1 is manually controlled only.
- **GateManager Connected**
Output port 1 will go ON whenever the SiteManager has a working GateManager connection.
- **LinkManager Connected**
Output port 1 will go ON whenever a connection is made to the SiteManager with LinkManager and when connecting with Go To Appliance from GateManager, LinkManager Mobile, or LinkManager's domain view.
- **Output 2 Signal** [hidden]
This parameter defines an internal signal which may trigger Output port 2 to go ON:
- **None**
Output port 2 is manually controlled only.
- **GateManager Connected**
Output port 2 will go ON whenever the SiteManager has a working GateManager connection.
- **LinkManager Connected**
Output port 2 will go ON whenever a connection is made to the SiteManager with LinkManager and when connecting with Go To Appliance from GateManager, LinkManager Mobile, or LinkManager's domain view.
- **GateManager Address**
Enter the DNS hostname or IP address of the GateManager server here.
If there is an alternative IP address for accessing the _same_ GateManager server, enter both addresses here separated by a space. If you use the Appliance Launcher to configure the GateManager page, click the DNS button and then enter the two IP addresses separated by a space.
- **Domain Token**
Enter the token for the GateManager home domain from which this SiteManager, as well as all its Agents and Relays, will be managed.
Domain Token length is limited to 127 bytes including dots, spaces and multi-byte characters.
_NOTE: The Domain Token is only used for selecting the initial domain on the GateManager; once connected, any changes to this field are ignored. Use the GateManager portal to move this SiteManager to a different domain - contact your GateManager Administrator for assistance._
- **Appliance Name**
Enter the name or other ID (maximum 127 characters) used by the GateManager Administrator to identify this particular SiteManager. The value of this field corresponds to the **%N** field code in the Appliance Name Format specifications. With the default Appliance Name Format, if this field is left blank, the **Device Name** is used, or if that is blank as well, the SiteManager's _Serial Number_ is used.
- **Preferred Protocol** [hidden]
By default, the SiteManager will automatically try a series of different methods and protocols to connect to the **GateManager Address** specified above. The preferred protocol option gives a hint to the SiteManager about which protocol it should try first (and force it to try only one protocol at a time); however, if the preferred protocol does not work, the SiteManager will still try the other methods. You can choose between the following options:
- _Automatic_: Automatically select the first protocol to use; in fact, with this setting, the SiteManager may try several protocols simultaneously to more quickly get a working connection to the GateManager. It will also try to locate a local web proxy using WPAD and other methods (in addition to an explicitly configured Web Proxy).
- _ACM/PXP (port 11444)_: This is a dedicated port for connecting to the GateManager server. Using a dedicated port is normally preferable as it separates the GateManager related traffic from other out-bound traffic in your network, so you can more easily track the GateManager traffic on your local network and on your Internet connection. But using a dedicated port also means that you will probably need to open this port in the company firewall, which may collide with corporate policy rules.
- _HTTPS/TLS (port 443)_: This connects to the GateManager using the TLS protocol on port 443. This should work through firewalls that allow out-going HTTPS connections.
- _TLS over HTTP (port 80)_: This connects to the GateManager using the standard HTTP port 80, but immediately upgrades that connection to a secure TLS connection. This _may_ work through a firewall that only allows out-going HTTP connections.
- _TLS via Web-proxy_: This connects through a specified Web Proxy (see below), requesting that Web Proxy to connect to the GateManager on port 443. Once established, the normal TLS protocol is used.
- _HTTP via Web-proxy_: This connects through a specified Web Proxy (see below), requesting that Web Proxy to connect to the GateManager on port 80. Once established, the connection is upgraded to a secure TLS connection.
- **Web-Proxy Address**
The IP address (and optional port number separated by colon) of the Web Proxy through which the SiteManager should connect to the GateManager.
Alternatively, you may specify a Web-Proxy Auto-Detect (WPAD) URL in this field, from which the SiteManager can obtain the actual Web-proxy address, for example http://172.16.1.1:8080/wpad.dat.
- **Web-Proxy Account** and **Web-Proxy Password**
If the Web Proxy requires authentication from the SiteManager, you can specify the necessary username and password here. Digest, NTLMv2, NTLM, and Basic auhtentication methods are supported (in that order).
For an NTLM-based Web-proxy, the account is typically specified as DOMAIN\USER, i.e. a domain name and a user name separated by a backslash character.
By default, "SiteManager" is used as workstation name in NTLM authentication; if needed, a different workstation name can be specified before the account name separated by a colon, i.e. WORKSTATION:DOMAIN\USER.
If you need to specify an empty domain, user, or password, write a single # character in the corresponding field.
- **Connection Watchdog** [hidden]
When enabled, the connection watchdog will automatically reboot the the SiteManager after one hour if it cannot connect to the GateManager. This is an attempt to recover from external issues like a stuck DEV1 switch port, malfunctioning DHCP server, or a stalled Mobile broadband modem.
Note that the watchdog is disabled by default for SiteManager models with a built-in 4-port switch or built-in Mobile broadband modem.
- **Keep-Alive Interval** [hidden]
If non-zero, this overrides the keep-alive interval defined by the GateManager Domain settings for this SiteManager. Notice that this setting only controls how often the SiteManager will send a keep-alive message to the server; the server still uses its own domain setting. This is primarily intended to be used to keep the GateManager connection alive in cases where the SiteManager is located behind an aggressive firewall that terminates the GateManager connection after a short period of inactivity.
- **Master Name Format** [hidden]
Here you can specify the format in which you want the SiteManager's name to appear in the GateManager Console. The specification is a mixture of normal characters, format-codes "%X", grouping operators "{...}", choice lists "{...|...|...}", and conditional blocks like "{?...}".
The default format is: "{%N|%D|%S}{ %W}".
See [Appendix D](https://10.1.30.1/AE3X/help.html#appendix.d) for a complete description of the formatting options.
- **Agent Name Format** [hidden]
Here you can specify the format in which you want the "Appliance names" for the GateManager Agents to appear in the GateManager Console.
The default format is: "{%n|%s} (%m){ - %t}{ %W}".
See [Appendix D](https://10.1.30.1/AE3X/help.html#appendix.d) for a complete description of the formatting options.
- **Relay Name Format** [hidden]
Here you can specify the format in which you want the "Appliance names" for the Device and Server Relays to appear in the GateManager Console.
The default format is: "{%n|%s} (%m) - %f{:%p} > %t". (The %t suffix is automatically appended if not already present.)
See [Appendix D](https://10.1.30.1/AE3X/help.html#appendix.d) for a complete description of the formatting options.
- : Save the changes made on this page. Changes to the GateManager address or protocol settings are not activated if this SiteManager is already connected to the GateManager.
- : Disconnect and reconnect to the GateManager using the current settings.
- : Use this button to show advanced options that are normally hidden (marked as [hidden] above).
### GateManager > Agents
The basic GateManager functionality enables monitoring and control of this SiteManager. Using additional GateManager Agents in this SiteManager, the GateManager's monitoring and control capabilities can be extended to the devices attached to this SiteManager.
The SiteManager can support several types of Agents, and new Agent types can be installed (as a firmware plugin) at any time.
See [**Appendix F: Agent Type-Specific Parameters**](https://10.1.30.1/AE3X/help.html#appendix.f) for a detailed description of all supported agents.
_Note: In order to make use of an Agent, after you create it here, you may need to create an appropriate Alert Rule in the GateManager and then attach the Alert Rule to the Agent. Consult the GateManager Reference Manual for more information._
The **Status** column shows the status for each of the configured Agents. The following status codes may occur:
- _IDLE, UP:nn_ - the device is operational and ready to relay traffic.
The _UP:nn_ status indicates that there are _nn_ active connections.
- _DOWN_ - the device is down.
- _STARTING_ - the Agent is trying to determine the device state.
- _WAIT_ - the device is up, but the Agent has not yet been acknowledged by the GateManager.
- _N/C_ - the device is up, but this LogTunnel Client is _Not Connected_ to a LogTunnel Master.
This indicates that either the Client is not yet linked to a LogTunnel Master in GateManager - or that the linked Master is offline.
- _ERROR_ - local configuration error; see the System Log for details.
To create and start an Agent to monitor an attached device, click on the **New** button, and fill in the new Agent settings:
- **Disable**
You can disable an Agent if you want to temporarily stop the GateManager's monitoring and control of the attached device.
- **S/N (Serial Number)**
Here you must enter a _unique_ identification for the attached device. This is the identity that the GateManager uses internally to distinguish this specific Agent from any of the other Agents known by the same GateManager. If more than one Agent has the same Agent Serial Number, only one of them will be visible in the GateManager.
When you create a new Agent, a Serial Number is automatically generated for the Agent based on the serial number of this SiteManager followed by # and a sequence number. For example, if the SiteManager's own serial number is 00:00:24:12:34:56, an automatically proposed Agent Serial Number might be 000024123456#03 (the digits before the # character is automatically hidden to reduce clutter on the screen).
You may use the proposed serial number or overwrite it. If you overwrite it, be sure to use a string that you know will uniquely identify the Agent, e.g. the Ethernet MAC address of a network-attached device. If what you enter starts with #, the string will be used together with this SiteManager's serial number. For example, if you enter #wiggly, and SiteManager's own serial number is 00:00:24:12:34:56, the Agent Serial Number will be 000024123456#wiggly.
- **Device Name**
Enter the name or other ID (maximum 47 characters) used by the LinkManager operator and GateManager Administrator to identify this particular Device Agent, corresponding to the **%n** field code in the [Agent Name Format](https://10.1.30.1/AE3X/help.html#gm.agentfmt). This field must not be left blank.
With the default Agent Name Format, **%n (%M)**, the [GM Appliance Name](https://10.1.30.1/AE3X/help.html#gm.apname) for this SiteManager is automatically appended to the specified Agent Name to create a GateManager Appliance Name for the Agent. This makes it easy for the GateManager Administrator to identify the SiteManager that hosts this Agent. For example, if this SiteManager's GM Appliance Name is test94 and you enter device-17 as the Agent Name on this page, the GateManager Appliance Name for the agent will show up as device-17 (test94).
- **Device Group**
Often a group of devices are logically related, meaning that a LinkManager user should get access to all the devices in the group at the same time, but not to any of the other devices attached to the same SiteManager.
To group devices together, prefix the **Group Name** to the **Device Name** using the following syntax:
    _**$**group name**:** device name_
That is: a _dollar sign_, followed by the _group name_, a _colon_, some optional _whitespace_, and finally the _device name_.
Group names can be freely chosen as long as the total length of the Device Name field does not exceed 47 characters, for example: "$group1: device1", "$group1: device2", "$group2: device1", and "$group2: device2".
_Note:_ The exact same characters must be used to identify a group; for example, "line1" and "line 1" identifies two different groups.
- **Device Type**
Here you select the proper Agent type corresponding to the type of the attached device. Agent types may be either a Custom Agent like the Ping Agent which can check for the presence of any kind of network-attached device, or a product specific Device Agent which provides automatic configuration of the necessary relay services for remote monitoring and control from a LinkManager.
- **Device IP & Parameters**
You can enter the specific parameters for this Agent in this field. The actual format of this field depends on the type of Agent.
It is highly recommended that you use the ![](https://10.1.30.1/properties.gif) icon to enter and edit the agent parameters.
- **Tunnel**
When a checkbox is present here, you can enable LogTunnel access to this device (the agent becomes a LogTunnel Client in GateManager).
- ![](https://10.1.30.1/properties.gif) **[Properties icon]**
Press this icon to open the detailed parameter entry page for this particular Agent (see [Appendix F: Agent Type-Specific Parameters](https://10.1.30.1/AE3X/help.html#appendix.f)).
- ![](https://10.1.30.1/wastebin.gif) **[Wastebin icon]**
Press this icon to delete this Agent entry.
- **Comment**
You can enter a comment further identifying this Agent or the attached device.
### GateManager > Agents > SNMP Profiles
Some Agent types provide support for retrieving configuration and status information from the attached device using SNMP. This information is forwarded to the GateManager, where it will be shown on the corresponding SiteManager instance.
Since you may well create multiple Agents that should all retrieve the same set of information from their respective attached devices, it is desirable to define the set of information only once, and then refer to this definition from each individual Agent.
This is done using SNMP Profiles; a SNMP Profile defines a set of IDs of SNMP objects whose values you want any number of Agents to retrieve. You can create multiple SNMP Profiles, each with a different set of objects. In the Agent configuration panel, you select which of the SNMP profiles you want this particular Agent to use.
To create a SNMP Profile, click the **New** button. Two new entries will appear; the first is for the SNMP Profile itself, and the second is for the (first) Object to put in the Profile.
The following fields and controls are available for the SNMP Profile:
- **Name**
Enter a name that you want to identify this Profile by. This is the name that will be referred to in the Agent configuration, so you should enter a name that is meaningful to distinguish between the Profiles.
_Note: After you have referenced a Profile from one or more Agents, if you change the Profile Name, you will need to reconfigure the Agents to refer to the new Profile Name._
_Note 2: There is a restriction to which characters may be used in the Name. Besides alphabetic letters and digits, only any of **._-()[]@#** is allowed (no spaces!)._
- ![](https://10.1.30.1/plus.gif) **[Plus icon]**
Click this icon to add a new Object to this Profile.
- ![](https://10.1.30.1/wastebin.gif) **[Wastebin icon]**
Click this icon to delete this Profile and all Objects in it.
- **Comment/Label**
You can enter a comment further describing this Profile (e.g., for which type of device it is used).
The following fields and controls are available for the Objects in the SNMP Profile:
- **Disable**
You can disable (rather than remove) an Object, e.g. while experimenting with which Objects to include in the Profile.
- **Object ID**
This is the SNMP OID of the Object.
It must be in numeric dotted format, and it must be fully qualified, i.e., starting from the root of the MIB tree (1.3.6.1...).
See [Appendix E: Common SNMP Objects IDs](https://10.1.30.1/AE3X/help.html#appendix.e) for examples of Object IDs that might be useful.
- **Index**
This is an optional field that is used to assign a specific index to this Object when forwarding it to the GateManager.
The index is needed when creating Alert Rules on the GateManager. Because you can only refer to predefined tag names (and not to SNMP OIDs) in Alert Rules, you need to map this Object to one of those tag names. E.g., an Object that you assign index 5 will be referred to in the Alert Rule as INTEGER5 (if it is an integer type Object) or STRING5 (all other types of Objects). If you leave this field blank, a number will automatically be assigned when the Agent is started.
_Note: The type of Object (integer or string) is automatically detected from the SNMP reply from the packet, so you don't have to (in fact, you can't) specify the type here - but you must know the type when creating the Alert Rule._
- ![](https://10.1.30.1/wastebin.gif) **[Wastebin icon]**
Click this icon to delete this Object.
- **Comment/Label**
This is the descriptive label shown for this object in the GateManager Portal (e.g. "Page counter", "Toner level", "Bytes sent").
### GateManager > Alerts
Based on the settings of this menu, the SiteManager can send alerts based on external triggering of its digital Input ports, Serial port or Ethernet ports.
Depending on the SiteManager model and the GateManager configuration, alerts can be sent as SMS or Email directly from the SiteManager or via the GateManager.
When using the GateManager as alert gateway, the SiteManager will queue SMS and email alerts if GateManager connection is lost, but queued alerts will be discarded if the SiteManager is rebooted.
Note: You must have created a GateManager Agent for each of the devices that need to send Alerts triggered by TCP or UDP, as only requests from known devices are accepted by the SiteManager.
Note: Each alert must fit within a single SMS unit, so alert texts should not exceed 70 characters.
The following parameters are available to setup the alerts:
- **Alert Mode**
Here you can enable local management of the Alert logic in addition to the Alert system managed via the GateManager administrator Portal. Note that disabling Alert mode here will not affect the Alert definitions created in the GateManager administrator Portal.
Also note that if disabling Alert Mode on a SiteManager with integrated modem, the SiteManager will not accept incoming SMSes for reading from the Serial port or the Ethernet port (For details on this topic refer to the separate guide "Working with SMS alerts"). Incoming SMSes related to SMS Wakeup configured under System > Uplink2 will work independent of this parameter.
- **Alert Identification**
By default, the identity of the SiteManager (Appliance name) and the agent (device IP address) is added to the alert text, so that the recipient can easily identify the SiteManager and device that sent the alert, and connect to it from GateManager or LinkManager.
If you have other means of identifying the device (e.g. if alert text itself identifies the device, or by checking who sent the SMS), you can specify that only some alert triggers should add the device identification: _INPUT_ (for input ports), _Agents_ (using UDP or TCP), _Serial_ (via Serial SMS modem), or any combination of these can be selected here.
- **Email Alert Gateway**
Here you can define if email alerts should be sent directly from the _SiteManager_ or using the _GateManager_ server as a mail relay.
Selecting _SiteManager_ as gateway does not require a GateManager connection for the alert to be sent, but requires the appropriate SMTP settings to be configured via the [SMTP>>] button. Note that you must ensure that the entered SMTP settings correspond to the active Uplink Interface.
Selecting the _GateManager_ as gateway will use the GateManager as mail service (if the GateManager version supports email alerts). Note that Alerts will have GateManager as sender, so the recipient must determine the sender based on the Alert identification in the email subject or body text.
- **SMS Alert Gateway**
All SiteManagers can use the GateManager as SMS Gateway, provided that SMS services are enabled on the GateManager (Domain > Domain configuration). This will be indicated in the sub-header of the Alerts configuration page in the SiteManager.
SiteManagers with integrated modems can be configured to send alerts directly via the local modem [_SiteManager_], and will therefore neither depend on an active GateManager connection, nor enabling of SMS services on the GateManager.
Note that if SMS Alert Gateway is set to _GateManager_, the SiteManager's integrated modem can still receive SMS messages that can be read on the Serial port or the Ethernet port. For details on this topic refer to the separate guide "Working with SMS alerts".
_Notice: Receiving requests to transmit SMSes in PDU format via the Serial port is not supported when using GateManager as SMS gateway._
Refer to [this section](https://10.1.30.1/AE3X/help.html#status.diagnostics.smsinformation) for more info on limitations and prerequisites in relation to using SiteManager as SMS gateway.
- **SMS Service Center Number**
Here you can specify the mobile number for the Service Center (SCA) if not progammed into the SIM card. This setting is only used when defining the SiteManager as SMS Gateway.
Note: If you need to specify a PIN code for the SIM card, you must use the relevant parameter on the System > UPLINK2 page.
The following parameters control how INPUT signals can be used to send alerts.
These settings operates completely independent of the INPUT port assignments on the GateManager > General page.
- **Input _N_ Alert**
Here you can enable sending an alert when an INPUT port changes state, either to ON, to OFF, or both (ON/OFF).
_IMPORTANT:_ If the status table shows "Toggle GateManager Access" for IN 1, it is not recommended to also define a local Alert action for this Input port, as the GateManager access toggling will have presendence over the local alert action, If defining it as "Alert when ON" and setting the GateManager as Alert Gateway, the alert will not be sent until the GateManager connection is restored. If your intention is to receive an alert when GateManager connection is lost, you should instead create an Alert in the GateManager Portal and associate it for Input 1 for this SiteManager, or define the SiteManager itself as Alert Gateway. If you want to use Input1 for a specific purpose and not for GateManager Access signaling, you can disable "Toggle GateManager Access" under GateManager > General > [More>>].
- **Alert Recipients** (_mobile_ numbers and/or <_email_> addresses)
Here you specify the mobile number(s) - or <>-bracketed email address(es) - to receive the alert message. Each email address must be encapsulated in <...> brackets. Multiple recipients can be specified by separating them with spaces, comma, or semicolon.
If you specify multiple recipients, you may even control who receives the alert based on time of day and day of week. See the section on alert schedules below.
- **Alert ON Text**
Here you can specify the alert text sent when the INPUT goes ON (and you have requested an alert for "ON" state).
- **Alert OFF Text**
Here you can specify the alert text sent when the INPUT goes OFF (and you have requested an alert for "OFF" state).
As mentioned above, it is possible to define an **Alert Schedule** to control which mobile numbers will receive an alert at different times of day and week.
For example, if you have a day-time number 11223344, a night-time number 55667788, and a weekend number 99009900, you can enter the following schedule in the relevant **Alert Recipient** field. Each of the {...} blocks specify a time frame for the following recipient(s):
    {m-f 6:30-17} 11223344 {m-th 17-6:30, fr 17-24} 55667788 {} 99009900
You read this from left to right as follows: From monday (m) to friday (f) at 6:30 to 17:00, call 11223344; or from monday to thursday (th) at 17 to 6:30 next morning, and on friday from 17 to midnight, call 55667788; if no preceding numbers are called, then call 99009900.
As you can see the last {} form specifies "the remaining periods".
Some details:
• Time-of-day is specified as hour or hour:minute, using 1 or 2 digits: H, HH, H:MM, HH:MM
• 24 hour clocks are used, 24:00 equals 0:00 the next day.
• Weekdays are specified as one or two letters: m mo tu w we th f fr sa su
• Ranges are specified as m-f and lists as m,w,f-su
• Times and dates follows the UTC timezone (unless you specify otherwise on System > Time).
The following parameters control how Ethernet attached devices (with a defined GateManager Agent) can send Alerts:
- **Agent Alerts TCP Port**
The TCP port at which the SiteManager receives TCP requests from Agents to send an Alert. Enter 0 to disable TCP alerts.
- **Agent Alerts UDP Port**
The UDP port at which the SiteManager receives UDP requests from Agents to send an Alert. Enter 0 to disable UDP alerts.
- **Agent Alerts Recipients**
The default mobile number(s) and email address(es) to which Agent requested alerts are sent - if a request does not itself contain a mobile number or email, or specifies mobile number 0.
- **Agent Alerts User Name**
If non-empty, the Agent Alert request must include this user name. If empty, any user name is accepted.
- **Agent Alerts Password**
If non-empty, the Agent Alert request must include this password. If empty, any password is accepted.
The following data formats are accepted to send an Alert:
- **/UserName/Password/Recipient/AlertText**
Send AlertText to the specified Recipient, a mobile number or a <>-bracketed email address. UserName and Password must match the configured settings above.
- **/Recipient/AlertText**
Send AlertText to the specified recipient (mobile number or bracketed <email> address - works only if the configured UserName and Password settings are empty.
- _Compatibility formats_
In addition to the native formats defined above, a number of complatibility formats are also supported. Please contact Secomea for information about compatibility with a specific type of equipment.
**Serial Port Alerts**
You can also send an SMS or Email via the serial port by setting it to use the "SMS Modem" protocol (see [Serial Port](https://10.1.30.1/AE3X/help.html#system.serial)).
Then you can use a standard "AT+CMGS=_recipient_ CR _message_ ctrl-Z" command to send an SMS.
You can also use a custom "AT+SMS=_recipient_ / _message_ CR" command; use \<CR> to insert a linebreak in the message.
The recipient can be a mobile number or a <>-bracketed email address.
### SMTP Setup
- **SMTP Server**
Enter the IP address (or DNS name) of a mail server to be used for sending outgoing mail.
Optionally, you can enter a port number in this field as well; this is done by typing a colon (:) and the port number after the IP address/DNS name. If you don't enter a port number, the standard SMTP port (25) will be used.
If you leave this field empty (or enter 0.0.0.0), the mail server for the recipient's domain will be looked up via DNS.
- **SMTP Auth Username**
User name used for SMTP Authenticaion.
- **Sender Password**
Password used for SMTP Authentication.
_Note: If any of the SMTP Server, AMTP Auth Username, or SMTP Auth Password parameters are not configured, SMTP Authentication will not be attempted, and the message is more likely to be rejected as spam._
- **Sender E-mail Address**
Optionally enter the e-mail address to be used as sender when submitting alert mails.
If this field is left empty, the SMTP Auth Username (above) will be used if it is a valid e-mail address.
### GateManager > Device Relays
The Device Relay functionality of this SiteManager co-operates with the GateManager to allow remote management systems to access the native services of devices connected to this SiteManager. A Device Relay is a non-interactive version of the _Go To Appliance_ feature of some GateManager Agents, where an application running on the GateManager Console PC can communicate with the remote device through the GateManager.
![](https://10.1.30.1/devrelay.png)
To access a service (identified by a dedicated TCP or UDP port) on an device attached to this SiteManager, we create a Device Relay which listens for connections on a _virtual device address_ on the central GateManager. When a management system connects to the service's port (or some other well-defined port) on the GateManager, the connection and associated traffic is automatically forwarded through the GateManager and this SiteManager to the device's local IP address and the defined service port number.
The **Status** column shows the status for each of the configured Device Relays. The following status codes may occur:
- _IDLE, UP:nn_ - the Device Relay is operational and ready to relay traffic.
The _UP:nn_ status indicates that there are _nn_ active connections.
- _ERROR_ - local configuration error; see the System Log for details.
- _Attaching_ - the Device Relay is being created.
- _DUP_ - the specified Device Virtual Address (and Port) is in use by some other Device in the network.
- _BLOCKED_ - the specified Device Virtual Address is outside the pool of addresses defined in the GateManager's domain relay configuration.
- _BUSY_ - the GateManager has no free resources to create the Device Virtual Address.
To create and start a Device Relay for an attached device, click on the **New** button, and fill in the new Relay settings:
- **Disable**
You can disable a Relay if you want to temporarily block remote access to the service on the attached Device.
- **Type**
Here you select the type of protocol to be handled by the Device Relay.
If you select TCP/UDP, the relay will support both TCP and UDP _on the specified port(s)_.
- **Serial Number**
Here you must enter a _unique_ identification for this Device Relay. This is the identity that the GateManager uses internally to distinguish this specific Device Relay from any of the other Device Relays known by the same GateManager. If more than one Device Relay has the same Serial Number, only one of them will be visible in the GateManager.
When you create a new Relay, a Serial Number is automatically generated for the Relay based on the serial number of this SiteManager followed by **#** and a sequence number. For example, if the SiteManager's own serial number is 00:00:24:12:34:56, an automatically proposed Relay Serial Number might be 000024123456#03.
You may use the proposed serial number or overwrite it. If you overwrite it, be sure to use a string that you know will uniquely identify the Device Relay, e.g. the Ethernet MAC address of the device itself. If what you enter starts with #, the string will be used together with this SiteManager's serial number. For example, if you enter #wiggly, and SiteManager's own serial number is 00:00:24:12:34:56, the Agent Serial Number will be 000024123456#wiggly.
- **Relay Name**
Enter the name or other ID (maximum 47 characters) used by the GateManager Administrator to identify this particular Device Relay, corresponding to the **%n** field code in the [Relay Name Format](https://10.1.30.1/AE3X/help.html#gm.relayfmt).
With the default Relay Name Format, **%n (%M)**, the [GM Appliance Name](https://10.1.30.1/AE3X/help.html#gm.apname) for this SiteManager is automatically appended to the specified Relay Name to create a GateManager Appliance Name for the Relay. This makes it easy for the GateManager Administrator to identify the SiteManager that hosts this Relay. For example, if this SiteManager's GM Appliance Name is test94 and you enter device-17 as the Relay Name on this page, the GateManager Appliance Name for the Relay will show up as device-17 (test94).
- **Device Virtual Address**
The virtual address (and port number) corresponding to the device on the central GateManager.
You may also specify a service type in this field _service://ip:port_; if you do so, the specified service will be used as the _Go To Appliance_ protocol for this Device in the GateManager Console. If there is no service specified, you cannot use _Go To Appliance_ for this Device via this Device Relay instance.
For a new device relay, the default virtual address is "0.0.0.0:0" - which means that the address has to be specified on the GateManager.
_Note: You can only use addresses that have been approved for use as device virtual addresses on the GateManager, and all devices (attached to any SiteManager) must use a unique device virtual address, or if they share an address, they must use unique port numbers for that address. The approved addresses are specified in the Device Pool section of the GateManager's domain relay configuration._
_Note 2: It is possible to restrict which management systems can connect to a device target via the GateManager, by creating a Device Access section in the GateManager's domain relay configuration, listing the approved (source) addresses for connections to the remote device addresses. Specifically, if you want to allow device attached to other SiteManagers to use a Server Relay to connect via a Device Relay to a device on this SiteManager, the GateManager Administrator must allow access from the GateManager server itself (by adding 127.0.0.1 to the Device Access section)._
- **Device Target Address**
The local address (and port number) of the device. The SiteManager connects to the Device using this address when a management system connects to the device virtual address.
- **MaxC**
The maximum number of concurrent connections to the device. For a TCP based relay, a blank field means _system limit_ (currently 20); for an UDP based relay, a blank field means _one connection_.
- **Idle**
The maximum idle time for any connection to the device; if a connection is idle (no data received or transmitted) for the specified period, the connection is closed without further notice. A blank field means _no timeout_. A bare number, _e.g. 90_ is measured in seconds. To specify a number of minutes or hours, add an _m_ or _h_ to the number, e.g. _10m_ or _1h_.
- **Ping**
Send periodic "ping" requests to the device to test whether it is powered on. When this option is selected, the Device Relay is only attached to the GateManager for as long as it responds to the ping. If you don't select this option, it is assumed that the device is always operational.
- **Comment**
You can enter a comment further identifying this Relay or the attached device.
- ![](https://10.1.30.1/wastebin.gif) **[Wastebin icon]**
Press this icon to delete this Relay entry.
### GateManager > Server Relays
The Server Relay functionality of this SiteManager co-operates with the GateManager to allow devices attached to this SiteManager to access remote servers through the GateManager. The Server Relay facility is like the _Device Relay_ facility, but is used for connections in the opposite direction.
![](https://10.1.30.1/srvrelay.png)
To access a service (identified by a dedicated TCP or UDP port) on a remote Server (which can be reached from the GateManager), we create a Server Relay which listens for connections on a _virtual Local address_ on this SiteManager. When a device connects to the service's port (or some other well-defined port) on the SiteManager, the connection and associated traffic is automatically forwarded through the SiteManager and the GateManager to the remote Server.
The **Status** column shows the status for each of the configured Server Relays. The following status codes may occur:
- _IDLE, UP:nn_ - the Server Relay is operational and ready to relay traffic.
The _UP:nn_ status indicates that there are _nn_ active connections.
- _ERROR_ - local configuration error; see the System Log for details.
- _Attaching_ - the Server Relay is being created.
Other error codes related to Server Relay may appear in the System Log for specific connections:
- _REFUSED_ - the specified Server refused the connection on the given port.
- _TIMEOUT_ - the specified Server recognized the connection request, but did not accept it in a timely manner.
To create and start a Server Relay for an attached Server, click on the **New** button, and fill in the new Relay settings:
- **Disable**
You can disable a Relay if you want to temporarily block device access to the service on the remote Server.
- **Type**
Here you select the type of protocol to be handled by the Server Relay.
If you select TCP/UDP, the relay will support both TCP and UDP _on the specified port(s)_.
- **Serial Number**
Here you must enter a _unique_ identification for this Server Relay. This is the identity that the GateManager uses internally to distinguish this specific Server Relay from any of the other Server Relays known by the same GateManager. If more than one Server Relay has the same Serial Number, only one of them will be visible in the GateManager.
When you create a new Relay, a Serial Number is automatically generated for the Relay based on the serial number of this SiteManager followed by **#** and a sequence number. For example, if the SiteManager's own serial number is 00:00:24:12:34:56, an automatically proposed Relay Serial Number might be 000024123456#03.
You may use the proposed serial number or overwrite it. If you overwrite it, be sure to use a string that you know will uniquely identify the Server Relay, e.g. the Ethernet MAC address of the Server itself. If what you enter starts with #, the string will be used together with this SiteManager's serial number. For example, if you enter #wiggly, and SiteManager's own serial number is 00:00:24:12:34:56, the Agent Serial Number will be 000024123456#wiggly.
- **Relay Name**
Enter the name or other ID (maximum 47 characters) used by the GateManager Administrator to identify this particular Server Relay, corresponding to the **%n** field code in the [Relay Name Format](https://10.1.30.1/AE3X/help.html#gm.relayfmt).
With the default Relay Name Format, **%n (%M)**, the [GM Appliance Name](https://10.1.30.1/AE3X/help.html#gm.apname) for this SiteManager is automatically appended to the specified Relay Name to create a GateManager Appliance Name for the Relay. This makes it easy for the GateManager Administrator to identify the SiteManager that hosts this Relay. For example, if this SiteManager's GM Appliance Name is test94 and you enter Server-17 as the Relay Name on this page, the GateManager Appliance Name for the Relay will show up as Server-17 (test94).
- **Server Target Address**
The remote server's address (and port number) used by the GateManager to reach that server. You can specify a remote server with a numeric IP address, like "1.2.3.4", or using a symbolic server name, like "S1" or "ALARM_RECEIVER", which is defined on the GateManager to point to a suitable target IP address. Using a symbolic name makes it easier to change the IP address of a central server, as the GateManager Administrator then only need to change the IP address on the GateManager, rather than pushing a configuration update to all attached SiteManagers.
For a new server relay, the default target address is "0.0.0.0:0" - which means that the address has to be specified on the GateManager.
_Note: You can only use numeric and symbolic remote server addresses that have been approved as such on the GateManager. Of course, multiple devices may sepcify the same server address or name. The approved addresses are specified in the Server Targets section of the GateManager's domain relay configuration._
- **Server Virtual Address**
The local virtual address and port number on this SiteManager corresponding to the remote Server. The specified address must be a local address on one of the Device network ports, either the primary address, or defined as an [IP Alias](https://10.1.30.1/AE3X/help.html#route.alias).
If no port number is specified, the port number from the Server Address field is used.
If no IP address is specified (the field is left blank or contains just _:port_), any of this SiteManager's primary or IP Alias addresses can be used by an attached device as the Server Virtual Address. _This method can only be used if no other Server Relay or SiteManager built-in service (such as the Web GUI or networked serial port) uses the same port number._
_Note: Each Server Relay on this SiteManager must use a unique server virtual address, or if they share an address, they must use unique port numbers for that address._
- **MaxC**
The maximum number of concurrent connections to the Server. For a TCP based relay, a blank field means _system limit_ (currently 20); for an UDP based relay, a blank field means _one connection_.
- **Idle**
The maximum idle time for any connection to the Server; if a connection is idle (no data received or transmitted) for the specified period, the connection is closed without further notice. A blank field means _no timeout_. A bare number, _e.g. 90_ is measured in seconds. To specify a number of minutes or hours, add an _m_ or _h_ to the number, e.g. _10m_ or _1h_.
- **Restr**
Select this option to restrict access through this Server Relay. If selected, only devices that are the target for a Device Relay (Device Address field) or a Device Agent (Target Address field) are granted access; if deselected, any source is granted access.
- **Comment**
You can enter a comment further identifying this Relay or the attached device.
- ![](https://10.1.30.1/wastebin.gif) **[Wastebin icon]**
Press this icon to delete this Relay entry.
### GateManager > Server Relays > Aliases
If you need to configure multiple Server Relays for a given Interface on this SiteManager, and those Server Relays use different local Server Virtual Addresses, you need to define those addresses as aliases for the corresponding Device Interface.
_Note: The SiteManager will respond to ARP requests for the IP addresses entered here._
- **Disable**
You can disable (rather than remove) an alias if you are implementing a new address allocation scheme, or you are troubleshooting address allocation problems.
- **IP Address** The additional public IP address allocated to the specified interface.
- **Subnet Mask**
The subnet mask specifies the IP subnet associated with this IP address. Leave the subnet mask empty if the IP address is within the primary subnet for the interface.
- **Interface**
This specifies which interface the IP address is associated with.
- **Comment**
You can enter a comment further identifying this alias (e.g. _Web server_), or you can add a note describing why a specific alias has been disabled.
- ![](https://10.1.30.1/wastebin.gif) **[Wastebin icon]**
Press this icon to delete this IP alias entry.
- ![](https://10.1.30.1/updown.gif) **[Arrow icon]**
Click and drag this icon (while pressing the mouse button) to move the alias to an arbitrary position in the list. Normally, the order is irrelevant, but you may want to view the aliases in a specific order for clarity.
- : Insert a new alias entry at the bottom of the list.
- : Save and activate the changes made on this page.
### GateManager > Web Proxy Relay
The GateManager Web Proxy Relay functionality allows clients on the Device networks to use this SiteManager as a Web Proxy, by forwarding all requests to a remote Web Proxy, and optionally handle HTTP CONNECT by connecting directly to a specified remote server via the GateManager.
It works like an automatic Server Relay, without the need to configure a local address for a specific remote server address. This may be used with legacy devices that already include the ability to connect via a Web Proxy to the Internet. If you also specify a remote web proxy, any type of HTTP request (except CONNECT) will be forwarded to that remote proxy, allowing you to browse the Internet through the GateManager connection.
On SiteManager hardware units, the web proxy supports both DHCP and DNS-based web proxy auto-discovery (WPAD).
- **Web Proxy Relay**
This is where you enable and disable the Web Proxy Relay functionality. By default it is enabled on hardware platforms and disabled on software platforms.
For proper operation, you must configure at least one of the **Remote Web Proxy** and **Connect Forwarding** parameters.
- **Auto-Discovery Modes**
This is where you enable and disable the Web Proxy Auto-Discovery (WPAD) functionality.
The default setting (on hardware based SiteManagers) is to enable DHCP-based WPAD used by programs like Internet Explorer and Skype.
If you use programs (e.g. Firefox) that only support the DNS-based WPAD method, you can change this setting to enable both DHCP and DNS-based WPAD.
_Note: You must enable the DHCP server (and DNS proxy) on the relevant interfaces for auto-discovery to work._
- **Local Port**
The local port (default 8080) on this SiteManager where the Web Proxy listens for requests.
Note that if you enable DNS-based WPAD, the Web Proxy Relay will also listen on port 80 in addition to the port configured here.
Note also that if you set the local port to 80, you also automatically enable DNS-based WPAD if you have enabled only DHCP-based WPAD above.
- **Remote Web Proxy**
This specifies the remote Web Proxy that requests are forwarded to. It may be specified as either the actual IP address and port number of the remote Web Proxy, or by a symbolic name, e.g. _WEBPROXY_ (the default), which is configured in the GateManager's domain relay configuration. If you leave this field blank, only HTTP CONNECT requests are handled by the Web Proxy Relay.
- **Idle Timeout**
Here you can enter the maximum idle timeout (in seconds) for the connections made through the Web Proxy Relay. A value of 0 means no timeout. Default is to terminate connections that are idle for more than 300 seconds.
- **Idle Threshold**
Here you can enter the maximum size (in bytes) of data packages (TCP payload) forwarded through the Web Proxy Relay in order for them to not reset the idle timer. The default value of 0 means any data on the connection will reset the idle timer. This can be used with some protocols that regularly send a small keep-alive package, but you still want such connections to be timed out.
- **Connect Forwarding**
This specifies how HTTP CONNECT requests are handled by the Web Proxy Relay. By default, these requests are forwarded to the **Remote Web Proxy** server, if configured. Alternatively, the Web Proxy Relay can intercept HTTP CONNECT requests with a numeric IP address and port number target address, and treat them like a form of anonymous _Server Relay_, making a direct connection to the given address and port number via the GateManager. Possible values are:
- _Via Remote Proxy_: Forward HTTP CONNECT requests via the configured Remote Web Proxy.
- _Direct - No auth_: Handle HTTP CONNECT directly, without authentication.
- : Save and activate the changes made on this page.
### GateManager > Status
Here you can view the status for the operational Agents as well as Device and Server Relays, and the currently active Web Proxy Relay Connections.
_Note: The "Idle" time reported for Web Proxy Relay connections is only updated if you have specified a non-zero **Idle Timeout**, and even in this case, the idle time is only updated in 10 seconds increments._
You can force close an active Web Proxy Relay connection, by clicking on the ![](https://10.1.30.1/wastebin.gif) **[Wastebin icon]** shown for the connection.
---
## Routing
### Routing > Static Routes
This allows you to create one or more static routes to networks located behind a router on DEV1. The interface of the router used as gateway for a given network must be directly connected to the same subnet as one of the interfaces of this SiteManager. Enter a description of the network in question as shown in the fields below, and the route will be created.
- **Network**
Enter the IP address of the network.
- **Subnet Mask**
Enter the subnet mask of the network.
- **Gateway**
Enter the IP address of the gateway used to reach the network in question.
_This is **not** the default gateway for the SiteManager itself as set under System > UPLINK._ _In special cases you can leave this field blank; in such cases the SiteManager will arp for the destination address on the interface (selected below)._
- **Interface** Optionally select the interface used to reach the gateway. If you leave this blank, the SiteManager will select an interface automatically.
- **Priority**
Select the priority of this static route. Routes with **High** priority are consulted _before_ routes to local networks, and routes with **Low** priority are consulted _after_ routes to local networks.
- ![](https://10.1.30.1/wastebin.gif) **[Wastebin icon]**
Press this icon to delete this route entry.
- : Press this button to create a new route entry.
- : Press this button to save the changes and activate the route(s).
---
## Secomea Data Collection Module (DCM)
The DCM system consists of 4 distinct parts:
- Data Collectors that collect data from devices using various protocols (I.e. ModBus, OPC-UA)
- Data Servers that delivers data to Cloud servers using various protocols (I.e. MQTT, HTTP)
- One aggregator that executes computations on collected data and generating new data
- One Store and Forward database, which receives data from the collectors and aggregators, stores them internally, and delivers the data to the dataservers, when needed.
By splitting the data collection task into the 4 distinct parts, the DCM becomes robust in the face of network problems and device/cloudserver outages. As the Store and Forward database is periodically saved to non-volatile memory, DCM is even robust in face of SiteManager outages.
The configuration of these 4 parts is done via the DCM config (in JSON format). The full documentation is [**here**](https://10.1.30.1/AE3X/dcmconf.html).
Setting up the different cloud system can be quite complicated and is described [**here**](https://10.1.30.1/AE3X/cloudsetup.html). Beware that this information can changed without warning as the Cloud providers see fit.
### DCM > Status
Show the current status of the DCM system.
Whenever possible, you can see the data values currently in the Store and Forward Database for a given samplename. Whenever the data consists of numerical values, it is also possible to see graph of these data values. Furthermore, it is possible to clear individual statistics sections.
### DCM > Settings
Change certain general the settings of the DCM system.
- Disable All DCM functions: All DCM functions are immediately stopped and will remain so, also across reboots.
- Disable Cloud config updates: Some Cloud systems can update the DCM configuration automatically. This can be disabled by this option, so only local edit and imports can change the DCM configuration.
- Override DCM EdgeID: The EdgeID is used by DCM to uniquely identify this SiteManager. It is constructed using the SiteManagerID (a 32bit hex index) and GateManager official DNS name. If, however, there is a need to use some other addressing scheme, the EdgeID can be overwritten with this setting.
### DCM > Edit
Change the JSON configuration of the DCM system.
### DCM > Export
Export the JSON configuration from the DCM system.
### DCM > Import
Import the JSON configuration into the DCM system.
### DCM > Restart
Restart the DCM system, optionally resetting the SSF database.
### DCM > Certificates
Certificates/Keys used to connect the DCM system to cloud systems. You can import Cerificates/Key from files and give them a symbolic name that can be referenced from the DCM configuration file.
---
## Maintenance
### Maintenance > Password
Change the primary and secondary passwords for the "admin" account.
**Always change the primary admin password in connection with first-time configuration.**
The secondary password for the admin account is useful if you are using a common password for all your SiteManagers, but you need to allow another user to have access to just this one SiteManager. Then you can set the primary password to your common password, and enable and set the secondary password to something specific for this SiteManager.
_**Important:** A password must have a certain degree of complexity to be acceptable: minimum 8 characters long, preferably longer; there is no maximum, but in order to be compatible with the Appliance Launcher, the password should have no more than 47 characters.
It must contain at least 1 non-alphabetic character. Space is ok, but not as the first or last character. Special characters, such as & # and ! are ok; national characters (such as æ, ø, å, Æ, Ø, Å in Danish) should be avoided. It is a good idea to keep to a subset of the 7-bit US-ASCII Character Set - see [Appendix A](https://10.1.30.1/AE3X/help.html#appendix.a)). Passwords are case-sensitive and it is a good idea to mix cases (upper and lower)._
### Maintenance > Reboot
Rebooting is used to activate certain settings. It is also necessary after upgrading firmware, resetting configurations to factory defaults, or importing a configuration file. You can choose a reboot without delay or schedule a reboot to take place after a number of hours - see the pull-down list.
_Note: Rebooting clears the contents of the log. Copy the log (Log > View) to a file **before** rebooting if you want to preserve its contents._
### Maintenance > Upgrade
This lets you upgrade the firmware of the SiteManager. You will be prompted to select a firmware file that you have saved on your local computer to send to the SiteManager. Rebooting is necessary to activate the new firmware.
_Note 1: Once you have started the upgrade, you must wait for the upload of the file to finish before navigating elsewhere in the menus. This can take several minutes._
_Note 2: Your **settings** will not be affected by an upgrade. This means e.g. that you will not automatically receive new built-in rules or a new factory default for a given parameter. Use the release notes to find new features and settings and decide whether or not you want to implement them manually (e.g. enter a new rule or change the value for a parameter to the new factory default)._
_Note 3: After a firmware upgrade, you may need to delete the cache (aka. "Temporary Internet Files") of your browser, in order for new **features** (e.g. new menu items and new fields) in the firmware to be displayed._
### Maintenance > Export
This lets you export the configuration of the SiteManager, and save it into a file on your computer.
### Maintenance > Import
This lets you import a configuration file from your computer into the SiteManager.
Alternatively, if you click on the ![](https://10.1.30.1/xml.gif) **[XML icon]**, a text field is displayed where you can paste and edit a full or partial configuration to be imported. Once you submit the data, there is no difference in importing a configuration from a file or using the text field.
After the import you may need to reboot the SiteManager to activate the imported configuration.
### Maintenance > Reset
This lets you reset the configuration to the factory defaults.
Enter the current password of the admin account to reset all settings and delete all custom configuration.
Note that the IP address of the DEV1 interface will be changed to 10.0.0.1 (effective after reboot), and the admin password will also be reset.
---
## Status
### Status > System
View system information, which varies according to the product. _Examples_:
- Device name
- Product and model
- Serial Number
- Current
- firmware level(s)
- license conditions such as maximum number of agents and relays
- settings for GateManager
- time and date
- uptime for the SiteManager
### Status > Network
View information about network interfaces and utilization. This information is split into multiple pages:
The
 button (default when you select Status > Network) displays
- **Interface Statistics** for each interface:
     * IP address
     * MAC address (if applicable)
     * Utilization (bps average for the last 30 seconds)
     * Traffic: total bytes and packets received/transmitted
The
 button lists the current ARP table entries.
The
 button updates the status on the current page.
### Status > Extended
This is a snap-shot of selected currently active settings in the system. Basically, you can look at all configurations and states that you can see in configuration panels or other status pages - except the log pages - and quite a lot more.
It always shows _at least_ the following basic system information:
- Device Name of this SiteManager (hostname)
- Domain (if any)
- Kernel version and build date.
- The information available in Status > System.
Depending on the state of the system, it also shows information _such as_:
- Memory usage, file system usage, CPU load, current system processes, periodic (scheduled) tasks
- Routing Policy and Network Routes
- Current DHCP client leases
- DHCP server configurations
Refresh by pressing "Extended" again on the 2nd-level menu - or by using Refresh on your browser.
### Status > Ping/Trace
This page lets you test connectivity using Ping or Traceroute, or by sending a TCP or UDP packet to a specific port.
- Target Address can be an IP address or a DNS host name, provided that DNS resolution is correctly configured [(System > DNS)](https://10.1.30.1/AE3X/help.html#system.dns).
- Source Address can be any (blank), or the IP address of a specific interface.
TCP specific note:
- An OK response (flags=SA) means that the port is open and the server accepted the request.
- A REJECTED response (flags=RA) means that the server is present, but the port is not listening.
- An ICMP response (or no response) typically means that there is no host at the specified address, or that a firewall may have blocked the packet.
UDP specific note:
- No response may or may not indicate a problem; even when the port is reachable and open, the target host is unlikely to respond to a packet that most likely doesn't contain any valid protocol data.
- An "ICMP Port Unreachable" response means that the target host is reachable, but the port is closed (other ICMP messages may also be received, e.g. from routers on the path).
### Status > Troubleshoot
The troubleshoot function performs a comprehensive connectivity test for this SiteManager including interfaces, routes, agents, etc, and verifies that configured addresses and services are valid and reachable using the ARP, ICMP (Ping) and DNS protocols.
For each test, the troubleshoot function will assign a severity level (_ok (green)_, _low (grey)_, _medium (yellow)_, or _high (red)_) which gives a subjective indication of the severity of potential problems with the configuration or connectivity of the SiteManager.
The information is organized in following groups:
#### Severity
A legend for the colors (and numeric values) for the meaning of the severity level for each value.
 
#### System
Information about hardware and software version.
The following information is verified:
- Reboot needed:
There are pending configuration changes which will not take effect until the SiteManagers is rebooted.
#### GateManager
Information about the connection to the GateManager.
#### Network Interfaces
The following information is verified for all network interfaces:
- The link state is assumed to be UP.
- The IP address is checked for duplicates on it's local network (using the ARP protocol)
- The DHCP server (if the interface uses DHCP) is checked to see if it is reachable (using ARP or ICMP).
- The DNS servers (if defined) are checked to see if they can resolve the GateManager's DNS name (or www.secomea.com).
- The subnet is checked for overlap with all other interface subnets.
#### Routes and gateways
The following information is verified for each static or default route which forwards via a point-to-point interface:
- If route's interface is a point-to-point interface, the gateway is checked to see if it is reachable (using ICMP).
_Note: On point-to-point interfaces toward ISPs, the gateway will typically not answer ICMP (ping) for security reasons._
For static and default routes which do _not_ go via a point-to-point interface, the following is verified:
- The gateway IP address is on the local subnet of the interface.
- The gateway IP address is reachable (using ARP).
#### GateManager Agents
The following information is verified for the currently enabled agents:
- If the agent has a target IP address, it is verified to be reachable (using APR or ICMP).
#### I/O
Information about the current state of the I/O pins on this unit.
#### Troubleshoot API for integrators:
The troubleshoot information is also available in JSON and TEXT formats which can be used as an API for other systems, and it can be obtained without username/password authentication, if it is requested from a device that is directly attached to one of the SiteManager's interfaces (i.e. _not_ via a router).
The troubleshoot URL is:
    https://_IPADDR_/tshoot?format=_FORMAT_[&filter=_FILTER_[+_FILTER_]...]
where _IPADDR_ is an interface address on the SiteManager, and _FORMAT_ is one of _html_, _json_, or _text_.
Without any _FILTER_ selectors, the entire troubleshoot information is returned for the URL. When you add one or more _FILTER_ selectors, only the selected sections are returned. Possible filter selectors are: _gm_, _agents_, _routes_, _ifaces_, _dns_, _dhcp_, _probe_, _io_, and _vpn_. The _dns_, _dhcp_, and _probe_ selectors are only used with _ifaces_. When you specify a filter, the legend section and all help-texts are omitted unless you also specify _legend_ and/or _help_, resp.
Example: To get just the GateManager and IO-port status in JSON format, use
    https://10.0.0.1/tshoot?format=json&filter=gm+io
For backward compatibility, the following URL syntax is also supported:
    https://_IPADDR_/tshoot?_FORMAT_[+_FILTER_[+_FILTER_]...]
---
## Log
This SiteManager has a system log file which is kept in RAM and which can only contain 500 KByte.
If the log exceeds this limit, it is truncated by removing the oldest messages in the log. The log is also cleared on each reboot.
### Log > Setup
- **Log Debug Messages**
Setting this to _Yes_ means that the frequent and often very verbose debug log messages will be recorded in the system log.
_Note: Enabling this may in some cases reduce the overall system performance, so it is recommended to only enable this if you are actually trying to resolve a specific problem, and need additional system information to do so._
- **System Watchdog**
The system watchdog constantly monitors that various critical system processes are running, and automatically restarts the SiteManager if one of these processes terminates unexpectedly.
### Log > View
This displays the entire log, and scroll the browser window to the last page of the log.
The time-stamp on the last line of the log shows when the log was displayed.
Below the log, there is a form which allows you to apply a view filter to the log; in the **Filter:** text box you can specify a string with _wildcards_ that must be present in the log messages that you want to view. The wildcard characters are: "*" which matches any string (including the empty string), and "?" which matches any single character. For example, to match any IP address in a specific subnet, use "10.0.1.*".
Then press "Apply" to view the filtered log; press "Apply" again to refresh.
To view the entire log again, press "View All". You can also press this to refresh the log, or refresh by pressing "View" again on the 2nd-level menu - or by using Refresh on your browser.
### Log > Clear
Force-clear the log.
### Log > Chat / Scratchpad
The SiteManager's integrated Chat / Scratchpad function can be used either as a simple per-SiteManager information scratchpad, or it can be used as an interactive chat feature (or both).
When you hit the **Send** button, whatever text is entered in the **Message** field is added to the scratchpad with the current time and date (UTC time), and the **Initials** that you have supplied to identify yourself as the author of the message.
Several users can open the Log > Chat panel simultaneously, and other users will automatically see your updates to the Scratchpad when you submit them. Likewise, you will automatically see any messages submitted by those other users.
For example an on-site technician using the SiteManager's web interface can chat with a GateManager (or LinkManager) user that uses the Go To Appliance function to open the Chat panel.
If your text contains a web link starting with http:// or https://, the link is automatically made clickable.
You can also include an image reference in the scratchpad if you enter the link on a separate line formatted as:
**/IMAGE http://your.image.site/your-image-name**
To clear the entire scratchpad, submit a message where the first line starts with this text:
**/CLEAR**
_Notice: All submitted messages are logged on the GateManager server (if SiteManager is connected to a GateManager)._
---
## Appendix A: 7-bit US-ASCII table
|Hex|ASCII|Hex|ASCII|Hex|ASCII|Hex|ASCII|Hex|ASCII|Hex|ASCII|
|---|---|---|---|---|---|---|---|---|---|---|---|
|20|space|30|0|40|@|50|P|60|`|70|p|
|21|!|31|1|41|A|51|Q|61|a|71|q|
|22|"|32|2|42|B|52|R|62|b|72|r|
|23|#|33|3|43|C|53|S|63|c|73|s|
|24|$|34|4|44|D|54|T|64|d|74|t|
|25|%|35|5|45|E|55|U|65|e|75|u|
|26|&|36|6|46|F|56|V|66|f|76|v|
|27|'|37|7|47|G|57|W|67|g|77|w|
|28|(|38|8|48|H|58|X|68|h|78|x|
|29|)|39|9|49|I|59|Y|69|i|79|y|
|2A|*|3A|:|4A|J|5A|Z|6A|j|7A|z|
|2B|+|3B|;|4B|K|5B|[|6B|k|7B|{|
|2C|,|3C|<|4C|L|5C|\|6C|l|7C|\||
|2D|-|3D|=|4D|M|5D|]|6D|m|7D|}|
|2E|.|3E|>|4E|N|5E|^|6E|n|7E|~|
|2F|/|3F|?|4F|O|5F|_|6F|o|
---
## Appendix D: Specification of Appliance Name Format strings
In a format string, most ordinary characters stand for themselves, with the following exceptions:
- **%** (percent) together with the following character denotes a _field substitution_, and
- **{** (left curly brace) starts a grouping, choice, or conditional _block_.
Inside a _block_ the following charachters also have a special meaning:
- **|** (vertical bar) separates choices in a choice list, and
- **}** (right curly brace) denotes the end of the block started by the most recent **{** character.
A block enclosed in a pair of curly braces **{** ... **}** is _discarded_ from the resulting string if _all_ field substitutions in the block (and all nested blocks) result in empty strings.
For example, if **%p** may expand to a port number or the empty string, the format **{:%p}** will only add the colon to the resulting string if **%p** expands to a non-empty port number.
Likewise, each of the choices in a choice list **{** ... **|** ... **|** ... **}** are expanded (left to right), and only the first choice that results in a non-empty field subsitution is added to the resulting string.
For example if "%A" expands to the empty string, while "%B" expands to "xyz", the format **{<%A>|[%B]}** expands to "[xyz]".
The following characters have a special meaning only if they immediately follow a **{** character:
- **?** (question mark) and **!** (exclamation mark) both start a conditional block, and
- **|** (vertical bar) starts an optional block.
A conditional block does not itself contribute to the resulting string, but may be used in a choice list to have one field substition depend on the value of another field substition. The **?** conditional test is true if any of the field substitions in the block produce a non-empty string, whereas the **!** condition is true only when all of the field substitions in the block produce empty strings.
For example, if "%A" and "%B" are as above, and "%C" expands to "123", the choice list **{{?%A}%B|%C}** expands to "123", while **{{!%A}%B|%C}** expands to "xyz".
An optional block is expanded as usual, but is discarded from the result if the surrounding blocks only produce empty field substitions.
For example, the result of **{{%A{|%B}}|%C}** is "123", since "%A" expands to the empty string in the block **{%A{|%B}}**. In contrast, **{%A|{%C{|%B}}}** expands to "123xyz".
To insert one of the special characters, prefix it with the **%** character, e.g. **%%** adds a single **%** to the resulting string.
The following **field substitution codes** are available in all format strings:
- **%N** - the **GateManager Appliance Name** string from GateManager > General.
- **%d** - the **GateManager Domain Token** string from GateManager > General.
- **%S** - the master SiteManager's _serial number_.
- **%U** - the master SiteManager's _serial number_ with all colons removed.
- **%D** - the **Device Name** string from System > General.
- **%C** - the **SysAdmin** contact (email address) from System > General.
- **%L** - the **Location** string from System > General.
- **%O** - the **Organization** string from System > General.
- **%V** - the version of the SiteManager's firmware.
- **%m** - A short-hand for the format string **{%N|%D|%S}**.
- **%H** - the hosting Windows System's host id (or host name), if applicable.
- **%W** - The SMS Wakeup number and code (if defined).
The following **field substitution codes** are available in the **Agent Name Format** string:
- **%M** - The result of expanding the **Master Name Format** string.
- **%n** - The agent's **Agent Name**.
- **%s** - The agent's **Serial Number**.
- **%u** - The agent's serial number without the _#xx_ part.
- **%#** - The _#xx_ part of the agent's serial number.
- **%a** - The agent's **Type**
- **%t** - The target address of device controlled by the agent; this is the first IP address in the agent's **Parameters** field.
- **%v** - The version of the agent firmware.
The following **field substitution codes** are available in the **Relay Name Format** string:
- **%M** - The result of expanding the **Master Name Format** string.
- **%n** - The relay's configured _Relay Name_.
- **%s** - The relay's serial number.
- **%u** - The relay's serial number without the _#xx_ part.
- **%#** - The _#xx_ part of the relay's serial number.
- **%a** - The relay's _protocol_ type.
- **%t** - The relay's _target address_, i.e. local device address for a Device Relay, and remote server address for a Server Relay.
- **%f** - The relay's _from address_, i.e. the remote virtual address for a Device Relay, and local virtual address for a Server Relay.
- **%r** - The relay's _remote address_.
- **%l** - The relay's _local address_.
- **%p** - The optional port number component of the last target/from/remote/local address expanded.
- **%>** - Expands to the ">" character for a Device Relay, and nothing for a Server Relay.
- **%<** - Expands to the "<" character for a Server Relay, and nothing for a Device Relay.
---
## Appendix E: Common SNMP Object IDs
|Object ID|Object Name|Reference|Comment|
|---|---|---|---|
|1.3.6.1.2.1.1.1.0|sysDescr|RFC1213 (MIB-2)|Description of the device.|
|1.3.6.1.2.1.1.3.0|sysUpTime|RFC1213 (MIB-2)|Time (sec/100) the device has been up.|
|1.3.6.1.2.1.1.5.0|sysName|RFC1213 (MIB-2)|Name of the device.|
|1.3.6.1.2.1.2.2.1.10.1|ifInOctets|RFC1213 (MIB-2)|Number of bytes received on (first) interface.|
|1.3.6.1.2.1.2.2.1.16.1|ifOutOctets|RFC1213 (MIB-2)|Number of bytes transmitted on (first) interface.|
|1.3.6.1.2.1.43.10.2.1.4.1.1|prtMarkerLifeCount|RFC1759 (printer-MIB)|Printer page counter.|
---
## Appendix F: Agent Type-Specific Parameters
### Vendor-specific Device Agents
The Vendor-specific Device Agents allow remote access to many well-known Ethernet and/or Serial attached devices using specific IP protocols and ports supported by each device type.
These agents support remote access via a LinkManager, through the GateManager Console "Go To Appliance" function (if supported by the device), and via automatically created static Device Relays on the GateManager.
In addition, these Agents may periodically send Ping requests to the device and makes the corresponding Agent Instance in the GateManager appear as "Connected" (Green) or "Failed" (Red) depending on whether the device responds to the pings or not.
_Note: Do not include any whitespace in any of the field values._
**Parameters** ( _field value_ ):
- **Device Address [Ethernet only]** ( _(first) ip_address_ ):
The IP address of the attached device.
If the address is specified as _.nnn_, it is automatically combined with the primary IP address of the first device interface. For example, if you specify .8 as the address, and the IP address of the interface is 10.0.0.1, the real target address is 10.0.0.8.
Specify the symbol "SM" to target the SiteManager 3339 itself.
- **Address on LinkManager** ( _(second) ip_address_ ):
Specifies an _alternate_ Device Virtual Address for the device when accessed via a remote _LinkManager_. Leave the field blank to use the Device Address (Ethernet attached) or SiteManager Local Address (Serial attached). Specify '#' to disable LinkManager access to this device.
- **Address on GateManager [Ethernet only]** ( gma=_ip_address_ ):
If non-empty, this fields specifies a static Device Virtual Address for the device when accessed via GateManager central server.
- **Baud Rate [Serial only]** ( _speed_ ):
Can be specified to override the default serial port speed for the attached device.
Supported values are: 300, 1200, 2400, 4800, 9600, 9600, 19200, 19200, 38400, 57600, 115200.
- **Data,Parity,Stop [Serial only]** ( _DPS_ ):
Can be specified to override the default serial port setting for number of databits _D_ (7 or 8), parity _P_ (N=none, E=even, O=odd), and stopbits _S_ (1 or 2).
- **Always On [Ethernet only]** ( -on ):
Disable the normal ping-based checking for the presence of the device, and just assume that the device is online.
A serial device is always assumed to be online; if you need to explicitly monitor a serial device, use the custom Serial agent.
- **Extra TCP ports** ( _port,port-port,..._ ):
If the standard vendor agent does not include all the necessary tcp port(s) you can add them here.
- **Extra UDP ports** ( _port,port-port,..._ ):
If the standard vendor agent does not include all the necessary usp port(s) you can add them here.
- **Extra GTA Service** ( _service,port_ ):
If the standard vendor agent does not include the service(*) necessary you can add it here. Only one extra service can be added. To add and extra service make sure that the needed port is also added to the Extra TCP ports option above.
Example: If a device has a web interface and you want to add this service you add the "http,80" to the Extra GTA Service and you add "80" to the Extra TCP ports field.
(*) A GTA service enables you to launch a service like http (WEB access) direct with a mouse-click from the LinkManager GUI.
- **Enable WWW/VNC/RDP service:** ( +http, +vnc, +rdp ):
Check mark this field and the http/vnc/rdp service will be included for this agent if not already defined.
The option "LinkManager Only" means that this service will only be available when you make a connect from a LinkManager console; i.e. LinkManager Mobile and GateManager Portal will NOT show the service.
You can check the "No OUTPUT1 signal" option, if you don't want the **OUT 1** port to go ON [Remote Service Alert] when using Go To Appliance from GateManager portal, from the LinkManager console domain view, or LinkManager Mobile.
_NOTE:_ When enabling WWW, both HTTP and HTTPS GTA sessions will be established as encrypted and authenticated connections between your browser and the GateManager, and not the end-device. So observe the following:
a) For HTTPS sessions the end device's TLS certificate is accepted by the GateManager acting as HTTPS client towards the end device and the validity of the certificate can therefore not be verified by your browser. Be careful using the "WWW Service" option if there is a risk that an end device could be maliciously exchanged for another device.
b) Information that your browser may store locally based on a session with one end device via the "WWW Service" option may be transmitted to other end devices. If you use the "WWW Service" option to manage devices with different security levels or in different organisations, we recommend establishing connections via the WWW Service with the browser in Incognito mode.
- **Custom Settings:**
This field is used for special settings like those listed below; normally you should leave this field blank.
- **+NBC** - Use Network Broadcasts
If your vendor software uses UDP broadcasts for device discovery, and it fails to find a device, you can try to add this option to try a diffent kind of broadcasts.
- **+noproxy** - Inhibit GateManager HTTPS/HTTP proxying for this device.
If the web browser in your device for some reason is unable to handle or support the GateManager's automatic GoToAppliance HTTPS proxy for HTTP connections, you can add this option to use plain HTTP to access the device via the GoToAppliance function in GateManager Portal and LinkManager Mobile. Please note that this will disable the encryption of the connection between the browser and GateManager.
- **-X** - Exclusive access
If your vendor software requires exclusive access to the device (via the LinkManager), you can add this option to the custom settings.
### Generic Agents
The Generic Agents are typically used to quickly connect a new device for which no vendor-specific agent is currently defined.
These agents simply allows a LinkManager to connect to all TCP and UDP ports on the device, and may also open for TCP connections from the device back to the LinkManager PC.
The following generic agents are defined:
- **NAT All, 1-way**:
Allow all ports from LinkManager to device, use SiteManager address as source (NAT).
- **NAT All, 2-way**:
Allow all ports from LinkManager to device, and all tcp-ports from device to LinkManager; use SiteManager address as source (NAT).
- **Transparent**:
Allow all ports from LinkManager to device, and all tcp-ports from device to LinkManager; use LinkManager address as source (no NAT).
This typically requires that the device is setup to use the SiteManager as default gateway.
### The AKA2XX Agent
The AKA2xx Agent is used for monitoring the status of a Danfoss AKA 244 or similar Gateway device connected to the Serial port.
**Parameters** ( _field value_ ):
- **Query Interval** ( -m_T_ ):
Specify the period (in minutes) used by the Agent to actively poll the Gateway if there has been no traffic from it in the previous period. The default period is _T_=10 minutes.
### The Device Agent
The Device Agent allows remote access to an network-attached device, via a LinkManager or GateManager device relay, using the IP/TCP and IP/UDP protocols.
The Device Agent also supports accessing the device through the GateManager Console "Go To Appliance" function.
In addition, the Device Agent periodically sends Ping or Snmp requests to the device and makes the corresponding Agent Instance in the GateManager appear as "Connected" (Green) or "Failed" (Red) depending on whether the device responds to the pings or not.
**Parameters** ( _field value_ ):
- **Device Address** ( _ip_address_ ):
The IP address of the attached device, e.g. 11.22.33.44.
If the address is specified as _.nnn_, it is automatically combined with the primary IP address of the first device interface. For example, if you specify .8 as the address, and the IP address of the interface is 10.0.0.1, the real target address is 10.0.0.8.
- **Address on LinkManager** ( dva=_ip_address_ ):
Specifies an _alternate_ Device Virtual Address for the device when accessed via a remote _LinkManager_. Leave the field blank to use the Device Address. Specify '#' to disable LinkManager access to this device.
- **Address on GateManager** ( sva=_ip_address [: [tcp_port,...] [/udp_port,...]]_ ):
If non-empty, this fields specifies a static Device Virtual Address for the device when accessed via GateManager central server.
- **TCP Ports** ( tcp=port,port-port,.... ):
If non-empty, this field specifies the TCP ports on the device that can be accessed via a remote LinkManager. A * specifies all ports.
- **UDP Ports** ( udp=port,port-port,.... ):
If non-empty, this field specifies the UDP ports on the device which can be accessed via a remote LinkManager. A * specifies all ports.
- **Always On** ( -on ):
Disable the normal ping-based checking for the presence of the device, and just assume that the device is online.
- **Enable Server** ( -S ):
Allow attached device to make TCP connections to the remote _LinkManager_.
- **Transparent** ( -T ):
Disable the normal network address translation using the local interface's IP address as source address when connecting from a remote LinkManager to the device.
Instead, to facilitate protocols which require transparent operation (such as FTP), the source adddress from the remote LinkManager's is used as source address.
_Note that this only works for devices attached to the DEV1 interface._
- **Exclusive Access** ( -X ):
Allow only one LinkManager at a time to access this device; if a second LinkManager tries to connect, the connection will be rejected.
- **Idle Timeout** ( -i_T_ ):
Connection idle timeout (in minutes). If no traffic is exchanged on a connection in _T_ minutes, automatically close the connections. Default is 10 minutes.
- **Max Connections** ( conn=_N_ ):
Allow maximum _N_ simultaneous connections to the device through this agent. Default is 5 connections.
- **Service** ( serv=_service_ ):
Optional service name for the "Go To Appliance" functionality. This service is associated with the first port in the TCP ports field.
_Note:_ If the service requires more than one open port to function properly, it can only really be used when an LinkManager connection is activated to the device; in this case, you can add a "-" prefix (e.g. -http) to exclude the service from the normal Go To Appliance drop-down list in the GateManager console and the service icon in the LinkManager console domain/appliance view.
- **User Name** ( user=_name_ ):
Optional user name for automatic login.
- **Password** ( pass=_secret_ ):
Optional password for automatic login.
- **Path** ( path=_path_ ):
Optional path component added to the "Go To Appliance" URL.
- **Use SNMP** ( +snmp ):
Query device using Snmp rather than Ping.
- **SNMP Profile** ( oid=_profile_ ):
Here you can specify an additional list of Object IDs (in the form of an SNMP Profile) whose values you want the Agent to retrieve and forward to the GateManager. If you don't select an SNMP profile, the agent only uses SNMP to test for the presence of the agent.
On the GateManager, you can create Alert Rules that react on these values.
- **Community** ( -c_name_ ):
The name by which the SNMP Agent will identify itself to the device. The default community is "public".
- **Poll Interval** ( -t_Interval[,Retries[,Timeout]]_ ):
Specifies how often the agent will send a simple SNMP request to the device to check for its presence. The _Interval_ is the time between polls (in seconds), _Retries_ specifies how many polls to send (if device does not respond), and _Timeout_ is the number of seconds to wait between the poll retries if device does not respond. The defaults are 60 seconds interval, 3 retries, and 10 seconds timeout.
- **Status Update Interval** ( -s_Interval_ ):
Specifies how often the agent will send a full SNMP request to the device to update the available status for all objects in the SNMP profile. The _Interval_ is the time between updates (in seconds).
_Note:_ A full SNMP request is always performed before sending a heartbeat to the GateManager.
### The Forwarding Agent
The Forwarding Agent allows devices (like PLCs, PCs or servers) to communicate, even when they are connected to separate interfaces of the SiteManager.
**Typical use:**
The forwarding agent is used when a local server on the Uplink network needs to collect data from devices attached to the Device network (DEV), or when a device on the Device network needs to submit log data to a server on the Uplink network.
**Activation:**
When configured correctly the forwarding agent is always ON and does not need to be activated by a LinkManager connection.
**Notice:** The Forwarding Agent will not show up in the GateManager Console or the LinkManager Console.
**Forwarding Rule Format**
Each forwarding rule must be combined from a number of elements as follows (see examples below):
[#|?] [[IN_IFACE*] [$LOCAL_IP]:] [PROTOCOL:] [SOURCE_IP[/MASK]:] [NAT_PORT] >[>] [OUT_IFACE[*]:] TARGET[/MASK] [:TARGET_PORT]
Elements in [...] are optional.
_NOTE: Spaces are not allowed in the rule (they are inserted above for readability purposes)._
- **#** :
A leading number sign in a rule specifies that the rule is disabled (i.e. to be ignored).
- **?** :
A leading question mark specifies an optional rule, meaning that any errors related to this rule should not be treated as fatal (i.e. rule is ignored in case of errors).
- **IN_IFACE / LOCAL_IP** ( [_interface name_[*]][$_local IP_] ):
This specifies the incoming interface (and/or local IP address/alias) for the connection; if omitted, it defaults to opposite of OUT_IFACE (if set), else UPLINK*. The * is a wildcard meaning any interface of the specified type, e.g. UPLINK* or DEV*.
The $ character is both a separator (if IN_IFACE is also specified) and is used to differentiate LOCAL_IP from the SOURCE_IP element.
- **PROTOCOL** ( _protocol_ ):
This specifies the network protocol, either TCP, UDP, or ANY; if omitted, it defaults to TCP.
When **ANY** is used in a rule with either NAT_PORT or TARGET_PORT, it means "both TCP and UDP"; otherwise it means "any IP protocol".
- **SOURCE_IP** ( _ip address_[/_mask_] or _hostname_ ):
This specifies a source IP address or subnet filter for this rule.
_Note: A hostname must start with a lower-case letter, a dash or a digit._
- **NAT_PORT** ( _port number[-number]_ ):
This specifies the original destination port number (range) for port forwarding targeted at the IN_IFACE. Port forwarding means that traffic addressed to that specific port (range) on a SiteManager interface is translated and forwarded to a specific external target and port with translation.
**Notice:**If you add a port forwarding rule for TCP port 443, this will disable access to the SiteManager WEB GUI from the rule's incoming interface. You can still access the WEB GUI using another interface or via the Appliance Launcher, or - if connected remotely - via LinkManager or GateManager.
- **> or >>** :
A double >> separator indicates that source NAT translation should be applied for traffic forwarded by this rule, making the SiteManager the source of the forwarded traffic.
A single > indicates no source translation.
- **OUT_IFACE** ( _interface name_[*] ):
This specifies the outgoing interface for the connection; if omitted, it defaults to opposite of IN_IFACE (if set), else DEV*. The * is a wildcard meaning any interface of the specified type, e.g. UPLINK* or DEV*.
- **TARGET** ( _ip address_[/_mask_] or _hostname_ ):
The TARGET part specifies the allowed IP address or subnet for the connection on the "other side" of the SiteManager.
- **TARGET_PORT** ( _port number[-number]_ ):
For a port forwarding rule (if NAT_PORT is specified), it specifies the target port (range) for the forwarded traffic; if omitted it defaults to the NAT_PORT.
Note: If a port range is specified in NAT_PORT do _not_ specify a port range here.
Otherwise, the TARGET_PORT part specifies the allowed target port number(s) on the target system.
**Example:**
A data logger on the Uplink network needs to access two different devices attached to the DEV interface, both using TCP port 80 (WEB server).
The UPLINK interface has only one IP address, so the port option needs to specify using, say, port 80 for the first device and port 81 for the second device.
The two forwarding rules in the forwarding agent configuration will look like this:
    UPLINK*:TCP:80>>192.168.1.2:80 (or just 80>>192.168.1.2:80)
    UPLINK*:TCP:81>>192.168.1.3:80 (or just 81>>192.168.1.3:80)
With these rules, the Forwarding Agent will forwarding connections to ports 80 and 81 on the UPLINK IP address to port 80 on devices 192.168.1.2 and 192.168.1.3, respectively.
**Optional parameters** ( _field value_ ):
- **Enable UPLINK Source Translation** ( +TUP ):
When this option is set, the Forwarding agent will apply Source NAT to all connections forwarded out through an UPLINK interface (from a device on a DEV interface), regardless of the > or >> settings in the forwarding rules. This means that the target system will see the SiteManager UPLINK IP address as the source address rather than the original Device IP address.
You will usually enable this option when creating outbound forwarding rules (from DEV to UPLINK). If not enabled, you probably need to configure static routes on the target system pointing at the UPLINK IP address, in order for the target system to determine the gateway back to the device.
- **Enable DEV Source Translation** ( +TDEV ):
When this option is set, the Forwarding agent will apply Source NAT to all connections forwarded out through a DEV interface (from a system on an UPLINK interface), regardless of the > or >> settings in the forwarding rules. This means that the target device will see the SiteManager DEV IP address as the source address rather than the original system's IP address. You will usually enable this option when creating inbound forwarding rules (from UPLINK to DEV).
- **DNS recheck interval (minutes)** ( DNSPOLL=_minutes_ ):
This number specifies the time interval between which, all DNS names used in the rules, are being reaffirmed. If a DNS name to IP address mapping has changed, the corresponding rules are also updated. If the DNS name no longer can be found, the rule is not updated. The value 0 means that DNS names are never reaffirmed. This is the default value.
### The Http Agent
The HTTP Agent allows the GateManager Administrator to access a the Web interface of a network-attached device through the GateManager Console "Go To Appliance" function.
In addition, the HTTP Agent periodically sends Ping requests to the device and makes the corresponding Agent Instance in the GateManager appear as "Connected" (Green) or "Failed" (Red) depending on whether the device responds to the pings or not.
**Parameters** ( _field value_ ):
- **Device Address** ( _ip_address[:port]_ ):
The IP address of the attached device with optional port number, e.g. 11.22.33.44:80.
If the address is specified as _.nnn_, it is automatically combined with the primary IP address of the first device interface. For example, if you specify .8 as the address, and the IP address of the interface is 10.0.0.1, the real target address is 10.0.0.8.
- **Address on LinkManager** ( dva=_ip_address_ ):
Specifies an _alternate_ Device Virtual Address for the device when accessed via a remote _LinkManager_. Leave the field blank to use the Device Address. Specify '#' to disable LinkManager access to this device.
- **Address on GateManager** ( sva=_ip_address_ ):
If non-empty, this fields specifies a static Device Virtual Address for the device when accessed via GateManager central server.
- **Always On** ( -on ):
Disable the normal ping-based checking for the presence of the device, and just assume that the device is online.
- **Idle Timeout** ( -i_T_ ):
Connection idle timeout (in minutes). If no traffic is exchanged on a connection in _T_ minutes, automatically close the connections. Default is 10 minutes.
- **Max Connections** ( conn=_N_ ):
Allow maximum _N_ simultaneous connections to the device through this agent. Default is 5 connections.
- **HTTPS** ( -https ):
Select the https protocol rather than http (implies that the traffic is assumed to be encrypted, so no additional encryption is performed)
- **Bypass HTTPS proxy** ( +noproxy ):
Inhibit the HTTPS to HTTP/HTTPS proxy function in GateManager. This may be necessary if client software does not support HTTPS.
- **Service** ( serv=_service_ ):
Optional service name for the "Go To Appliance". Default is "http" (or "https").
- **User Name** ( user=_name_ ):
Optional user name for automatic login.
- **Password** ( pass=_secret_ ):
Optional password for automatic login.
- **Host** ( host=_hostname or ip address_ ):
Optional direct connection address to the device; if specified, do not connect via the GateManager proxy.
- **Path** ( path=_path_ ):
Optional path component added to the "Go To Appliance" URL.
- **Flags** ( flag=_flags_ ):
Control flags for connections. The value is the sum of the following integer values:
**1:**encrypt data, **2:**close proxy port after first connect.
### The Modem Agent
The Modem Agent is used for connecting to a remote modem-attached serial device on a specific telephone number via a dial-out modem attached to the Serial port.
The Modem agent is "always on" (as we cannot monitor the remote serial device anyway).
Notice that Modem Agents will _not_ be connected if you do "Connect All" from a LinkManager, This allows several instances of the Modem agent (with different telephone numbers) to share the same modem attached to the serial port, as you have to explicitly connect to the relevant modem instance to reach a specific remote location.
**Parameters** ( _field value_ ):
- **Address on LinkManager** ( dva=_ip_address_ ):
Specifies an _alternate_ Device Virtual Address for the device when accessed via a remote _LinkManager_. Leave the field blank to use the SiteManager Local Address. Specify '#' to disable LinkManager access to this device.
- **Telephone Number** ( tno=_phone_number_ ):
If non-empty, any data sent _to_ the serial port is analyzed, looking for dial-out commands (ATD, ATDT, ATDP), and if found, the telephone number specified in the dial-out command is substituted by the _phone_number_ specified here. This means that any random telephone number can be used by the remote application, and still reach the proper remote device.
_Caveat:_If the modem is set to echo command characters, the application dialing out will receive the substituted phone number rather than the original phone number it sent itself; this may confuse some applications.
- **Service** ( serv=_service_ ):
Optional service name for the "Go To Appliance". Default is "telnet".
- **User Name** ( user=_name_ ):
Optional user name for automatic login.
- **Password** ( pass=_secret_ ):
Optional password for automatic login.
- **Flags** ( flag=_flags_ ):
Control flags for serial connections. The value is the sum of the following integer values:
**1:** do not encrypt data, **2:** do not close proxy port after first connect.
- **Service 2** ( serv2=_service_ ):
Optional secondary service name for the "Go To Appliance". Default is "raw".
- **User Name 2** ( user2=_name_ ):
Optional user name for automatic login to the secondary service.
- **Password 2** ( pass2=_secret_ ):
Optional password for automatic login to the secondary service.
- **Flags 2** ( flag2=_flags_ ):
Proxy control flags for serial connections to the secondary service.
### The PC Agent
The PC Agent allows the GateManager Administrator to access a network-attached PC through the "Go To Appliance" function, as well as remote access via a LinkManager.
In addition, the PC Agent periodically sends Ping requests to the PC and makes the corresponding Agent Instance in the GateManager appear as "Connected" (Green) or "Failed" (Red) depending on whether the PC responds to the pings or not.
**Parameters** ( _field value_ ):
- **Device Address** ( _ip_address_ ):
The IP address of the PC.
If the address is specified as _.nnn_, it is automatically combined with the primary IP address of the first device interface. For example, if you specify .8 as the address, and the IP address of the interface is 10.0.0.1, the real target address is 10.0.0.8.
- **Address on LinkManager** ( dva=_ip_address_ ):
Specifies an _alternate_ Device Virtual Address for the device when accessed via a remote _LinkManager_. Leave the field blank to use the Device Address. Specify '#' to disable LinkManager access to this device.
- **Always On** ( -on ):
Disable the normal ping-based checking for the presence of the PC, and just assume that it is online. You may need to do this if the PC has a local firewall which does not allow the PC to respond to Ping requests.
- **MS Remote Desktop** ( +rdp ):
Enable remote access to MicroSoft Remote Desktop service of the PC.
Corresponding GateManager GoToAppliance service name is "rdp".
- **VNC Remote Desktop** ( +vnc ):
Enable remote access to VNC Remote Desktop service of the PC.
Corresponding GateManager GoToAppliance service name is "vnc".
- **Netop Remote Desktop** ( +netop ):
Enable remote access to Netop Client-to-Client Remote Desktop service of the PC.
Corresponding GateManager GoToAppliance service name is "netop".
- **HTTP Server** ( +http ):
Enable remote access to an HTTP server on the PC.
Corresponding GateManager GoToAppliance service name is "http".
- **HTTPS Server** ( +https ):
Enable remote access to an HTTPS server on the PC.
Corresponding GateManager GoToAppliance service name is "https".
- **Bypass HTTPS proxy** ( +noproxy ):
Inhibit the HTTPS to HTTP/HTTPS proxy function in GateManager. This may be necessary if client software does not support HTTPS.
- **User Name** ( user=_name_ ):
Optional user name for automatic login. Default is no user name.
- **Password** ( pass=_secret_ ):
Optional password for automatic login. Default is no password.
- **Custom Settings**:
The target ports for each of the above services can be modified by adding a custom setting like _service_=_port_, e.g. vnc=5610.
### The Ping Agent
The Ping Agent periodically sends Ping requests to a specified network-attached device and makes the corresponding Agent Instance in the GateManager appear as "Connected" (Green) or "Failed" (Red) depending on whether the device responds to the pings or not.
**Parameters** ( _field value_ ):
- **Target Address** ( _ip_address_ ):
The IP address of the attached device, e.g. 11.22.33.44.
If the address is specified as _.nnn_, it is automatically combined with the primary IP address of the first device interface. For example, if you specify .8 as the address, and the IP address of the interface is 10.0.0.1, the real target address is 10.0.0.8.
- **Ping Interval** ( -t_Interval[,Retries[,Timeout]]_ ):
Specifies how often the agent will ping the target address to see if the device is alive. The _Interval_ is the time between checks (in seconds), _Retries_ specifies how many pings to send (if device does not respond), and _Timeout_ is the number of seconds to wait between the ping retries if device does not respond. The defaults are 60 seconds interval, 3 retries, and 10 seconds timeout.
### The Scada Agent
The Scada Agent allows upto 3 local Scada systems on the UPLINK interface of a SiteManager to connect to devices on the SiteManager DEV networks.
**Notice:** Neither the Scada Agent, nor the Scada PCs can be managed from GateManager via this agent.
**Parameters** ( _field value_ ):
- **Scada Address 1** ( _ip_address_ ):
The IP address of the first Scada PC.
- **Scada Address 2** ( _ip_address_ ):
The IP address of the second Scada PC.
- **Scada Address 3** ( _ip_address_ ):
The IP address of the third Scada PC.
- **Enable UPLINK Source Translation** ( +TUP ):
When this option is set, the Scada agent will apply Source NAT to all connections forwarded out through an UPLINK interface (from a device on a DEV interface). This means that the target system will see the SiteManager UPLINK IP address as the source address rather than the original Device IP address.
- **Enable DEV Source Translation** ( +TDEV ):
When this option is set, the Scada agent will apply Source NAT to all connections forwarded out through a DEV interface (from a system on an UPLINK interface). This means that the target device will see the SiteManager DEV IP address as the source address rather than the original system's IP address.
### The Serial Agent
The Serial Agent is used for accessing and monitoring the status of a device connected to the Serial port.
**Parameters** ( _field value_ ):
- **Address on LinkManager** ( dva=_ip_address_ ):
Specifies an _alternate_ Device Virtual Address for the device when accessed via a remote _LinkManager_. Leave the field blank to use the SiteManager Local Address. Specify '#' to disable LinkManager access to this device.
- **Address on GateManager** ( sva=_ip_address_ ):
If non-empty, this fields specifies a static Device Virtual Address for the device when accessed via GateManager central server.
- **Telephone Number** ( tno=_phone_number_ ):
If non-empty, any data sent _to_ the serial port is analyzed, looking for dial-out commands (ATD, ATDT, ATDP), and if found, the telephone number specified in the dial-out command is substituted by the _phone_number_ specified here. This means that any random telephone number can be used by the remote application, and still reach the proper remote device.
_Caveat:_If the modem is set to echo command characters, the application dialing out will receive the substituted phone number rather than the original phone number it sent itself; this may confuse some applications.
- **Always On** ( -on ):
Assume that the serial device is always powered on and alive. This disables both query polls and DTR low checking.
- **Query String** ( poll=_string_ ):
When there has been no activity on the serial line for the time specified by the **Query Interval**, the serial agent sends this string on the serial line, expecting the attached device to send some response, indicating that it is alive; the response data are discarded. The query string should be harmless for the attached device, in the sense that it should simply cause the device to respond, but not perform any action.
The string can contain normal alpha-numeric characters, as well as control characters using the format **^C**, CR/NL/TAB as **\r**, **\n**, and **\t**, as well as arbitrary byte values specified in hexadecimal notation **\xx**. To include "\" or "^" in the string, double the character. To include a space, use "\20".
- **Query Interval** ( -m_T_ ):
Specify the period (in minutes) used by the Agent to actively poll the device if there has been no traffic from the device in the previous period. The default period is _T_=10 minutes.
- **Max DTR Low** ( -d_T_ ):
Normally, the Serial Agent will monitor the DTR pin on the serial connector to see if the attached device is powered on. Some devices will lower DTR for a brief period to disconnect the serial connection. To avoid interpreting this as a power down, the agent will ignore a DTR low condition that is shorter than the period (in seconds) specified by this parameter. The default is 60 seconds.
If this field is set to **0**, the state of the DTR pin is ignored (i.e. it is assumed that the device is always powered on).
- **Idle Timeout** ( -i_T_ ):
Automatically disconnect connections after _T_ minutes of inactivity. Default is 10 minutes. A value of **0** means no timeout.
- **Non-Exclusive** ( +X ):
Normally, the serial port can only be used by one LinkManager at a time; this allows simultaneous access from multiple LinkManagers.
- **Service** ( serv=_service_ ):
Optional service name for the "Go To Appliance". Default is "telnet".
- **User Name** ( user=_name_ ):
Optional user name for automatic login.
- **Password** ( pass=_secret_ ):
Optional password for automatic login.
- **Flags** ( flag=_flags_ ):
Control flags for serial connections. The value is the sum of the following integer values:
**1:** do not encrypt data, **2:** do not close proxy port after first connect.
- **Service 2** ( serv2=_service_ ):
Optional secondary service name for the "Go To Appliance". Default is "raw".
- **User Name 2** ( user2=_name_ ):
Optional user name for automatic login to the secondary service.
- **Password 2** ( pass2=_secret_ ):
Optional password for automatic login to the secondary service.
- **Flags 2** ( flag2=_flags_ ):
Proxy control flags for serial connections to the secondary service.
### The Snmp Agent
The Snmp Agent periodically sends SNMP requests to a specified network-attached device and makes the corresponding Agent Instance in the GateManager appear as "Connected" (Green) or "Failed" (Red) depending on whether the device responds to the requests or not.
**Parameters** ( _field value_ ):
- **Target Address** ( _ip_address[:port]_ ):
The IP address of the attached device with optional port number, e.g. 11.22.33.44:161.
If the address is specified as _.nnn_, it is automatically combined with the primary IP address of the first device interface. For example, if you specify .8 as the address, and the IP address of the interface is 10.0.0.1, the real target address is 10.0.0.8.
- **Community** ( -c_name_ ):
The name by which the SNMP Agent will identify itself to the device. The default community is "public".
- **SNMP Profile** ( oid=_profile_ ):
Here you specify a list of Object IDs (in the form of a SNMP Profile) whose values you want the Agent to retrieve and forward to the GateManager.
On the GateManager, you can create Alert Rules that react on these values.
- **Poll Interval** ( -t_Interval[,Retries[,Timeout]]_ ):
Specifies how often the agent will send a simple SNMP request to the device to check for its presence. The _Interval_ is the time between polls (in seconds), _Retries_ specifies how many polls to send (if device does not respond), and _Timeout_ is the number of seconds to wait between the poll retries if device does not respond. The defaults are 60 seconds interval, 3 retries, and 10 seconds timeout.
- **Status Update Interval** ( -s_Interval_ ):
Specifies how often the agent will send a full SNMP request to the device to update the available status for all objects in the SNMP profile. The _Interval_ is the time between updates (in seconds).
_Note:_ A full SNMP request is always performed before sending a heartbeat to the GateManager.
- **Enable HTTP** ( +http ):
Enable http access to the managed device.
### The TCP Agent
The TCP Agent allows remote access to an network-attached device using the IP/TCP protocol.
The TCP Agent supports remote access via a LinkManager and via a static device relay on GateManager, but it does not support accessing the device through the GateManager Console "Go To Appliance" function.
In addition, the TCP Agent periodically sends Ping requests to the device and makes the corresponding Agent Instance in the GateManager appear as "Connected" (Green) or "Failed" (Red) depending on whether the device responds to the pings or not.
**Parameters** ( _field value_ ):
- **Device Address** ( _ip_address[:port]_ ):
The IP address of the attached device and optional port numbers and port ranges, e.g. 11.22.33.44:80,443,8000-8005.
If the address is specified as _.nnn_, it is automatically combined with the primary IP address of the first device interface. For example, if you specify .8 as the address, and the IP address of the interface is 10.0.0.1, the real target address is 10.0.0.8.
- **Address on LinkManager** ( dva=_ip_address_ ):
Specifies an _alternate_ Device Virtual Address for the device when accessed via a remote _LinkManager_. Leave the field blank to use the Device Address. Specify '#' to disable LinkManager access to this device.
- **Address on GateManager** ( sva=_ip_address_ ):
If non-empty, this fields specifies a static Device Virtual Address for the device when accessed via GateManager central server.
- **Always On** ( -on ):
Disable the normal ping-based checking for the presence of the device, and just assume that the device is online.
- **Enable Server** ( -S ):
Allow attached device to make TCP connections to the remote _LinkManager_.
- **Transparent** ( -T ):
Disable the normal network address translation using the local interface's IP address as source address when connecting from a remote LinkManager to the device.
Instead, to facilitate protocols that require transparent operation (such as FTP), the source adddress from the remote LinkManager's is used as source address.
_Note that this only works for devices attached to the DEV1 interface._
- **Exclusive Access** ( -X ):
Allow only one LinkManager at a time to access this device; if a second LinkManager tries to connect, the connection will be rejected.
- **Idle Timeout** ( -i_T_ ):
Connection idle timeout (in minutes). If no traffic is exchanged on a connection in _T_ minutes, automatically close the connections. Default is 10 minutes.
- **Max Connections** ( conn=_N_ ):
Allow maximum _N_ simultaneous connections to the device through this agent. Default is 5 connections.
### The UDP Agent
The UDP Agent allows remote access to an network-attached device using the IP/UDP protocol.
The UDP Agent supports remote access via a LinkManager and via a static device relay on GateManager, but it does not support accessing the device through the GateManager Console "Go To Appliance" function.
In addition, the UDP Agent periodically sends Ping requests to the device and makes the corresponding Agent Instance in the GateManager appear as "Connected" (Green) or "Failed" (Red) depending on whether the device responds to the pings or not.
**Parameters** ( _field value_ ):
- **Device Address** ( _ip_address[:port[-port],port...]_ ):
The IP address of the attached device and optional port numbers and port ranges, e.g. 11.22.33.44:2222,4000-4005.
If the address is specified as _.nnn_, it is automatically combined with the primary IP address of the first device interface. For example, if you specify .8 as the address, and the IP address of the interface is 10.0.0.1, the real target address is 10.0.0.8.
- **Address on LinkManager** ( dva=_ip_address_ ):
Specifies an _alternate_ Device Virtual Address for the device when accessed via a remote _LinkManager_. Leave the field blank to use the Device Address. Specify '#' to disable LinkManager access to this device.
- **Address on GateManager** ( sva=_ip_address_ ):
If non-empty, this fields specifies a static Device Virtual Address for the device when accessed via GateManager central server.
- **Always On** ( -on ):
Disable the normal ping-based checking for the presence of the device, and just assume that the device is online.
- **Transparent** ( -T ):
Disable the normal network address translation using the local interface's IP address as source address when connecting from a remote LinkManager to the device.
Instead, to facilitate protocols that require transparent operation (such as FTP), the source adddress from the remote LinkManager's is used as source address.
_Note that this only works for devices attached to the DEV1 interface._
- **Exclusive Access** ( -X ):
Allow only one LinkManager at a time to access this device; if a second LinkManager tries to connect, the connection will be rejected.
- **Idle Timeout** ( -i_T_ ):
Connection idle timeout (in minutes). If no traffic is exchanged on a connection in _T_ minutes, automatically close the connections. Default is 10 minutes.
- **Max Connections** ( conn=_N_ ):
Allow maximum _N_ simultaneous connections to the device through this agent. Default is 5 connections.
### The Vnc Agent
The VNC Agent allows the GateManager Administrator to access a network-attached PC through the "Go To Appliance" function, as well as remote access via a LinkManager or a static device relay on GateManager.
In addition, the VNC Agent periodically tries to connect to the VNC service port on the PC and makes the corresponding Agent Instance in the GateManager appear as "Connected" (Green) or "Failed" (Red) depending on whether the PC accepts the connection or not.
**Parameters** ( _field value_ ):
- **Device Address** ( _ip_address[:display|::port]_ ):
The IP address of the PC with optional display or port number, e.g. 11.22.33.44:1 or 11.22.33.44:1234.
If neither _display_ nor _port_ is specified, the default target port is _5900_. If a display _D_ is specified, the port number is _5900+D_. If the address is specified as _.nnn_, it is automatically combined with the primary IP address of the first device interface. For example, if you specify .8 as the address, and the IP address of the interface is 10.0.0.1, the real target address is 10.0.0.8.
- **Address on LinkManager** ( dva=_ip_address_ ):
Specifies an _alternate_ Device Virtual Address for the device when accessed via a remote _LinkManager_. Leave the field blank to use the Device Address. Specify '#' to disable LinkManager access to this device.
- **Address on GateManager** ( sva=_ip_address_ ):
If non-empty, this fields specifies a static Device Virtual Address for the device when accessed via GateManager central server.
- **Always On** ( -on ):
Disable the normal ping-based checking for the presence of the PC, and just assume that it is online. You may need to do this if the PC has a local firewall which does not allow the PC to respond to Ping requests.
- **Ping Device** ( +ping ):
Use ICMP Ping requests instead of dummy TCP connects to query the device online state; this is less informative, as it doesn't really check whether it is possible to connect a VNC viewer to the device, but some VNC servers on some devices may have problems handling the dummy TCP connects.
- **No Close** ( -x ):
Allow VNC client to disconnect and reconnect via the GateManager connection. Normal VNC clients don't need this.
- **Idle Timeout** ( -i_T_ ):
Connection idle timeout (in minutes). If no traffic is exchanged on a connection in _T_ minutes, automatically close the connections. Default is 10 minutes.
- **Max Connections** ( conn=_N_ ):
Allow maximum _N_ simultaneous connections to the device through this agent. Default is 1 connection.
- **Service** ( serv=_service_ ):
Optional service name for the "Go To Appliance". Default is "vnc".
- **User Name** ( user=_name_ ):
Optional user name for automatic login. Default is "vnc".
- **Password** ( pass=_secret_ ):
Optional password for automatic login. Default is no password.