Each available item in the WAN Link Manager matches with the particular WAN interface. Depending on your hardware model, WAN links can be made up of either Wireless Wide Area Network (WWAN), Wireless LAN (WLAN), Ethernet or PPP over Ethernet (PPPoE) connections. Please note that each WAN link has to be configured and enabled in order to appear on this page.

In case a WAN link goes down, the system will automatically switch over to the next link in order of priority (the priorities can be changed using the arrows on the right side of the window). A link can be either established when the switch occurs or permanently to minimize link downtime.

Up to four priorities can be used.

Links are being triggered periodically and put to sleep in case it was not possible to establish them within a certain amount of time. Hence it might happen that permanent links will be dialed in background and replace links with lower priority again as soon as they got established. In case of interfering links sharing the same resources (for instance in dual-SIM operation) you may define a switch-back interval after which an active hotlink is forced to go down in order to let the higher-prio link getting dialed again.

Outgoing traffic can also be distributed over multiple links on a per IP session basis. Choose the option “distributed” as an Operation Mode with the appropriate Weight.

In the following example, the outgoing traffic will be distributed between LAN2 (80 %) and WWAN1 (20 %) links.

	Note
	This option is general and applies to all outgoing traffic. See Section 7.3.3, “Multipath Routes” for more detailed configuration.

We recommend using the permanent option for WAN links. However, in case of time-limited mobile tariffs, the switchover option should be used.

After clicking on the WWAN “Edit” button, you can additionally set the “IP passthrough” option for the selected LAN interface. The result is that the connected device over the selected LAN port will obtain M!DGE’s mobile IP address via DHCP. In another words, M!DGE will be transparent for the connected device and will only serve for the mobile connectivity. Typically, such connected device (e.g. firewall) will not need any special configuration facing M!DGE, it will just use its mobile IP address (usually the public IP address).

Once established, a small subnet containing the cellular IP is created, by default the netmask is 255.255.255.248. This small subnet consists of a network and broadcast address as a regular subnet. In some situations it may lead to unreachability of several remote hosts due to IP address overlapping. If this is the case, user can manually configure the APN network, e.g. 10.203.0.0/255.255.128.0.

In any case, the M!DGE unit is reachable via the default gateway automatically obtained from M!DGE by DHCP. The gateway IP address is set as the first available IP address after the specified APN address range. If not specified, it is the first usable IP within the /29 subnet.

Note

We recommend to define the APN network/netmask manually. There might be situations in which the default /29 disables the communication. E.g. WWAN IP is 10.10.10.6. The connected device obtains this IP via DHCP and sets the default gateway to 10.10.10.7 – but this IP is a broadcast IP within /29 subnet and the communication is not possible. If you configure subnet 10.10.10.0/29 manually, a default gateway would be 10.10.10.8 in newly created local /28 subnet.

Example: If the APN network is 10.203.0.0/17, the default gateway is set to 10.203.128.0. The web interface is reachable via this IP address over the selected LAN interface. The connected device’s network mask is /16 (1 bit wider), otherwise the default gateway would not be usable.

	Note
	This option is configurable within WWAN links only. Remember that LAN1 cannot be used as the port for the IP passthrough functionality. LAN10 is not usable within M!DGE routers. Do not select it.

Network outage detection can be used for switching between available WAN links and can be performed by sending pings on each link to authoritative hosts. A link will be declared as down if all trials have failed. The link will be considered up again if at least one host is reachable.

You may further specify an emergency action if no uplink can be established at all.

Configurable actions are:

The maximum segment size defines the largest amount of data of TCP packets (usually MTU minus 40). You may decrease the value in case of fragmentation issues or link-based limits.

This menu can be used to individual assigning of Ethernet ports to LAN interfaces if you want to have different subnets per port or to use one port as the WAN interface.

If it is desired to have both ports in the same LAN you may assign them to the same interface. Please note that the ports will be bridged by software and operated by running the Spanning Tree Protocol.

	Note
	If USB/ETH adapter is attached and enabled, LAN10 interface is configured with 10.9.8.7/28 IP address and DHCP enabled.

Link negotiation can be set for each Ethernet port individually. Most devices support auto negotiation which will configure the link speed automatically to comply with other devices in the network. In case of negotiation problems, you may assign the modes manually but it has to be ensured that all devices in the network utilize the same settings then.

M!DGE2 supports authentication via the IEEE 802.1X standard. This can be configured for each Ethernet port individually. Current 802.1X can operate only in a “client” mode, i.e. the port can be authenticated against some external RADIUS server.

The following options exist:

M!DGE routers support Virtual LAN according to IEEE 802.1Q which can be used to create virtual interfaces on top of the Ethernet interface. The VLAN protocol inserts an additional header to Ethernet frames carrying a VLAN Identifier (VLAN ID) which is used for distributing the packets to the associated virtual interface. Any untagged packets, as well as packets with an unassigned ID, will be distributed to the native interface. In order to form a distinctive subnet, the network interface of a remote LAN host must be configured with the same VLAN ID as defined on the router. Further, 802.1P introduces a priority field which influences packet scheduling in the TCP/IP stack.

The following priority levels (from the lowest to the highest) exist:

	Note
	The maximum number of VLAN tunnels/interfaces was increased from 4 to 10 in 4.6.40.102 software.

Two individual tabs will be used when different LANs are set in the Port settings menu. Each of them can be configured either in the LAN mode or in the WAN mode.

	Note
	The default IP address is 192.168.1.1/24 (LAN1).

