Page 1
MDSTM Orbit MCR-4G
Managed Connected Router 4G and WiFi
Technical Manual
MDS 05-6628A01, Rev. C
NOVEMBER 2013
Installation and Operation Guide
Page 2
Quick-Start instructions for this product are contained in publication 05-6702A01.
Visit our website for downloadable copies of all documentation at www.gemds.com.
Page 3
TABLE OF CONTENTS
1.0 INTRODUCTION .................................................................................................................. 1
1.1 About This Manual ........................................................................................................................ 1
Software Command Notations ......................................................................................................... 1
2.0 PRODUCT DESCRIPTION................................................................................................... 3
2.1 Key Features .................................................................................................................................3
2.2 Interface Types .............................................................................................................................. 3
2.3 Typical Application ......................................................................................................................... 3
2.4 Connectors and Indicators ............................................................................................................ 4
Grounding Considerations ...............................................................................................................9
Mounting Options...........................................................................................................................10
Optional DIN Rail Mounting ...........................................................................................................10
Antenna Planning & Installation ................................................................................................... 11
Accessories and Spares ................................................................................................................ 13
3.0 Device Management........................................................................................................... 14
3.1 Connecting to a PC ..................................................................................................................... 14
Differences Between Serial & SSH................................................................................................14
Establishing Communication—Serial Interface..............................................................................14
Setting Basic Parameters—First Steps..........................................................................................15
One-Time “Recovery” Passwords.................................................................................................. 16
3.2 Pre-Configured Settings .............................................................................................................. 17
3.3 YANG Interface ............................................................................................................................18
CLI Login Prompt ........................................................................................................................... 19
3.4 Operational Topic Areas ..............................................................................................................25
Serial Console ........................................................................................................................ 26
Network ..................................................................................................................................27
LAN ........................................................................................................................................30
VLAN Operation ..................................................................................................................... 33
Cell .........................................................................................................................................34
WiFi ........................................................................................................................................37
Bridging ..................................................................................................................................42
Routing ...................................................................................................................................45
Firewall and NAT .................................................................................................................... 46
Packet Filtering ......................................................................................................................48
Network Address Translation (NAT) ...................................................................................... 51
VPN ........................................................................................................................................56
DNS ........................................................................................................................................63
DHCP Service ........................................................................................................................ 64
Iperf Service ........................................................................................................................... 66
Date, Time and NTP ..............................................................................................................67
Geographical-location ............................................................................................................ 68
User Management and Access Controls ................................................................................ 69
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual i
Page 4
Login-Lockout ......................................................................................................................... 71
RADIUS ..................................................................................................................................72
File Servers ............................................................................................................................ 73
Certificate Management .........................................................................................................74
Event Logging ........................................................................................................................81
Firmware Management ..........................................................................................................82
Support Bundle ......................................................................................................................84
Configuration Scripts .............................................................................................................. 85
4.0 Technical Reference ........................................................................................................... 86
4.1 Troubleshooting ........................................................................................................................... 86
LED Status Indicators ....................................................................................................................86
4.2 Technical Specifications .............................................................................................................. 87
General .......................................................................................................................................... 87
Physical.......................................................................................................................................... 87
Environmental ................................................................................................................................ 87
Agency/Regulatory Approvals........................................................................................................87
2.4 GHz WiFi Specifications...........................................................................................................87
4.3 Glossary of Terms & Abbreviations ............................................................................................. 88
APPENDIX A – Data Configuration Tree .................................................................................... 90
APPENDIX B – Command Line Interface (CLI) Features......................................................... 104
APPENDIX C – Integrity Measurement Authority (IMA) ........................................................... 120
APPENDIX D – Common Event Expression (CEE).................................................................. 123
APPENDIX E– Configuring Firmware Management ................................................................. 127
APPENDIX F– Obtaining Provisioned Cell Service (Verizon)................................................... 129
APPENDIX G – Device Manager.............................................................................................. 130
11.1 Web Browser Connection ........................................................................................................ 130
APPENDIX H – Licenses .......................................................................................................... 132
Copyright and Trademark
This manual and all software described herein is protected by Copyright: 2013 GE MDS, LLC. All
rights reserved. GE MDS, LLC reserves its right to correct any errors and omissions in this publication.
ii MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 5
RF Safety Notice (English and French)
RF Exposure
l'exposition aux RF
Concentrated energy from a directional antenna may pose a health hazard to
humans. Do not allow people to come closer to the antenna than the distances
listed in the table below when the transmitter is operating. More information on
RF exposure can be found online at the following website:
www.fcc.gov/oet/info/documents/bulletins.
Concentré d'énergie à partir d'une antenne directionnelle peut poser un risque
pour la santé humaine. Ne pas permettre aux gens de se rapprocher de l'antenne
que les distances indiquées dans le tableau ci-dessous lorsque l'émetteur est en
marche. Plus d'informations sur l'exposition aux RF peut être trouvé en ligne à
l'adresse suivante: www.fcc.gov / oet / info / documents et bulletins.
Antennas must not be co-located. All transmission antennas must be at least 20 cm apart to comply
with FCC co-location rules.
Orbit Device vs. Minimum RF Safety Distance
Radio Module Type
MCR-4G 20 cm
MCR-900 23 cm
Other models Consult factory prior to operation.
Minimum Safety Distance
from Antenna
FCC Part 15 Notice
Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may
cause undesired operation. Any unauthorized modification or changes to this device without the
express approval of the manufacturer may void the user’s authority to operate this device. Furthermore, this device is intended to be used only when installed in accordance with the instructions outlined in this manual. Failure to comply with these instructions may void the user’s authority to
operate this device.
Industry Canada Notice
This Class A digital apparatus complies with Canadian ICES-003.
Cet appareil numérique de la classe A est conforme à la norme NMB-003 du Canada.
Operational Safety Notices
The MDS Orbit MCR-4G may not be used in an environment where radio frequency equipment is
prohibited or restricted in its use. This typically includes aircrafts, airports, hospitals, and other sensitive electronic areas.
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual iii
Page 6
Do not operate RF devices in an environment that may be susceptible to radio interference
resulting in danger, specifically:
• Areas where prohibited by law
Follow any special rules and regulations and obey all signs and notices. Do not use the MCR-4G
when you suspect that it may cause interference or danger.
• Near Medical and life support equipment
Do not use the MCR-4G in any area where medical equipment, or life support equipment may be
located, or near any equipment that may be susceptible to any form of radio interference.
Cellular Operational Bands
The following table shows the bands in which the cellular module operates for each wireless technology.
FCC IDs of Installed Transmitters
As of the printing date, the following identifiers are assigned to the modules listed below. For the
latest, official listings of all agency approvals, please contact your factory representative.
CELL Modem FCC ID: PKRNVWE362, IC ID: 3229B:E362
WIFI Module FCC ID: M4Y-ZCN722MV1, IC ID 3195A-ZCN722MV1
CE Mark and RTTE Notice
This product, using the "WIFI internal radio module" only, is CE marked and compliant with the
RTTE directive. Other configurations will be added for EU use in future releases.
iv MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 7
Servicing Precautions
No user-serviceable parts are contained inside this equipment. Opening of the unit by unauthorized
personnel voids the warranty. All servicing must be performed by an authorized repair facility.
When servicing energized equipment, be sure to wear appropriate Personal Protective Equipment
(PPE). During internal service, situations could arise where objects accidentally contact or short
circuit components and the appropriate PPE would alleviate or decrease the severity of potential
injury. When servicing equipment, all workplace regulations and other applicable standards for
live electrical work should be followed to ensure personal safety.
Manual Revision and Accuracy
This manual was prepared to cover a specific version of firmware code. Accordingly, some screens
and features may differ from the actual unit you are working with. While every reasonable effort
has been made to ensure the accuracy of this publication, product improvements may also result in
minor differences between the manual and the product shipped to you. If you have additional questions or need an exact specification for a product, please contact GE MDS using the information at
the back of this guide. In addition, manual updates can be found on our web site at
www.gemds.com
Environmental Information
The manufacture of this equipment has required the extraction and use of natural resources.
Improper disposal may contaminate the environment and present a health risk due to hazardous
substances contained within. To avoid dissemination of these substances into our environment, and
to limit the demand on natural resources, we encourage you to use the appropriate recycling systems for disposal. These systems will reuse or recycle most of the materials found in this equipment
in a sound way. Please contact GE MDS or your supplier for more information on the proper disposal of this equipment.
Battery Disposal—This product may contain a battery. Batteries must be disposed of properly, and
may not be disposed of as unsorted municipal waste in the European Union. See the product documentation for specific battery information. Batteries are marked with a symbol, which may
include lettering to indicate cadmium (Cd), lead (Pb), or mercury (Hg). For proper recycling return
the battery to your supplier or to a designated collection point. For more information see:
www.weeerohsinfo.com.
Product Test Data Sheets
Test Data Sheets showing the original factory test results for this unit are available upon request
from the GE MDS Quality Leader. Contact the factory using the information at the back of this
manual. Serial numbers must be provided for each product where a Test Data Sheet is required.
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual v
Page 8
CSA/us Notice
EXPLOSION
HAZARD!
This product is approved for use in Class 1, Division 2, Groups A, B, C & D Hazardous Locations.
Such locations are defined in Article 500 of the National Fire Protection Association (NFPA) publication NFPA 70, otherwise known as the National Electrical Code. The transceiver has been recognized for use in these hazardous locations by the Canadian Standards Association (CSA) which
also issues the US mark of approval (CSA/US). The CSA Certification is in accordance with CSA
STD C22.2 No. 213-M1987.
CSA Conditions of Approval: The transceiver is not acceptable as a stand-alone unit for use in the
hazardous locations described above. It must either be mounted within another piece of equipment
which is certified for hazardous locations, or installed within guidelines, or conditions of approval,
as set forth by the approving agencies. These conditions of approval are as follows: The transceiver
must be mounted within a separate enclosure which is suitable for the intended application.The
antenna feedline, DC power cable and interface cable must be routed through conduit in accordance with the National Electrical Code. Installation, operation and maintenance of the transceiver
should be in accordance with the transceiver's installation manual, and the National Electrical
Code. Tampering or replacement with non-factory components may adversely affect the safe
use of the transceiver in hazardous locations, and may void the approval. A power connector
with screw-type retaining screws as supplied by GE MDS must be used.
Do not disconnect equipment unless power has been switched off or the area is known to
be non-hazardous. Refer to Articles 500 through 502 of the National Electrical Code
(NFPA 70) for further information on hazardous locations and approved Division 2 wiring
methods.
vi MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 9
1.0 INTRODUCTION
The MCR-4G Setup Guide, Part no. 05-6702A01,
contains installation instructions, as well as basic
startup information for this product.
All GE MDS user manuals and updates are available
online at www.gemds.com.
This manual describes the MDS Orbit MCR-4G Managed Connected Router (Figure 1). The unit is a highly
secure, industrial grade, wireless communication product for broad-based applications including control
center monitoring, well site pad operations, and video surveillance. It serves the need for localized WiFi
communications with a cellular back-up or backhaul option, while providing the extended temperature
range and industrial-grade packaging inherent to GE MDS products. These features allow the best use of
communication options at each installation site.
Figure 1. MCR-4G Unit
(Standard 2E1S configuration shown)
With a common hardware architecture and user interface, the MCR offers flexibility in network design and
application, with simplified training, maintenance, and deployment costs. GE MDS provides an array of
communication products with multiple interface options and a variety of enclosures to give customers the
choice and flexibility to design their communications network to meet geographic and industry specific
challenges. Information on other GE MDS products can be found by visiting our website at
www.gemds.com.
1.1 About This Manual
This manual is intended for systems engineers, network administrators, and others responsible for planning,
commissioning, using, and troubleshooting the wireless system. Installation steps are not included in this
publication. For installation instructions, refer to the companion MCR-4G Setup Guide, part no.
05-6702A01. Electronic copies of all user documentation are available free of charge at www.gemds.com.
1.1.1 Software Command Notations
The product is designed for software control via a connected PC. As such, there are no external controls or
adjustments present. To show the names of software commands, keyboard entries, or other information displayed on a PC screen, a bolded font is used throughout the manual. In the case of tabular data displayed on
a PC screen, a variation on this font is used to maintain proper layout. (See examples that follow.)
Bolded font example (used in text for software commands and keyboard entries)
Bolded font example (used to show tables displayed on a PC screen)
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 1
Page 10
In the Device Management section of this manual (Section 3.0), there are a number of command strings
where information is presented by the unit, and a reply is required from the user. In such cases, information
from the unit is shown in a non-bolded font, and the user response is shown in bold. For example:
(none) login: admin
Further, in some cases, command lines will be shown with non-bolded, italicized text contained within the
string. Such text indicates the need for user-supplied variable parameters, such as the name of an item. For
example:
set interfaces interface myBridge virtual-type bridge
In the above example, you would enter the specific name of your bridge to complete the entry.
NOTE: The software commands and responses shown in this manual were obtained from a unit operating
in a lab environment. The information displayed may differ from field service conditions.
2 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 11
2.0 PRODUCT DESCRIPTION
The MCR-4G is a rugged networking router providing comprehensive solutions for IP/Ethernet, serial, and
machine-to-machine wireless communication. This industrial package provides integrated 4G LTE wireless
technology and connectivity for Ethernet and serial devices requiring secure operation.
2.1 Key Features
MCR units include the following key features:
• Security—The unit uses industry-leading security features to protect data while maintaining com-
patibility with deployed infrastructures. Features include AAA user access with passwords and lockout protection, VPNs, signed firmware, secure booting, integrity management, and more.
NOTE: The Orbit MCR device is designed for high security environments. As such, management of the
device does not support Telnet, but instead implements the more secure SSH protocol.
• Small Form Factor—The unit is housed in a rugged enclosure suited for operation in harsh indus-
trial environments. It requires only protection from direct exposure to the weather, and may be easily
mounted inside a NEMA enclosure for outdoor applications when required.
• Network Interfaces—Several network interfaces are present to provide connectivity for a variety
of equipment and applications. Ethernet, serial, and WiFi interfaces provide local connections while
a cellular interface provides access to public carrier networks.
• User Interface—Multiple user interfaces are provided for configuration and monitoring of the unit.
These include local serial console, web, SSH, USB, and NETCONF.
NOTE: When the unit is installed in hazardous locations, use only the serial or Ethernet connections on
the unit’s front panel. Do not use the USB port in hazardous locations.
• NETCONF—A next-generation management protocol is used that provides an array of features for
device configuration and monitoring.
• Network Management System—The PulseNET Network Management System allows administer-
ing and monitoring the operation of small-to-large scale deployments.
2.2 Interface Types
MCR units are offered in two external interface offerings; 2 Ethernet/1 Serial (2E1S), or 2 Serial/1 Ethernet
(2S1E). The 2E1S configuration (Figure 1) is the standard model and is the focus of this manual. Most information applies equally to both configurations, however.
2.3 Typical Application
The unit provides flexibility in network communications and may be used in a wide variety of applications.
In a common scenario, it provides cellular connectivity to locally-connected devices that are located on a
local/internal/private LAN or WiFi network. The unit acts as an Access Point on the WiFi interface to provide connectivity to WiFi clients. Figure 2 shows an example network in whic h the unit provides connectivity to multiple end devices. The end devices are connected via Ethernet, serial, and WiFi links.
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 3
Page 12
Invisible place holder
DC Power
(10-60 Vdc)
Ethernet Ports
(RJ-45 10/100)
Mini USB
Port
Cellular
Antennas
(Aux & Main)
SIM Card
Slot
COM Port
WiFi Antenna
LED Indicator
Panel
Figure 2. Typical MCR Application
2.4 Connectors and Indicators
Figure 3 shows the unit’s front panel connectors and indicators. These items are referenced in the
text that follows. The unit’s LED Indicator Panel is described in Table 4 on Page 9.
Figure 3. Connectors and Indicators
(2E1S configuration shown)
4 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 13
PWR—Two-conductor DC input connection. The unit includes a 6-foot (1. 83 meter) power cable suitable
Lead
Screws (2)
Binding
Wire Ports (2)
(Polarity: Left +, Right –)
Retaining
Screws (2)
for indoor or outdoor use when properly connected. The DC power connector (Figure 4) is keyed, and can
only be inserted one way.
Invisible place holder
Figure 4. DC Power Connector (P/N 73-1194A39)
NOTE: The unit is designed for use in negative ground DC power systems only.
Input voltage to the unit must be well filtered, and within the range of 10-60 Vdc. The maximum rated power
consumption of the device is 15 watts, but actual power may be much less, depending on configuration. The
power supply must be capable of supplying the expected maximum power for the installation. For expected
power requirements in common configurations, see “Technical Specifications” on Page 86.
ETH1 / ETH2— Ethernet connection port. These ports support both device management and payload data
transport. Depending on product version, the unit may have one or two Ethernet ports. This is a standard
RJ-45 jack, and features MDIX auto-sensing capability, allowing straight-through or crossover cables to be
used.
Connecting to the unit via SSH supports device management and provides the same user interface available
using the unit’s
COM1 serial port. Various options are available for passing Ethernet data, allowing system
administrators to optimize the configuration for maximum efficiency, based on the system’s operating characteristics.
(As viewed from the outside of the unit)
Table 1. ETH1/2 Pin Details
Pin Function
1
Transmit Data (TX) High
2
Transmit Data (TX) Low
3
Receive Data (RX) High
4
Unused
5
Unused
6
Receive Data (RX) Low
7
Unused
8
Unused
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 5
Page 14
USB Port—This port allows for connection of a laptop or PC. The port provides a local console for management of the device. A standard host-to-mini device USB 2.0 cable may be used.
COM Port—This
connector serves as the serial interface port for both console management and payload
data. By default, the port is enabled for local console control. The COM port serves as the primary interface
for connecting the unit to an external DTE serial device supporting RS-232 or RS-485. If necessary, an
adapter may be used to convert the unit’s RJ-45 serial jack to a DB-9F type (GE MDS 73-2434A12).
NOTE: Not all PCs include a serial port. If one is not available, the unit’s USB port may be used to access
the device management interface. Alternatively, a PC’s USB port may be used with a
USB-to-Serial adapter and appropriate driver software. These devices are available from several
manufacturers.
The COM port supports a serial data rate of 1200-115200 bps (115200 default, asynchronous only). The unit
is hardwired as a DCE device. Supported data formats for the COM port are:
8N1 - 8 char bits, no parity, 1 stop bit (Default setting)
8N2 - 8 char bits, no parity, 2 stop bits
8O1 - 8 char bits, odd parity, 1 stop bit
8O2 - 8 char bits, odd parity, 2 stop bits
8E1 - 8 char bits, even parity, 1 stop bit
8E2 - 8 char bits, even parity, 2 stop bits
7N1 - 7 char bits, no parity, 1 stop bit
7N2 - 7 char bits, no parity, 2 stop bits
7O1 - 7 char bits, odd parity, 1 stop bit
7O2 - 7 char bits, odd parity, 2 stop bits
7E1 - 7 char bits, even parity, 1 stop bit
7E2 - 7 char bits, even parity, 2 stop bits.
The tables below provide pin descriptions for the COM1 data port in RS-232 mode and RS-485 modes,
respectively.
NOTE: The COM2 port, if present, is restricted to RS-232 mode; it cannot be used for RS-485.
(As viewed from the outside of the unit)
Table 2. COM1/2 Port Pin Details (RS-232)
Pin
Number
1 Reserved
2
3 Reserved
4 Ground Connects to ground (negative supply potential) on chassis
Input/Output Pin Description
OUT DCD (Data Carrier Detect)
6 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 15
Table 2. COM1/2 Port Pin Details (RS-232) (Continued)
Pin
Number
5
6
7
8
Input/Output Pin Description
OUT RXD (Received Data)—Supplies received data to the connected device
IN TXD (Transmitted Data)—Accepts TX data from the connected device
OUT CTS (Clear to Send)
IN RTS (Ready to Send)
Table 3. COM1 Port Pin Details (RS-485)
Pin
Number
1 Reserved
2
3 Reserved
4 Ground Connects to ground (negative supply potential) on chassis
5 OUT TXD+ (Transmitted Data +)—Non-inverting driver output. Su pplies
6 IN RXD+ (Received Data +)— Non-inverting receiver input. Accepts
Input/Output Pin Description
OUT DCD (Data Carrier Detect)
received payload data to the connected device.
payload data from the connected device.
7 OUT TXD-/TXB (Transmitted Data -)—Inverting driver output
8 IN RXD-/RXB (Received Data -)— Inverting receiver input
COM1 Port notes and wiring arrangements (RS-485):
The COM1 port supports 4-wire and 2-wire RS-485 mode.
· RXD+ / RXB and RXD– / RXA are data sent into the unit
· RXD+ / RXB is positive with respect to RXD– / RXA when the line input is a “0”
· TXD+ / TXB and TXD– / TXA are data sent out by the unit
· TXD+ / TXB is positive with respect to the TXD– / TXA when the line output is a “0”
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 7
Page 16
Cell Antennas (AUX and MAIN)—These SMA coaxial connectors are for attachment of cellular antennas.
The MAIN connection is for basic cellular transmission/reception, and the AUX connector is for attachment
of a receive-only antenna which provides MIMO receive operation (diversity) with standard 4G modules,
improving signal quality in many installations. In general, both antennas should always be used for cellular
operation. The GE MDS part number for this antenna type is 97-2485A04.
Figure 5. Directly-Connected Cellular Antenna (Typical Style)
(GE MDS Part No. 97-2485A04)
WiFi Antenna—Antenna connection for 2.4 GHz WiFi service. The connector appears similar to the cellular connectors discussed above, but is a Reverse-SMA type. It contains a pin that matches with an SMA-F
connector. The GE MDS part number for this antenna is 97-4278A48.
SIM Port—This port accepts a mini SIM card (2FF type) for 4G cell operation. The unit’s cellular interface
will not function without a valid SIM card installed. The customer is responsible for obtaining a provisioned
SIM card for the appropriate service plan from their cellular provider.
module’s IMSI/IMEI (typically required for provisioning) is provided on Page 35 of this manual.
CAUTION: Do not insert the SIM card when the unit is powered on.
Card Insertion: The SIM card only inserts one way; do not force it. It should be inserted with the printed
label facing up, and the cut-off corner on the left side (see Figure 6). This side is inserted first. A small
instrument, such as a flathead screwdriver, may be helpful to gently push the SIM all the way in until it
locks.
Information on determining the cell
Invisible place holder
Figure 6. Steps for Inserting the SIM Card
8 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 17
LED Status Indicators—The LEDs on the unit provide visual indications of the status of the device as
shown in Figure 7 and explained in Table 4 which follows.
Figure 7. LED Status Indicators
Table 4. Description of LED Status Indicators
LED Name LED State Description
PWR
(DC Power)
ETH
(Ethernet)
COM
(Serial Comm. Port)
NIC1
(Cell)
Off
Solid Green
Fast Blink/Red (1x/sec.)
Off
Solid Green
Blinking Green
Off
Blinking Green
Off
Solid Green
No power to unit
Unit is powered, no problems detected
Alarm indication
No Ethernet link to network
Ethernet link present
Ethernet traffic in/out
No serial connection, or idle
Serial traffic in/out
No cellular connection
Cell Connection
NIC2
(WiFi)
Access Point Mode Solid Green
Station Mode Off
Off Interface disabled
Operating as AP and at least one client connection
Solid Red
Solid Green
Operating as an AP and no client connection
No connection
Wi-Fi connection established.
NOTE: In addition to the LEDs above, the Ethernet connector has two embedded LEDs. A yellow indi-
cates a link at 100 Mbps operation. A flashing green indicates Ethernet data traffic.
2.4.1 Grounding Considerations
To minimize the chance of damage to the unit and its connected equipment, a safety ground (NEC
Class 2 compliant) is recommended, which bonds the chassis, antenna system(s), power supply,
and connected data equipment to a single-point ground, keeping all ground leads as short as possible.
Normally, the unit is adequately grounded if mounted with the flat brackets to a well-grounded
metal surface. If the unit is not mounted to a grounded surface, it is recommended that a safety
ground wire be attached to the screw provided on the bottom corner of the enclosure, in the
recessed flat area. Alternatively, a safety ground wire may be attached to one of the mounting
bracket screws.
The use of a lightning protector is recommended where the antenna cable enters the building; Bond
the protector to the tower ground, if possible. All grounds and cabling must comply with applicable
codes and regulations. One source for lightning protection products may be found online at
http://www.protectiongroup.com/PolyPhaser.
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 9
Page 18
2.4.2 Mounting Options
8.5 (21.59 cm)
9.25 (23.5 cm)
4.81 (12.22 cm)
The unit may be mounted with flat mounting brackets or an optional 35 mm DIN rail attachment.
Figure 8 shows the mounting dimensions for a unit equipped with flat mounting brackets.
Invisible place holder
Figure 8. Flat Mounting Bracket Dimensions
NOTE: To prevent moisture from entering the unit, do not mount the case with the cable connectors
pointing up. Also, dress all cables to prevent moisture from running along the cables and into the
unit.
2.4.3 Optional DIN Rail Mounting
If ordered with the DIN rail mounting option, the unit is supplied with a DIN rail clip attached to
the case. The integrated bracket on the unit’s case allows for quick installation and removal from
a DIN mounting rail as shown in Figure 9.
Figure 9. DIN Rail Attachment and Removal
(Pull down tab to release from rail)
10 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 19
2.4.4 Antenna Planning & Installation
Consideration must be taken to select appropriate antennas for optimal RF performance. This section
reviews the key factors involved in selecting and installing antennas for the MCR-4G. Only approved
antennas may be used on the unit's RF output connectors, as listed in Table 5. The use of non-approved
antennas may result in a violation of FCC rules, and subject the user to FCC enforcement action.
Table 5. Approved Antenna Types
Antenna Application GE MDS Part Number
WiFi (direct connect), RP SMA,
2.4-2.5 GHz Antenna, 3.2dBi Gain
WiFi (external mount), Omni Ant. N M
Term., 2.4-2.5 GHz, 2 dBi Gain
Cell (direct connect), 960/2170/2700MHz 97-2485A04
Cell (external mount, ground plane),
960/2170/2700MHz, requires ground
WiFi (Magnetic Mount) 5 ft./1.52 m Cable,
RP SMA Plug
Antenna Type and Orientation
It is important to use antennas designed to operate in the applicable cellular coverage bands with a Return
Loss of 10 dB or better. Placement of the antennas also plays a key role in the coverage of the system. While
the antennas can be placed directly on the face of the unit in some short range installations, the best performance is obtained when mounting antennas remotely using low loss coaxial cable. Antennas mounted in
close proximity to each other can couple signals between them and desensitize the RF module.
97-4278A34
97-4278A48
97-2485A05
97-4278A78
When placing the indoor SMA style “paddle” antennas on the face of the unit, position them with a 90
degree angle of separation to improve the isolation. A “V” or an “L” configuration is a common approach
to use with the Main channel typically mounted for vertical polarization. The multipath nature of Cellular
systems means that polarization for indoor use is not normally a critical factor. Isolation between the
antennas is more important.
Note that with any installation, there needs to be a minimum 20 cm spacing between the Wi-Fi antenna and
any other radio antenna to avoid co-location difficulties.
Indoor use case:
1. This scenario employs direct mounting of an LTE paddle antenna (GE MDS PN: 97-2485A04) on the
Main and Aux Cell channels, and cabled mounting of the Wi-Fi antenna (GE MDS PN: 97-4278A34)
using a magnetic mount (GE MDS PN: 97-4278A78). This configuration offers easy mobility for
evaluation purposes or indoor applications with good cellular signal coverage (see Figure 10).
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 11
Page 20
Figure 10. Direct Mounting of Cell Antenna; Cabled WiFi Antenna
Minimum 8-inch (20.32 cm) separation between cell and WiFi antennas
2. This arrangement employs cabled mounting of the L TE paddle antennas (GE MDS 97-2485A04) o n the
Main and AUX Cell channels, and cabled mounting of the Wi-Fi antenna (GE MDS 97-4278A34)
using a magnetic mount (GE MDS 97-4278A78). The Wi-Fi antenna may also be directly attached to
the unit if desired. This configuration works well for indoor installations in equipment closets, or for
more permanent applications.
Outdoor use case:
External enclosures—If the system is going to be installed in a weathertight enclosure and mounted outside
in the elements, cabled use of external LTE antennas (GE MDS PN: 97-2485A05) on the Main and AUX
Cell ports, with cabled use of the External Wi-Fi antenna (GE MDS PN: 97-4278A48) is a good solution.
This configuration requires a suitable metallic ground plane for the Cellular antennas (8" diameter disc minimum for the 97-2485A05 series) or a suitable counterpoise for frequencies as low as 698 MHz. Metal
enclosures work well for ground plane requirements when ground contact inside the box is not impeded by
painted surfaces.
Do not use internally mounted antennas inside of metal enclosures.
Other antenna configurations can be easily customized for applications not listed here. Consult your factory
representative for installation matters.
12 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 21
2.4.5 Accessories and Spares
Table 6 lists common accessories and spare items for use with the MCR-4G. GE MDS also offers an Acces-
sories Selection Guide listing an array of additional items that may be used with the product. Contact your
factory representative or visit
Item Description Part Number
DC Power Plug, 2-pin, polarized Mates with power connector on the
Setup Guide
(for installation instructions)
Flat Mounting Bracket Kit Bra ckets that attach to the bottom of
COM Port Adapter Converts the unit’s RJ-45 serial jack
www.gemds.com to obtain a copy of the guide.
Table 6. Accessories & Ancillary Items
unit’s case. Screw terminals are
provided for wires, threaded locking
screws to prevent accidental
disconnect.
Describes the installation and setup
of the unit. It is a companion to this
Technical Manual. PDF copy
available free at www.gemds.com.
the unit. Used for mounting to a flat
mounting surface.
to a DB-9F type.
73-1194A53
05-6702A01
03-4123A14
73-2434A12
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 13
Page 22
3.0 DEVICE MANAGEMENT
This section describes the steps for connecting a PC, logging in, and setting unit parameters. The focus here
is on the local serial console interface, but other methods of connection are available and offer similar capabilities. The key differences are with initial access and appearance of data.
The MCR offers several interfaces to allow device configuration and monitoring of status and performance.
These include local serial console, USB, NETCONF, HTTPS, and Secure Shell (SSH) for local and remote
access via the WAN and LAN networks. The serial console, USB, and SSH services offer a command line
interface (CLI). There are three user accounts/roles for management access:
accounts can be centrally managed with a RADIUS server. RADIUS accounts can be mapped to one of the
three user accounts/roles (see see “RADIUS” on Page 71).
NOTE: The Orbit MCR device is designed for high security environments. As such, management of the
device does not support Telnet, but instead implements the more secure SSH protocol.
Web-Based Device Manager
A web-based user interface is also available fo r this product. The web interface provides an intuitive, graphical facility, well-suited for many simple routine configuration and control tasks. An introduction and
sample screens for the web interface are provided in “APPENDIX G – Device Manager” on Page 129.
3.1 Connecting to a PC
3.1.1 Differences Between Serial & SSH
admin, tech, and oper. User
Serial and SSH both present identical management capabilities, but the method of access is different for each. Serial involves an RS-232 serial connection from a PC to the unit’s management
COM port. SSH uses an Ethernet PC connection to the unit’s ETH port. Maximum recommended
cable length for a serial connection is 50 feet (15 meters). SSH can be connected to the unit from
any network point that has connectivity with the PC, including remotely over the Internet, or using
other networks.
The focus of these instructions is on Serial access, but SSH may also be used by following these
additional points, which replace Steps 1-3 below:
• Connect to the unit with a PC that is on the same IP network as the MCR. Launch an SSH
client program, and connect to the unit using its programmed IP address.
• The default IP address for the unit is 192.168.1.1. If you do not know the current IP address
of the unit, follow the serial configuration instructions below, where you can determine the
address and continue configuration, or check with your network administrator.
3.1.2 Establishing Communication—Serial Interface
Follow these steps to configure the unit for its first use with serial console interface:
1. Connect a PC to the unit’s
COM port as shown in Figure 11. (Maximum recommended cable
length: 50 ft./15 m)
NOTE: Not all PCs include a serial port. If one is not available, a USB port may be used, along with a USB-to-Serial
adapter (with appropriate driver software). Adapters are available from many manufacturers, including GE
MDS. The MCR Orbit’s USB port can be used to access the device management console by using a
Mini-USB cable between the device and a PC. The PC needs to register the device driver.
14 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 23
NOTE: If the COM port has been configured for terminal server operation, pressing +++ switches it to console
PC Running Terminal Session
To COM Port
ENTER
ENTER
ENTER
(management) mode. Serial console mode is required for the following steps.
Launch a terminal communications program, such as HyperTerminal with the following communication parameters: 1 15200 bps (default speed), 8 bits, no parity, one stop bit (8N1), and flow
control disabled. Incorrect parameter settings are a frequent cause of connection difficulties;
Double check to be sure they are correct.
If necessary, an adapter may be used to convert the unit’s RJ-45 serial jack to a DB-9F type (GE
MDS part no. 73-2434A12). If no serial port exist on the PC, a USB-to-serial adapter cable may be
used to connect to the MCR unit, or a Mini-USB cable may be connected between the MCR’s USB
device port and the PC.
Invisible place holder
Figure 11. PC Connection for Programming/Management
2. Press the key to receive the Login: prompt. This indicates that the unit is ready to receive
commands.
3. At the Login: prompt, enter admin (lower case) and press .
4. If no password has been previously set, enter the default password (admin) and press ;
Otherwise, enter the saved password at the Password: prompt. (Before placing the unit in final
service, it is recommended that the default password be changed to ensure that only authorized
users have access.)
5. After successful login, the command prompt appears where you may configure and manage a
number of unit settings.
3.1.3 Setting Basic Parameters—First Steps
There are three tasks that should be performed after initial startup and connection to a PC, as follows:
1. Create One-Time Programmable passwords for device recovery in the event a password is lost.
2. Change the login passwords.
3. Evaluate the default factory configuration and set it to the user's required security level.
Tab Completion Feature
Tab-completion is a powerful feature that presents CLI users with assistance while typing. Depending on
the text that was already entered, tab-completion will display different possible completions. When the tab
key is pressed and no text has been entered, the CLI shows all possible commands that can be typed.
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 15
Page 24
3.1.4 One-Time “Recovery” Passwords
The MDS Orbit platform employs extensive security measures to prevent unauthorized access. As such,
there are no hidden manufacturer passwords or other “backdoors” found in less secure products. If a password is lost, there is no way to access the unit, except by using a one-time password (OTP) for recovery.
This must be established by the user beforehand. Without a one-time password, the unit will not be accessible, and the hardware will need to be replaced. Not even the factory will be able to assist you if a password
is lost, so creating a one-time password is strongly encouraged.
One-Time Passwords: How They Work
One-time recovery passwords put control directly and exclusively in the user’s hands. They are similar to
spare keys for a lock. If you make a spare key, and put it away safely, you can take it out to quickly gain
entry when your primary key is lost. If you don’t make a spare, you are always at risk of locking yourself out.
A one-time recovery password is different from the one used to log into the unit on a routine basis. It is only
for use when the primary password is lost or forgotten. When a one-time password is used to log in, that
password is automatically revoked from the list of passwords created. (You may create up to five one-time
passwords at one time, and more can be created if some get used). A password cannot be used ag ain for
log-in to the unit (hence the name “one-time” password).
Creating a One-Time Password
To create a one-time recovery password, proceed as follows:
1. Upon successful log-in, enter the following command:
request system recovery one-time-passwords create function <selected function>
A one-time password is automatically generated and displayed on the screen. Copy this password
and save it in the desired location on your PC. There is no way to ever view it again from the
command line console, so be sure it is properly saved.
2. To create additional one-time passwords (up to a total of five), repeat the step above.
Logging in With a One-Time Password
Logging in with a one-time password can only be performed from the local serial or USB cons ole. You
cannot use a one-time password when connecting to the unit remotely. To use the one-time password for
log-in, proceed as follows:
1. At the username prompt, enter the word
2. At the
password prompt, paste in the one-time-password saved earlier on your PC. Using a
recovery.
one-time-password forces the unit to perform the “function” which was previously defined when the
password was created:
factory-reset—The unit resets its entire configuration to factory defaults
•
login—The unit allows logging in with “admin” privileges
•
Special case: If someone has disabled console access on the
COM port, the login prompt will still be present
on that console, but only one-time-passwords will be accepted. This is done to provide a way to recover the
unit in the case where the
COM port has been disabled and the unit cannot be accessed via TCP (for example;
SSH).
Deleting a One-Time Password
As noted earlier, a one-time password is automatically revoked when it is used for log-in. A revoked password may be replaced, but it must first be removed from the list so a new one can be generated. Any of the
five stored passwords may be removed on demand. As long as there is a free slot, an additional password
can be created, up to the maximum number of five. Logs are generated when the user creates, deletes or logs
in with a one-time-password. To remove an existing password from the list, proceed as follows:
16 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 25
Enter the command request system recovery one-time-passwords delete identifier X, where X is a number
from the currently available one-time passwords. This identifier is not reused. If all five passwords have
been created, then ID 1 can be deleted, and the next created password will be at ID 6.
The current list of passwords may be viewed by issuing the command
. The following is an example output from that command. On the unit shown, only two passwords
words
show system recovery one-time-pass-
have been stored. Password 1 or 2 can be deleted from this list.
DATE
IDENTIFIER FUNCTION STATUS DATE CREATED REVOKED USER
----------------------------------------------------------------------
1 login usable 2012-06-19T00:27:24+00:00
2 login usable 2012-06-19T00:27:25+00:00
3.2 Pre-Configured Settings
The MCR is highly configurable to meet field requirements, but comes pre-configured as follows:
• The COM and USB ports are enabled for local console operation
• The Ethernet ports are bridged with the WiFi AP
• WiFi AP SSID is set based on the unit's serial number, and takes the form of:
GEMDS_<SERNUM>. The unit’s serial number is printed on the chassis sticker.
• WiFi is enabled with passphrase:
• A DHCP server is enabled for WiFi clients and the Ethernet LAN ports
• Cellular service is enabled with firewall/router rules in place.
• The following default configured firewall rules are also in effect:
# Firewall
set services firewall enabled true
set services firewall address-set LOCAL-NETS addresses [ 192.168.1.0/24 ]
set services firewall filter IN_TRUSTED rule 10 match protocol all
set services firewall filter IN_TRUSTED rule 10 actions action accept
set services firewall filter IN_UNTRUSTED rule 1 match protocol icmp
set services firewall filter IN_UNTRUSTED rule 1 actions action accept
set services firewall filter IN_UNTRUSTED rule 2 match protocol udp
set services firewall filter IN_UNTRUSTED rule 2 match src-port services [ dns ]
set services firewall filter IN_UNTRUSTED rule 10 match protocol all
set services firewall filter IN_UNTRUSTED rule 10 actions action drop
set services firewall filter OUT_TRUSTED rule 10 match protocol all
set services firewall filter OUT_TRUSTED rule 10 actions action accept
set services firewall filter OUT_UNTRUSTED rule 1 match src-address address-set LOCAL-NETS
set services firewall filter OUT_UNTRUSTED rule 1 match src-address add-interface-address true
set services firewall filter OUT_UNTRUSTED rule 10 match protocol all
set services firewall filter OUT_UNTRUSTED rule 10 actions action drop
set services firewall nat source rule-set MASQ rule 1 source-nat interface
GEMDS_ORBIT
The commands below show how the default settings are made. The unit must be in Configuration Mode to
make these settings. Each command string begins with the word
1. set interfaces interface Wi-Fi physical-interface Wi-Fi
2. set interfaces interface Wi-Fi wifi-config mode access-point ap-config ap GEMDS_1 broadcast-ssid true
privacy-mode wpa2-personal psk-config psk GEMDS_ORBIT
3. set interfaces interface Cell physical-interface Cell
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 17
set:
Page 26
4. set interfaces interface Cell ipv4 dhcp
5. set interfaces interface Cell filter in put IN_UNTRUSTED
6. set interfaces interface Cell filter ou tput OUT_UNTRUSTED
7. set interfaces interface Cell nat source MASQ
8. set services serial console serial-ports [ COM1 USB1 ]
9. set interfaces interface ETH1 ph ysical-interface ETH1
10. set interfaces interface ETH2 physical-interface ETH2
11. set interfaces interface Bridge virtual-type bridge
12. set interfaces interface Bridge filter input IN_TRUSTED
13. set interfaces interface Bridge filter output OUT_TRUSTED
14. set interfaces interface Bridge ipv4 address 192.168.1.1 prefix-length 24
15. set interfaces interface Bridge bridge-settings members port ETH1
16. set interfaces interface Bridge bridge-settings members port ETH2
17. set interfaces interface Bridge bridge-settings members wifi-ap GEMDS_1
18. set services dhcp v4subnet 192.168.1.0/24 range-start 192.168.1.2 range- end 192.168.1.10 broadcast-address 192.168.1.255 router 192.168.1.1
19. set services dhcp enabled true
3.3 YANG Interface
The unit employs a data modeling language called YANG to model the configuration and status of the
device. YANG is used in conjunction with the NETCONF protocol to provide a device-specific data model
that can be administered by any NETCONF-capable NMS. The YANG data model is released with each
version of the device so NMS administrators can accurately administer the device per release.
Together, YANG and NETCONF present a structured user interface for the unit. The device data defined
by the YANG data model is either Operational Data or Configuration Data. Configuration Data may be
changed, but Operational Data can only be viewed.
Configuration Data
Configuration Data is any piece of data that can be changed by an administrator and the changes are persistent even if the device reboots. The IP address of the LAN port is an example of Configuration Data.
Operational Data
Operational Data is any piece of data that is volatile and will not be saved if the device is rebooted. Operational data is typically read-only, such as statistics information showing status or a value representing the
operation of the device. Ethernet statistics are an example of operational data.
Default Values
While configuring the unit, some of the configuration data may not need to be explicitly set, but instead the
data assumes the default value defined in the data model. For example, when a File Server configuration is
added and the server type is specified as TFTP, then the remote TFTP port will default to
69 if the user does
not explicitly specify the port. Data nodes that do not have a default value will require entry of a value for
that node during configuration. The command line interface (CLI) prompts for entry of a node value if the
node is mandatory and does not have a default value.
18 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 27
When viewing the configuration, the nodes that have default values and have not been explicitly set by the
user are not displayed. Users can selectively view these defaulted values by using
The
show command can be used to view configuration data. Notice that the information displayed is dif-
details option on the CLI.
ferent, depending on which mode the CLI is in; Operational or Configuration.
Remote Procedure Call (Request)
This is an action that a user requests. Rebooting of the device, for example, is considered a request.
Privilege
A user who logs on to the device will belong to a role-based group. Each group is limited in capability to
view operational data or to change configuration data. Groups with lesser privileges will not be presented
with the option to view or change data on the CLI, which can be done by higher-privileged groups.
Changing Configuration Data and committing changes
Changing configuration data requires two steps. The first step is to use a user-interface to add, remove, or
alter a piece of configuration data. The second step is to use the user-interface to commit the change. Multiple changes can be made prior to committing them. This two-step process allows users to make multiple
changes to the configuration and apply them in a bulk commit. Additionally, the device can validate the bulk
commit and reject it if there is an error.
3.3.1 CLI Login Prompt
The CLI is available via the serial console or an SSH session. Use the default serial console settings shown
in the section titled “Serial Console” on Page 26 to connect a Computer to the unit via a serial cable. Once
the network settings are configured, users can also connect to the device via SSH over the network.
The CLI prompts for a login to the device before any other actions can be made. The defaults for both username and password are
admin. These credentials should be changed before placing the unit in full service.
(none) login: admin
Password: (valid password, default is admin)
Welcome to the CLI
admin connected from 127.0.0.1 using console on (none)
admin@(none) 04:24:12>
Using the CLI
This section describes how to use the CLI by using an example: changing the name of the unit.
Step 1: Login to the device using the serial console and us e the default username admin and the default pass-
admin.
word
(none) login: admin
Password:
Welcome to the CLI
admin connected from 127.0.0.1 using console on (none)
admin@(none) 04:24:12>
Step 2: Instruct the device to enter configuration mode by typing configure and pressing the enter key:
admin@(none) 04:51:06> configure
Entering configuration mode private
[ok][2012-06-20 04:51:07]
[edit]
admin@(none) 04:51:07%
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 19
Page 28
Step 3: Change the device name by typing in the following, followed by enter: set system name Device539
admin@(none) 05:31:14% set system name Device539
[ok][2012-06-20 05:32:45]
[edit]
admin@(none) 05:32:45%
Step 4: Verify the change looks correct by reading the data back using the following, followed by the enter
show system name
key:
admin@(none) 05:32:53% show system name
name Device539;
[ok][2012-06-20 05:35:28]
[edit]
admin@(none) 05:35:28%
Step 5: Commit the change by typing in the following, followed by the enter key: commit
admin@(none) 05:36:20% commit
Commit complete.
[ok][2012-06-20 05:36:21]
[edit]
admin@Device539 05:36:21%
Step 6: Exit the configuration mode by typing the following, followed by the enter key: exit
admin@Device539 05:40:15% exit
[ok][2012-06-20 05:40:17]
admin@Device539 05:40:17>
Step 7: Exit the login session by typing the following, followed by the enter key: exit
admin@Device539 05:40:32> exit
Device539 login:
20 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 29
CLI Quick Reference Table
Table 7 provides a summary listing of commonly-needed tasks and the appropriate commands to enter. The
table can be used as a quick reference before consulting the more detailed information which follows in this
section. Each CLI command is proceeded by the symbol
> for operational command, or % for a configura-
tion command.
Table 7. CLI Quick Reference Table
If you wish to... Enter this CLI command:
Create a one-time password > request system recovery one-time-password create function <user
function>
View all network interface
status and statistics
Create a bridge % set interfaces interface myBridge virtual-type bridge
Add the ETH1 interface to a
bridge
Remove the ETH1 interface
from a bridge
Set WiFi AP SSID % set interfaces interface Wi-Fi wifi-config mode access-p oint
Enable WiFi WPA2-Personal
security
Enable WiFi SSID
Broadcasting
View WiFi settings > show configuration interfaces interface Wi-Fi wifi-config | details
Monitor WiFi statistics > show interfaces interface Wi-Fi statistics | repeat 5
View the cell module status > show interfaces interface Cell
View the cell APN > show configuration interfaces interface Cell cell-config apn
View the routing table > show routing
View the event log > show table logging event-log
Set the admin user’s
password
Set the device name % set system name “Mydevice”
Set the baud rate on COM1 % set services serial ports COM1 baud-rate b19200
Download a firmware
package from TFTP server at
192.168.1.10
Monitor firmware download
status
Export configuration file to a
TFTP server at 192.168.1.10
Reboot device to firmware
image #2
> show interfaces
% set interfaces interface myBridge bridge-settings members port
ETH1
% delete interfaces interface myBridge bridge-settings members port
ETH1
ap-config ap myssid
% set interfaces interface Wi-Fi wifi-config mode access-p oint
ap-config ap myssid privacy-mode wpa2-personal psk-config psk
mypassphrase encryption ccmp
% set interfaces interface Wi-Fi wifi-config ap-config ap myssid
broadcast-ssid true
> request system authentication change-password user admin
password admin1234
> request system firmware reprogram-inactive-image filename
iwc-bkrc-1_0_0.mpk manual-file-server { tftp { address 192.168.1.10 } }
> show system firmware reprogramming-status
> request system configuration-files export filename myConfig.txt
manual-file-server {tftp {address 192.168.1.10} }
> request system power restart-to-image location 2
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 21
Page 30
Specific Examples
Example #1
In Figure 12, the MCR-4G is functioning as a WiFi Access Point to provide connectivity between a set of
laptops and a handheld device. The MCR-4G is also acting as a DHCP server for the laptops and handheld
device.
Invisible place holder
Figure 12. Example 1: Unit Providing Laptop and Handheld Device Connectivity
The following commands will configure the MCR-4G for this scenario.
1. % set interfaces inter fa ce Wi-Fi physical-interface Wi-Fi
2. % set interfaces inter fa ce Wi-Fi wifi-config mode access-point ap-config ap myssid enabled true
3. % set interfaces inter fa ce myBridge virtual-type bridge
4. % set interfaces inter fa ce myBridge bridge-settings members port ETH1
5. % set interfaces inter fa ce myBridge bridge-settings members wifi-ap myssid
6. % set interfaces inter fa ce myBridge ipv4 address 192.168.1.21 prefix-length 24
7. % set services dhcp enabled true v4subnet 192.168.1.0/24 domain-name gemds range-start 192.168.1.10
range-end 192.168.1.19 router 192.168.1.1 broadcast-address 192.168.1.255
22 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 31
Example #2
In Figure 13, there are two MCR-4G devices, one acting as a WiFi Access Point, the other as a WiFi Station.
Together, the MCR-4G devices are providing a wireless bridge between the laptop and the SCADA device.
Invisible place holder
Figure 13. Example 2: Units Providing Wireless Bridge Between Laptop & SCADA Device
The following commands will configure the MCR-4G #1 for this scenario.
1. % set interfaces interface Wi-Fi physical-interface Wi-Fi
2. % set interfaces interface Wi-Fi wifi-config mode access-point ap-config ap myssid
3. % set interfaces interface myBridge bridge-settings members port ETH1
4. % set interfaces interface myBridge bridge-settings members wifi-ap myssid
5. % set interfaces interface myBridge ipv4 address 192.168.1.21 prefix-length 24
6. % set services dhcp enabled true v4subnet 192.168.1.0/24 domain-nam e gemds range-start 192.168.1.10
range-end 192.168.1.19 router 192.168.1.1 broadcast-address 192.168.1.255
The following commands will configure the MCR-4G #2 for this scenario.
1. % set interfaces interface Wi-Fi physical-interface Wi-Fi
2. % set interfac es interface Wi-Fi wifi-config mode station station-config ap myssid enabled true
3. % set interfaces interface myBridge virtual-type bridge
4. % set interfaces in terface myBridge bridge-settings members port ETH1
5. % set interfaces in terface myBridge bridge-settings members wifi-station interface Wi-Fi
6. % set interfaces in terface myBridge ipv4 address 192.168.1.22 prefix-length 24
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 23
Page 32
Example #3
Figure 14 shows the MCR-4G #2 device acting as a terminal server to provide connectivity to the
serial-based SCADA device via UDP.
NOTE: The configuration for MCR-4G #1 in Figure 14 is identical to the configuration shown in the previous
example (Example #2).
Invisible place holder
Figure 14. Example 3: Unit Providing Connectivity to Serial-Based SCADA Device via UDP
The following commands will configure the MCR-4G #2 for this scenario.
1. % set interfaces interface Wi-Fi physical-interface Wi-Fi
2. % set interfaces in terface Wi-Fi wifi-config mode station station-config ap myssid enabled true
3. % set interfaces interface myBridge virtual-type bridge
4. % set interfaces in terface myBridge bridge-settings members port ETH1
5. % set interfaces in terface myBridge bridge-settings wifi-station members interface Wi-Fi
6. % set interfaces in terface myBridge ipv4 address 192.168.1.22 prefix-length 24
7. % set services serial terminal-server server COM1 mode udp port 30000 remote address 192.168.1.11 port
30001
24 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 33
Example #4
In Figure 15, the MCR-4G provides internet access for a laptop that is accessing a public web page.
Invisible place holder
Figure 15. Example 4: Unit Providing Internet Access for Laptop
SIM Type: In this scenario, the MCR-4G has a SIM card installed that simply provides Internet access.
The following commands will configure the MCR-4G for this scenario.
1. % set interfaces interface myBridge virtual-type bridge
2. % set interfaces interface myBridge bridge-settings members port ETH1
3. % set interfaces interface myBridge ipv4 address 192.168.1.21 prefix-length 24
4. % set interfaces interface Cell physical-interface Cell enabled true
5. % set services firewall enabled true
6. % set services firewall filter IN_UNTRUSTED
7. % set services firewall filter IN_UNTRUSTED rule 1 match protocol icmp
8. % set services firewall filter IN_UNTRUSTED rule 1 actions action accept
9. % set services firewall filter IN_UNTRUSTED rule 10 match protocol all
10. % set services firewall filter IN_UNTRUSTED rule 10 actions action drop
11. % set interfaces interface Cell filter input IN_UNTRUSTED
12. % set services firewall filter OUT_UNTRUSTED rule 10 match protocol all
13. % set services firewall filter OUT_UNTRUSTED rule 10 actions action accept
14. % set interfaces interface Cell filter output OUT_UNTRUSTED
15.
% set services firewall nat source rule-set MASQ
16. % set services firewall nat source rule-set MASQ rule 1 source-nat interface
17. % set services interfaces interface Cell nat source MASQ
3.4 Operational Topic Areas
The remaining headings in this section describe key operational features of the MCR unit, and list configurational options for them. Each major heading begins at the top of a new page. For this reason, large areas
of white space exist at the end of some sections. This is done to provide a clear delineation between major
sections.
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 25
Page 34
Serial Console
A serial cable may be used to connect to a COM port on the unit to access the CLI. The default serial console
settings are 115200 bps with 8N1 format. A mini-USB-to-USB cable may also be used to connect to a Computer in case no serial port exists. If a mini-USB connection is used, the computer must contain the appropriate device driver. A driver for serial operation can be found on GE MDS website.
Configuring
This sequence shows how to add console access to the COM1 and COM2 serial ports and set the COM2
baud rate to 19200 bps:
admin@(none) 00:04:43% set services serial console serial-ports [ COM1 COM2 ]
[ok][2012-06-19 00:04:57]
[edit]
admin@(none) 00:04:59% set services serial ports COM2 baud-rate b19200
[ok][2012-06-19 00:05:28]
[edit]
admin@(none) 00:05:28% commit
Commit complete.
[ok][2012-06-19 00:07:51]
[edit]
admin@(none) 00:07:51%
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the state and statistics:
admin@(none) 00:10:38> show configuration services serial | details
ports COM1 {
line-mode rs232;
baud-rate b115200;
byte-format bf8n1;
hw-flow-control false;
vmin 255;
vtime 1;
capability rs485-2-wire,rs485-4-wire;
}
ports COM2 {
line-mode rs232;
baud-rate b19200;
byte-format bf8n1;
hw-flow-control false;
vmin 255;
vtime 1;
capability "";
}
console {
serial-ports [ COM1 COM2 ];
}
[ok][2012-06-19 00:12:00]
admin@(none) 00:12:00>
26 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 35
Network
Understanding
The unit has multiple network interfaces including LAN, Cellular, and WiFi. Each of these has numerous
networking features and each feature is described in a separate section on the following pages:
• Static or dynamic IP addressing (DHCP) for each interface
•Bridging
• Firewall
• Routing
•VPN
Configuring
See each individual section for details about configuring the LAN, Cell, WiFi interfaces, and related networking features.
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the state and statistics of all the
network interfaces. The result of this command will vary from one configuration to another, so the following
is intended merely to serve as an example:
admin@(none) 11:36:52> show interfaces
interfaces interface Bridge
oper-status up
if-index 1
phys-address 00:06:3d:06:ea:99
lower-layer-if [ ETH1 ETH2 ]
statistics discontinuity-time 2013-09-09T16:16:13-04:00
statistics in-octets 397914757
statistics in-unicast-pkts 1755097
statistics in-multicast-pkts 0
statistics in-discards 0
statistics in-errors 0
statistics out-octets 734348
statistics out-unicast-pkts 14144
statistics out-discards 0
statistics out-errors 0
system-device br0
PREFIX
IP LENGTH
----------------------
192.168.1.102 23
IP PHYS ADDRESS STATE
-------------------------------------------------
192.168.1.1 04:fe:7f:e3:7b:c2 stale
192.168.1.91 80:c1:6e:fb:99:33 stale
192.168.1.171 68:05:ca:05:de:2a stal e
192.168.1.98 80: c1:6e:f0:3b:7a reachable
192.168.1.172 00:1e:67:18:b3:34 stal e
FF02::1 33:33:00:00:00:01 noarp
FF02::1:FF00:1 33:33:ff:00:00:01 noarp
FF02::1:FFBF:1917 33:33:ff:bf:19:17 noarp
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 27
Page 36
bridgeStatus stp port ETH1
number 1
priority 0
state forwarding
path-cost 100
designated-root 7035.04fe7fe36980
designated-cost 100
designated-bridge 8000.000 2fd5dd280
designated-port 32788
bridgeStatus stp port ETH2
number 2
priority 0
state disabled
path-cost 100
designated-root 8000.00063d06ea99
designated-cost 0
designated-bridge 8000.000 63d06ea99
designated-port 32770
bridgeStatus stp port GEMDS_ORBIT
interfaces interface Cell
oper-status not-present
if-index 2
lower-layer-if [ ]
statistics discontinuity-time 2013-09-09T16:16:13-04:00
statistics in-octets 0
statistics in-unicast-pkts 0
statistics in-multicast-pkts 0
statistics in-discards 0
statistics in-errors 0
statistics out-octets 0
statistics out-unicast-pkts 0
statistics out-discards 0
statistics out-errors 0
system-device eth5
cell-status imsi ""
cell-status imei ""
cell-status iccid ""
cell-status mdn ""
cell-status apn ""
cell-status app-sw-version ""
cell-status modem-sw-versi on ""
cell-status sim-state unknow n
cell-status modem-state unkn own
cell-status roaming-state un known
cell-status service-state no ne
cell-status rssi 0
interfaces interface ETH1
oper-status up
if-index 3
phys-address 00:06:3d:06:ea:99
lower-layer-if [ ]
speed 10000000
statistics discontinuity-time 2013-09-09T16:16:13-04:00
statistics in-octets 461542638
statistics in-unicast-pkts 2649078
statistics in-multicast-pkts 0
statistics in-discards 13
statistics in-errors 0
statistics out-octets 991884
statistics out-unicast-pkts 18019
28 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 37
statistics out-discards 0
statistics out-errors 0
eth-phy-status "10 Mb, Half Duplex"
system-device eth0
interfaces interface ETH2
oper-status lower-l ay er -d ow n
if-index 4
phys-address 00:06:3d:06:ea:99
lower-layer-if [ ]
speed 1000000 0
statistics discontinuity-t ime 2013-09-09T16:16:13-04:0 0
statistics in-octets 0
statistics in-unicast-pkts 0
statistics in-multicast-pk ts 0
statistics in-discards 0
statistics in-errors 0
statistics out-octets 0
statistics out-unicast-pkt s 0
statistics out-discards 0
statistics out-errors 0
eth-phy-status "Not Connected"
system-device eth1
interfaces interface Wi-Fi
oper-status not-pre se nt
if-index 5
lower-layer-if [ ]
statistics discontinuity-t ime 2013-09-09T16:16:14-04:0 0
statistics in-octets 0
statistics in-unicast-pkts 0
statistics in-multicast-pk ts 0
statistics in-discards 0
statistics in-errors 0
statistics out-octets 0
statistics out-unicast-pkt s 0
statistics out-discards 0
statistics out-errors 0
system-device wlan0
wifi-status serial-number ""
wifi-status mode ""
wifi-status tx-power 0
wifi-status channel 0
wifi-status ap-status ap GEMDS_ORBIT
[ok][2013-09-12 11:37:02]
admin@(none) 11:37:02>
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 29
Page 38
LAN
Understanding
The unit has external Local Area Network (LAN) ports that can be used to connect to a local LAN. It supports both IPv4 and IPv6 addresses and may be assigned multiple IP addresses. The LAN port can be
assigned static IP addresses or a dynamically allocated address can be assigned using DHCP.
NOTE: The LAN port should be assigned IP addresses only if it is a routed interface (that is, not in a
bridge). Refer to the section on Bridging later in the document.
Configuring
The following sequence shows how to configure the
admin@(none) 06:03:53> configure
Entering configuration mode private
[ok][2012-06-20 06:03:54]
admin@(none) 06:04:45% set interfaces interface ETH1 ipv4 address 192.168.1.11
prefix-length 24
[ok][2012-06-20 06:05:01]
[edit]
admin@(none) 06:05:01% commit
Commit complete.
[ok][2012-06-20 06:05:03]
ETH1 port with a static IPv4 address:
[edit]
admin@(none) 06:05:03%
The following sequence shows how to configure the ETH1 port to obtain a dynamic IPv4 address usin g
DHCP:
admin@(none) 06:03:53> configure
Entering configuration mode private
[ok][2012-06-20 06:03:54]
admin@(none) 06:04:45% set interfaces interface ETH1 ipv4 dhcp
[ok][2012-06-20 06:05:01]
[edit]
admin@(none) 06:05:01% commit
Commit complete.
[ok][2012-06-20 06:05:03]
[edit]
admin@(none) 06:05:03%
30 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 39
Monitoring
Ensure the CLI is in Operational mode. Follow the example below to view the state and statistics of the
ETH1 port:
admin@(none) 11:41:58> show interfaces interface ETH1
interfaces interface ETH1
oper-status up
if-index 3
phys-address 00:06:3d:06:ea:99
lower-layer-if [ ]
speed 10000000
statistics discontinuity-time 2013-09-09T16:16:13-04:00
statistics in-octets 34359972 13
statistics in-unicast-pkts 37 738358
statistics in-multicast-pkt s 0
statistics in-discards 13
statistics in-errors 0
statistics out-octets 3537454
statistics out-unicast-pkts 73998
statistics out-discards 0
statistics out-errors 0
eth-phy-status "10 Mb, Half Duplex"
system-device eth0
PREFIX
IP LENGTH
----------------------
192.168.1.11 24
IP PHYS ADDRESS STATE
----------------------------------------------
192.168.1.100 04:fe:7f:e3:7b:c2 reachable
192.168.1.171 68:05:ca:05:de:2a stale
192.168.1.104 00:06:3d:06:bd:12 stale
192.168.1.98 80:c1:6e:f0:3b:7a reachable
192.168.1.172 00:1e:67:18:b3:34 stale
FF02::1:3 33:33:00:01:00:03 noarp
FF02::1:FF00:1 33:33:ff:00:00:01 noarp
[ok][2013-09-24 11:42:15]
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 31
Page 40
VLAN Operation
Understanding
Virtual Local Area Networks (VLANs) are generic interface types in the MCR-4G, and can be assigned
unique IP addresses. They are treated the same as any other interface type, but they offer a way to link traffic
between interface ports. As such, a VLAN device can be thought of as a “bridging device.”
Setup
To setup a VLAN, you must first create one or more VLAN interfaces. Four sample commands are shown
below for doing this; one with an ID of
% set interfaces interface mgmt_vlan virtual-type vlan
% set interfaces interface mgmt_vlan vlan-config vlan-id 99
% set interfaces interface video_vlan virtual-type vlan
% set interfaces interface video_vlan vlan-config vlan-id 300
Operational Modes
Interfaces can have three separate VLAN modes:
set interface behavior, and examples of their use are provided below.
Trunk: To add ETH1 as a trunk (tagged) port in both defined VLANs above, the command is:
% set interfaces interface ETH1 vlan-mode trunk vlans [ video_vlan mgmt_vlan ]
Access: To set ETH2 as an access port for video_vlan the command is:
99 and another with an ID of 300:
none (default), trunk, or access. These modes are used to
% set interfaces interface ETH2 vlan-mode access vlan video_vlan
Native VLANs
A VLAN device may also be specified as a “native” VLAN, and this is set by the command:
set interfaces interface my_native_vlan virtual-type vlan vlan-config vlan-id 600 native-vlan true
A native VLAN is conceptually the same as a standard VLAN except that the packets will never be tagged.
The purpose of a native VLAN is to segregate untagged packets on a VLAN trunk port that normally o nly
contains tagged traffic. If a VLAN trunk port receives an untagged packet, and the trunk is a member of the
native VLAN, that packet will be treated as if it came from the native VLAN. If the trunk port is not a
member of the native VLAN and an untagged packet arrives on that port, the packet will be dropped.
As VLAN's are implemented as bridges, and it is not valid for a bridge to be a member of another bridge, it
follows that a VLAN interface cannot be configured as a member of a bridge. VLANs can be configured
with IP addresses just as any other interface in the system can.
32 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 41
Cell
Understanding
The unit incorporates a 4G LTE module capable of operation on Verizon Wireless LTE/CDMA network
(LTE 700 Mhz Band 13) in the United States. The unit supports routing of TCP/UDP/IP data from the Cellular WAN network interface to any of the other network interfaces (including WiFi or LAN) using the
IPsec VPN or network address and port translation (NAPT) feature and to the COM1 (or COM2) serial port
using the terminal server service. The configuration of these uses cases is specified in respective sections
on VPN, Firewall and NAT, and Terminal Service.
The cellular modem inside the unit supports main (primary) and secondary antenna (for receive diversity).
The primary antenna must be installed for cell modem to register with the cellular network. It is strongly
recommended that secondary antenna be installed for achieving a robust cellular link. There should be no
physical obstructions around the antennas. The main and diversity antennas must have a minimum amount
of 27 dB isolation from each other to ensure optimal LTE mode operation of the module.
Cell Configuration Hierarchy
interface Cell {
cell config {
apn <apn-name>
keep-alive {
address <host name or address>
interval <host name or address>
recovery-on-timeout <true| false>
}
service-recovery {
general-recovery-interva l <time in seconds>
lte-recovery <true|false>
lte-recovery-interval <tim e in seconds>
}
}
}
Access Point Name (APN)
After MCR has registered on the cellular network, it sets up the IP data connection with a specific Packet
Data Network identified by the Access Point Name (APN). APN is a string identifier.
The MCR comes preconfigured with APN of “vzwinternet”. Hence, it attempts to set up a data connection
toward internet PDN that provides internet connectivity. For this data connection to succeed, a SIM card
that has been provisioned for internet access needs to be obtained from the service provider and installed in
MCR.
If a private network (PN) account has been arranged with the service provider, a SIM card will be issued
from that account. When the modem is powered up with such a SIM, the default APN on the modem is automatically updated by the service provider to the one that identifies the user’s private network. This procedure is called OTA APN update. This procedure may not always succeed, and hence, requires the user to
manually update the APN on the MCR. The following example shows how to update APN manually via
CLI:
admin@(none) 15:28:44> config
Entering configuration mode private
[ok][2013-01-18 15:28:46]
[edit]
Cell
admin@(none) 15:28:46% set interfaces interface
[ok][2013-01-18 15:29:36]
[edit]
admin@(none) 15:29:36% commit
Commit complete.
[ok][2013-01-18 15:29:46]
cell-config apn GEDEROC.GW6.VZWENTP
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 33
Page 42
LTE Recovery
The cellular modem used inside the unit may occasionally remain in a 3G (EVDO-REV A) service state and
not transition to 4G LTE. The firmware incorporates a recovery mechanism to recover from this condition.
If the cellular modem has been in 3G coverage for more than 15 minutes, the firmware resets the modem to
bring it back into LTE service state. LTE recovery is enabled by default. This mechanism should be disabled
if the unit is deployed in areas that either lack or have poor LTE coverage. Otherwise, the cellular modem
will unnecessarily reset every 15 minutes.
Keep Alive
This feature allows the cellular modem to maintain a connection in situations where no traffic is passed over
cellular link for long periods of time, which would otherwise cause disruption. The keep alive mechanism
sends an ICMP echo message to the configured address/host at the configured interval. This feature should
be used only if an application is passing data very infrequently over a cellular connection (i.e., if data is
passed at a rate of less than once per hour).
The commands for setting 3G/4G operation are as follows:
4G Operation
% set interfaces interface Cell cell-config service-recov ery lte-recovery true
% commit
– Default programming.
3G Operation – Turn off the LTE Recovery Mode to allow continual 3G mode operation without periodic
disconnection for 4G service search.
% set interfaces interface Cell cell-config service-recov ery lte-recovery false
% commit
NOTE: The Verizon network can disconnect the cellular connection if any packets get routed from LAN
to Cellular interface without undergoing masquerading (Source Network Address Translation
(NAT) before exiting the cellular interface. Therefore, always configure masquerading on the
cellular interface. Refer to the “Firewall and NAT” section (Page 45) in this manual for more
information on NAT configuration.
34 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 43
Monitoring
Ensure the CLI is in Operational mode. Follow the example below to view the cellular interface state and
statistics:
admin@(none) 08:33:32> show interfacesshow interfaces interface Cell
interfaces interface Cell
oper-status up
if-index 2
phys-address 00:15:ff:75:93:50
lower-layer-if [ ]
statistics discontinuity-time 2013-03-18T09:07:53+00:00
statistics in-octets 3847
statistics in-unicast-pkts 26
statistics in-multicast-pkts 0
statistics in-discards 0
statistics in-errors 0
statistics out-octets 55555
statistics out-unicast-pkts 220
statistics out-discards 0
statistics out-errors 0
system-device eth5
cell-status imsi 311480023788535
cell-status imei 990000624071751
cell-status iccid 89148000000234127059
cell-status mdn 5853534418
cell-status apn GEDEROC.GW6.VZWENTP
cell-status sw-version "1.41 SVN 0 [2011-08-23 18:47:59]"
cell-status sim-state "SIM INIT COMPLETED"
cell-status modem-state connected
cell-status roaming-state home
cell-status service-state lte
cell-status rssi -61
Determining the Cell Module’s IMSI/IMEI
When provisioning the cell module for network service, the cellular provider typically requires the International Mobile Subscriber Identity code (IMSI) or International Mobile Station Equipment Identity code
(IMEI) to be provided. These codes can be determined by entering the following command:
> show interfacesshow interfaces interface Cell cell-status
(Where Cell is the configured name for the cellular device. Cell is the factory default name, but it may have
been changed by a previous user.)
When the above command is entered, a number of items are returned as shown in the example below. The
first two items (highlighted blue) show the IMSI and IMEI codes. These are unique for each unit.
cell-status imsi 31148002363 1413
cell-status imei 99000094760 8727
cell-status iccid 8914800000 0232694605
cell-status mdn 5857948168
cell-status apn VZWINTERNET
cell-status app-sw-version 0.0.5
cell-status modem-sw-version "4.08.02 SVN 0 [2012-12-21 10:52:58]"
cell-status sim-state Ready
cell-status modem-state conn ected
cell-status roaming-state ho me
cell-status service-state lt e
cell-status rssi -62
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 35
Page 44
WiFi
Understanding
The internal WiFi module has FCC modular approval and may only be used with one of the GE MDS
approved antennas (see 802.11 WiFi Module Specifications below). The WiFi antenna is connected to the
reverse-SMA connector on the unit’s front panel. Only these antennas may be used. The WiFi module can
be configured to operate as an 802.11b/g/n Access Point or Station. The operational mode and frequency
can be configured through the user interface.
The specifications for the 2.4 GHz WiFi module (including permissible antennas) are covered in “Technical
Specifications” on Page 86.
The unit supports the following WiFi security modes:
None (should be used only to test connectivity)
1.
WPA2 + CCMP/AES Encryption – This mode should be used if all client devices support WPA2/CCMP.
2.
Encryption + TKIP Encryption – This mode should be used if there is mix of both legacy client devices
3.
that only support WPA/TKIP and newer devices that support WPA2/CCMP.
Also, WPA and WPA2 can be configured further in following modes:
Personal – This uses pre-shared keys (passphrases) configured on the MCR and client devices.
•
Enterprise – This supports EAP-TLS based authentication of client devices (configured with certif-
•
icates/keys) via RADIUS.
The default SSID is based on the unit's serial number, and takes the form of:
GEMDS_<SERNUM> (the serial
number is printed on the chassis sticker). The default password for WiFi operation is GEMDS_ORBIT.
AP Mode
Basic configuration with defaults
The following will configure a basic access point with
admin@(none) 17:06:10% set interfaces interface
admin@(none) 17:06:12% set interfaces interface
operation-mode 80211g ap
admin@(none) 17:06:13% show interfaces interface
mode access-point;
tx-power 15;
ap-config {
ap somessid {
broadcast-ssid true;
station-max 7;
station-timeout 300;
beacon-interval 100;
privacy-mode none;
vlan-mode none;
}
channel 6;
operation-mode 80211g;
dtim-period 2;
rts-threshold 2347;
fragm-threshold 2346;
}
[ok][2013-09-24 17:06:21]
somessid
somessid and set up a basic AP to verify connectivity:
Wi-Fi
physical-interface Wi-Fi
Wi-Fi
wifi-config mode access-point ap-config
Wi-Fi
wifi-config | details
admin@(none) 17:06:37% commit
Commit complete.
[ok][2013-09-24 17:06:39]
36 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 45
Privacy Mode Configuration
The default privacy mode is
wpa2-personal
. (The privacy mode in the previous example was set to none.)
The following configures the unit to use WPA2-Personal security with the default of CCMP/AES encryption and disables the broadcasting of the SSID.
admin@(none) 17:08:10% set interfaces interface
broadcast-ssid false privacy-mode wpa2-personal psk-config psk
admin@(none) 17:08:24% show interfaces interface
mode access-point;
tx-power 15;
ap-config {
ap somessid {
broadcast-ssid false;
station-max 7;
station-timeout 300;
beacon-interval 100;
privacy-mode wpa2-personal;
psk-config {
encryption ccmp;
key-mgmt wpa-psk;
psk somepassphrase;
}
vlan-mode none;
}
channel 6;
operation-mode 80211g;
dtim-period 2;
rts-threshold 2347;
fragm-threshold 2346;
}
[ok][2013-09-24 17:08:26]
Wi-Fi
wifi-config ap-config ap
somepassphrase
Wi-Fi
wifi-config | details
somessid
encryption ccmp
admin@(none) 17:08:30% commit
Commit complete.
[ok][2013-09-24 17:08:33]
This example takes the previous configuration and changes the security to WPA2-Personal with
CCMP/AES + TKIP encryption.
admin@(none) 17:09:10% set interfaces interface
broadcast-ssid false privacy-mode wpa2-personal psk-config psk
ccmp-tkip
admin@(none) 17:09:12% show interfaces interface
mode access-point;
tx-power 15;
ap-config {
ap somessid {
broadcast-ssid false;
station-max 7;
station-timeout 300;
beacon-interval 100;
privacy-mode wpa2-personal;
psk-config {
encryption ccmp-tkip;
key-mgmt wpa-psk;
psk somepassphrase;
}
vlan-mode none;
}
Wi-Fi
wifi-config ap-config ap
somepassphrase
Wi-Fi
wifi-config | details
somessid
encryption
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 37
Page 46
channel 6;
operation-mode 80211g;
dtim-period 2;
rts-threshold 2347;
fragm-threshold 2346;
}
[ok][2013-09-24 17:09:16]
admin@(none) 17:09:30% commit
Commit complete.
[ok][2013-09-24 17:09:31]
Other configuration
The following configures the device to broadcast its SSID, support 802.11b/g/n modes, and operate on
channel 3.
admin@(none) 17:09:14% set interfaces interface
channel 3 ap
somepassphrase
admin@(none) 17:09:24% show interfaces interface
mode access-point;
tx-power 15;
ap-config {
ap somessid {
broadcast-ssid true;
station-max 7;
station-timeout 300;
beacon-interval 100;
privacy-mode wpa2-personal;
psk-config {
encryption ccmp-tkip;
key-mgmt wpa-psk;
psk somepassphrase;
}
vlan-mode none;
}
channel 3;
operation-mode 80211n;
dtim-period 2;
rts-threshold 2347;
fragm-threshold 2346;
}
[ok][2013-09-24 17:09:26]
somessid
encryption ccmp-tkip
broadcast-ssid true privacy-mode wpa2-persona l psk-config psk
Wi-Fi
wifi-config ap-config operation-mode 80211n
Wi-Fi
wifi-config | details
admin@(none) 17:09:37% commit
Commit complete.
[ok][2013-09-24 17:09:44]
38 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 47
Station Mode
This sets the unit to act as a WiFi station to connect to an AP with
admin@(none) 17:28:10% set interfaces interface
somessid
admin@(none) 17:28:23% show interfaces interface
enabled true;
wifi-config {
mode station;
tx-power 15;
station-config {
ap somessid {
enabled true;
privacy-mode wpa2-personal;
psk-config {
encryption ccmp;
key-mgmt wpa-psk;
psk somepasshrase;
}
}
}
}
physical-interface Wi-Fi;
[ok][2013-09-25 09:37:31]
admin@(none) 17:28:35% commit
Commit complete.
[ok][2013-09-24 17:28:39]
enabled true privacy-mode wpa2-p ersonal psk-config psk
Wi-Fi
wifi-config mode station station-config ap
Wi-Fi
| details
somessid and WPA2 Personal security.
somepassphrase
encryption ccmp
Monitoring
Ensure the CLI is in Operational mode.
Access Point Mode
The following shows status and statistics of the WiFi interface with two stations connected.
admin@(none) 09:45:40> show interfaces interface Wi-Fi wifi-status
wifi-status serial-number N7 22M33NU000628
wifi-status mode "Access Point"
wifi-status tx-power 15
wifi-status channel 4
wifi-status ap-status ap somes sid
[ok][2013-09-25 09:46:29]
admin@(none) 09:48:59> show interfaces interface Wi-Fi statistics
statistics discontinuity-time 2013-09-24T13:12:25-04:00
statistics in-octets 3747
statistics in-unicast-pkts 26
statistics in-multicast-pkts 0
statistics in-discards 0
statistics in-errors 0
statistics out-octets 55511
statistics out-unicast-pkts 215
statistics out-discards 0
statistics out-errors 0
[ok][2013-09-25 09:49:10]
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 39
Page 48
Station Mode
The following shows status when connected to a configured AP.
admin@(admin) 10:04:42> show interfaces interface Wi-Fi wifi-status
wifi-status serial-number N7 22M33NU000628
wifi-status mode Station
wifi-status tx-power 15
wifi-status channel 4
wifi-status station-status ssid somessid
wifi-status station-status bssid 00:19:70:2c:40:3f
wifi-status station-status rssi -58
wifi-status station-status authenticated true
wifi-status station-status authorized true
wifi-status station-status inactive 29270
wifi-status station-status rxbytes 27119
wifi-status station-status rxpackets 564
wifi-status station-status txbitrate 54
wifi-status station-status txbytes 897
wifi-status station-status txpackets 9
wifi-status station-status txfailed 0
wifi-status station-status txretries 0
[ok][2013-09-25 10:05:00]
admin@(admin) 10:05:53> show interfaces interface Wi-Fi statistics
statistics discontinuity-time 2013-09-24T13:12:25-04:00
statistics in-octets 288
statistics in-unicast-pkts 2
statistics in-multicast-pkts 0
statistics in-discards 0
statistics in-errors 0
statistics out-octets 752
statistics out-unicast-pkts 7
statistics out-discards 0
statistics out-errors 0
[ok][2013-09-25 10:06:42]
40 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 49
Bridging
Understanding
The unit supports transparent bridging of LAN and WiFi networks. The bridge forwards traffic between
LAN and WiFi networks at the layer-2 of OSI model. This allows LAN and WiFi clients to be in the same
IP sub-network.
The bridge learns the clients’ locations by analyzing the source address of incoming frames from all
attached networks (LAN and WiFi network). For example, if a bridge sees a frame arrive on LAN port from
Host A, the bridge concludes that Host A can be reached through the segment connected to LAN port.
Through this process, the bridge builds a forwarding table (the learning process). When a frame is received
on one of the bridge's interfaces, the bridge looks up the frame's destination address in its forwarding table.
If the table contains an association between the destination address and any of the bridge's ports aside from
the one on which the frame was received, the frame is forwarded out the indicated port. If no association is
found, the frame is flooded to all ports except the inbound port. Broadcasts and multicast also are flooded
in this way.
Typically, for LAN/WiFi-to-Cellular Router use case (a.k.a LAN/WiFi HotSpot), the LAN and WiFi interface (acting as an Access Point) are bridged. However, for security and bandwidth considerations, a user
might want to remove LAN and WiFi networks from the bridge (i.e., configuring LAN and WiFi networks
as separate IP networks). In this network setup, broadcast/multicasts data packets coming into WiFi are not
directed out the LAN connection and vice versa.
The bridged network is addressable via bridge interface (a virtual interface). The interfaces that are in the
bridge are called bridged interfaces. The interfaces that are not in the bridge are called routed interfaces.
Bridging is performed between bridged interfaces. Routing is performed between routed interfaces. The
bridge interface is a routed interface.
NOTE: The Cellular modem by its nature can never be added to the bridge and is, therefore, a routed inter-
face. Advanced details of networking concepts such as routing and bridging are outside the scope
of this manual but are available through various training materials freely available on the Internet.
Theory of Operation
Refer to Figure 16 for this discussion. In a typical application, the MCR-4G provides cellular connectivity
to locally connected devices that are located on the user’s local/internal/private LAN or WiFi network. The
MCR-4G acts as an Access Point on the Wi-Fi interface, providing connectivity to Wi-Fi clients. The Wi-Fi
traffic is combined with the local Ethernet port traffic through a Layer 2 bridge. The serial interface is
matched to a terminal server that encapsulates serial data over a TCP or UDP connection.
The MCR-4G provides Network Address Translation (NAT) (both Masquerading and Port Forwarding) as
well as Firewalling between the cellular data interface (WAN side) and the local network (LAN/WiFi). The
MCR-4G can also act as a VPN client to provide a secure tunnel for LAN data to the user’s local network
(LAN/WiFi). This configuration obviates the need for NAT, as the back-office network behind the VPN
Concentrator (VPNC) can address the local LAN or WiFi network directly via the secure tunnel.
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 41
Page 50
Figure 16. Bridging Functions Diagram
Configuring
Creating a bridge interface and assigning it an IP address:
admin@(none) 00:02:09% set interfaces interface myBridge virtual-type bridge
admin@(none) 00:02:20% set interfaces interface myBridge bridge-settings ageing-time 500
admin@(none) 00:22:26% set interfaces interface myBridge ipv4 addres s 192.168.1.10 prefix-length 24
Invisible place holder
Adding LAN (ETH1) interface to the bridge:
admin@(none) 00:06:20% set interfaces interface myBridge bridge-settings members port ETH1
Adding WiFi interface to the bridge (Access Point):
admin@(none) 00:06:20% set interfaces interface myBridge bridge-settings members wifi-ap myssid
OR:
Adding WiFi interface to the bridge (Station):
admin@(none) 00:23:00% set interfaces interface myBridge bridge-settings members wifi-station
interface Wi-Fi
Removing LAN (ETH1) interface from the bridge:
admin@(none) 00:06:36% delete interfaces interface myBridge bridge-settings members port ETH1
Removing WiFi interface from the bridge:
admin@(none) 00:06:20% delete interfaces interface myBridge bridge-settings members wifi-ap
somessid
OR:
admin@(none) 00:06:20% delete interfaces interface myBridge bridge-settings members wifi-station
interface Wi-Fi
Removing the bridge interface:
admin@(none) 00:23:00% delete interfaces interface myBridge
42 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 51
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the state and statistics of a bridge.
In this example, bridge (Bridge) is bridging the LAN (ETH1).
admin@(none) 10:14:19> show interfaces interface Bridge
interfaces interface Bridge oper-status up
if-index 1
phys-address 00:06:3d:06:ea:99
lower-layer-if [ ETH1 ]
statistics discontinuity-time 2013-09-24T13:12:24-04:00
statistics in-octets 10528064 7
statistics in-unicast-pkts 48 6200
statistics in-multicast-pkt s 0
statistics in-discards 0
statistics in-errors 0
statistics out-octets 899432
statistics out-unicast-pkts 8728
statistics out-discards 0
statistics out-errors 0
system-device br0
PREFIX
IP LENGTH
----------------------
192.168.1.102 23
IP PHYS ADDRESS STATE
----------------------------------------------------------------
192.168.1.100 04:fe:7f:e3:7b:c2 reachable
192.168.1.171 68:05:ca:05:de:2a stale
192.168.1.104 00:06:3d:06:bd:12 stale
192.168.1.98 80:c1:6e:f0:3b:7a reachable
192.168.1.172 00:1e:67:18:b3:34 stale
FF02::1:FFC4:D0A1 33:33:ff:c4:d0:a1 noarp
FF02::1 33:33:00:00:00:01 noarp
FF02::1:FF00:1 33:33:ff:00:00:01 noarp
bridgeStatus stp port ETH1
number 1
priority 0
state forwarding
path-cost 100
designated-root 7035.04fe7fe36 980
designated-cost 100
designated-bridge 8000.0002f d5dd280
designated-port 32789
bridgeStatus stp port somessid
number 2
priority 0
state listening
path-cost 100
designated-root 7035.04fe7fe36 980
designated-cost 200
designated-bridge 8000.00063 d06ea99
designated-port 32770
[ok][2013-09-25 10:14:30]
admin@(none) 10:14:30>
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 43
Page 52
Routing
Understanding
The unit can be configured to route IP packets between routed interfaces.
Configuring a default static route:
admin@(none) 00:50:52% set routing static-routes ipv4 route 1 dest-prefix 0.0.0.0/0 next-hop
192.168.1.10
Configuring a static host route:
% set routing static-routes ipv4 route 2 dest-prefix 10.2.3.1/32 next -h op 192.168.1.9
admin@(none) 00:04:57% show routing static-routes
ipv4 {
route 1 {
dest-prefix 0.0.0.0/0;
next-hop 192.168.1.10;
route 2 {
dest-prefix 10.2.3.1/32;
next-hop 192.168.1.9;
[ok][2012-06-19 00:05:01]
[edit]
admin@(none) 00:05:01% commit
Commit complete.
[ok][2012-06-19 00:05:09]
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the state of the routing table:
admin@(none) 09:04:19> show routing
OUTGOING
DEST PREFIX NEXT HOP INTERFACE SOURCE
----------------------------------------------------
10.10.10.0/23 - ETH1 kernel
172.168.1.0/24 - ETH2 kernel
192.110.11.0/24 - Wi-Fi kernel
192.168.0.0/24 - Bridge kernel
216.171.112.36/32 10.10.10.101 ETH1 static
fe80::/64 - kernel
fe80::/64 - Bridge kernel
fe80::/64 - ETH1 kernel
fe80::/64 - Wi-Fi kernel
[ok][2013-09-13 09:04:28]
44 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 53
Firewall and NAT
Understanding
The MCR incorporates a firewall service that provides the following functionality:
1. Packet filtering to permit or deny incoming or outgoing traffic on an interface.
2. Network Address Translation (NAT)
• Source NAT - Masquerading
• Destination NAT – Port Forwarding
Packet Flow
This section provides a simplified view of packet flow for various categories of traffic flows going in and
out of the MCR unit. Figure 17 shows the flow of packets terminating at MCR. For example, device management traffic using SSH or NETCONF protocol terminating at local device management process within
the MCR unit.
Invisible place holder
Figure 17. Packets Terminating at MCR
Figure 18 shows flow of packets originating from the MCR unit. For example, DNS queries and/or VPN
connection setup traffic originating from local VPN service within the MCR unit.
Invisible place holder
Figure 18. Packets Originating from MCR
Figure 19 shows the flow of packets being forwarded (routed ) through the MCR unit. For example, IP
packets arriving inside IPsec VPN tunnel, being routed from cellular WAN to the local Ethernet interface.
Invisible place holder
Figure 19. Packets Being Forwarded Through MCR
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 45
Page 54
Figure 20 shows the flow of packets being port-forwarded (DNAT’ed) through the MCR unit. For example,
TCP traffic arriving at the cellular interface and getting port forwarded to a private host connected to the
local Ethernet interface.
Invisible place holder
Figure 20. Packets Being Port-Forwarded Through MCR
Figure 21 shows the flow of packets being masqueraded (source NATed) through the MCR unit. For
example, TCP traffic from a private host arriving at Local Ethernet interface, being masqueraded to the cellular interface’s IP address before being sent out the cellular interface.
Invisible place holder
Figure 21. Packets Being Masqueraded Through MCR
46 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 55
Packet Filtering
Understanding
Packet filtering allows configuring and applying a packet filter (also called Access Control List, or ACL) to
incoming or outgoing traffic on an interface. A filter is a set of one or more rules. Each rule consists of two
parts:
• Matching criteria that a packet must satisfy for the rule to be applied. Matching criteria consists of
various parameters like protocol, source/destination addresses and ports etc
• Actions that specify what to do with the packet when the matching criteria is met, for example, to
drop or accept the packet.
The filter can then be applied to an interface in the incoming or outgoing direction. Note that typically, different filters are applied in the incoming and outgoing direction on an interface. For example, a filter applied
to the cellular (WAN) interface of the MCR is typically very restrictive, permitting only a small set of traffic
to enter the MCR, where as outgoing filter might permit all outgoing traffic etc.
NOTE: If the firewall service is enabled and no filter is applied to an interface, then both incoming and
outgoing traffic is dropped on that interface.
Configuring
Configuration Hierarchy
NOTE: The configuration parameters shown here are a subset of the available configuration parameters.
Refer to the appendix for a complete listing.
firewall {
enabled <true|false>;
filter <name> {
rule <id> {
match {
protocol <icmp|udp|tcp|esp|all>;
src-address {
address <network/prefix> or address-range;
}
src-port {
services [ <name1> <name2> …] or port-range;
}
dst-address {
address <network/prefix> or address-range;
}
dst-port {
services [ <name1> <name2> …] or port-range;
}
ipsec {
direction <in|out>;
tunnel-src-address <network/prefix>;
tunnel-dst-address <network/prefix>;
}
}
actions {
action <accept|drop|reject>;
reject-type <net-unreachable|…>;
log {
level <debug|info|…>;
prefix <string>;
interfaces {
interface <name> {
filter {
input <name>;
output <name>;
.....
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 47
Page 56
Packet filter configuration on MCR involves following these high level steps:
1. Create a filter, decide on default policy of the filter. For example, there are usually two ways to or ganize
a filter:
a. Create a “restrictive” filter i.e. the last rule in the filter (also called “default policy” of
filter) is to deny traffic and rules are added to specifically permit the traffic. For example,
i. Rule 1 = permit protocol=tcp, dst port=22
ii. Rule 2 = permit protocol=icmp
iii. Rule 3 = deny everything
b. Or Create a “permissive” filter i.e. the last rule in the filter (also called “default policy” of
filter) is to permit traffic and rules are added to specifically deny traffic. For example,
i. Rule 1 = deny protocol=tcp, dst port=80
ii. Rule 2 = deny protocol=icmp
iii. Rule 3 = permit everything
2. Apply the filter to input or output direction of the interface.
The following example describes the step-by-step configuration of an example filter that can be applied to
cellular interface of the MCR. Change to CLI configuration mode:
1. Enable firewall service
admin@(none) 19:33:20% set services firewall enabled true
2. Create a “restrictive” filter named “IN_UNTRUSTED” to indicate that this filter has been
designed to be applied to an untrusted cellular interface of MCR. The cellular interface can be
considered untrusted as it is connected to public cellular network, which is inherently an untrusted
network.
admin@(none) 19:33:20% set services firewall filter IN_UNTRUSTED
3. Create rule to permit encrypted IPsec tunnel traffic i.e. tra ffic with protocol=ESP
admin@(none) 19:33:20% set services firewall filter IN_UNTRUSTED rule 1 match protocol esp
admin@(none) 19:33:20% set services firewall filter IN_UNTRUSTED rule 1 actions action accept
4. Create rule to permit traffic for the following UDP services: DNS, NTP and IKE (to allow IPsec
connection setup).
admin@(none) 19:33:20% set services firewall filter IN_UNTRUSTED rule 2 match protocol udp
src-port services [ dns ike ntp ]
admin@(none) 19:33:20% set services firewall filter IN_UNTRUSTED rule 2 actions action accept
5. Create rule to permit traffic for following TCP services: SSH and NETCONF (to allow
management of MCR):
admin@(none) 19:33:20% set services firewall filter IN_UNTRUSTED rule 3 match protocol tcp
dst-port services [ netconf ssh ]
admin@(none) 19:33:20% set services firewall filter IN_UNTRUSTED rule 3 actions action accept
48 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 57
NOTE: The rule stated in step 5 permits SSH or NETCONF connection addressed to the cellular inter-
face’s IP address. If it is desired that SSH or NETCONF connection only be allowed via the VPN
tunnel, then ipsec match criteria described below should be used instead of the rule stated in step
5.
admin@(none) 19:33:20% set services firewall filter IN_UNTRUSTED rule 3 match ipsec direction in
tunnel-src-address 10.150.1.1/32 tunnel-dst-address 10.150.1.10/32
admin@(none) 19:33:20% set services firewall filter IN_UNTRUSTED rule 3 actions action accept
The above example assumes cell interface’s IP address is 10.150.1.10 and VPN Gateway’s IP address is
10.150.1.1.
6. Create the last rule for this “restrictive” filter to deny everything else. Note that rules are applied in
ascending order using rule IDs. Any rules added after this last rule will have no effect, as they
would match “any” traffic, and be dropped. In this example rule ID 10 is chosen. This facilitates
the insertion of new rules prior to this last one to support future new traffic types.
admin@(none) 19:33:20% set services firewall filter IN_UNTRUSTED rule 10 match protocol all
admin@(none) 19:33:20% set services firewall filter IN_UNTRUSTED rule 10 actions action drop
7. Apply this filter to incoming direction on cellular interface “Cell”.
admin@(none) 19:33:20% set interfaces interface Cell filter input IN_UNTRUSTED
8. Create a “permissive” filter that permits all traffic. Later on, if needed, this filter can be enhanced
to deny certain traffic from getting out of the cellular interface.
admin@(none) 19:33:20% set services firewall filter OUT_UNTRUSTED rule 10 match protocol all
admin@(none) 19:33:20% set services firewall filter OUT_UNTRUSTED rule 10 actions action accept
9. Apply this filter to ou tgoing direction on cellular interface “Cell”.
admin@(none) 19:33:20% set interfaces interface Cell filter output OUT_UNTRUSTED
10. Commit configuration and exit configuration mode.
admin@(none) 19:33:20% commit
Commit complete.
[ok][2013-09-24 19:33:20]
admin@(none) 19:33:21% exit
admin@(none) 19:33:21>
Monitoring
At this time there are no commands to monitor traffic statistics for packets being dropped or permitted by
the firewall. This feature may be added to future revisions of firmware.
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 49
Page 58
Network Address Translation (NAT)
Understanding
Network address translation allows one to map private IP addresses to public IP addresses and vice versa.
There are two basic kinds of network address translation:
• Source NAT
• Destination NAT
Source NAT
Source NAT performs translation of source IP address of the traffic egressing an interface. This is typically
used to provide many-to-one translation (also called masquerading) of a private network behind MCR to
allow hosts on that private network to access a host (say HOST-B) on the public network. (See Figure 22.)
All traffic originating from hosts in the private network will appear to have originated from a single IP
address (the IP address of the public interface of the MCR, typically, cellular interface) from HOST-B’s
point of view. To allow return IP traffic for UDP/TCP connections, to be delivered to right private host, the
MCR also performs source port translation. Therefore, masquerading consists of Network Address and Port
Translation (NAPT).
Invisible place holder
Figure 22. Source NAT Translation of IP Address
50 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 59
Configuring
Configuration Hierarchy
services {
firewall
nat {
source {
rule-set <name> {
rule <id> {
match {
src-address {
dst-address {
source-nat {
interface;
address <IP>;
}
}
}
}
}
}
interfaces {
interface <name> {
nat {
source <name>;
}
}
}
not <boolean>;
add-interface-address <tru e|false>;
address <network/prefix>;
address-range <to/from>;
address-set <name> {
add-interface-address <tru e|false>
not <boolean>
}
}
not <boolean>;
add-interface-address <tru e|false>;
address <network/prefix>;
address-range <to/from>;
address-set <name> {
add-interface-address <tru e|false>
not <boolean>
}
}
Source NAT configuration on MCR involves following high level steps:
1. Create a source NAT rule-set.
2. Add rule to perform source NAT on the public interface.
3. Apply the source NAT rule-set to the public interface.
Following example describes the step-by-step configuration of an example source NAT rule-set to perform
masquerading on cellular interface of MCR. Change to CLI configuration mode:
1. Enable firewall service, if it is not already enabled.
admin@(none) 19:33:20% set services firewall enabled true
2. Create source NAT rule-set named MASQ.
admin@(none) 19:33:20% set services firewall nat source rule-set MASQ
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 51
Page 60
3. Create rule for masquerading
admin@(none) 19:33:20% set services firewall nat source rule-set MASQ rule 1 source-nat interface
4. Apply this source NAT rule-set to the cellular interface.
admin@(none) 19:33:20% set interfaces Cell nat source MASQ
5. Commit configuration and exit configuration mode.
admin@(none) 19:33:20% commit
Commit complete.
[ok][2013-09-24 17:06:39]
admin@(none) 19:33:20% exit
admin@(none) 19:33:20>
Monitoring
At this time there are no commands to monitor traffic statistics for packets being masqueraded by the firewall. This feature may be added in future revisions of firmware.
Destination NAT
Destination NAT performs translation of destination IP address (and, optionally, destination port) of the
traffic ingressing an interface. This is typically used to allow a host on the public network (HOST-B) to
access a service running on a host in the private network (HOST-1). This is also called port forwarding.
Invisible place holder
Figure 23. Destination NAT Translation of IP Address
52 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 61
Configuring
Configuration Hierarchy
services {
firewall
nat {
destination {
rule-set <name> {
rule <id> {
match {
dst-address {
address <ip-address>;
port <unit16>;
}
}
}
}
}
}
interfaces {
interface <name> {
nat {
destination <name>;
}
}
}
src-address {
not <boolean>;
add-interface-address <tru e|false>;
address <network/prefix>;
address-range <to/from>;
address-set <name> {
add-interface-address <tru e|false>
not <boolean>
}
}
not <boolean>;
add-interface-address <tru e|false>;
address <network/prefix>;
address-range <to/from>;
address-set <name> {
add-interface-address <tru e|false>
not <boolean>
}
}
destination-nat {
Destination NAT configuration on MCR involves following high level steps:
1. Create a destination NAT rule-set.
2. Add one or more rules to perform destination NAT for specific incoming traffic on the public interface.
3. Apply the destination NAT rule-set to the public interface.
Following example describes the step-by-step configuration of an example destination NAT rule-set to perform port forwarding for incoming Modbus protocol (TCP port 512) traffic on the cellular interface to the
private HOST-1 (assume that modbus traffic is running on port 5512 on HOST-1). Change to CLI co nfiguration mode:
1. Enable firewall service, if it is not already enabled.
admin@(none) 19:33:20% set services firewall enabled true
2. Create source NAT rule-set named IO_SERVICES.
admin@(none) 19:33:20% set services firewall nat destination rule-set IO_SERVICES
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 53
Page 62
3. Create rule for port forwarding Modbus TCP traffic coming into cellular interface on port 512 to
port 5512 on private HOST-1.
admin@(none) 19:33:20% set services firewall nat destination rule-set IO_SERVICES rule 1 match protocol tcp dst-address address 10.150.1.1/32
Value for ‘services firewall nat destination rule-set IO_SERVICES rule 1 destination-nat-address’(<IP address>):
192.168.1.1
admin@(none) 19:33:20% set services firewall nat destination rule-set IO_SERVICES rule 1 match
dst-port 512
admin@(none) 19:33:20% set services firewall nat destination rule-set IO_SERVICES rule 1 destination-nat port 5512
4. Apply this destination NAT rule-set to the cellular interface.
admin@(none) 19:33:20% set interfaces Cell nat destination IO_SERVICES
5. Commit configuration and exit configuration mode.
admin@(none) 19:33:20% commit
Commit complete.
[ok][2013-09-24 19:33:20]
admin@(none) 19:33:21% exit
admin@(none) 19:33:21>
Monitoring
At this time there are no commands to monitor traffic statistics for packets being masqueraded by the
firewall. This feature may be added in future revisions of firmware.
54 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 63
VPN
Understanding
The MCR supports standards-based IPsec Virtual Private Network (VPN) technology to securely connect
remote private network (LAN or WiFi) with the customer’s backoffice/data center private network see
Figure 24). This allows IP traffic from/to devices connected to either LAN, WiFi or Serial port of the MCR
to securely flow to/from back-office applications via a secure tunnel through a public cellular network. The
tunneled application traffic is authenticated and encrypted to protect from eavesdropping, tampering and
replay attacks.
Invisible place holder
Figure 24. VPN Setup Example
Figure 24 shows an example network, where a remote Ethernet device is connected to MCR via Ethernet on
192.168.1.0/24 network. The MCR establishes a VPN connection with IPsec VPN gateway, thereby
securely connecting remote private network (192.168.1.0/24) with back-office private network
(192.168.2.0/24). This allows PC (192.168.2.2) to communicate with remote Ethernet device (192.168.1.2)
using any TCP/UDP/IP based protocol and vice versa.
IPsec, Internet Protocol Security, is a set of protocols defined by the IETF, Internet Engineering Task Force,
to provide IP security at the network layer.
An IPsec based VPN is made up by two parts:
• Internet Key Exchange protocol (IKE)
• IPsec protocols (ESP, AH)
The first part, IKE, is the initial negotiation phase, where the MCR and VPN gateway agree on which
methods will be used to provide security for the underlying IP traffic. There are two IKE protocol versions:
IKE-v1 and IKE-v2. These are not compatible with each other. The IKE-v2 is more efficient and therefore
should be preferred for new deployments. The MCR supports IKE-v1 and IKE-v2.
The other part is the actual IP data being transferred, using the encryption and authentication methods
agreed upon in the IKE negotiation. This is accomplished by using IPsec protocols like Encapsulating Security Payload (ESP) or Authentication Header (AH). The MCR only supports ESP protocol as it provides
both encryption and authentication of the data. The AH protocol provides only data authentication.
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 55
Page 64
The process of IPsec VPN connection establishment consists of following phases:
• IKE Phase-1 (IKE security negotiation)
- Negotiate how IKE should be protected
• IKE Phase-2 (IPsec Security Association)
- Negotiate how IPsec should be protected
- Derive fresh keying material from the key exchange in phase-1, to provide session keys to be used
in the encryption
- and authentication of the VPN data flow
• Exchange data over the IPsec tunnel
Both the IKE and the IPsec connections have limited lifetimes. These lifetimes prevent a connection from
being used too long, which is desirable from a cryptanalysis perspective.
The IPsec lifetime is generally shorter than the IKE lifetime. This allows for the IPsec connection to be
re-keyed simply by performing another phase-2 negotiation.
Configuration
VPN Configuration Hierarchy
NOTE: The configuration parameters shown here are a subset of all available configuration parameters.
Refer to the appendix section for all available parameters.
services {
vpn {
enabled <true|false>;
ike {
policy <name> {
auth-method <eap-tls|eap-t tls|pre-shared-key|pub-key> ;
pki {
cert-type <rsa|ecdsa>;
cert-id <certificate-id>;
key-id <private-key-id>;
ca-cert-id <ca-certificate-id>;
}
ciphersuite <name> {
encryption-algo <aes-256-c bc|….>;
mac-algo <sha256-hmac|….>;
dh-group <dh-14|….>;
}
}
peer <name> {
ike-policy <reference-to-ike-policy>;
peer-identity {
address <ip-address>;
default <ip-address>;
dn <name>;
fqdn <string>;
user-fqdn <string>;
}
peer-endpoint {address|any |fqdn};
peer-identity-no-idr <true|false>;
local-identity {address|default|dn|fqdn|user-fqdn};
local-endpoitn {address|any|sqdn};
role <initiator|responder>;
dpd-interval <interval (secs)>
dpd-enabled <true|false>;
}
}
ipsec {
policy <name> {
life-time <sec>;
ciphersuite <name> {
encryption-algo <aes-256-c bc|…>;
mac-algo <sha256-hmac|…>;
dh-group <dh-14|…>;
}
}
56 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 65
connection <name> {
ike-peer <reference-to-ike-peer>;
ipsec-policy <reference-to-ipsec-policy>;
local-ip-subnet <ip address/len>;
remote-ip-subnet <ip address/len>;
failure-retry-interval 1;
is-out-of-band-ima <true|false>
local-source-ip-address <ip address>;
periodic-retry-interval <mins>;
}
}
}
}
Firewall Filters for the Cellular Interface
When setting up IPsec VPN over a Cellular interface, the following firewall filters are recommended to be
configured and applied to the cellular interface. The
IN_UNTRUSTED and OUT_UNTRUSTED filters should
be applied to incoming and outgoing traffic respectively.
filter IN_UNTRUSTED {
rule 1 {
match {
protocol udp;
src-port {
services [ dns ike ntp ];
}
}
actions {
}
}
rule 2 {
}
rule 3 {
}
rule 4 {
action accept;
}
rule 10 {
}
}
filter OUT_UNTRUSTED {
rule 1 {
}
action accept;
match {
protocol esp;
}
actions {
action accept;
}
match {
protocol icmp;
}
actions {
action accept;
}
match {
ipsec {
direction in;
tunnel-src-address <VPN SERVER IP ADDRESS>/32;
tunnel-dst-address <CELL INTE RFACE IP ADDRESS>/32;
}
}
actions {
}
match {
protocol all;
}
actions {
action drop;
}
match {
src-address {
address <CELL INTERFACE IP ADDRES S>/32;
}
}
actions {
action accept;
}
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 57
Page 66
rule 2 {
match {
ipsec {
direction out ;
tunnel-src-address <CELL INTE RFACE IP ADDRESS>/32;
tunnel-dst-address <VPN SERVER IP ADDRESS>/32;
}
}
actions {
action accept;
}
}
rule 10 {
match {
protocol all;
}
actions {
action drop;
}
}
}
VPN configuration involves the following high level steps:
1. Configure an IKE policy specifying an authentication method, cipher suites to be included in the
proposal during IKE phase-1 and the credentials to be used for authentication e.g. certificates or
preshared-keys.
2. Configure an IKE peer specifying peer endpoint address, IKE policy to used for IKE phase-1 negotiation. The “role” specifies whether MCR initiates connection (initiator) or it waits for the connection
from the peer (responder). This should usually be set to “initiator”.
3. Configure an IPsec policy specifying ESP cipher suites to be included in the proposal during IKE
phase-2.
4. Configure an IPsec connection specifying IKE peer, IPsec policy, local and remote private IP subnets.
NOTE: The above configuration parameters should match with the corresponding parameters set in the
peer. Otherwise, the IPsec VPN connection will not succeed. Typical configuration mistakes
include incorrect security credentials (psk or certificates/keys), mismatched cipher suite configuration, and mismatched local and remote subnet configuration.
The following example describes the step-by-step VPN configuration for the example network shown in
figure above. We’ll assume that certificates are being used as security credentials and have already been
loaded in the MCR either manually or via SCEP.
1. Ensure that cellular interface has been configured.
2. Ensure that device has been configured with certificates/keys.
3. Ensure that device has been configured to obtain time via NTP.
NOTE: The VPN connection will fail unless the time is synchronized on the device because certificate
validation will fail.
58 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 67
4. Enable VPN service
admin@(none) 20:38:44% set services vpn enabled true
5. Create IKE policy with auth-method “public-key encryption”.
admin@(none) 19:33:29% set services vpn ike policy IKE-POLICY-1 auth-method pub-key
6. Configure Public Key Infrastructure (PKI) security credentials
a. Certificate type as “rsa” if RSA public key encryption based certificates are being used.
b. Client certificate ID – This is the ID that was assigned to the client certificate obtained via
SCEP or loaded manually.
c. Client private key ID – This is the ID that was assigned to the client private key generated
during SCEP procedure or loaded manually.
d. Certificate Authority (CA) certificate ID – This is the ID that was assigned to the CA
certificate obtained via SCEP or loaded manually.
admin@(none) 19:33:29% set services vpn ike policy IKE-POLICY-1 pki cert-type rsa
admin@(none) 19:33:29% set services vpn ike policy IKE-POLICY-1 pki cert-id ID-1
admin@(none) 19:33:29% set services vpn ike policy IKE-POLICY-1 pki key-id ID-1
admin@(none) 19:33:29% set services vpn ike policy IKE-POLICY-1 pki ca-cert-id GEPKI
1. Configure the following ciphersuite to be included as proposal for IKE phase-1 negotiation:
a. Encryption Algorithm = AES 256 Bit in CBC mode
b. Message Authentication Algorithm = HMAC using SHA256 digest
c. Diffie-Hellman Group = DH-14 (group 14 modp2048)
admin@(none) 19:33:29% set services vpn ike policy IKE-POLICY-1 ciphersuite
AES256_CBC-SHA256-DH14 encryption-algo aes-256-cbc
admin@(none) 19:33:29% set services vpn ike policy IKE-POLICY-1 ciphersuite
AES256_CBC-SHA256-DH14 mac-algo sha256-hmac
admin@(none) 19:33:29% set services vpn ike policy IKE-POLICY-1 ciphersuite
AES256_CBC-SHA256-DH14 dh-group dh-14
NOTE: More than one ciphersuite can be included in the proposal.
1. Create IKE peer with address 10.150.1.1 and dead peer detection enabled and interval set to 5 mins.
The dead peer detection (DPD) is enabled by default. When enabled, it sends
messages to the peer if there no other data sent within DPD interval. This allows MCR to detect dead VPN
peers and clear a VPN connection. The DPD interval should be set to no less than 300 seconds (5 minutes)
to reduce the periodic traffic in the network.
The peer-identity-no-idr parameter, when set to true, prevents the unit from sending the responder’s ID (IDr)
IKE_AUTH request which might prevent the peer from finding matching a configuration.
in its
admin@(none) 19:33:29% set services vpn ike peer VPN-GW role initiator
admin@(none) 19:33:29% set services vpn ike peer VPN-GW ike-policy IKE-POLICY-1
admin@(none) 19:33:29% set services vpn ike peer VPN-GW peer-endpoint address 10.150.1.1
admin@(none) 19:33:29% set services vpn ike peer VPN-GW peer-identity-no-idr true
admin@(none) 19:33:29% set services vpn ike peer VPN-GW dpd-interval 300
R_U_THERE/INFORMATIONAL
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 59
Page 68
2. Create an IPsec policy and configure the following ciphersuite to be included as proposal for IKE
phase-2 negotiation:
• Encryption Algorithm = AES 256 Bit in CBC mode
• Message Authentication Algorithm = HMAC using SHA256 digest
• Diffie-Hellman Group = DH-14 (group 14 modp2048)
admin@(none) 19:33:29% set services vpn ipsec policy IPSEC-POLICY-1 ciphersuite
AES256_CBC-SHA256-DH14 encryption-algo aes-256-cbc
admin@(none) 19:33:29% set services vpn ipsec policy IPSEC-POLICY-1 ciphersuite
AES256_CBC-SHA256-DH14 mac-algo sha256-hmac
admin@(none) 19:33:29% set services vpn ipsec policy IPSEC-POLICY-1 ciphersuite
AES256_CBC-SHA256-DH14 dh-group dh-14
NOTE: More than one ciphersuite can be included in the proposal.
3. Create IPsec connection
admin@(none) 19:33:29% set services vpn ipsec connection VPN-GWY-CONN-1 ike-peer VPN-GWY
admin@(none) 19:33:29% set services vpn ipsec connection VPN-GWY-CONN-1 ipsec-policy
IPSEC-POLICY-1
admin@(none) 19:33:29% set services vpn ipsec connection VPN-GWY-CONN-1 local-ip-subnet
192.168.1.0/24
admin@(none) 19:33:29% set services vpn ipsec connection VPN-GWY-CONN-1 remote-ip-subnet
192.168.2.0/24
admin@(none) 19:33:29% set services vpn ipsec connection VPN-GWY-CONN-1 failure-retry-interval 1
The following table describes the VPN connection attempt retries and time interval between them. After
giving up as listed below, the unit waits for “failure-retry-interval” and repeats the connection attempt
sequence.
Relative Timeout
Attempt#
100
st
2 (1
retry)
nd
3 (2
retry)
rd
4 (3
retry)
5 (4th retry)
th
6 (5
retry)
Give up 76 165
Wait for “failure-retry-interval”, then repeat above sequence
Between Attempts (secs)
44
711
13 24
23 47
42 89
Absolute Timeout
From First Attempt (secs)
During initial configuration set failure-retry-interval to lowest value of 1 min, to have MCR attempt connection more quickly. This allows debugging of any connection-related issue by watching logs on peer side
etc. Be sure to change this value to 5 mins or higher to prevent excessive attempts and traffic.
Commit configuration and exit configuration mode.
admin@(none) 20:38:44% commit
Commit complete.
admin@(none) 20:38:44% exit
[ok][2013-01-18 20:40:45]
admin@(none) 20:38:44>
60 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 69
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the VPN connection state (connecting, connected or disconnected). The failure-reason displays the reason for last connection failure.
admin@(none) 20:40:45> show services vpn
services vpn ipsec ipsec-status connection
state connecting
failure-reason none
last-timestamp 2013-01-18T20:24:15+00:00
ima-evaluation none
ima-recommendation none
admin@(none) 20:40:45> show services vpn
services vpn ipsec ipsec-status connection
state connected
failure-reason none
last-timestamp 2013-01-18T20:24:15+00:00
ima-evaluation none
ima-recommendation none
VPN-GWY-CONN-1
VPN-GWY-CONN-1
With a connection made, ping the back-office PC to make sure the traffic is passing between device and PC.
admin@(none) 20:41:32> ping 192.168.2.1
PING 192.168.1.2 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_req=1 ttl=63 time=389 ms
64 bytes from 192.168.2.1: icmp_req=2 ttl=63 time=161 ms
[ok][2013-01-18 20:49:42]
VPN Troubleshooting
The following are common reasons for VPN connection failure:
1. Invalid certificate or keys loaded on the device
2. Time not synchronized on the device. Note that after cell connection is established, device can take few
minutes to sync time from NTP server. VPN connection will not succeed until time is synchronized.
3. Mismatch in ciphersuites configured for IKE policy on device and peer VPN gateway.
4. Mismatch in ciphersuites configured for IPsec policy on device and peer VPN gateway.
5. Mismatch in remote and local IP subnets configured for IPsec connection on device and peer VPN
gateway. Note the following:
a. For device
i. remote ip subnet = back-office subnet
ii. local ip subnet = local LAN or WIFI subnet on device
b. For VPN gateway
i. remote ip subnet = device’s local LAN or WIFI subnet
ii. loca l ip subnet = back-office subnet on device
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 61
Page 70
DNS
Understanding
Domain Name System (DNS) servers can be configured on the unit to facilitate the resolution of domain
names to IP addresses.
NOTE: Manual configuration of DNS overrides any DNS settings obtained via DHCP.
Configuring
The following example shows how to configure a DNS server with IP address 192.168.1.2 on the MCR.
Note that the “search” option can take a list of arguments and in this example, there are two arguments;
and
gemds.
admin@(none) 00:31:02% set system dns server 192.168.1.2 search [ mds gemds ] options attempts 3
timeout 3
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the state and statistics.
The ping utility can be used on the CLI when it is in operational mode to verify that DNS is working prop-
erly. If ping can resolve a name on the connected network to an IP address then DNS settings are working
properly. The example below shows the resolution of the name “example.com” to the IP address
“192.0.43.10” on a unit that is connected to the Internet.
mds
Use the control sequence “CTRL-C” to stop the ping utility.
admin@(none) 00:20:33> ping example.com
PING example.com (192.0.43.10) 56(84) bytes of data.
64 bytes from 43-10.any.icann.org (192.0.43.10): icmp_req=1 ttl=237 time=30.8 ms
64 bytes from 43-10.any.icann.org (192.0.43.10): icmp_req=2 ttl=237 time=44.7 m
[ok][2012-06-19 00:24:08]
admin@(none) 00:24:08>
62 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 71
DHCP Service
Understanding
The unit can be configured to act as a DHCP server. When enabled, this service will respond to DHCP
requests from any interface.
Configuring
The following shows an example of configuring DHCP service on the unit. The unit will administer IPv4
addresses from the 192.168.x.x network when requests are received from DHCP clients.
NOTE: At least one of the unit’s interfaces (ETH1, ETH2, WiFi or Bridge if the interface is bridged) must
be configured with an IP address from this subnet.
admin@(none) 04:18:26% set services dhcp v4subnet 192.168.0.0/16 domain-name gemds range-start
192.168.1.100 range-end 192.168.1.150 rout er 192.168.1.1 broadcast-address 192.168.255.255
ntp-servers [ time.mds ]
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the DHCP leases.
admin@(none) 04:18:26> show services dhcp
services dhcp leases 192.168.1.100
starts 2013-01-22T12:55:13+00:00
ends 2013-01-23T00:55:13+00:00
binding-state free
client-mac 70:f1:a1:fc:1d:da
hostname ""
[ok][2013-01-23 04:18:27]
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 63
Page 72
Terminal Service
Understanding
The unit allows the setup of the COM ports as a terminal server that passes data to/from the serial port to
network interfaces. The serial port must be configured to do this, in addition to the baud rate and data format.
The data from the serial port is treated as a seamless stream; meaning it is not protocol aware and will send
data from the serial port to the remote endpoint as soon as the data is received. A terminal-server can consist
of a TCP server, a TCP client, or a UDP endpoint, and a MODBUS-TCP server.
When a terminal server on the unit is configured as TCP server, then the unit listens on a TCP port for client
connections. When a terminal server on the unit is configured as TCP client, then the unit will attempt to
connect to the remote IP address. Once a TCP connection is established, then serial traffic from the COM
port can pass to and from the TCP port as long as the TCP connection remains established.
When a terminal server on the unit is configured as a UDP endpoint, then traffic from the COM port is sent
to the remote host at the specified port in UDP packets. Likewise, traffic sent to the UDP port of the unit is
forwarded out the COM port. Since UDP is stateless, some packets may not reach their intended destination
or may arrive out of order. The protocol contained in the UDP messages must handle these scenarios.
When a terminal server on the unit is configured as a MODBUS/TCP server, then the unit listens on a TCP
port for a client connection. Once a TCP connection is established, the unit will convert the incoming
MODBUS/TCP frame into either a MODBUS/RTU or MODBUS/ASCII frame for transmitting on the
serial port. Serial data received is converted from either MODBUS/RTU or MODBUS/ASCII to
MODBUS/TCP for transmission back to the MODBUS/TCP client.
NOTE: Once a terminal-server is enabled on a COM port, the port stays in data mode and the CLI will
not be available on that port. To break out of data mode, the escape sequence
on the PC’s keyboard. The baud rate and format must match on the PC and on the unit for the
escape sequence to be detected. Once the sequence is detected, the login prompt is presented as
long as the port is enabled for console access.
Configuring
The following shows how to enable a UDP terminal server on COM1
admin@(none) 01:34:45% set services serial terminal-server server COM1 mode udp port 10000
remote address 192.168.1.12 port 10000
[ok][2012-06-19 01:35:36]
[edit]
admin@(none) 01:35:36% commit
The following shows how to enable a TCP terminal server on COM1
admin@(none) 01:22:09% set services serial terminal-server server COM1 mode tcp-server port
30011 idle-timeout 30
[ok][2012-06-19 01:22:36]
[edit]
admin@(none) 01:22:36% commit
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the state and statistics:
admin@(none) 22:03:06> show services serial
SERIAL SERIAL SERIAL SERIAL
SERIAL IP TX IP TX IP RX IP RX TX TX RX RX
PORT PACKETS BYTES PACKETS BYTES PACKETS BYTE S PACKETS BYTES
-------------------------------------------------------------------------COM2 0 0 0 0 0 0 0 0
+++ can be entered
[ok][2013-01-24 22:03:13]
64 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 73
Iperf Service
Understanding
Iperf service allows one to receive TCP traffic from remote host running iperf. Currently, iperf service is
hardcoded to act only as a TCP server listening on port 5001.
Configuring
The following shows how to enable iperf service:
admin@(none) 22:04:32% set services iperf enabled true
admin@(none) 22:04:32% commit
Commit complete.
[ok][2013-09-24 22:04:33]
NOTE: If firewall is enabled, then it must be configured to permit incoming TCP traffic on port 5001.
Monitoring
Ensure the CLI is in operational mode. Follow the example to view the state of iperf service:
admin@(none) 22:07:37> show services
NAME STATUS
-------------------------DHCP Server running
Firewall running
IPerf Server running
Serial running
SNMP Server running
SSH Server disabled
VPN running
Web Server running
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 65
Page 74
Date, Time and NTP
Understanding
The date and time can be set on the MCR using a manual ly configured value or automatically via Network
Time Protocol (NTP). The NTP settings take precedence over the manual settings. If NTP is enabled, then
the user will not be able to set the date and time manually.
Configuring
To manually set the date and time, use the request set-current-datetime:
admin@(none) 18:18:58> request system clock set set-current-datetime current-datetime
2013-10-01T8:33:45
To use an NTP server, an NTP server must be configured on MCR:
admin@(none) 00:20:33% set system ntp use-ntp true ntp-server
admin@(none) 00:20:33% commit
Commit complete.
[ok][2012-06-19 00:20:36]
time.nist.gov
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the state and statistics:
admin@(none) 00:20:34> show system clock
system clock current-datetime 2012-06-19T00:20:34+00:00
system clock boot-datetime 2012-06-19T00:18:01+00:00
[ok][2012-06-19 00:20:34]
66 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 75
Geographical-location
The geographical-location of the unit can be configured as shown below:
admin@(none) 00:50:46% set system geographical-location altitude 1.0 latitude 43.117807
longitude -77.611896
[ok][2012-06-19 00:56:00]
[edit]
admin@(none) 00:56:00% commit
Commit complete.
[ok][2012-06-19 00:56:05]
[edit]
admin@(none)
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 67
Page 76
User Management and Access Controls
Understanding
There are three user accounts/roles (administrator, technician, and operator) for management access.
Users in the admin group have the highest privilege and can read everything in the tree that is readable, write
everything that is writable, and can execute any of the requests.
Users in the tech group have less access than admin. Generally, the tech group cannot configure any secu-
rity-related configuration.
Users in the oper group can only view status and configuration. They do not have access to modify the
device configuration.
By default, the password for each account is the same as the username. The passwords should be changed
by users prior to deploying the device. When local user management is being used, passwords are stored in
non-volatile memory using PKCS#5 based encryption.
The user authentication can be done using locally stored passwords or via RADIUS.
Configuring
The password for each user account can be changed using a request:
admin@(none) 01:04:19> request system authentication change-password user admin password
new_password
NOTE: If the admin password is forgotten, the only way to reset the login password is by using the login
One-Time-Password. This will reset the user passwords AND reset the entire unit’s configuration
to defaults. Refer to section 3.1.4 One-Time “Recovery” Passwords on Page 16.
User authentication order can be specified to give preference to which method is used first when authenticating user access. In the following example, the list of RADIUS servers will be contacted first before the
local authentication rules are used.
NOTE: If the local-users option is specified before RADIUS, then only the local-users option will be
utilized; the RADIUS servers will never be contacted.
admin@(none) 01:05:07% set system authentication user-authentication-order [ radius local-users ]
admin@(none) 01:05:07% commit
Commit complete.
[ok][2013-09-24 01:05:10]
68 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 77
Monitoring
Ensure the CLI is in operational mode. Follow the example below to see the history of login attempts by
reviewing the event log:
admin@(none) 01:21:48> show logging event-log event-type console_login
logging event-log 62625
time-stamp 2011-12-21T01:18:08.985996+00:00
priority notice
event-type console_login
status success
message “user_name oper, “
logging event-log 62627
time-stamp 2011-12-21T01:23:00.288046+00:00
priority notice
event-type console_login
status failure
message “msg noauth, user_name admin, “
[ok][2011-12-21 01:23:03]
admin@(none) 01:23:03>
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 69
Page 78
Login-Lockout
Understanding
The unit has protections against repeated login attempts. The max-login-attempts configuration determines
the number of failed logins that can occur in succession before the unit disables the ability to login for a
specified amount of time. The amount of time is determined by failed-login-lockout-time, which represents
the time in seconds.
Configuring
admin@(none) 01:51:26% set system max-login-attempts
[ok][2012-06-19 01:56:38]
[edit]
admin@(none) 01:56:38% set system failed-login-lockout-time
[ok][2012-06-19 01:56:56]
[edit]
admin@(none) 01:56:56% commit
Commit complete.
[ok][2012-06-19 01:56:58]
30
300
70 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 79
RADIUS
Understanding
User accounts can be centrally managed with a RADIUS server. RADIUS accounts can be mapped to one
of the three user roles.
If the RADIUS server is not accessible, users may use the local username/password to “fall back” to local
authentication if the unit is configured to do so. Many RADIUS servers do not respond to a failed login
attempt. To the unit, this appears the same as if the server is not there. The consequence of this behavior is
that after three failed login attempts, the authentication will take place against the local user/password database if local fallback is enabled. Refer to the section on “Local User Management” for configuring the
authentication order.
If more than one RADIUS server is configured, then the unit will attempt each RADIUS server in the order
that they appear in the configuration until a successful response is received. A RADIUS server must be configured to provide the user’s authentication group in its authentication reply via a GE MDS vendor attribute.
This can be configured in freeradius (an open source RADIUS server) by using the following dictionary file:
VENDOR GEMDS 4130
BEGIN-VENDOR GEMDS
ATTRIBUTE GEMDS-UserAuth-Group 1 integer
VALUE GEMDS-UserAuth-Group Operator 0
VALUE GEMDS-UserAuth-Group Technician 1
VALUE GEMDS-UserAuth-Group Admin istrator 2
END-VENDOR GEMDS
And configuring users as follows:
admin Cleartext-Password := “a dmin”
GEMDS-UserAuth-Group := Administrator
tech Cleartext-Password := “tech”
GEMDS-UserAuth-Group := Technician
oper Cleartext-Password := “oper”
GEMDS-UserAuth-Group := Operator
Configuring
The following shows how to configure a RADIUS server:
admin@(none) 02:23:42% set system mds-radius servers
shared-secret
admin@(none) 00:06:15% show system mds-radius
servers server1 {
address 192.168.1.2;
authentication-port 1812;
shared-secret abcd1234;
user-authentication-type radius-CHAP;
}
[ok][2012-06-19 00:06:22]
abcd1234
user-authentication-type radius-CHAP
server1
address 192.168.1.2
[edit]
admin@(none) 00:06:22% commit
Commit Complete.
[ok][2012-06-19 00:06:25]
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 71
Page 80
File Servers
Understanding
External file servers can be preconfigured so that the configuration can easily be referenced in other services
without the need to re-enter the information. File Server Configurations can be used for reprogramming,
downloading certificates, configuration script import and export, and sending support bundles for debugging.
Configuring
The following shows how to add a file server configuration named “GE File Server 1”:
admin@(none) 05:11:42% set file-servers
admin@(none) 05:11:42% commit
Commit complete.
[ok][2012-06-19 05:11:43]
admin@(none) 05:11:45> show configuration file-servers
file-servers GE_file_server_1 {
tftp {
address 192.168.1.2;
}
}
[ok][2012-06-19 05:11:46]
GE_file_server_1
tftp address 192.168.1.2
Monitoring
Ensure the CLI is in operational mode. The file transfer status is available as operational data. Refer to the
sections on “Firmware Management” and “Certificate Management” for more information.
72 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 81
Certificate Management
Understanding
The unit uses x509 public certificates and private keys for the following services:
• Secure Reprogramming
• Syslog over TLS
• IPsec VPN/IMA (when using pub-key, EAP-TLS or EAP-TTLS based authentication)
• WiFi (when doing EAP-TLS authentication in station mode)
Certificates can be loaded into the device using one of two methods: manual or SCEP. Note that certificates
for secure reprogramming can only be loaded using the manual method.
The unit can load certificates that are in DER, PEM, or Encrypted PEM format. The unit can load private
keys that are in DER, PEM,or Encrypted PEM.
Configuring
From either operational or configuration mode, requests can be made on the device related to certificate
management. Using the Tab character after entering 'request pki' shows a list of the available requests.
admin@(none) 05:04:37> request pki
Possible completions:
cancel-scep-operation - Canc el the last SCEP operation initiated.
delete-cacert - Delete identified CA certificat e
delete-clientcert - Delete identified Client certificate
delete-firmware-cert - Delete identified certificate
delete-priv-key - Delete identified Priva te Key
generate-priv-key -
get-ca-cert - Request the certmgr to retrieve a CA cert fro m st or e.
get-client-cert - Request the certmgr to retr ieve a client cert from
get-firmware-cert - Install a certificate to be used for firmware
get-priv-key - Retrieve private key file from netw ork or local file
show-cert-info - Dump identifie d certificate as text to display
store.
validation
system.
Manual Download of Security Material
The ‘get’ series of requests allow security material to be downloaded from the network. The specifics of the
communication can either be defined in the request or a server can be preconfigured separately (see “File
Servers” on Page 72) and used in the request.
To manually load certificates from a file server, the following requests must be used:
· get-ca-cert – To load CA certificates
· get-client-cert – To load device/client certificates
· get-firmware-cert – To load firmware verification certificates
· get-priv-key – To load device/client private key
When loading certificates manually, the file server from which the certificate will be retrieved must be provided. The file server configuration can be entered every time or, to reduce typing, the file server configuration can be selected from one of the preconfigured file servers (see “File Servers” section on Page 72):
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 73
Page 82
The following example shows loading of CA certifica tes using a file server defined prior to using the Certificate Manager request:
admin@(none) 01:19:31> request pki get-ca-cert file { preconfigured-file-server {
configuration_name
is-valid true
[ok][2012-06-19 01:20:03]
admin@(none) 01:20:03> show pki
CACERT
IDENTITY
--------ex_cacert
GE_file_server_1
} filename
cacert.der
} cacert-identity
ex_cacert
Here is an example of defining the file server manually in-line with the request call:
admin@(none) 00:35:27> request pki get-priv-key manual-file-server { tftp { address
192.168.1.2 } } filename
is-valid true
[ok][2012-06-19 00:36:27]
admin@(none) 00:36:27> show pki
KEY KEY
IDENTITY LENGTH KEY DATE TIME
---------------------------------------ex_key_1 2048 2012-06-19T04:36:26Z
der2048-priv-key.der
key-identity
ex_key_1
When defining a file server manually you may, as in this example, accept the defaults provided (in this
example, block-size, port and timeout). After entering the address, a space and ‘}’ must be entered to complete the parameters for the chosen mode. Always try the Tab-Enter to have the CLI show the next needed
parameters.
SCEP and CA Configuration
The process of interacting with a SCEP server involves getting the currently published certificate(s) from
the CA and then making a request for a client certificate with information and key material.
Before any attempt to interact with the SCEP server, the SCEP server itself, the CA associated with the
SCEP server must be identified and the certificate information must be defined:
· pki certificate-servers
· pki ca-servers
· pki cert-info
The certificate server is defined under certificate-server. In the operation shown below, we define the SCEP
server.
admin@(none) 23:46:28> config
Entering configuration mode private
[ok][2012-06-22 23:46:35]
[edit]
admin@(none) 23:48:14% set pki certificate-servers certificate-server
server-type scep scep-server-setting uri
poll-interval 5 retry-count 12 0 digest-algo sha256 encrypt-algo aes 12 8_cbc
[ok][2012-06-22 23:49:52]
[edit]
admin@(none) 23:49:52% commit
Commit complete.
[ok][2012-06-22 23:49:56]
192.168.1.5:12345/certserv/mscep/mscep.dll
ex_scep_serv
[edit]
admin@(none) 23:49:56%%
74 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 83
This defines the server that is running the SCEP protocol on an accessible network. The unit will append an
'http://' to the URL so it must not be entered as part of the uri parameter in the configuration. Note also, the
above is just an example. Your IP address, specific port (if different from the default), and path to .dll or
.cgi or other SCEP server mechanism must be obtained from your Sys tem Administration or Security personnel.
The configuration of the Certificate Authority that will be accessed at the above server is setup in a second
command under ca-servers.
admin@(none) 03:05:56% set pki ca-servers ca-server
c1f2b0930c2c8e96164c3ed2d7e970a16860df8537403632dc18d7bf9bb7d546
[ok][2012-06-20 03:08:07]
[edit]
admin@(none) 03:08:07% commit
Commit complete.
[ok][2012-06-20 03:08:30]
[edit]
admin@(none) 03:08:30%
ex_ca_serv
ca-fingerprint
The fingerprint of the CA server is another data item you will obtain from your System Administrator or
Security personnel. The ca server name is the name that will be referenced in the SCEP operations described
below. In general, it is simply for your reference and does not have to be a specific name. In fact, it can be
the same name as the ca-server if this helps to remember it.
Also, client certificate information that goes in the “Subject” portion of an X.509 certificate must be configured. Some fields may be fixed/required by the specific SCEP server.
admin@(none) 05:08:11% config
Entering configuration mode private
[ok][2012-06-23 04:08:19]
[edit]
admin@(none) 04:08:19% set pki cert-info certificate-info
Possible completions:
common-name-x509 country-x509 locale-x509 org-unit-x509 organization-x509 pkcs9-email-x509 state-x509 -
ex_ca_serv
The list above was displayed by entering Space-Tab after entering a name for the new set of certificate info.
The parameters that must be entered for your client certificate information must again be obtain ed from your
System Administration or Security personnel. The common name will always be required. Other parameters
may be required.
Here is an example:
admin@(none) 06:37:30> config
Entering configuration mode private
[ok][2012-06-23 06:37:32]
[edit]
admin@(none) 06:37:32% set pki cert-info certificate-info
MDS LLC
[ok][2012-06-23 06:38:34]
[edit]
admin@(none) 06:38:34% commit
Commit complete.
[ok][2012-06-23 06:38:38]
” org-unit-x509
Engineering
common-name-x509
ey_ca_serv
00102200000102030411223344556670
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 75
organization-x509 “
GE
Page 84
Generating a Private Key
To have the device generate a private key, the following request must b e used:
· > request pki generate-priv-key
The following example shows how to generate a private key with identifier ex_key:
admin@(none) 21:54:47> request pki generate-priv-key key-size 2048 key-identity ex_key
SCEP Certificate Requests
To load certificates via SCEP, the following requests must be used:
•
> request pki get-ca-cert scep – To obtain CA certificate chain
> request pki get-client-cert scep – To obtain device/client certificate
•
The first step is to acquire the CA published public certificate(s):
admin@(none) 00:27:14> request pki get-ca-cert scep { cert-server-name
ca-server-name
is-valid true
[ok][2012-06-23 00:27:47]
admin@(none) 00:27:47> show pki
KEY KEY
IDENTITY LENGTH KEY DATE TIME
---------------------------------------ex_key 2048 2012-06-20T10:46:59Z
CACERT
IDENTITY
---------ex_cacert
ex_cacert_ENC
ex_cacert_SGN
ex_ca_serv }
cacert-identity
ex_cacert
ex_scep_serv
Additional CA server files sent as part of the request and needed later are saved with the base name you
selected for the CA server and an added extension. Some of the names that may be added are:
· _ENC , SCEP encryption certificate
· _SGN , SCEP digital signature certificate
The second step is to request a client cert from the CA server via the SCEP server.
admin@(none) 06:28:39> request pki get-client-cert scep { cert-server-name
ca-server-name
51F67BBA1BCF20F1
is-valid true
[ok][2012-06-20 06:32:04]
ex_ca_server
cacert-identity-name
cert-info-name
ex_ca_server
ex_cacert
} clientcert-identity
cert-key-name
ex_scep_serv
ex_key
ca-challenge
ex_client
76 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 85
admin@(none) 06:32:04> show pki
KEY KEY
IDENTITY LENGTH KEY DATE TIME
---------------------------------------ex_key 2048 2012-06-20T10:46:59Z
CACERT
IDENTITY
---------ex_cacert
ex_cacert_ENC
ex_cacert_SGN
CERT
IDENTITY
---------ex_client
The parameter that must be entered for your ca-challenge must be obtained from your System Administrator
or Security personnel.
Certificate Renewal with SCEP
At some point, the dates on your certificate will need to be renewed due to time or security policy. A client
certificate can be renewed using the existing certificate with the same key as originally used when it was
generated. An alternative is to provide a new key and identify for the certificate that is to be renewed and
rekeyed.
The same request is used to renew as for the original request with a slight change in parameters provided.
For this request, the cert-key-name is always the key that will be used in the certificate that you identify with
the cert-identification-name. The ‘self’ cert and optional ‘self’ key are respectively the existing certificate
that will be renewed and the key that was originally used when it was created.
In the case we are going to use the same key in a renewed cert. Here is a renewal request formed accordingly:
admin@(none) 02:03:49% request pki get-client-cert scep { cert-server-name
cert-info-name
cert-key-name
cert-identity
is-valid true
[ok][2012-06-24 02:05:19]
[edit]
admin@(none) 02:05:19% exit
admin@(none) 02:13:51> show pki
KEY KEY
IDENTITY LENGTH KEY DATE TIME
---------------------------------------ex_key 2048 2012-06-20T10:46:59Z
CACERT IDENTITY
------------------
ex_cacert
ex_cacert_ENC
ex_cacert_SGN
CERT
IDENTITY
------------ex_c_cert
ex_client
admin@(none) 02:05:19%
ex_ca_server
ex_key
cert-self-cert-name
ex_c_cert
ca-server-name
ex_ca_server
ex_client
cert-self-key-name
cacert-identity-name
ex_scep_serv
ex_key
} client-
ex_cacert
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 77
Page 86
Here is an example of how to renew a cert with a new key named ex_key_1:
admin@(none) 05:16:58> request pki get-client-cert scep { cert-server-name
cert-info-name
cert-key-name
cert-identity
is-valid true
[ok][2012-06-24 05:17:32]
admin@(none) 05:17:32> show pki
KEY KEY
IDENTITY LENGTH KEY DATE TIME
---------------------------------------ex_key 2048 2012-06-20T10:46:59Z
ex_key_1 2048 2012-06-19T10:57:10Z
CACERT IDENTITY
-----------------ex_cacert
ex_cacert_ENC
ex_cacert_SGN
CERT
IDENTITY
------------ex_c_cert
ex_client
tst4
[ok][2012-06-24 05:17:38]
admin@(none) 05:17:38>
ex_ca_server
ex_key_1
tst4
ca-server-name
cert-self-cert-name
ex_ca_server
ex_client
cert-self-key-name
cacert-identity-name
ex_key }
ex_scep_serv
ex_cacert
client-
Deleting security material
Obsolete security material in all categories can be deleted from the device with the ‘delete’ series of
requests:
delete-cacert
•
• delete-clientcert
• delete-firmware-cert
• delete-priv-key
Here is an example of deleting the private key we have moved beyond when we re-keyed the client certificate in the last step:
admin@(none) 06:07:41% request pki delete-priv-key key-identity ex_key
is-valid true
[ok][2012-06-24 06:07:55]
admin@(none) 06:07:55%
Firmware Certificate
The following example shows how to retrieve a certificate that can be used to verify a signed firmware
package:
admin@(none) 06:07:41% request pki get-firmware-cert preconfigured-file-server {
configuration_name GE-FileServer-1 } filename certs/cert1.pem identity cert1
78 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 87
Monitoring
Certificate information can be viewed for the following items:
· ca-cert-info
· client-cert-info
· firmware-cert-info
· priv-key-info
Ensure the CLI is in operational mode. Follow the example below to view the state and statistics:
admin@(none) 01:03:45> show pki
KEY
KEY IDENTITY LENGTH KEY DATE TIME
--------------------------------------------test_priv_key 1024 2012-06-19T00:05:23Z
CACERT IDENTITY
-----------------test_ca_cert
test_ca_cert_INT
test_ca_cert_ISS
CERT IDENTITY
-----------------test_client_cert
FWCERT
IDENTITY CERT HASH
---------------------------------------------------------------------------GE_Cert1 7bd5c7aa56f469614f5ee13daa0a0800b60d97fbccfcb85c9fc2af87656043d8
[ok][2012-06-19 01:03:49]
admin@(none) 01:03:49>
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 79
Page 88
Event Logging
Understanding
An event is a notification that something meaningful occurred on the unit. Events contain information about
the occurrence that may be useful for administrators. The event can be stored locally and/or transported to
a remote server. Administrators can adjust which events are reported by the unit. The structure of the information about the event is described below (CEE).
Logs are stored in the Event Log, which can be viewed with the command:
admin@(none) 00:15:32> show table logging event-log
NETCONF-notifications
The events generated by the unit are converted to NETCONF notifications. NETCONF clients can subscribe
to the unit to receive those notifications.
Syslog
The events generated by the unit can be sent to remote syslog servers. The connection to the syslog server
can be made secure using syslog over TLS. To set up a syslog server, use the command:
admin@(none) 00:16:20> % set logging syslog server my_server ip 192.168.1.200
When logging to a syslog server, the following attributes can also be set:
• priority
• syslog-facility
Event Rules
All events can be configured to be logged to any combination of the following locations based on the event
type:
• Local: Store event in the local event log.
• Netconf-notification: generate a NETCONF notification
• Syslog: Forward events to a remote syslog server.
Configure the event rules
% set logging event-rules <parameter> <functions/outputs>
80 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 89
Firmware Management
Understanding
The unit can have two firmware packages programmed into the device. The package that the device booted
into is referred to as the Active Firmware. The other image is referred to as the Inactive Firmware.
To reprogram the device, the Active Firmware streams the new firmware package from the network and
writes the package into the Inactive Firmware location in memory. To use the new firmware package, the
user must reboot the device to the Inactive Firmware. Doing so will make the Inactive Firmware the Active
Firmware and vice-versa.
Firmware packages released by the factory are digitally signed using a private key. The unit will not accept
firmware packages that are unsigned nor will it accept firmware packages that fail to verify while using the
public certificates loaded into the device. Therefore it is necessary to have the GE MDS public certificate
loaded into the device to reprogram the firmware.
Users may add their own signatures to the firmware package using the GE MDS code signing tool.
NOTE: Any additional signatures added to a firmware package will require the corresponding public
certificates to be loaded into the unit for firmware reprogramming to complete successfully. Simi-
larly, any additional firmware-validation public certificates loaded into the unit require a firm-
ware package to be signed with the corresponding private keys.
The request reprogram-inactive-image initiates the reprogramming sequence on the unit. The request will
return immediately and the reprogramming sequence will continue in the background on the device. The
reprogramming sequence can take several minutes. The status of the reprogramming sequence can be polled
to know when reprogramming has completed.
admin@(none) 06:24:44> request system firmware reprogram-inactive-image
preconfigured-file-serve r { configuration_name
files/firmware.mpk
[ok][2012-06-21 06:25:26]
admin@(none) 06:25:26>
GE-FileServer-1
} filename
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 81
Page 90
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the state and statistics of the currently installed firmware packages:
admin@(none) 03:55:43> show system firmware versions
system firmware versions 1
version 1.0.1
active true
CERTIFICATE
SIGNING
INDEX CERTIFICATE SHA256
------------------------------------------------------------------------------1 3d9d795dcf374084de536986a29238ea7dc87104259619bc7aa4cfa3e2c64990
system firmware versions 2
version 1.0.0
active false
CERTIFICATE
SIGNING
INDEX CERTIFICATE SHA256
------------------------------------------------------------------------------1 3d9d795dcf374084de536986a29238ea7dc87104259619bc7aa4cfa3e2c64990
Requesting an update
admin@(none) 03:55:43>request system firmware reprogram-inactive-image filename iwc-bkrc-1_0_0.mpk
manual-file-server { tftp { address 192.168.1.10 } }
Retrieving Status on a Reprogramming Session
admin@(none) 03:55:43>show system firmware reprogramming-status
system firmware reprogramming-status state active
system firmware reprogramming-status detailed-message “Transferring file"
system firmware reprogramming-status size 36005116
system firmware reprogramming-status bytes-transferred 7455744
system firmware reprogramming-status percent-complete 20
admin@(none) 03:55:43>show system firmware reprogramming-status
system firmware reprogramming-status state complete
system firmware reprogramming-status detailed-message "Reprogrammed successfully"
system firmware reprogramming-status size 36005116
system firmware reprogramming-status bytes-transferred 35984896
system firmware reprogramming-status percent-complete 100
The command below provides a simple way to monitor percent complete. (Use Ctrl-C to abort.)
admin@(none) 03:55:43>show system firmware reprogramming-st at us percent-complete | repeat 1
system firmware reprogramming-status percent-complete 25
system firmware reprogramming-status percent-complete 27
system firmware reprogramming-status percent-complete 28
82 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 91
Support Bundle
Understanding
The MCR incorporates a facility to generate a support package bundle that includes internal debugs, logs,
etc. This can help factory personnel troubleshoot user issues.
Configuring
The following example shows how to have MCR generate and transfer a support package bundle (named
debug-2013-01-24.tgz) to a FTP server running on host (address 192.168.1.2) that is accessible from the
MCR (e.g. a locally connected host or remote host accessible via cellular interface):
admin@(none) 22:14:57> request system support generate-support-package filename
debug-2013-01-24.tgz manual-file-server { ftp { address 192.168.1.2 username xyz password xyz } }
The MCR supports TFTP, FTP, and SFTP transfer protocols.
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the state of the support bundle
transfer:
admin@(none) 22:17:18> show system support
system support support-transfer-status state active
system support support-transfer-status detailed-message “Transferring”
system support support-transfer-status size 0
system support support-transfer-status bytes-transferred 0
system support support-transfer-status percent-complete 0
[ok][2013-01-24 22:17:21]
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 83
Page 92
Configuration Scripts
NOTE: The web-based device manager interface should not be active when importing a configuration
script.
Understanding
An exported configuration script will contain all of the settable parameters of the unit for which the current
user has read-access; e.g. configuration scripts exported by the tech user will not contain values which only
the admin user has permissions to view. Configuration scripts can be saved and used to restore known-good
configurations.
Configuring
The following example shows how to have MCR generate and transfer a configuration script (named configscript-2013-09-24.txt) to a SFTP server running on host (address 192.168.1.10) that is accessible from
the MCR (e.g. a locally connected host or remote host accessible via cellular interface):
admin@(none) 22:14:57> request system configuration-files export manual-file-server { sftp { address
192.168.1.10 username myusername password mypassword } } filename configscript-2013-09-24.txt
The configuration script can then be imported to the unit using TFTP, for example, using the commands
below:
admin@(none) 22:18:32> request system configuration-files import manual-file-server { tftp { address
192.168.1.10 } } filename configscript-2013-09-24.txt
The MCR supports TFTP, FTP, and SFTP transfer protocols for configuration script export and import.
Monitoring
Ensure the CLI is in operational mode. Follow the example below to view the state of the configuration
script file transfer:
admin@(none) 22:17:18> show syst e m co nfiguration-file transfer-status
system support configuration-fi le s tr an sfer-status state active
system support configuration-files transfer-status detailed-message “Transferring”
system support configuration-files transfer-status size 30004
system support configuration-files transfer-status bytes-transfe r red 29404
system support configuration-files transfer-status percent-complete 97
[ok][2013-09-24 22:17:21]
84 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 93
4.0 TECHNICAL REFERENCE
4.1 Troubleshooting
All units must meet the basic requirements listed below for proper operation. Check these items first when
troubleshooting a system problem:
• Adequate and stable primary power
• Secure connections (antennas, data and power)
• A clear transmission path between associated units
• An efficient, properly installed antenna system
• Proper configuration of unit settings
• Correct interface between the unit and other equipment
4.1.1 LED Status Indicators
The LEDs on the unit are visual indications of the status of the device. These indicators can provide useful
information when troubleshooting. Refer to Table 8 for LED indications.
Figure 25. LED Status Indicators
Table 8. Description of LED Status Indicators
LED Name LED State Description
PWR
(DC Power)
ETH
(Ethernet)
COM
(Serial Comm. Port)
NIC1
(Cell)
NIC2
(WiFi)
Access Point Mode Solid Green
Station Mode Off
Off
Solid Green
Fast Blink/Red (1x/sec.)
Off
Solid Green
Blinking Green
Off
Blinking Green
Off
Solid Green
Off Interface disabled
Solid Red
Solid Green
No power to unit
Unit is powered, no problems detected
Alarm indication
No Ethernet link to network
Ethernet link present
Ethernet traffic in/out
No serial connection, or idle
Serial traffic in/out
No cellular connection
Cell Connection
Operating as AP and at least one client connection
Operating as an AP and no client connection
No connection
Wi-Fi connection established.
NOTE: In addition to the LEDs above, the Ethernet connector has two embedded LEDs. A yellow indi-
cates a link at 100 Mbps operation. A flashing green indicates Ethernet data traffic.
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 85
Page 94
4.2 Technical Specifications
4.2.1 General
Input Power: 10 to 60 Vdc, 15 Watts maximum, depending on configuration. Below are power consumption figures for common configurations:
• Typical High Throughput Wi-Fi power consumption <= 4.1 Watts
• Minimum Wi-Fi power consumption <= 3.4 Watts
Ethernet Port(s): RJ-45 10/100 Mbps Auto-MDIX
Serial Port(s): RJ-45, supporting RS-232/RS-485
LAN Protocols: 802.3 (Ethernet) 802.1D (Spanning Tree) TCP/IP, DHCP, ICMP, IGMP, FTP, TFTP,
SFTP, UDP, SNMP, VPN, VLAN
Networking: DHCP, Port Forwarding, NAT, VLAN, SNMP
Configuration: Serial console, SSH, HTTP/HTTPS, Configuration files
Security: Encryption, Password access, Radius, Firewall, SCEP, VPN
4.2.2 Physical
Size: 6.5” long (16.51 cm), 4.625” wide (11.75 cm), 1.5” High (3.81 cm)
Housing: Die-cast Aluminum
Weight: 2 lbs (without mounting hardware)
4.2.3 Environmental
Operating Temperature Range: -40°C to +70°C
4.2.4 Agency/Regulatory Approvals
FCC:
• WiFi – M4Y-ZCN722MV1,
• Cell – PKRNVWE362
IC - Industry:
• WiFi – 3195A-ZCN722MV1
• Cell -3229B-E362
Specifications subject to change without notice or obligation.
4.2.5 2.4 GHz WiFi Specifications
• Protocol: IEEE 802.11b/g/n OFDM 6 to 54Mbps, CCK 1 to 11Mbps
• Frequency Range: 2400 to 2500 MHz
• Maximum Transmit Power: 18 dBm (Default is 15 dBm)
• Permissible Antennas:
- GE MDS 97-4278A36
- GE MDS 97-4278A34
- GE MDS 97-4278A35
• FCC: Part 15C
• FCC ID: VRA-SG9011028
• WiFi Antenna Connector: Female Reverse SMA
86 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 95
4.3 Glossary of Terms & Abbreviations
If you are new to wireless communications systems, some of the terms used in this guide may be unfamiliar.
The following glossary explains many of these terms and will prove helpful in understanding the operation
of the unit.
Antenna System Gain: A figure, normally expressed in dB, representing the power increase resulting from
the use of a gain-type antenna. System losses (from the feedline and coaxial connectors, for example) are
subtracted from this figure to calculate the total antenna system gain.
Bit: The smallest unit of digital data, often represented by a one or a zero. Eight bits (plus start, stop, and
parity bits) usually comprise a byte.
Bits-per-second: See BPS.
BPS (Bits-per-second): A measure of the information transfer rate of digital data across a communication
channel.
Bridging: (see Ethernet Bridging)
Byte: A string of digital data usually made up of eight data bits and start, stop and parity bits.
CLI: Command Line Interface. A method of user control where commands are entered as character strings
to set configuration and operating parameters.
CTS: Clear to Send
Decibel (dB): A measure computed from the ratio between two signal levels. Frequently used to express
the gain (or loss) of a system.
Data Circuit-terminating Equipment: See DCE.
Data Communications Equipment: See DCE.
Data Terminal Equipment: See DTE.
dBi: Decibels referenced to an “ideal” isotropic radiator in free space, frequently used to express antenna
gain.
dBm: Decibels referenced to one milliwatt. An absolute unit used to measure signal power, as in transmitter
power output, or received signal strength.
DCE (Data Circuit-terminating Equipment) (or Data Communications Equipment): In data communica-
tions terminology, this is the “modem” side of a computer-to-modem conn ection. The unit described in this
manual is hardwired as a DCE device.
DTE (Data Terminal Equipment): A device that provides data in the form of digital signals at its output.
DTE connects to the DCE device.
ETH: Ethernet
Ethernet Bridging: To be supplied.
Fade Margin: The greatest tolerable reduction in average received signal strength that will be anticipated
under most conditions. It provides an allowance for reduced signal strength due to multipath, slight antenna
movement or changing atmospheric losses. A fade margin of 20 to 30 dB is usually sufficient in most systems.
FPGA: Field Programmable Gate Array
Frame: A segment of data that adheres to a specific data protocol and contains definite start and end points.
It provides a method of synchronizing transmissions.
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 87
Page 96
Hardware Flow Control: A feature used to prevent data buffer overruns when the unit is handling
high-speed data from an RTU or PLC. When the buffer approaches overflow, the unit drops the
clear-to-send (CTS) line, which instructs the RTU or PLC to delay further transmission until CTS again
returns to the high state.
Host Computer: The computer installed at the master unit, which controls the collection of data from one
or more remote sites.
IP: Internet Protocol
LAN: Local Area Network
LED: Light Emitting Diode
mA: Milliamperes
MAC: Media Access Control
Poll: A request for data issued from the host computer (or master PLC) to a Remote unit.
PLC (Programmable Logic Controller): A dedicated microprocessor configured for a specific applica-
tion with discrete inputs and outputs. It can serve as a host or as an RTU.
PPM: Parts per Million
Programmable Logic Controller: See PLC.
Remote Terminal Unit: See RTU.
RTS: Request-to-send
RTU: Remote Terminal Unit. A data collection device installed at a Remote unit site.
RX: Abbreviation for “Receive.”
Signal-to-Noise Ratio: See SNR.
SCADA (Supervisory Control And Data Acquisition): An overall term for the functions commonly pro-
vided through a multiple address radio system.
SCEP: Simple Certificate Enrollment Protocol. A scalable protocol for networks based on digital certifi-
cates, which can be requested by users without the need for assistance or manual intervention from a system
administrator.
SNR (Signal-to-Noise ratio): A measure of how well the signal is being received at a radio relative to noise
on the channel.
SSH: Secure Shell protocol for a network that allows users to open a window on a local PC and connect to
a remote PC as if they were present at the remote.
SSID (Service Set Identifier): A name that identifies a particular 802.11wireless LAN.
Supervisory Control And Data Acquisition: See SCADA.
Telnet: A terminal emulation protocol that enables an Internet user to communicate with a Remote device
for management activities as if it were locally connected to a PC.
TX: Abbreviation for “Transmit.”
WAN: Wide Area Network.
88 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 97
5.0 APPENDIX A – DATA CONFIGURATION TREE
Current version matches with Firmware version 1.1.9.
The following is a hierarchical view of the data configuration tree for the unit. It is a composition of all
YANG files used by the unit.
+--rw interfaces
| +--rw interface [name]
| | +--rw name string
| | +--rw description? string
| | +--rw enabled? boolean
| | +--ro oper-status? enumeration
| | +--ro last-change? yang:date-and-time
| | +--ro if-index? int32
| | +--rw link-up-down-trap-enab le? enumeration
| | +--ro phys-address? yang:phys-address
| | +--ro higher-layer-if* interface-ref
| | +--ro lower-layer-if* interface-ref
| | +--ro speed? yang:gauge64
| | +--ro statistics
| | | +--ro discontinuity-time? yang:date-and-time
| | | +--ro in-octets? yang:counter64
| | | +--ro in-unicast-pkts? yang:counter64
| | | +--ro in-broadcast-pkts? yang:counter64
| | | +--ro in-multicast-pkts? yang:counter64
| | | +--ro in-discards? yang:counter32
| | | +--ro in-errors? yang:counter32
| | | +--ro in-unknown-protos? yang:counter32
| | | +--ro out-octets? yang:counter64
| | | +--ro out-unicast-pkts? yang:counter64
| | | +--ro out-broadcast-pkts? yang:counter64
| | | +--ro out-multicast-pkts? yang:counter64
| | | +--ro out-discards? yang:counter32
| | | +--ro out-errors? yang:counter32
| | +--rw ip:ipv4?
| | | +--rw ip:enabled? boolean
| | | +--rw ip:forwarding? boolean
| | | +--rw ip:mtu? uint16
| | | +--rw ip:address [ip]
| | | | +--rw ip:ip inet:ipv4-address-no-zone
| | | | +--rw (subnet)
| | | | +--:(prefix-length)
| | | | | +--rw ip:prefix-length? uint8
| | | | +--:(netmask)
| | | | +--rw ip:netmask? yang:dotted-quad
| | | +--rw ip:neighbor [ip]
| | | | +--rw ip:ip inet:ipv4-address-no-zone
| | | | +--rw ip:phys-address? yang:phys-ad dress
| | | +--rw mdsif:dhcp?
| | | | +--rw mdsif:client-identifier? stri ng
| | | | +--rw mdsif:retry-interval? uint16
| | | +--ro mdsif:current-address [ip]
| | | +--ro mdsif:ip inet:ipv4-address-no-zone
| | | +--ro mdsif:prefix-length? uint8
| | +--rw ip:ipv6?
| | | +--rw ip:enabled? boolean
| | | +--rw ip:forwarding? boolean
| | | +--rw ip:mtu? uint32
| | | +--rw ip:address [ip]
| | | | +--rw ip:ip inet:ipv6-address-no-zone
| | | | +--rw ip:prefix-length uint8
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 89
Page 98
| | | +--rw ip:neighbor [ip]
| | | | +--rw ip:ip inet:ipv6-address-no-zone
| | | | +--rw ip:phys-address? yang:phys-ad dress
| | | +--rw ip:dup-addr-detect-transmits? uint32
| | | +--rw ip:autoconf
| | | | +--rw ip:create-global-addresse s? boolean
| | | | +--rw ip:create-temporary-addre sses? boolean
| | | | +--rw ip:temporary-valid-lifeti me? uint32
| | | | +--rw ip:temporary-preferred-li fetime? uint32
| | | +--ro mdsif:current-address [ip]
| | | +--ro mdsif:ip inet:ipv6-address-no-zone
| | | +--ro mdsif:prefix-length? uint8
| | +--rw mdsif:eth-phy-rate? bits
| | +--ro mdsif:eth-phy-status? enumeration
| | +--rw mdsif:virtual-type? identityref
| | +--rw mdsif:physical-interfa ce? leafref
| | +--ro mdsif:system-device? string
| | +--ro mdsif:neighbors
| | | +--ro mdsif:ip? inet:ip-address-no-zone
| | | +--ro mdsif:phys-address? yang:phys-address
| | | +--ro mdsif:state? enumeration
| | +--rw mds_wifi:wifi-config?
| | | +--rw mds_wifi:mode enumeration
| | | +--rw mds_wifi:tx-power? uint32
| | | +--rw mds_wifi:station-config?
| | | | +--rw mds_wifi:ap [ssid]
| | | | +--rw mds_wifi:ssid string
| | | | +--rw mds_wifi:enabled? boolean
| | | | +--rw mds_wifi:privacy-mode? enumeration
| | | | +--rw mds_wifi:psk-config
| | | | | +--rw mds_wifi:encryption? enumeration
| | | | | +--rw mds_wifi:key-mgmt? enumeration
| | | | | +--rw mds_wifi:psk? string
| | | | +--rw mds_wifi:eap-config
| | | | | +--rw mds_wifi:encryption? enumeration
| | | | | +--rw mds_wifi:key-mgmt? enumeration
| | | | | +--rw mds_wifi:eap-method? enumeration
| | | | +--rw mds_wifi:pki?
| | | | +--rw mds_wifi:cert-type enumeration
| | | | +--rw mds_wifi:cert-id string
| | | | +--rw mds_wifi:key-id string
| | | | +--rw mds_wifi:ca-cert-id string
| | | +--rw mds_wifi:ap-config?
| | | +--rw mds_wifi:ap [ssid]
| | | | +--rw mds_wifi:ssid string
| | | | +--rw mds_wifi:broadcast-ssid? boolean
| | | | +--rw mds_wifi:station-max? uint32
| | | | +--rw mds_wifi:station-timeout? uint32
| | | | +--rw mds_wifi:beacon-interval? uint32
| | | | +--rw mds_wifi:privacy-mode? enumeration
| | | | +--rw mds_wifi:psk-config
| | | | | +--rw mds_wifi:encryption? enumeration
| | | | | +--rw mds_wifi:key-mgmt? enumeration
| | | | | +--rw mds_wifi:psk? string
| | | | +--rw mds_wifi:eap-config
| | | | | +--rw mds_wifi:encryption? enumeration
| | | | | +--rw mds_wifi:key-mgmt? enumeration
| | | | | +--rw mds_wifi:eap-method? enumeration
| | | | +--rw mds_wifi:radius-server? leafref
| | | | +--rw mds_vlan:vlan-mode? enumeration
| | | | +--rw mds_vlan:vlans* if:interface-ref
| | | | +--rw mds_vlan:vlan? if:interface-ref
| | | +--rw mds_wifi:channel? uint32
| | | +--rw mds_wifi:operation-mode? enumera tion
| | | +--rw mds_wifi:dtim-period? uint32
| | | +--rw mds_wifi:rts-threshold? uint32
90 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Page 99
| | | +--rw mds_wifi:fragm-threshold? uint3 2
| | +--ro mds_wifi:wifi-status
| | | +--ro mds_wifi:serial-number? display-string
| | | +--ro mds_wifi:mode? display-string
| | | +--ro mds_wifi:tx-power? uint8
| | | +--ro mds_wifi:channel? uint8
| | | +--ro mds_wifi:ap-status
| | | | +--ro mds_wifi:ap [ssid]
| | | | +--ro mds_wifi:ssid ssid
| | | | +--ro mds_wifi:client [mac]
| | | | +--ro mds_wifi:mac string
| | | | +--ro mds_wifi:rssi? int8
| | | | +--ro mds_wifi:authenticated? boolean
| | | | +--ro mds_wifi:authorized? boolean
| | | | +--ro mds_wifi:inactive? uint32
| | | | +--ro mds_wifi:rxbytes? uint32
| | | | +--ro mds_wifi:rxpackets? uint32
| | | | +--ro mds_wifi:txbitrate? uint16
| | | | +--ro mds_wifi:txbytes? uint32
| | | | +--ro mds_wifi:txpackets? uint32
| | | | +--ro mds_wifi:txfailed? uint32
| | | | +--ro mds_wifi:txretries? uint32
| | | +--ro mds_wifi:station-status
| | | +--ro mds_wifi:ssid? ssid
| | | +--ro mds_wifi:bssid? string
| | | +--ro mds_wifi:rssi? int8
| | | +--ro mds_wifi:authenticated? boolean
| | | +--ro mds_wifi:authorized? boolean
| | | +--ro mds_wifi:inactive? uint32
| | | +--ro mds_wifi:rxbytes? uint32
| | | +--ro mds_wifi:rxpackets? uint32
| | | +--ro mds_wifi:txbitrate? uint16
| | | +--ro mds_wifi:txbytes? uint32
| | | +--ro mds_wifi:txpackets? uint32
| | | +--ro mds_wifi:txfailed? uint32
| | | +--ro mds_wifi:txretries? uint32
| | +--rw mds_vlan:vlan-config
| | | +--rw mds_vlan:vlan-id? vlan-id
| | | +--rw mds_vlan:native-vlan? boolean
| | +--rw mds_vlan:vlan-mode? enumeration
| | +--rw mds_vlan:vlans* if:interface-ref
| | +--rw mds_vlan:vlan? if:interface-ref
| | +--rw mds_bridge:bridgeStatu s
| | | +--rw mds_bridge:stp
| | | +--ro mds_bridge:port [interface]
| | | +--ro mds_bridge:interface if:interface-ref
| | | +--ro mds_bridge:number? uint32
| | | +--ro mds_bridge:priority? uint8
| | | +--ro mds_bridge:state? enumeration
| | | +--ro mds_bridge:path-cost? uint32
| | | +--ro mds_bridge:designated-root? string
| | | +--ro mds_bridge:designated-cost? uint32
| | | +--ro mds_bridge:designated-bridge? string
| | | +--ro mds_bridge:designated-port? uint32
| | +--rw mds_bridge:bridge-sett ings
| | | +--rw mds_bridge:members
| | | | +--rw mds_bridge:port [interface]
| | | | | +--rw mds_bridge:interface if:interface-ref
| | | | | +--rw mds_bridge:port-priority? uint32
| | | | | +--rw mds_bridge:port-path-cost? uint32
| | | | +--rw mds_bridge:wifi-ap [ssid]
| | | | | +--rw mds_bridge:ssid leafref
| | | | | +--rw mds_bridge:port-priority? uint32
| | | | | +--rw mds_bridge:port-path-cost? uint32
| | | | +--rw mds_bridge:wifi-station
| | | | +--rw mds_bridge:interface? if:interface-ref
MDS 05-6628A01, Rev. C MDS Orbit MCR Technical Manual 91
Page 100
| | | | +--rw mds_bridge:port-priority? uint32
| | | | +--rw mds_bridge:port-path-cost? uint32
| | | +--rw mds_bridge:stp-mode? enumeration
| | | +--rw mds_bridge:ageing-time? uint32
| | | +--rw mds_bridge:max-age? uint32
| | | +--rw mds_bridge:hello-time? uint32
| | | +--rw mds_bridge:forward-delay? uint32
| | | +--rw mds_bridge:bridge-priority? uint32
| | +--rw mds-cell:cell-config
| | | +--rw mds-cell:apn? string
| | | +--rw mds-cell:keep-alive?
| | | | +--rw mds-cell:address inet:host
| | | | +--rw mds-cell:interval? uint8
| | | | +--rw mds-cell:recovery-on-time out? boolean
| | | | +--rw mds-cell:max-num-retries? uint8
| | | +--rw mds-cell:service-recovery
| | | +--rw mds-cell:general-recovery-i nterval? uint16
| | | +--rw mds-cell:lte-recovery? boolean
| | | +--rw mds-cell:lte-recovery-inter val? uint16
| | +--ro mds-cell:cell-status
| | | +--ro mds-cell:imsi? display-string
| | | +--ro mds-cell:imei? display-string
| | | +--ro mds-cell:iccid? display-string
| | | +--ro mds-cell:mdn? display-string
| | | +--ro mds-cell:apn? display-string
| | | +--ro mds-cell:app-sw-version? display-string
| | | +--ro mds-cell:modem-sw-version? display-string
| | | +--ro mds-cell:sim-state? display-string
| | | +--ro mds-cell:modem-state? enumeration
| | | +--ro mds-cell:roaming-state? enumeration
| | | +--ro mds-cell:service-state? enumeration
| | | +--ro mds-cell:rssi? int8
| | +--rw fire:filter
| | | +--rw fire:input? leafref
| | | +--rw fire:output? leafref
| | +--rw fire:nat
| | +--rw fire:source? leafref
| | +--rw fire:destination? leafref
| +--rw mdsif:physical-interface [name]
| +--rw mdsif:name string
| +--rw mdsif:type identityref
| +--rw mdsif:system-name string
+--rw system
| +--rw contact? string
| +--rw name? string
| +--rw location? string
| +--ro platform
| | +--ro os-name? string
| | +--ro os-release? string
| | +--ro os-version? string
| | +--ro machine? string
| | +--ro nodename? string
| +--rw clock
| | +--ro current-datetime? yang:date-an d-time
| | +--ro boot-datetime? yang:date-and-time
| | +--rw (timezone)?
| | | +--:(timezone-location)
| | | | +--rw timezone-location? ianatz:iana-timezone
| | | +--:(timezone-utc-offset)
| | | +--rw timezone-utc-offset? int16
| | +--rw mdssys:set
| +--rw ntp
| | +--rw use-ntp? boolean
| | +--rw ntp-server [address]
| | +--rw association-type? enumeration
| | +--rw address inet:host
92 MDS Orbit MCR Technical Manual MDS 05-6628A01, Rev. C
Loading...