Static configuration of M!DGE’s own IP address and Subnet mask is available for the LAN mode. The Alias IP address enables configuring the LAN interface with a second IP address/subnet.

	Note
	Setting of the IP address is interconnected with the DHCP Server (if enabled) – menu the SERVICES – DHCP Server menu.

When running in WAN mode, the interface can be configured with two IP versions in the following way:

Depending on the selected IP version, you can configure your interface with the following settings:

IPv4 Settings – the router can configure its IPv4 address via:

IPv6 Settings – the router can configure its IPv6 address via:

	Note
	You may configure MTU and MAC for any IP configuration option.

This page lists all available WWAN modems. They can be disabled on demand. Define number of antennas to match a current physical installation.

This page allows you to send Hayes AT commands to the modem. Besides the 3GPP-conforming AT command-set, further modem-specific commands can be applied (can be provided on demand). Some modems also support running Unstructured Supplementary Service Data (USSD) requests, e.g. for querying the available balance of a prepaid account.

The SIM page gives an overview about the available SIM cards, their assigned modems and the current state. Once a SIM card has been inserted, assigned to a modem and successfully unlocked, the card should remain in state ready and the network registration status should have turned to registered. If not, please double-check your PIN.

Please keep in mind that registering to a network usually takes some time and depends on signal strength and possible radio interferences. You may hit the Update button at any time in order to restart PIN unlocking and trigger another network registration attempt.

Under some circumstances (e.g. in case the modem flaps between base stations) it might be necessary to set a specific service type or assign a fixed operator. The list of operators around can be obtained by initiating a network scan (may take up to 60 seconds). Further details can be retrieved by querying the modem directly, a set of suitable commands can be provided on request.

A SIM card is generally assigned to a default modem but this may switch, for instance if you set up two WWAN interfaces with one modem but different SIM cards. Close attention has to be paid when other services (such as SMS or Voice) are operating on that modem as a SIM switch will affect their operation.

You can configure the following parameters:

PIN protection	Depending on the used card, it can be necessary to unlock the SIM with a PIN code. Please check the account details associated with your SIM whether the PIN protection is enabled.
PIN code	The PIN code for unlocking the SIM card
PUK code	The PUK code for unlocking the SIM card if the card was blocked due to several wrong PIN attempts.
Default modem	The default modem assigned to this SIM card.
Bands	The list of allowed bands to which the unit can connect. Up to four different bands for each service type (2G, 3G and 4G) can be selected. I.e., 12 in total.

Preferred service	The preferred service type to be used with this SIM card. The default option is “automatic”, in areas with interfering base stations you can force a specific type (e.g. 3G-only) in order to prevent any flapping between the stations around. Preferred service type is usually set in the WWAN Interface settings, not SIM settings. Settings in WWAN interface overrides this SIM settings.
Registration mode	The default option is set to “all networks”. You can limit the modem registration to “packet-switched only” (e.g. no Dial-in Server) or “circuit-switched only” option, which can be for example used for the Dial-in Server so one can use PPP over the Circuit-Switched Networks (analog modem style).
Network selection	LAI is a globally unique number that identifies the country, network provider and LAC of any given location area. It can be used to force the modem to register to a particular mobile cell in case of competing stations. You may further initiate mobile network scan for getting networks in range and assign a LAI manually.

This page can be used to manage your WWAN interfaces. The resulting link will pop up automatically on the WAN Link Management page once an interface has been added. The Mobile LED will be blinking during the connection establishment process and goes on as soon as the connection is up. Refer to the troubleshooting section or log files in case the connection did not come up.

The following mobile settings are required:

Please note that these settings supersede the general SIM based settings as soon as the link is being dialed.

Generally, the connection settings are derived automatically as soon as the modem has been registered and the network provider has been found in our database. Otherwise, it will be required to configure the following settings:

Further on, you may configure the following advanced settings:

USB administration cannot be disabled. Any supported USB converter can be attached and configured for example as another serial link (RS232, see Section 7.2.6, “Serial Port”). Another typical usage is the management access via USB/ETH Adapter Axago XA or XR. The same as for RipEX and RAy devices.

	Note
	Supported modules are pl2303, ch341, ftdi (quad-channel adapter), asix, pegasus and rndis.

Following parameter can be configured:

Click on the Refresh button in the tab Devices for displaying connected USB devices and add them with by clicking on the plus sign.

Modem emulator enables replacement for legacy dial-in / dial-out connections based on analog or GSM modems. M!DGE supports the Hayes AT Command set on the serial interface and behaves like a regular router.

You can easily replace your old Modem with M!DGE. There is also no need to configure the attached device as you can prepare the M!DGE accordingly.

The Phonebook configuration will keep the aliases of any Phone numbers so that you do not need to reconfigure your device and can use the original addressing scheme.

The port settings configuration is the same as with the Device Server – Section 7.2.6.1, “Device Server” except the Advanced settings called MTU and Idle size.

	Note
	More details in the Serial SCADA Protocols application note.

MTU

An incoming frame is closed at this size even if the stream of bytes continues. Consequently, a permanent data stream coming to the serial interface results in a sequence of MTU-sized frames sent over the network. The default value is set to 1400 bytes.

Idle size

Received frames on COM are closed when the gap between bytes is longer than the Idle value. This parameter defines the maximum gap (in milliseconds) in the received data stream. If the gap exceeds this value, the link is considered idle, the received frame is closed and forwarded to the network.

The default Idle size differs based on the serial baud rate configuration. Remember that the default Idle sizes are set to the minimal possible values:

Each SCADA protocol like Modbus, DNP3, IEC101, DF1 etc. has its unique message format, most importantly its unique way of addressing the remote units. The following text is valid for all M!DGE/RipEX units (further in this Section 7.2.6.3, “Protocol Server” referred to as a “Unit”) – the special properties for mobile cellular networks (e.g. limitation of broadcasting) are mentioned here. The basic task for the protocol server is to check whether a received frame is within the protocol format and is not corrupted. Most of the SCADA protocols are using some type of Error Detection Code (Checksum, CRC, LRC, BCC, etc.) for data integrity control, so each Unit calculates this code and checks it against the received one.

Cellular mobile network operates in IP environment, so the basic task for the Protocol server is to convert SCADA serial packets to UDP datagrams. The Address translation settings are used to define the destination IP address and UDP port. Then these UDP datagrams are sent to the M!DGE router, processed there and are forwarded as unicasts through the mobile network to their destination. When the gateway defined in the Routing table belongs to the Ethernet LAN, UDP datagrams are instead forwarded to the Ethernet interface. After reaching the gateway, the datagram is forwarded according to the Routing table.

When the UDP datagram reaches its final IP destination, it should be in a M!DGE or RipEX router again. It is processed further according to its UDP port. It can be delivered to the Protocol server where the datagram is decapsulated and the data received on the serial interface of the source unit are forwarded to COM. The UDP port can also be that of a Terminal server (RipEX) or any other special protocol daemon on Ethernet like Modbus TCP etc. The datagram is then processed according to the respective settings.

	Note
	All timeouts in the parameters described below are derived from the time when the packet is sent into the COM driver, i.e. it includes the transfer time of the packet. Take this into account especially when there is a low Baud rate set in the COM settings.

	Important
	If configuring the Protocol server together with VPN tunnels the “Poll response control” protocol specific parameter must be turned off.

	Important
	Only one Protocol server can be configured and utilized only on the primary RS232 interface (it is not supported on the COMIO RS232/485 interface). This 2nd COM port can be controlled by Device server or SDK functionality.

7.2.6.3.1. Common parameters

For any SCADA protocol, the Transport protocol and the specific port can be chosen. The default values is UDP port 8882. The unit listens on this port for incoming messages and forwards them to the Protocol server itself.

	Note
	Only UDP protocol is currently implemented.

The parameters described in this section are typical of most protocols.
There is only a link to them in description of the respective Protocol.

Mode of Connected device
List box: Master, Slave
Default = Master
The typical SCADA application follows the Master–Slave scheme where the structure of the message is different for the Master and Slave SCADA units. Because of that, it is necessary to set which type of SCADA unit is connected to the Unit.

	Important
	For the SCADA Master, set Master, for the SCADA Slave, set Slave.

• Master
  The SCADA Master always sends addressed messages to Slaves. Addressing is different for each SCADA protocol, so this is one of the main reasons why an individual Protocol server in each Unit for each SCADA protocol has to be used.

  • Broadcast
    List box: On, Off
    Default = Off
    Some Master SCADA units send broadcast messages to all Slave units. SCADA applications typically use a specific address for such messages. RipEX (Protocol utility) converts such messages into a customized IP broadcast and broadcasts it to all RipEX units resp. to all SCADA units within the network.

    	Note
    	Broadcasts in the cellular network are not possible, thus setting of broadcast functionality is not allowed with M!DGE units.

    If On, the address for broadcast packets in the SCADA protocol has to be defined:

    • Broadcast address format – List box Hex, Dec – format in which the broadcast address is defined.

    • Broadcast address – address in the defined format (Hex, Dec)

  • Address translation
    List box: Table, Mask
    Default = Mask
    In a SCADA protocol, each SCADA unit has a unique address, a “Protocol address”. In a cellular mobile network, each SCADA unit is represented by an IP address (typically that of the ETH interface) and a UDP port (that of the protocol daemon or the COM port server to which the SCADA device is connected via serial interface).
    A translation between the “Protocol address” and the IP address & UDP port pair has to be done. It can be done either via Table or Mask.
    Hence, a SCADA message received from the serial interface is encapsulated into a UDP/IP datagram, where the destination IP address and the destination UDP port are defined according to the settings of the Address translation.

    • Mask
      

      Translation using the Mask is simpler to set, however it has some limitations:
      − all IP addresses used have to be within the same network, which is defined by this Mask
      −the same UDP port is used for all the SCADA units, which results in the following:
        − SCADA devices on all sites have to be connected to the same interface
        − only one SCADA device can be connected to one COM port

      • Base IP
        Default = IP address of the ETH interface
        When creating the IP destination address of UDP datagram, in which the serial SCADA message received from COM is encapsulated, this is created, this Base IP is taken as the basis and only the part defined by the Mask is replaced by the ‘Protocol address’.

      • Mask
        Default = 255.255.255.0
        A part of the Base IP address defined by this Mask is replaced by the ‘Protocol address’. The SCADA protocol address is typically 1 byte, so Mask 255.255.255.0 is most frequently used.

      • UDP port (Interface)
        List box: COM, Manual
        This UDP port is used as the destination UDP port in the UDP datagram in which the serial SCADA packet received from COM1 is encapsulated. The default UDP port for COM can be used or the UDP port can be set manually. If the destination IP address belongs to a Unit and the UDP port is not assigned to COM (COM1(2) or to a Terminal server in case of RipEX) or to any special daemon running in the destination address, the packet is discarded.

        	Note
        	M!DGE use UDP port 8882 for its COM port.

    • Table
      The Address translation is defined in a table. There are no limitations such as when the Mask translation is used. If there are more SCADA units on the RS485 (e.g. with RipEX COM2) their interface, their “Protocol addresses” should be translated to the same IP address and UDP port pair, where the multiple SCADA units are connected. There are 3 possibilities how to fill in the line in the table:
      − One “Protocol address” to one “IP address” (e.g.: 56 −−> 192.168.20.20)
      − Range of “Protocol addresses” to one “IP address” (e.g.: 56 – 62 ===> 192.168.20.20)
      − Range of “Protocol addresses” to range of “IP addresses” (e.g.: 56 – 62 ===> 192.168.20.20 – 26). One option is to write only the start IP and a dash, the system will add the end address itself.

      • Protocol address
        This is the address which is used by the SCADA protocol. It may be set either in Hexadecimal or Decimal format according to the List box value.
        Protocol address length can be 1 byte, but for the DNP3 and UNI protocols support 2 bytes addresses.

      • IP
        The IP address to which Protocol address will be translated. This IP address is used as the destination IP address in the UDP datagram in which serial SCADA packet received from COM is encapsulated.

      • UDP port (Interface)
        This is the UDP port number which is used as the destination UDP port in the UDP datagram in which the serial SCADA message, received from COM, is encapsulated.

      • Note
        You may add a note to each address up to 16 characters long for your convenience. (E.g. “Remote unit #1”).

      • Active
        You may tick/un-tick each translation line in order to make it active/not active.

      • Modify
        Edit, Delete Add buttons allow to edit or to add or to delete a line. The lines can be sorted using up and down arrows.

• Slave
  The SCADA Slave typically only responds to Master requests, however in some SCADA protocols it can communicate spontaneously.
  Messages from the serial interface are processed in a similar way as the Master site, i.e. they are encapsulated in UDP datagrams, processed by the router inside the M!DGE unit and forwarded to the respective interface, typically to the mobile network.

  • Broadcast accept
    List box: On, Off
    Default = Off
    If On, broadcast messages from the Master SCADA device to all Slave units are accepted and sent to connected Slave SCADA unit.

    	Important
    	Broadcasting is not supported with mobile networks.

The administration page can be used to enable and disable firewalling. When turning it on, a shortcut can be used to generate a predefined set of rules which allow administration (over HTTP, HTTPS, SSH or TELNET) by default but block any other packets coming from the WAN interface. Please note that the specified rules are processed by order, that means, traversing the list from top to bottom until a matching rule is found. If there is no matching rule found, the packet is allowed.

This menu can be used to form address or port groups which can be later used for firewall rules in order to reduce the number of rules.

M!DGE can be configured with its Ethernet interfaces being bridged. In this case, the transparent firewall functionality can be configured to limit reachability of individual hosts connected to M!DGE based on their MAC addresses, i.e. units connected to ETH1 cannot communicate to units connected to ETH2.

Note

Asymmetric routing is when a packet takes one path to the destination and takes another path when returning to the source. These data were dropped by M!DGE2 firewall preceding 4.4.40.104 firmware release. It could cause temporary issues if RipEX Backup paths were configured in the network. It can be controlled now via CLI. The required parameter is “firewall.invalid_ip”. $ cli-set firewall.invalid_ip = 0 // enables assymetric routing $ cli-set firewall.invalid_ip = 1 // disables assymetric routing

The administration page lets you specify the interfaces on which masquerading will be performed. NAT will hereby use the address of the selected interface and choose a random source port for outgoing connections and thus enables communication between hosts from a private local area network towards hosts on the public network.

Inbound rules can be used to modify the target section of IP packets and, for instance, forward a service or port to an internal host. By doing so, you can expose that service and make it available from the Internet. You may also establish 1:1 NAT mapping for a single host using additional outbound rules.

	Note
	The rules are processed by order, that means, traversing the list from top to bottom until a matching rule is found. If there is no matching rule found, the packet will pass as is.

Outbound rules will modify the source section of IP packets and can be used to establish 1:1 NAT mappings but also to redirect packets to a specific service.

If enabled, OpenVPN client configurations will be started whenever a WAN link has been established. Server configuration will be started immediately after the bootup.

The router supports a single server tunnel and up to 4 client tunnels. You can specify tunnel parameters in standard configuration or upload an expert mode file which has been created in advance. Refer to section Section 7.5.1.3, “Client Management” to learn more about how to manage clients and generate the files.

	Note
	M!DGE can be running up to 4 OpenVPN tunnels in the Client mode, but only one tunnel in the Server mode.

Client Mode

Server Mode

Additional settings (compared to the client mode):

A server tunnel typically requires the following files:

	Important
	OpenVPN tunnels require a correct system time. Please ensure that all NTP servers are reachable. When using host names, a working DNS server is required as well.

Once you have successfully set up an OpenVPN server tunnel, you can manage and enable clients connecting to your service. Currently connected clients can be seen on this page, including the connect time and IP address. You may kick connected clients by disabling them.

In the Networking section you can specify a fixed tunnel endpoint address for each client. Please note that, if you intend to use a fixed address for a particular client, you would have to apply fixed addresses to the other ones as well.

You may specify the network behind the clients as well as the routes to be pushed to each client. This can be useful for routing purposes, e.g. in case you want to redirect traffic for particular networks towards the server. Routing between the clients is generally not allowed but you can enable it if desired.

Finally, you can generate and download all expert mode files for enabled clients which can be used to easily populate each client.

Operating in server mode with certificates, it is possible to block a specific client by “kicking” (disconnecting) him.

	Note
	The downloaded expert mode file needs to be unzipped and then individual client expert files can be uploaded to the respective routers.

	Note
	See the OpenVPN configuration example in our Application notes.

	Note
	Since the firmware 4.4.40.104, the maximum number of IPsec tunnels has increased from 4 to 10.

General

IKE Proposal

RACOM routers support IKEv1 or IKEv2 authentication via the pre-shared keys (PSK) or certificates within a public key infrastructure.

Using PSK requires the following settings:

Using Public Key Infrastructure requires similar settings, but the Operation mode must be configured.

Operation mode

Mode can be set either to “server” or “client”. As a “server” and once you have successfully set up an IPsec tunnel, you can manage and enable clients connecting to your service. It is possible to generate and download expert mode files for enabled clients which can be used to easily populate each client.

When using certificates you would need to specify the Operation mode. When run as the PKI client you can create a Certificate Signing Request (CSR) in the certificates section which needs to be submitted at your Certificate Authority and imported to the router afterwards. In the PKI server mode the router represents the Certificate Authority and issues the certificates for remote peers.

Using XAUTH the following settings can be made:

IPsec Proposal

Networks

When creating Security Associations, IPsec keeps track of routed networks within the tunnel. Packets are only transmitted when a valid SA with the matching source and destination network is present. Therefore, you may need to specify the networks behind the endpoints by applying the following settings:

	Note
	Since the firmware 3.7.40.103, the maximum number of networks for individual IPsec tunnels has increased from 4 to 10.

Excl. Networks

If IPsec is used as default gateway (Remote Network 0.0.0.0/0), this option can be used to exclude some subnet/network. I.e. IPsec is not used for this particular subnet/network.

	Note
	See the IPsec configuration example in our Application notes.

The arena scripting language offers a broad range of POSIX functions (like printf or open) and provides, together with tailor-made API functions, a simple platform for implementing any sort of applications to interconnect your favourite device or service with the router.

Here comes a short example:

/* This script prints short status and if the SMS section is setted properly, the status will be send even to your mobile phone :-)
 */
 
printf("------------------------------");
printf("\n\n");
printf(nb_status_summary(all));
printf("\n\n");
printf("------------------------------");
 
/* Please change the following number to your mobile phone number
 */
nb_sms_send("+420123456789", nb_status_summary(all));

A set of example scripts can be downloaded directly from the router, you can find a list of them in the appendix. The manual at menu SERVICES-Administration-Troubleshooting-SDK API gives a detailed introduction of the language, including a description of all available functions.

The current range of API functions can be used to implement the following features:

The SDK API manual at menu SERVICES-Administration-Troubleshooting-SDK API provides an overview but also explains all functions in detail.

Please note that some functions require the corresponding services (e.g. E-Mail, SMS) to be properly configured prior to utilizing them in the SDK.

Let’s now pay some attention to the very powerful API function nb_status. It can be used to query the router’s status values in the same manner as they can be shown with the CLI. It returns a structure of variables for a specific section (a list of available sections can be obtained by running cli status -h).

By using the dump function you can figure out the content of the returned structure:

/* Dump current WAN status */

dump ( nb_status ("wan") );

The script will then generate lines like maybe these:

struct(35): {
  .WANLINK1_GATEWAY = string[3]: "n/a"
  .WANLINK2_REGISTRATION_STATE = string[23]: "registeredInHomeNetwork"
  .WANLINK1_STATE = string[7]: "dialing"
  .WANLINK2_STATE_UP_SINCE = string[19]: "2018-12-03 09:08:30"
  .WANLINK1_DIAL_ATTEMPTS = string[3]: "320"
  .WANLINK2_SIGNAL_STRENGTH = string[3]: "-69"
  .WANLINK2_DATA_DOWNLOADED = string[6]: "747608"
  .WANLINK2_DATA_UPLOADED = string[7]: "1225984"
  .WANLINK1_DATA_UPLOADED = string[3]: "n/a"
  .WANLINK2_ADDRESS = string[11]: "10.203.0.28"
  .WANLINK2_NETWORK = string[7]: "O2 - CZ"
  .WANLINK1_DIAL_SUCCESS = string[1]: "0"
  .WANLINK2_PDP = string[4]: "PDP1"
  .WANLINK1_ADDRESS = string[3]: "n/a"
  .WANLINK1_DOWNLOAD_RATE = string[1]: "0"
  .WANLINK2_SIM = string[4]: "SIM1"
  .WANLINK2_DOWNLOAD_RATE = string[2]: "52"
  .WANLINK1_UPLOAD_RATE = string[1]: "0"
  .WANLINK2_SIGNAL_LEVEL = string[2]: "46"
  .WANLINK2_SIGNAL_QUALITY = string[4]: "good"
  .WANLINK2_UPLOAD_RATE = string[2]: "85"
  .WANLINK2_DIAL_FAILURES = string[1]: "0"
  .WANLINK1_TYPE = string[3]: "eth"
  .WANLINK1_DIAL_FAILURES = string[3]: "319"
  .WANLINK2_DIAL_ATTEMPTS = string[1]: "3"
  .WANLINK2_MODEM = string[7]: "Mobile1"
  .WANLINK1_INTERFACE = string[4]: "LAN4"
  .WANLINK1_DATA_DOWNLOADED = string[3]: "n/a"
  .WAN_HOTLINK = string[8]: "WANLINK2"
  .WANLINK2_INTERFACE = string[5]: "WWAN1"
  .WANLINK2_SERVICE_TYPE = string[3]: "LTE"
  .WANLINK2_DIAL_SUCCESS = string[1]: "3"
  .WANLINK2_TYPE = string[4]: "wwan"
  .WANLINK1_STATE_DIALING_SINCE = string[19]: "2018-12-03 12:15:10"
  .WANLINK2_STATE = string[2]: "up"
}

In combination with the nb_config_set function, it is possible to start a re-configuration of any parts of the system upon status changes. You may find all possible parameters by reading the /etc/config/factory-config.cfg file accessible via CLI.

~ $ cat /etc/config/factory-config.cfg | grep ntp
network.ntp.status                              =1
network.ntp.server0                             =0.pool.ntp.org
network.ntp.server1                             =1.pool.ntp.org
network.ntp.ping                                =1
network.ntp.interval                            =256
network.ntp.gpstime                             =0
network.ntp.stratum                             =15
network.ntp.access.0.address                    =192.168.1.0
network.ntp.access.0.netmask                    =255.255.255.0
network.ntp.access.1.address                    =
network.ntp.access.1.netmask                    =
network.ntp.access.2.address                    =
network.ntp.access.2.netmask                    =

Here is an example how one might adopt those functions:

/* Check the current NTP server and set it to the IP address 192.168.0.2
and enable the NTP synchronisation */

printf ("The NTP server was previously using IP address: ");
printf (nb_config_get("network.ntp.server0"));
printf("\n\n");

nb_config_set("network.ntp.server0=192.168.0.2");

if (nb_config_get ("network.ntp.status") == "0"){
  printf ("and was not running.");
  printf("\n\n");
  nb_config_set ("network.ntp.status=1");
}
else {
  printf ("and was running.");
  printf("\n\n");
}

printf ("The NTP server is now running with IP address: ");
printf (nb_config_get("network.ntp.server0"));

In the SDK, we are speaking of scripts and triggers which form jobs. Any arena script can be uploaded to the router or imported by using dedicated user configuration packages. You may also edit the script directly at the Web Manager or select one of our examples. You also have a testing section on the router which can be used to check your syntax or doing test runs.

Once uploaded, you will have to specify a trigger, that is, telling the router when the script is to be executed. This can be either time-based (e.g. each Monday) or triggered by one of the pre-defined system events (e.g. wan-up) as described in Section 7.6.7, “Events”. With both, a script and a trigger, you can finally set up an SDK job now. The test event usually serves as a good facility to check whether your job is working as expected. The admin section also offers facilities to troubleshoot any issues and control running jobs. The SDK host (sdkhost) corresponds to the daemon managing the scripts and their operations and thus avoiding any harm to the system. In terms of resources, it will limit CPU and memory for running scripts and also provide a pre-defined portion of the available flash storage. You may, however, extend it by external USB storage.

Files written to/tmp will be hold in the memory and will be cleared upon a script restart.. As your scripts operate in the sandbox, you will have no access to the system tools (such as ifconfig).

Administration

This page can be used to control the SDK host and apply the following settings:

The status page informs you about the current SDK status. It provides an overview about any finished jobs, you can also stop a running job there and view the script output in the troubleshooting section where you will also find links for downloading the manuals and examples.

Job Management

This page can be used to set up scripts, triggers and jobs.

It is usually a good idea to create a trigger first which is made up by the following parameters:

You can now add your personal script to the system by applying the following parameters:

Name	A meaningful name to identify the script
Description	An optional script description
Arguments	An optional set of arguments passed to the script (supports quoting)
Action	You may either edit a script, upload it to the system or select one of the example scripts or an already uploaded script

You are ready to set up a job afterwards, it can be created by using the following parameters:

Testing

/* Check the current NTP server and set it to the IP address 192.168.0.2
and enable the NTP synchronisation */

printf ("The NTP server was previously using IP address: ");
printf (nb_config_get("network.ntp.server0"));
printf("\n\n");

nb_config_set("network.ntp.server0=192.168.0.2");

if (nb_config_get ("network.ntp.status") == "0"){
  printf ("and was not running.");
  printf("\n\n");
  nb_config_set ("network.ntp.status=1");
}
else {
  printf ("and was running.");
  printf("\n\n");
}

printf ("The NTP server is now running with IP address: ");
printf (nb_config_get("network.ntp.server0"));

The testing page offers an editor and an input field for optional arguments which can be used to perform test runs of your script or test dedicated portions of it. Please note that you might need to quote arguments as they will otherwise be separated by white-spaces.

/* arguments : schnick schnack "s c h n u c k" */

for (i = 0; i < argc ; i++) {
    printf (" argv %d: %s\n", i, argv [i]);
}

/* generates: 
* argv 0: /scripts/testrun
* argv 1: schnick
* argv 2: schnack
* argv 3: s c h n u c k
*/

In case of syntax errors, arena will usually print error messages as follows (indicating the line and position where the parsing error occurred):

/scripts/testrun:2:10:FATAL: parse error, unexpected $, expecting ’;’

	Note
	It is now possible to upload SDK scripts into the Testing menu via browsing the required SDK script and clicking on the “Run” button.

As an introduction, you can step through a sample application, namely the SMS control script, which implements remote control over short messages and can be used to send a system status back to the sender. The source code is listed in the appendix.

Once enabled, you can send a message to the phone number associated with a SIM / modem. It generally requires a password to be given on the first line and a command on the second, such as:

admin01
status

We strongly recommend to use authentication in order to avoid any unintended access, however you may pass noauth as argument to disable it. You can then skip the first line containing the password. Having a closer look to the script, you will see that you will also be able to restrict the list of permitted senders. Please inspect the system log for troubleshooting any issues.

The following commands are supported:

A response to the status command typically looks like:

System: MIDGE midge (0002A9FFC32E) 
WAN1: WWAN1 is up (10.204.8.3, Mobile1,
HSPA, -65 dBm, LAI 23003)
DIO: IN1=off, IN2=off, OUT1=off, OUT2=on

	Note
	Correct time is a must! Otherwise, old SMS will be dropped. The script is included by default, but it is not working by default (FWs 4.4.40.102 and older). For a proper functionality, you would need to uncheck and then check the “store password” in User management for “admin” user.

On RACOM routers it is possible to receive or send short messages (SMS) over each mounted modem (depending on the assembly options). Messages are received by querying the SIM card over a modem, so prior to that, the required assignment of a SIM card to a modem needs to be specified on the SIMs page.

Please bear in mind, in case you are running multiple WWAN interfaces sharing the same SIM, that the system may switch SIMs during operation which will also result in different settings for SMS communication.

Sending messages heavily depends on the registration state of the modem and whether the provided SMS Center service works and may fail. You may use the sms-report-received event to figure out whether a message has been successfully sent.

Received messages are pulled from the SIMs and temporarily stored on the router but get cleared after a system reboot. Please consider to consult an SDK script in case you want to process or copy them.

Sending messages heavily depends on the registration state of the modem and whether the provided SMS Center service works and may fail. You may use the sms-report-received event to figure out whether a message has been successfully sent.

Please do not forget that modems might register roaming to foreign networks where other fees may apply. You can manually assign a fixed network (by LAI) in the SIMs section.

We identify SIMs based on their IMEI number and track their statistics in a non-volatile manner.

The relevant page can be used to enable the SMS service and specify on which modem should operate.

By using SMS routing you can specify outbound rules which will be applied whenever messages are sent. You can forward them to an enabled modem. For a particular number, you can for instance enforce messages be sent over a dedicated SIM.

Phone numbers can also be specified by regular expressions, here are some examples:

+12345678   Specifies a fixed number
+1*         Specifies any numbers starting with +1
+1*9        Specifies any numbers starting with +1 and ending with 9
+[12]*      Specifies any numbers starting with either +1 or 2

Please note that numbers have to be entered in international format including a valid prefix. On the other hand, you can also define rules to drop outgoing messages, for instance, when you want to avoid using any expensive service or international numbers.

Both types of rules form a list will be processed in order, forwarding outgoing messages over the specified modem or dropping them. Messages which are not matching any of the rules below will be dispatched to the first available modem.

Filtering serves a concept of firewalling incoming messages, thus either dropping or allowing them on a per-modem basis. The created rules are processed in order and in case of matches will either drop or forward the incoming message before entering the system. All non-matching messages will be allowed.

The status page can be used to the current modem status and get information about any sent or received messages. There is a small SMS inbox reader which can be used to view or delete the messages. Please note that the inbox will be cleared each midnight in case it exceeds 512 kbytes of flash usage.

This page can be used to test whether SMS sending in general or filtering/routing rules works. The maximum length per message part is limited to 160 characters, we also suggest to exclusively use characters which are supported by the GSM 7-bit alphabet.

Once the SNMP agent is enabled, SNMP traps can be generated using SDK scripts or can be triggered by various Events (see the SYSTEM → Events menu).

When running in SNMPv3, it is possible to configure the following two authentication options:

	Note
	The SNMP daemon is also listening on WAN interfaces and it is therefore suggested to restrict the access via the firewall.

This menu allows to configure the behaviour of the LEDs on the front panel. The first LED (STAT) cannot be changed. A common settings for EXT LED is WWAN to show a signal strength.

This feature can be used to automatically perform a software/config update as soon as an USB storage stick has been plugged in. Following files must exist in the root directory of a FAT16/32 formatted stick:

The autorun.key file must hold valid access keys to perform any actions when the storage device is plugged in. The keys are made up of your configured password (SHA256). They can be generated and downloaded. You may also define multiple keys in this file (line-after-line) in case your admin password differs if applied to multiple M!DGE routers.

For new devices with an empty password the hash key
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 can be used.

The hash keys can be generated by running the command
echo -n “<admin-password>” | sha256sum on a Linux system or an Internet hash key generator (search for “sha-256 hash calculator”).

	Note
	Units in complete factory state have Autorun feature enabled, using the hash key above. Once the ‘admin’ password is configured to access M!DGE unit, the Autorun feature is disabled until you set the Password within this menu.

Network Time Protocol (NTP) is a protocol for synchronizing the clocks of computer systems over packet-switched, variable-latency data networks. M!DGE can synchronize its system time with an NTP server. If enabled, time synchronization is usually triggered after a WAN link has come up but before starting any VPN connections. Further time synchronizations are scheduled in the background every 60 minutes.

Sync will perform the time synchronization immediately.

Virtualization gives customers the possibility to execute their own applications.

This menu can be used to reboot the system. All WAN links will be interrupted.

This page offers a simple shortcut to allow only secure connections (SSH, HTTPS) for managing the router. If the option “Secure authentication preferred” is set, users will be redirected to HTTPS but can still login via HTTP/telnet.

This page lets you manage the user accounts on the device.

The standard admin user is a built-in power user that has permission to access the Web Manager and other administrative services and is used by several services as the default user. Keep in mind that the admin password will be also applied to the root user which is able to enter a system shell. Any other user represents a user with lower privileges, for instance it has only permission to view the status page or retrieve status values when using the CLI.

The Web Manager supports up to 5 concurrent users with ‘user’ access rights (and only one Administrator). If login was successful, any duplicate users from other remote hosts will be logged out. Web interface is being blocked for 5 minutes after 10 failed login attempts.

	Note
	When adding additional admin users you are required to provide the password of the default administrator. The user access management was improved in 4.4.40.104 firmware. It is now possible to grant native shell access to additional admin users or to disable shell access for a user.

A remote RADIUS server can be used to authenticate users. This applies for the Web Manager and other services supporting and incorporating remote authentication.

Primary RADIUS configuration:

Secondary RADIUS configuration:

This is used if the first server is not available.

This menu can be used to run a manual software update.

When issuing a software update, the current configuration (including files like keys/certificates) will be backuped. Any other modifications to the filesystem will be erased. The configuration is generally backward-compatible. We also apply forward compatibility when downgrading to a previous software within the same release line, which is accomplished by sorting out unknown configuration directives which actually may lead to loss of settings and features. Therefore, it’s always a good idea to keep a copy of the working configuration. Generally, we do not recommend downgrading the software.

A software image can be either uploaded via the Web Manager or retrieved from a specific URL. It will be unpacked and deployed to a spare partition which gets activated if the update completed successfully. The whole procedure is accompanied by all green LEDs flashing up, the subsequent system reboot gets denoted by a slowly blinking Status LED. The backuped configuration will be applied at bootup and the Status LED will blink faster during this operation. Depending on your configuration, this may take a while.

Note

Starting with SW release 4.2 we set default to not saving passwords; using password hashes instead. Storing passwords for users can be enabled, but is not recommended for new applications. Older SW releases require the passwords to be stored encrypted on the device. As we don’t have them any more in release version 4.2 and later you will have to provide the administrator password if you want to downgrade to a release 4.1.x and lower. The same passphrase will be used for bootloader login as well. All users which have no password stored on the device will not be able to login after downgrade until new passwords have been applied.

Important

Upgrade the Toby LTE module version to 17.00,A01.00 before updating M!DGE2 Software to 4.4.40.111. If installing 4.4.40.111 MIDGE2 software, make sure you have already upgraded Toby LTE module to newer version than 15.63 (i.e. 16.19,A01.02, 16.19,A01.04 or 17.00,A01.00)! Otherwise, the AT communication between M!DGE2 and the module stops working, which usually ends in a USB disconnection (i.e., MIDGE2/Toby LTE module cannot connect to cellular network).

This menu can be used to perform a firmware update of a specific module.

The maximum file size for WWAN firmware-update files was increased to 45 MB (since M!DGE2 software 4.4.40.107). This should be sufficient to perform most FW updates directly via web interface without the need for an external web or FTP server.

In every router you have two software profiles. One is active (currently used) and one is inactive. You can easily switch between these profiles any time.

It can be for example useful when there is some issue with the newest firmware and you need to restore the previous firmware version easily. Or you can just test some new features in the newest firmware and then get back to the previous one.

This section can be used to download the currently running system configuration (including essential files such as certificates).

The current configuration file is updated after every change and the time of this update is displayed along with a configuration version and a security hash. The current configuration can be updated manually by pressing the Apply button.

In order to restore a particular configuration you can upload a configuration previously downloaded or update configuration from the provided URL link.

You can choose between missing configuration directives stay the same as in the currently running configuration or be replaced with factory defaults.

A configuration file can be downloaded and encrypted with a password. When the file is uploaded, you need to provide this password to decrypt the file again.

This menu can be used to reset the device to factory defaults. Your current configuration will be lost.

This procedure can also be initiated by pressing and holding the Reset button for at least 10 seconds. A successfully initiated factory reset can be noticed by all LEDs being turned on.

Factory reset will set the IP address of the Ethernet interface back to 192.168.1.1. You will be able to communicate again with the device using the default network parameters.

You may store the currently running configuration as factory defaults which will reside active even when a factory reset has been initiated (e.g. by your service staff). Please ensure that this corresponds to a working configuration. A real factory reset to the default settings can be achieved by restoring the original factory configuration and initiating the factory reset again.

	Important
	If you store the currently running configuration as the factory defaults, have in mind that the password is also stored within this configuration.

Various tools reside on this page for further analysis of potential configuration issues. The ping utility can be used to verify the remote host reachability.

Define the remote host (IP address or hostname), number of packets and the packet size.

The traceroute utility can be used to print the route to a remote host.

Define the target host (IP or hostname), Time-To-Live (TTL – number of hops on the resulting route) and the timeout in seconds (max. time to wait for the final respond).

The tcpdump utility generates a network capture (PCAP) of an interface which can be later analyzed with Wireshark. Interface can also be set as “ANY” to capture data from all available interfaces simultaneously.

Several basic protocols can be excluded from the resulting PCAP file (HTTP, HTTPS, Telnet and SSH). Only specific IP addresses and/or ports can be captured.

	Note
	The default number of received packets is set to 1000. For downloading the file, just click on the Download button. The captured file can be also downloaded from the /tmp/ directory via the appropriate file manager.

Log files can be viewed, downloaded and reset here. Please study them carefully in case of any issues.

Default debugging levels for individual daemons are as follows:

You can change the values to suit your needs and you can reset the values into their defaults by pressing the “Reset” button afterwards.

You can generate and download a tech support file here.

We strongly recommend providing this file when getting in touch with our support team, either by e-mail or via our online support form, as it would significantly speed up the process of analyzing and resolving your problem.

	Note
	For both direct E-mail and Online support form a connection to the Internet has to be available.

You can encrypt the Techsupport file in order to secure the file against reading it without knowing the security key for decrypting the file. It is more secure way to send the techsupport file via nonsecure e-mail. The decrypting key is known by our support team only and cannot be provided to anybody. Another option is to exclude secrets – passwords, credentials… But they are not readable in a plain text anyway. The last option is to include SDK scripts as well.