Rugged Operating System RMC30 (ROS®) v3.10 User Guide For use with :

Rugged Operating System RMC30 (ROS®) v3.10 User Guide For use with :
Rugged Operating System
(ROS®) v3.10 User Guide
For use with :
RMC30
January 19, 2012
www.RuggedCom.com
Rugged Operating System
Rugged Operating System: (ROS®) v3.10 User Guide
Copyright © 2012 RuggedCom Inc.
ALL RIGHTS RESERVED
Dissemination or reproduction of this document, or evaluation and communication of its contents, is not authorized except where
expressly permitted. Violations are liable for damages. All rights reserved, particularly for the purposes of patent application or
trademark registration.
This document contains proprietary information, which is protected by copyright. All rights are reserved. No part of this document may
be photocopied, reproduced or translated to another language without the prior written consent of RuggedCom Inc.
Disclaimer Of Liability
We have checked the contents of this manual against the hardware and software described. However, deviations from the description
cannot be completely ruled out.
RuggedCom shall not be liable for any errors or omissions contained herein or for consequential damages in connection with the
furnishing, performance, or use of this material.
The information given in this document is reviewed regularly and any necessary corrections will be included in subsequent editions.
We appreciate any suggested improvements. We reserve the right to make technical improvements without notice.
Registered Trademarks
RuggedServer™, RuggedWireless™, RuggedCom Discovery Protocol™ (RCDP™), RuggedExplorer™, Enhanced Rapid Spanning
Tree Protocol™ (eRSTP™), are trademarks of RuggedCom Inc. Rugged Operating System® (ROS®) and RuggedSwitch® are
registered trademarks of RuggedCom Inc. Other designations in this manual might be trademarks whose use by third parties for their
own purposes would infringe the rights of the owner.
Warranty
Five (5) years from date of purchase, return to factory. For warranty details, visit www.ruggedcom.com or contact your customer
service representative.
Contacting RuggedCom
Corporate Headquarters
US Headquarters
Europe Headquarters
RuggedCom Inc.
RuggedCom
RuggedCom
300 Applewood Crescent
1930 Harrison St., Suite 209
Unit 41, Aztec Centre,
Concord, Ontario
Hollywood, Florida
Aztec West, Almondsbury, Bristol
Canada, L4K 5C7
USA, 33020
United Kingdom BS32 4TD
Tel: +1 905 856 5288
Tel: +1 954 922 7938 ext. 103
Tel: +44 1454 203 404
Fax: +1 905 856 1995
Fax: +1 954 922 7984
Fax: +44 1454 203 403
Toll-free: 1 888 264 0006
Toll-free: 1 888 264 0006
Email: [email protected]
Technical Support
Toll Free (North America): 1 866 922 7975
International: +1 905 856 5288
Email: [email protected]
Web: www.RuggedCom.com
Rugged Operating System
Table of Contents
Preface ................................................................................................................................. 9
Supported Platforms ..................................................................................................... 9
Who Should Use This User Guide ............................................................................... 9
How Chapters are organized ....................................................................................... 9
Document Conventions ................................................................................................ 9
Applicable Firmware Revision .................................................................................... 10
Firmware/User Guide Version Numbering System ..................................................... 10
1. Administration ................................................................................................................. 11
1.1. The ROS® User Interface ................................................................................... 11
1.1.1. Using the RS232 Port to Access the User Interface ................................ 11
1.1.2. The Structure of the User Interface .......................................................... 11
1.1.3. Making Configuration Changes ................................................................ 12
1.1.4. Updates Occur In Real Time .................................................................... 13
1.1.5. Alarm Indications Are Provided ................................................................ 13
1.1.6. The CLI Shell ........................................................................................... 13
1.2. The ROS® Secure Shell Server ......................................................................... 13
1.2.1. Using a Secure Shell to Access the User Interface .................................. 13
1.2.2. Using a Secure Shell to Transfer Files ..................................................... 13
1.3. The ROS® Web Server Interface ....................................................................... 14
1.3.1. Using a Web Browser to Access the Web Interface ................................. 14
1.3.2. Customizing the Log In Page ................................................................... 15
1.3.3. The Structure of the Web Interface .......................................................... 16
1.3.4. Making Configuration Changes ................................................................ 16
1.3.5. Updating Statistics Displays ..................................................................... 17
1.4. Administration Menu ............................................................................................ 17
1.5. IP Interfaces ........................................................................................................ 18
1.6. IP Gateways ........................................................................................................ 20
1.7. IP Services .......................................................................................................... 21
1.8. System Identification ........................................................................................... 22
1.9. Passwords ........................................................................................................... 23
1.10. System Time Management .............................................................................. 25
1.10.1. Configuring System Time ....................................................................... 26
1.10.1.1. Configuring Time and Date ........................................................ 26
1.10.1.2. Configuring NTP Service ............................................................ 28
1.11. SNMP Management .......................................................................................... 29
1.11.1. SNMP Users ........................................................................................... 29
1.12. RADIUS ............................................................................................................. 31
1.12.1. RADIUS overview ................................................................................... 32
1.12.2. User Login Authentication and Authorization .......................................... 32
1.12.3. Radius Server Configuration .................................................................. 33
1.13. TACACS+ .......................................................................................................... 34
1.13.1. User Login Authentication and Authorization .......................................... 35
1.13.2. TACACS+ Server Configuration ............................................................. 35
1.13.3. User Privilge Level Configuartion ........................................................... 37
1.13.4. TACACS+ Server Privilege Configuration .............................................. 37
1.14. Syslog ................................................................................................................ 37
ROS® v3.10 User Guide
3
RMC30
Rugged Operating System
1.14.1. Configuring Local Syslog ........................................................................
1.14.2. Configuring Remote Syslog Client ..........................................................
1.14.3. Configuring the Remote Syslog Server ..................................................
1.15. Troubleshooting .................................................................................................
2. Serial Protocols .............................................................................................................
2.1. Serial Protocols Overview ...................................................................................
2.1.1. Raw Socket protocol features ..................................................................
2.1.2. DNP over Raw Socket protocol features ..................................................
2.1.3. Preemptive Raw Socket protocol features ...............................................
2.1.4. Modbus protocol features .........................................................................
2.1.5. DNP protocol features ..............................................................................
2.1.6. Microlok protocol features ........................................................................
2.1.7. WIN protocol features ...............................................................................
2.1.8. TIN protocol features ................................................................................
2.1.9. TelnetComPort protocol features ..............................................................
2.2. Serial Protocols Operation ..................................................................................
2.2.1. Serial Encapsulation Applications .............................................................
2.2.1.1. Character Encapsulation (Raw Socket) .........................................
2.2.1.2. RTU Polling ...................................................................................
2.2.1.3. Broadcast RTU Polling ..................................................................
2.2.1.4. Preemptive Raw Socket ................................................................
2.2.1.5. Use of Port Redirectors .................................................................
2.2.1.6. Message Packetization ..................................................................
2.2.2. Modbus Server and Client Applications ....................................................
2.2.2.1. TCPModbus Performance Determinants .......................................
2.2.2.2. A Worked Example ........................................................................
2.2.2.3. Use of Turnaround Delay ..............................................................
2.2.3. DNP 3.0, Microlok, TIN and WIN Applications .........................................
2.2.3.1. The Concept of Links ....................................................................
2.2.3.2. Address Learning ...........................................................................
2.2.3.2.1. Address Learning for TIN ....................................................
2.2.3.2.2. Address Learning for DNP ..................................................
2.2.3.2.3. Broadcast Messages ...........................................................
2.2.3.3. Transport Protocols ........................................................................
2.2.3.3.1. Transport for Raw Socket ...................................................
2.2.3.3.2. Transport for Protocols with Defined Links ..........................
2.2.3.3.3. Use of Differentiated Services Code Point (DSCP) .............
2.2.4. Force Half-Duplex Mode of Operation ......................................................
2.3. Serial Protocol Configuration ...............................................................................
2.3.1. Serial Ports ...............................................................................................
2.3.2. Raw Socket .............................................................................................
2.3.3. Remote Hosts ...........................................................................................
2.3.4. Preemptive Raw Socket ...........................................................................
2.3.5. Modbus Server .........................................................................................
2.3.6. Modbus Client ...........................................................................................
2.3.7. WIN and TIN ............................................................................................
2.3.8. MicroLok ...................................................................................................
2.3.9. DNP ..........................................................................................................
2.3.10. DNP over Raw Socket ...........................................................................
ROS® v3.10 User Guide
4
38
39
39
41
42
42
42
42
43
43
43
43
43
43
43
44
44
44
44
45
46
47
47
48
48
50
50
50
51
51
51
52
53
53
53
54
54
54
55
56
58
61
62
64
65
66
68
69
70
RMC30
Rugged Operating System
2.3.11. Mirrored Bits ........................................................................................... 72
2.3.12. TelnetComPort ........................................................................................ 74
2.3.13. Device Addresses ................................................................................... 75
2.3.14. Dynamic Device Addresses .................................................................... 77
2.4. Serial Statistics .................................................................................................... 78
2.4.1. Link Statistics ........................................................................................... 78
2.4.2. Connection Statistics ................................................................................ 80
2.4.3. Serial Port Statistics ................................................................................. 81
2.4.4. Clearing Serial Port Statistics ................................................................... 82
2.4.5. Resetting Serial Ports ............................................................................... 82
2.5. Troubleshooting ................................................................................................... 82
3. Diagnostics ..................................................................................................................... 84
3.1. Using the Alarm System ..................................................................................... 84
3.1.1. Active Alarms ............................................................................................ 84
3.1.2. Passive Alarms ......................................................................................... 85
3.1.3. Alarms and the Critical Failure Relay ....................................................... 85
3.1.4. Configuring Alarms ................................................................................... 85
3.1.5. Viewing and Clearing Alarms ................................................................... 88
3.2. Viewing CPU Diagnostics ................................................................................... 89
3.3. Viewing and Clearing the System Log ................................................................ 89
3.4. Viewing Product Information ............................................................................... 90
3.5. Loading Factory Default Configuration ................................................................ 91
3.6. Resetting the Device ........................................................................................... 92
4. Using the CLI Shell ........................................................................................................ 93
4.1. Summary Of CLI Commands available in ROS® ................................................ 93
4.2. Obtaining Help For A Command ......................................................................... 93
4.3. Viewing Files ....................................................................................................... 93
4.3.1. Listing Files .............................................................................................. 94
4.3.2. Viewing and Clearing Log Files ................................................................ 94
4.4. Managing The Flash Filesystem ........................................................................ 94
4.4.1. Flash Filesystem Memory Mapping .......................................................... 95
4.4.2. Obtaining Information On A Particular File ............................................... 95
4.4.3. Defragmenting The Flash Filesystem ....................................................... 96
4.5. Pinging a Remote Device ................................................................................... 96
4.6. Tracing Events .................................................................................................... 96
4.6.1. Enabling Trace ......................................................................................... 97
4.6.2. Starting Trace ........................................................................................... 98
4.7. Viewing DHCP Learned Information ................................................................... 99
4.8. Executing Commands Remotely Through RSH .................................................. 99
4.9. Resetting the Device ........................................................................................... 99
5. Firmware Upgrade and Configuration Management .................................................... 100
5.1. Files Of Interest ................................................................................................. 100
5.2. File Transfer Mechanisms ................................................................................. 100
5.3. Console Sessions .............................................................................................. 100
5.4. Upgrading Firmware .......................................................................................... 100
5.4.1. Applying the Upgrade ............................................................................. 101
5.4.2. Security Considerations .......................................................................... 101
5.4.3. Upgrading Firmware Using XModem .................................................... 101
5.4.4. Upgrading Firmware Using the ROS TFTP Server ................................ 102
ROS® v3.10 User Guide
5
RMC30
Rugged Operating System
5.4.5. Upgrading Firmware Using the ROS® TFTP Client ..............................
5.4.6. Upgrading Firmware Using SFTP .........................................................
5.5. Updating Configuration ......................................................................................
5.6. Backing Up ROS System Files .........................................................................
5.6.1. Backing Up Files Using SFTP ................................................................
5.7. Using SQL Commands .....................................................................................
5.7.1. Getting Started .......................................................................................
5.7.2. Finding the Correct Table .......................................................................
5.7.3. Retrieving Information .............................................................................
5.7.4. Changing Values in a Table ...................................................................
5.7.5. Setting Default Values in a Table ...........................................................
5.7.6. Using RSH and SQL ..............................................................................
A. SNMP MIB Support .....................................................................................................
A.1. Standard MIBs ..................................................................................................
A.2. RuggedCom proprietary MIBs ..........................................................................
B. SNMP Trap Summary .................................................................................................
C. List of Objects Eligible for RMON Alarms ...................................................................
D. ModBus Management Support and Memory Map .......................................................
D.1. Modbus Memory Map .......................................................................................
D.1.1. Text ........................................................................................................
D.1.2. Cmd ........................................................................................................
D.1.3. Uint16 .....................................................................................................
D.1.4. Uint32 .....................................................................................................
D.1.5. PortCmd .................................................................................................
D.1.6. Alarm ......................................................................................................
D.1.7. PSStatusCmd .........................................................................................
D.1.8. TruthValue ..............................................................................................
E. Command Line Listing .................................................................................................
Index .................................................................................................................................
ROS® v3.10 User Guide
6
102
103
103
104
104
105
105
105
106
107
107
107
109
109
110
112
113
118
119
122
122
123
123
123
124
124
125
126
128
RMC30
Rugged Operating System
List of Figures
1.1. Main Menu With Screen Elements Identified ..............................................................
1.2. The ROS log in page ..................................................................................................
1.3. The ROS log in page with Custom login banner and empty banner.txt .......................
1.4. The ROS log in page with Custom Logo ....................................................................
1.5. Main Menu via Web Server Interface .........................................................................
1.6. Web Page Header Showing Alarms Link ....................................................................
1.7. Parameters Form Example .........................................................................................
1.8. Administration Menu ...................................................................................................
1.9. IP Interfaces Form ......................................................................................................
1.10. IP Gateways Form ....................................................................................................
1.11. IP Services Form ......................................................................................................
1.12. System Identification Form ........................................................................................
1.13. Passwords Form .......................................................................................................
1.14. System Time Manager Menu ....................................................................................
1.15. Time and Date Form .................................................................................................
1.16. NTP Server List ........................................................................................................
1.17. NTP Server Form ......................................................................................................
1.18. SNMP User Table .....................................................................................................
1.19. SNMP User Form .....................................................................................................
1.20. RADIUS Server Summary .........................................................................................
1.21. RADIUS Server Form ...............................................................................................
1.22. TACACS+ Server Summary .....................................................................................
1.23. TACACS+ Server Form ............................................................................................
1.24. TACACS+ Server Privilege Form ..............................................................................
1.25. Local Syslog Form ....................................................................................................
1.26. Remote Syslog Client Form ......................................................................................
1.27. Remote Syslog Server Table ....................................................................................
1.28. Remote Syslog Server Form ....................................................................................
1.29. Using A Router As A Gateway .................................................................................
2.1. Character Encapsulation .............................................................................................
2.2. RTU Polling .................................................................................................................
2.3. Broadcast RTU Polling ................................................................................................
2.4. Permanent and Dynamic Master Connection Support ................................................
2.5. Modbus Client and Server ..........................................................................................
2.6. Sources of Delay and Error in an End-to-End Exchange ............................................
2.7. Source/Destination Two-Way Communication ............................................................
2.8. Optical Loop Topology ................................................................................................
2.9. Serial Protocols Menu .................................................................................................
2.10. Serial Port Table .......................................................................................................
2.11. Serial Port Configuration Form .................................................................................
2.12. Raw Socket Table .....................................................................................................
2.13. Raw Socket Form .....................................................................................................
2.14. Remote Hosts Table .................................................................................................
2.15. Remote Hosts Form ..................................................................................................
2.16. Preemptive Raw Socket Table ..................................................................................
2.17. Preemptive Raw Socket Form ..................................................................................
ROS® v3.10 User Guide
7
12
14
15
15
16
16
17
18
19
20
21
22
24
26
26
28
28
30
30
33
34
35
36
37
38
39
39
40
41
44
44
45
46
48
49
51
54
55
56
56
58
59
61
61
62
62
RMC30
Rugged Operating System
2.18. Modbus Server Table ................................................................................................
2.19. Modbus Server Form ................................................................................................
2.20. Modbus Client Form ..................................................................................................
2.21. WIN and TIN Form ...................................................................................................
2.22. MicroLok Form ..........................................................................................................
2.23. DNP Form .................................................................................................................
2.24. DNP over Raw Socket Table ....................................................................................
2.25. DNP over Raw Socket Form ....................................................................................
2.26. Mirrored Bits Table ...................................................................................................
2.27. Mirrored Bits Form ....................................................................................................
2.28. TelnetComPort Form .................................................................................................
2.29. Device Address Table ...............................................................................................
2.30. Device Address Form ...............................................................................................
2.31. Dynamic Device Address Table ................................................................................
2.32. Dynamic Device Address Form ................................................................................
2.33. Link Statistics Table ..................................................................................................
2.34. Link Statistics Form ...................................................................................................
2.35. Connection Statistics Table .......................................................................................
2.36. Serial Port Statistics Table ........................................................................................
2.37. Clear Serial Port Statistics Form ...............................................................................
2.38. Reset Serial Port(s) Form .........................................................................................
3.1. Diagnostics Menu ........................................................................................................
3.2. Alarm Configuration Table ..........................................................................................
3.3. Alarm Configuration Form ...........................................................................................
3.4. Alarm Table .................................................................................................................
3.5. CPU Diagnostics Form ...............................................................................................
3.6. Viewing the System Log .............................................................................................
3.7. Product Information Form ...........................................................................................
3.8. Load Factory Defaults Dialog .....................................................................................
3.9. Reset Device Dialog ...................................................................................................
4.1. Displaying Help For A Command ...............................................................................
4.2. Displaying The Directory Of A ROS Device ...............................................................
4.3. Flashfiles command summary ....................................................................................
4.4. Flashfile Memory Mapping Summary ..........................................................................
4.5. Obtaining Information About "main.bin" ......................................................................
4.6. Displaying Trace Settings ...........................................................................................
4.7. Enabling Trace ............................................................................................................
4.8. Starting Trace .............................................................................................................
ROS® v3.10 User Guide
8
64
64
65
66
68
69
70
70
72
72
74
76
76
77
78
79
79
80
81
82
82
84
86
87
88
89
90
90
92
92
93
94
95
95
96
97
98
98
RMC30
Preface
Preface
This manual contains instructions, examples, guidelines, and general theory on how to use
the Rugged Operating System (ROS®) management software.
Supported Platforms
ROS is designed to work on many RuggedCom product hardware platforms, ensuring a
consistent user experience when migrating from one product model to another. ROS supports
the following RuggedCom products:
•
•
•
•
•
•
•
•
•
•
•
•
•
RuggedSwitch® i800, i801, i802, and i803
RuggedSwitch® RS8000 and RS1600
RuggedSwitch® RS900/RS930 with both ‘L’ (EoVDSL) and ‘W’ (WLAN) port variants
RuggedSwitch® RS900GP
RuggedSwitch® RS900G/RS940G with Gigabit
RuggedSwitch® RS950
RuggedSwitch® RS969/M969 waterproof with Gigabit
RuggedSwitch® RSG2100/M2100, RSG2200/M2200, and RSG2300 modular switches with
Gigabit Ethernet
RuggedSwitch® RSG2288 modular switch with Gigabit Ethernet, PTP (Precision Time
Protocol - IEEE 1588), GPS, and IRIG-B support
RuggedServer™ RS416, RS910 and RS920 modular serial servers
RuggedServer™ RS416v2 modular serial server with PTP and IRIG-B support
RuggedServer™ RS400
RuggedMC™ Media Converters RMC30 and RP110
Each product model has a subset of the entire ROS feature set. This manual is intended for
use with the RMC30 product family and has been streamlined to only describe the relevant
features.
Who Should Use This User Guide
This guide is to be used by network technical support personnel who are familiar with the
operation of networks. Others who might find the book useful are network and system planners,
system programmers and line technicians.
How Chapters are organized
The index of this guide has been prepared with:
• Entries to each of the “Features” sections of the manual
• Entries to each of the “Troubleshooting” sections of the manual (located at the end of each
chapter)
• Entries to each of the Menus, organized by name
Document Conventions
This publication uses the following conventions:
ROS® v3.10 User Guide
9
RMC30
Preface
Means reader take note. Notes contain helpful suggestions or references to
materials not contained in this guide.
It is recommended that you use this guide along with the following applicable documents:
•
•
•
•
RMC30 Family Installation Guide
RuggedCom Fiber Guide
RuggedCom Wireless Guide
White paper: Rapid Spanning Tree in Industrial Networks
Applicable Firmware Revision
This guide is applicable to ROS software revisions v3.9.0.
Firmware/User Guide Version Numbering System
ROS has a three-digit version numbering system of the form X.Y.Z where each digit is a
number starting from zero. The 'X.Y' digits represent the functional version of ROS whereas the
'Z' digit represents firmware patches. The 'X' digit is incremented for major functional updates
of the product. The 'Y' digit is incremented for minor functional updates of the product. The 'Z'
digit is incremented for bug fixes, cosmetic enhancements and other minor issues.
User guides follow the same format. In general, a user guide will have the same 'X.Y' digits
as the firmware to which it corresponds.
It is RuggedCom's policy to provide Web access to only the latest 'patch' release for a version
of firmware. If you decide that an upgrade is merited, then getting all the fixes only makes
sense. It is for this reason that release notes are created detailing all patches for a given
functional version.
ROS® v3.10 User Guide
10
RMC30
1. Administration
1. Administration
The Administration menu covers the configuration of administrative parameters of both device
and network (local services availability, security methods employed, system identification and
functionality related to the IP network):
•
•
•
•
•
•
•
•
•
•
IP Address, Subnet Mask and Gateway Address (static or dynamically obtainable)
Management VLAN
Management Connection Inactivity Timeout
TFTP Server Permissions
System Identification
Passwords
Time-keeping
SNMP Management
Radius Server
Remote Syslog
1.1. The ROS® User Interface
1.1.1. Using the RS232 Port to Access the User Interface
Attach a terminal (or PC running terminal emulation software) to the RS232 port. The terminal
should be configured for 8 bits, no parity operation at 57.6 Kbps. Hardware and software flow
control must be disabled. Select a terminal type of VT100.
Once the terminal is connected, restart the unit and press and hold <Ctrl-Z>. The following
will be printed:
“Console mode…
Type 'yes' if you want to enter console mode: “
After typing ‘yes’ , pressing any key on the keyboard will prompt for the user name and
password to be entered.
The switch is shipped with a default administrator user name - “admin” - and password “admin”. Once successfully logged in, the user will be presented with the main menu.
1.1.2. The Structure of the User Interface
The user interface is organized as a series of menus with an escape to a command line
interface (CLI) shell. Each menu screen presents the switch name (as provided by the
System Identification parameter), Menu Title, Access Level, Alarms indicator, Sub-Menus and
Command Bar.
Sub-menus are entered by selecting the desired menu with the arrow keys and pressing the
enter key. Pressing the escape key returns you to the parent menu.
ROS® v3.10 User Guide
11
RMC30
1. Administration
Figure 1.1. Main Menu With Screen Elements Identified
The command bar offers a list of commands that apply to the currently displayed menu. These
commands include:
• <Ctrl-Z> to display help on the current command or data item
• <Ctrl-S> to switch to the CLI shell
• <Ctrl-Up/Down> to jump to next/previous page of a status display
The main menu also provides a <Ctrl-X> command, which will terminate the session. This type
of menu is accessible via serial console, telnet session and SSH session.
1.1.3. Making Configuration Changes
When changing a data item, the user selects the data item by the cursor keys and then pressing
the enter key. The cursor will change position to allow editing of the data item.
Typing a new value after pressing enter always erases the old parameter value. The left and
right cursor keys can be used to position the edit point without erasing the old parameter value.
The up and down cursor keys can be used to cycle through the next higher and lower values
for the parameter.
After the parameter has been edited, press enter again to change other parameters. When
all desired parameters have been modified, press <Ctrl-A> to apply changes. The switch will
automatically prompt you to save changes when you leave a menu in which changes have
been made.
Some menus will require you to press <Ctrl-I> to insert a new record of information and <CtrlL> to delete a record.
ROS® v3.10 User Guide
12
RMC30
1. Administration
1.1.4. Updates Occur In Real Time
All configuration and display menus present the current values, automatically updating if
changed from other user interface sessions or SNMP. All statistics menus will display changes
to statistics as they occur.
1.1.5. Alarm Indications Are Provided
Alarms are events for which the user is notified through the Diagnostics sub-menu. All
configuration and display menus present an indication of the number of alarms (in the upper
right hand corner of the screen) as they occur, automatically updating as alarms are posted
and cleared.
1.1.6. The CLI Shell
The user interface provides a Command Line Interface shell for operations that are more easily
performed at the command line. You may switch back and forth from the menu system and
shell by pressing <Ctrl-S>. For more information on the capabilities of the shell please refer
to Chapter 4, Using the CLI Shell.
1.2. The ROS® Secure Shell Server
1.2.1. Using a Secure Shell to Access the User Interface
SSH (Secure Shell) is a network protocol which provides a replacement for insecure remote
login and command execution facilities, such as telnet and remote shell. SSH encrypts traffic
in both directions, preventing traffic sniffing and password theft.
SSH protocol version 2 is implemented in ROS. The authentication method is "keyboardinteractive" password authentication. A user logged in via SSH has the same privileges as
one logged in via the console port.
1.2.2. Using a Secure Shell to Transfer Files
ROS implements an SFTP server via SSH to transfer files securely. The file system visible
on the RuggedSwitch® has a single directory. The files in it are created at startup time and
can be neither deleted nor renamed. Existing files can be downloaded from the switch. For
example, firmware images may be downloaded for backup and log files may be downloaded
for analysis. Some files may be overwritten by uploading a file of the same name to the switch,
as would be done in order to upgrade the firmware.
The implemented commands are:
dir/ls
list directory contents
get
download a file from the switch
put
upload a file to the switch
The files that may be overwritten via SFTP upload are:
main.bin
main ROS firmware image
ROS® v3.10 User Guide
13
RMC30
1. Administration
boot.bin
RuggedSwitch bootloader image
config.csv
ROS configuration file
fpga.xsvf
FPGA configuration file
1.3. The ROS® Web Server Interface
1.3.1. Using a Web Browser to Access the Web Interface
A web browser uses a secure communications method called SSL (Secure Socket Layer) to
encrypt traffic exchanged with its clients. The web server guarantees that communications
with the client are kept private. If the client requests access via an insecure HTTP port, it will
be rerouted to the secure port. Access to the web server via SSL will be granted to a client
that provides a valid user name / password pair.
It can happen that upon connecting to the ROS web server, a web browser may
report that it cannot verify the authenticity of the server's certificate against any
of its known certificate authorities. This is expected, and it is safe to instruct the
browser to accept the certificate. Once the browser accepts the certificate, all
communications with the web server will be secure.
Start a web browser session and open a connection to the switch by entering a URL that
specifies its host name or IP address. For example, in order to access the unit at its factory
default IP address, enter http://192.168.0.1. Once in contact with the switch, start the login
process by clicking on the "Login" link. The resulting page should be similar to that presented
below:
Figure 1.2. The ROS log in page
ROS® v3.10 User Guide
14
RMC30
1. Administration
Enter the “admin” user name and the password for the admin user, and then click the
“LogIn” button. The switch is shipped with a default administrator password of “admin”. After
successfully logging in, the main menu appears.
1.3.2. Customizing the Log In Page
To hide the device information on the log in page, set the ‘Login Banner’ option in the System
Identification menu to ‘Custom’. Add the information to be displayed on the log in page to the
“banner.txt” file. If the “banner.txt” file is empty, the log in page appears as shown here:
Figure 1.3. The ROS log in page with Custom login banner and empty banner.txt
To add a custom logo to the log in page, upload a new logo file to the device. The logo file
must meet the following requirements:
• The image must be a GIF file.
• The file must be no larger than 32 KB in size.
• The file must be named logo.gif.
For more information, see Section 5.1, “Files Of Interest”.
When using a custom logo file, the RuggedCom logo and banner at the top of the page does
not appear:
Figure 1.4. The ROS log in page with Custom Logo
ROS® v3.10 User Guide
15
RMC30
1. Administration
1.3.3. The Structure of the Web Interface
The user interface is organized as a series of linked web pages. The main menu provides the
links at the top level of the menu hierarchy and allows them to be expanded to display lowerlevel links for each configuration subsystem.
Figure 1.5. Main Menu via Web Server Interface
Every web page in the menu system has a common header section which contains:
• The System Name, as configured in the System Identification menu, is displayed in the top
banner, in between elements of the RuggedCom logo.
• A "Log out" link at left and immediately below the banner, terminates the current web
session.
• A "Back" link at left and below "Log out" links back to the previously viewed page.
• The menu title, in the center of the page and below the banner, is a link to a context-sensitive
help page.
• The access level, e.g. "access admin", is displayed by default at the right of the page and
below the banner. If, however, any alarms are pending, the text will be replaced with a link
which displays the number of pending alarms. Following this link displays a table of pending
alarms.
Figure 1.6. Web Page Header Showing Alarms Link
1.3.4. Making Configuration Changes
When changing a data item, the user selects the data item by selecting the field to edit with
the mouse, entering a new value and clicking on the apply field. More than one parameter
may be modified at a time.
ROS® v3.10 User Guide
16
RMC30
1. Administration
Figure 1.7. Parameters Form Example
Some menus will require you to create or delete new records of information.
1.3.5. Updating Statistics Displays
You may click the refresh button to update statistics displays.
1.4. Administration Menu
The Administration menu provides ability to configure network and switch administration
parameters.
ROS® v3.10 User Guide
17
RMC30
1. Administration
Figure 1.8. Administration Menu
1.5. IP Interfaces
These parameters provide the ability to configure IP connection parameters, such as address,
network, and mask. Only one IP interface can be configured.
You can choose from the following IP Address types: Static, DHCP, BOOTP, and Dynamic.
The Static IP Address type refers to the manual assignment of an IP address. The DHCP,
BOOTP, and Dynamic IP Address types refer to the automatic assignment of an IP address.
DHCP is widely used in LAN environments to dynamically assign IP addresses from a
centralized server, which reduces the overhead of administrating IP addresses.
BOOTP is a subset of the DHCP protocol. ROS supports the transfer of a BOOTFILE via
BOOTP. The BOOTFILE represents any valid ROS file, such as config.csv. The name of the
BOOTFILE on the BOOTP server must match the corresponding ROS file.
The Dynamic IP Address type refers to a combination of the BOOTP and DHCP protocols.
Starting with BOOTP, the system tries BOOTP and DHCP in a round-robin fashion until it
receives a response from the corresponding server.
On non-management interfaces, only static IP addresses can be assigned.
On the management interface, the user can choose from the following IP Address types:
Static, DHCP, BOOTP and Dynamic. Static IP Address type refers to the manual assignment
of an IP address while DHCP, BOOTP and Dynamic IP Address types refer to the automatic
assignment of an IP address.
DHCP is widely used in LAN environments to dynamically assign IP addresses from a
centralized server, which reduces the overhead of administrating IP addresses.
BOOTP is a subset of the DHCP protocol. ROS supports the transfer of a BOOTFILE via
BOOTP. The BOOTFILE represents any valid ROS file such as config.csv. The name of
BOOTFILE on the BOOTP server must match the corresponding ROS file.
ROS® v3.10 User Guide
18
RMC30
1. Administration
The Dynamic IP Address type refers to a combination of the BOOTP and DHCP protocols.
Starting with BOOTP, the system will try BOOTP and DHCP in a round-robin fashion until it
receives a response from the corresponding server.
Figure 1.9. IP Interfaces Form
You can use the ROS web interface to change the IP Address Type of the
management interface from Static to DHCP. However, after doing so, you cannot
use the web interface to change the IP Address Type back to Static and set an IP
address. If you need to change the IP Address Type of the management interface
from DHCP to Static, configure the setting through a telnet, SSH, RSH, or serial
port connection, or upload a new configuration file to the device.
IP Address Type
Synopsis: { Static, Dynamic, DHCP, BOOTP }
Default: Static
Specifies whether the IP address is static or is dynamically assigned via DHCP or BOOTP.
The Dynamic option automatically switches between BOOTP and DHCP until it receives
a response from the relevant server. The Static option must be used for non-management
interfaces.
IP Address
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Default: 192.168.0.1
Specifies the IP address of this device. An IP address is a 32-bit number that is notated by
using four numbers from 0 through 255, separated by periods. Only a unicast IP address
is allowed, which ranges from 1.0.0.0 to 233.255.255.255.
Subnet
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Default: 255.255.255.0
ROS® v3.10 User Guide
19
RMC30
1. Administration
Specifies the IP subnet mask of this device. An IP subnet mask is a 32-bit number that is
notated by using four numbers from 0 through 255, separated by periods. Typically, subnet
mask numbers use either 0 or 255 as values (e.g. 255.255.255.0) but other numbers can
appear.
1.6. IP Gateways
These parameters provide the ability to configure gateways. A maximum of 10 gateways can
be configured. When both the Destination and Subnet fields are both 0.0.0.0 (displayed as
blank space), the gateway is a default gateway.
Figure 1.10. IP Gateways Form
Destination
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Default: 0.0.0.0
Specifies the IP address of the destination device. An IP address is a 32-bit number that
is notated by using four numbers from 0 through 255, separated by periods.
Subnet
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Default: 0.0.0.0
Specifies the IP subnet mask of the destination. An IP subnet mask is a 32-bit number
that is notated by using four numbers from 0 through 255, separated by periods. Typically,
subnet mask numbers use either 0 or 255 as values (e.g. 255.255.255.0) but other
numbers can appear.
Gateway
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Default: 0.0.0.0
Specifies the gateway IP address. The gateway address must be on the same IP subnet
as this device.
The default gateway configuration will not be changed when resetting all
configuration parameters to defaults.
ROS® v3.10 User Guide
20
RMC30
1. Administration
1.7. IP Services
These parameters provide the ability to configure properties for IP services provided by the
device.
Figure 1.11. IP Services Form
Inactivity Timeout
Synopsis: 1 to 60 or { Disabled }
Default: 5 min
Specifies when the console will timeout and display the login screen if there is no user
activity. A value of zero disables timeouts for console and Telnet users. For Web Server
users maximum timeout value is limited to 30 minutes.
Telnet Sessions Allowed
Synopsis: 0 to 4
Default: 4
Limits the number of Telnet sessions. A value of zero prevents any Telnet access.
Web Server Users Allowed
Synopsis: 1 to 16
Default: 16
Limits the number of simultaneous web server users.
TFTP Server
Synopsis: { Disabled, Get Only, Enabled }
Default: Get Only
As TFTP is a very insecure protocol, this parameter allows the user to limit or disable TFTP
Server access.
ROS® v3.10 User Guide
21
RMC30
1. Administration
DISABLED - disables read and write access to TFTP Server
GET ONLY - only allows reading of files via TFTP Server
ENABLED - allows reading and writing of files via TFTP Server
ModBus Address
Synopsis: 1 to 254 or { Disabled }
Default: Disabled
Determines the Modbus address to be used for Management through Modbus.
SSH Sessions Allowed
Synopsis: 1 to 4
Default: 4
Limits the number of SSH sessions.
RSH Server
Synopsis: { Disabled, Enabled }
Default: Enabled
Disables/enables Remote Shell access.
1.8. System Identification
The system identification is displayed in the sign-on screen and in the upper left hand corner
of all ROS screens.
Figure 1.12. System Identification Form
System Name
Synopsis: Any 19 characters
Default: System Name
The system name is displayed in all ROS menu screens. This can make it easier to identify
the switches within your network, provided that all switches are given a unique name.
Location
Synopsis: Any 49 characters
ROS® v3.10 User Guide
22
RMC30
1. Administration
Default: Location
The location can be used to indicate the physical location of the switch. It is displayed in
the login screen as another means to ensure you are dealing with the desired switch.
Contact
Synopsis: Any 49 characters
Default: Contact
The contact can be used to help identify the person responsible for managing the switch.
You can enter name, phone number, email, etc. It is displayed in the login screen so that
this person may be contacted, should help be required.
Login Banner
Synopsis: { Standard, Custom }
Default: Standard
Provides the ability to customize the banner displayed on the login screen. Either the
standard RuggedCom ROS banner may be displayed or, if "Custom" is selected, the
contents of a file named "banner.txt", uploaded to the device, will be used as a login banner.
1.9. Passwords
These parameters provide the ability to configure parameters for authorized and authenticated
access to the device's services (HMI via Serial Console, Telnet, SSH, RSH, Web Server).
Access to the switch can be authorized and authenticated via RADIUS or TACACS+ servers,
or using locally configured passwords that are configured per user name and access level.
Note that access via the Serial Console is always authorized first using local settings. If a
local match is not found, RADIUS/TACACS+ will be used if enabled. For all other services,
if RADIUS/TACACS+ is enabled for authentication and authorization, the local setting will be
used only if configured.
To access the unit, the user name and password must be provided.
Three user names and passwords can be configured. They correspond to three access levels,
which provide or restrict access to change settings and execute various commands within the
device.
• guest users can view most settings, but may not change settings or run commands.
• operator cannot change settings, but can reset alarms, clear statistics and logs.
• admin user can change all the settings and run commands.
ROS® v3.10 User Guide
23
RMC30
1. Administration
Figure 1.13. Passwords Form
Auth Type
Synopsis: { Local, RADIUS, TACACS+, RADIUSorLocal, TACACS
+orLocal }
Default: Local
Password authentication can be performed using locally configured values, a remote
RADIUS server, or a remote TACACS+ server. Setting this value to one of the
combinations that includes RADIUS or TACACS+ requires that the Security Server Table
be configured.
• Local - authentication from the local Password Table
• RADIUS - authentication using a RADIUS server
• TACACS+ - authentication using a TACACS+ server
• RADIUSOrLocal - authentication using RADIUS. If the server cannot be reached,
authenticate from the local Password Table.
• TACACS+OrLocal - authentication using TACACS+. If the server cannot be reached,
authenticate from the local Password Table
Guest Username
Synopsis: 15 character ASCII string
Default: guest
Related password is in the Guest Password field; view only, cannot change settings or
run any commands.
ROS® v3.10 User Guide
24
RMC30
1. Administration
Guest Password
Synopsis: 15 character ASCII string
Default: guest
Related user name is in the Guest Username field; view only, cannot change settings or
run any commands.
Confirm Guest Password
Synopsis: 15 character ASCII string
Default: None
Confirm the input of the above Guest Password.
Operator Username
Synopsis: 15 character ASCII string
Default: operator
Related password is in the Oper Password field; cannot change settings; can reset alarms,
statistics, logs, etc.
Operator Password
Synopsis: 15 character ASCII string
Default: operator
Related user name is in the Oper Username field; cannot change settings; can reset
alarms, statistics, logs, etc.
Confirm Operator Password
Synopsis: 15 character ASCII string
Default: None
Confirm the input of the above Operator Password.
Admin Username
Synopsis: 15 character ASCII string
Default: admin
Related password is in the Admin Password field; full read/write access to all settings and
commands.
Admin Password
Synopsis: 15 character ASCII string
Default: admin
Related user name is in the Admin Username field; full read/write access to all settings
and commands.
Confirm Admin Password
Synopsis: 15 character ASCII string
Default: None
Confirm the input of the above Admin Password.
1.10. System Time Management
ROS running on the RMC30 offers the following time-keeping and time synchronization
features:
• Local hardware time keeping and time zone management
ROS® v3.10 User Guide
25
RMC30
1. Administration
• SNTP time synchronization
1.10.1. Configuring System Time
The System Time Manager option within the ROS Administration menu fully configures time
keeping functions on a ROS-based device:
Figure 1.14. System Time Manager Menu
1.10.1.1. Configuring Time and Date
This menu configures the current time, date, time zone, and DST (Daylight Savings Time)
settings.
Figure 1.15. Time and Date Form
Time
Synopsis: HH:MM:SS
This parameter enables both the viewing and setting of the local time.
Date
Synopsis: MMM DD, YYYY
This parameter enables both the viewing and setting of the local date.
Time Zone
Synopsis: {
ROS® v3.10 User Guide
26
RMC30
1. Administration
UTC-12:00 (Eniwetok, Kwajalein), UTC-11:00 (Midway Island,
Samoa),
UTC-10:00 (Hawaii), UTC-9:00 (Alaska), UTC-8:00 (Los Angeles,
Vancouver),
UTC-7:00 (Calgary, Denver), UTC-6:00 (Chicago, Mexico City),
UTC-5:00 (New York, Toronto), UTC-4:00 (Caracas, Santiago),
UTC-3:30 (Newfoundland), UTC-3:00 (Brasilia, Buenos Aires),
UTC-2:00 (Mid Atlantic), UTC-1:00 (Azores),
UTC-0:00 (Lisbon, London), UTC+1:00 (Berlin, Paris, Rome),
UTC+2:00 (Athens, Cairo, Helsinki), UTC+3:00 (Baghdad, Moscow),
UTC+3:30 (Teheran), UTC+4:00 (Abu Dhabi, Kazan, Muscat),
UTC+4:30 (Kabul), UTC+5:00 (Islamabad, Karachi),
UTC+5:30 (Calcutta, New Delhi), UTC+5:45 (Kathmandu),
UTC+6:00 (Almaty, Dhaka), UTC+6:30 (Rangoon),
UTC+7:00 (Bangkok, Hanoi), UTC+8:00 (Beijing, Hong Kong)
UTC+9:00 (Seoul, Tokyo), UTC+9:30 (Adelaide, Darwin),
UTC+10:00 (Melbourne, Sydney), UTC+11:00 (Magadan, New
Caledonia),
UTC+12:00 (Auckland, Fiji) }
Default: UTC-0:00 (Lisbon, London)
This setting enables the conversion of UTC (Universal Coordinated Time) to local time.
DST Offset
Synopsis: HH:MM:SS
Default:00:00:00
This parameter specifies the amount of time to be shifted forward/backward when DST
begins and ends. For example, for most of the USA and Canada, DST time shift is 1 hour
(01:00:00) forward when DST begins and 1 hour backward when DST ends.
DST Rule
Synopsis: mm.n.d/HH:MM:SS mm.n.d/HH:MM:SS
Default:
This parameter specifies a rule for time and date when the transition between Standard
and Daylight Saving Time occurs.
• mm - Month of the year (01 - January, 12 - December)
• n - week of the month (1 - 1st week, 5 - 5th/last week)
• d - day of the week (0 - Sunday, 6 - Saturday)
• HH - hour of the day (0 - 24)
• MM - minute of the hour (0 - 59)
• SS - second of the minute (0 - 59)
Example: The following rule applies in most of the USA and Canada:
03.2.0/02:00:00 11.1.0/02:00:00
In the example, DST begins on the second Sunday in March at 2:00am, and ends on the
first Sunday in November at 2:00am.
Current UTC Offset
Synopsis: 0 s to 1000 s
ROS® v3.10 User Guide
27
RMC30
1. Administration
Default: 34 s
Coordinated Universal Time (UTC) is a time standard based on International Atomic
Time (TAI) with leap seconds added at irregular intervals to compensate for the Earth’s
slowing rotation. The Current UTC Offset parameter allows the user to adjust the difference
between UTC and TAI. The International Earth Rotation and Reference System Service
(IERS) observes the Earth’s rotation and nearly six months in advance (January and July)
a Bulletin-C message is sent out, which reports whether or not to add a leap second in
the end of June and December.
Please note that change in the Current UTC Offset parameter will result in a temporary
disruption in the timing network.
1.10.1.2. Configuring NTP Service
ROS may optionally be configured to refer periodically to a specified NTP server to correct
any accumulated drift in the on-board clock. ROS will also serve time via SNTP to hosts that
request it.
Two NTP servers (primary and secondary) may be configured for the device. The primary
server is contacted first upon each attempt to update the system time. If the primary server
fails to respond, the secondary server is contacted. If either the primary or secondary server
fails to respond, an alarm is raised.
Figure 1.16. NTP Server List
Figure 1.17. NTP Server Form
Server
Synopsis: Primary, Secondary
This field displays the chosen NTP server. The remaining fields on this form correspond
to the chosen server.
IP Address
Synopsis: ###.###.###.### where ### ranges from 0 to 255
ROS® v3.10 User Guide
28
RMC30
1. Administration
Default:
This parameter specifies the IP address of an (S)NTP server ((Simple) Network Time
Protocol); programming an address of '0.0.0.0' disables SNTP requests. This device is an
SNTP client which may connect to only one server. If a server address is programmed
then a manual setting of the time will be overwritten at the next update period.
Update Period
Synopsis: 1 to 1440
Default: 60 min
This setting determines how frequently the (S)NTP server is polled for a time update. If the
server cannot be reached, three attempts are made at one-minute intervals and then an
alarm is generated, at which point the programmed rate is resumed.
1.11. SNMP Management
ROS supports Simple Network Management Protocol Versions 1 (SNMPv1), 2 (SNMPv2c),
and 3 (SNMPv3). SNMPv3 protocol provides secure access to devices by a combination of
authentication and packet encryption over the network. SNMPv3 security features include the
following:
• message integrity – ensures that a packet has not been tampered with in-transit.
• authentication – determines the message is from a valid source.
• encryption – scrambles the contents of a packet to prevent it from being seen by an
unauthorized source.
SNMPv3 provides security models and security levels. A security model is an authentication
strategy that is set up for a user and the group in which the user resides. A security level is
a permitted level of security within a security model. A combination of a security model and
security level will determine which security mechanism is employed when handling an SNMP
packet.
Note the following about the SNMPv3 protocol:
a group also defines the security model and security level for its users.
• each user belongs to a group.
• a group defines the access policy for a set of users.
• an access policy defines what SNMP objects can be accessed for: reading, writing and
creating notifications.
• a group determines the list of notifications its users can receive.
Community is configured for protocols v1 and v2c. Community is mapped to the group and
access level with security name (which is configured as User name).
1.11.1. SNMP Users
These parameters provide the ability to configure users for the local SNMPv3 engine, along
with the community for SNMPv1 and SNMPv2c. Note that when employing the SNMPv1 or
SNMPv2c security level, the User Name maps the community name with the security group
and access level. Up to 32 entries can be configured.
ROS® v3.10 User Guide
29
RMC30
1. Administration
Figure 1.18. SNMP User Table
Figure 1.19. SNMP User Form
Name
Synopsis: Any 32 characters
Default: initial
The name of the user. This user name also represents the security name that maps this
user to the security group.
IP Address
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Default:
The IP address of the user's SNMP management station. If IP address is configured, SNMP
requests from that user will be verified by IP address as well. SNMP Authentication trap
will be generated to trap receivers if request was received from this user, but from any
other IP address. If IP address is empty, traps can not be generated to this user, but SNMP
requests will be served for this user from any IP address.
ROS® v3.10 User Guide
30
RMC30
1. Administration
v1/v2c Community
Synopsis: Any 32 characters
Default:
The community string which is mapped by this user/security name to the security group if
security model is SNMPv1 or SNMPv2c. If this string is left empty, it will be assumed to
be equal to the same as user name.
Auth Protocol
Synopsis: { noAuth, HMACMD5 }
Default: noAuth
An indication of whether messages sent on behalf of this user to/from SNMP engine, can
be authenticated, and if so, the type of authentication protocol which is used.
Priv Protocol
Synopsis: { noPriv, CBC-DES }
Default: noPriv
An indication of whether messages sent on behalf of this user to/from SNMP engine can
be protected from disclosure, and if so, the type of privacy protocol which is used.
Auth Key
Synopsis: 31 character ASCII string
Default:
The secret authentication key (password) that must be shared with SNMP client. Ifthe key
is not an emtpy string, it must be at least 6 characters long.
Confirm Auth Key
Synopsis: 31 character ASCII string
Default:
The secret authentication key (password) that must be shared with SNMP client. Ifthe key
is not an emtpy string, it must be at least 6 characters long.
Priv Key
Synopsis: 31 character ASCII string
Default:
The secret encription key (password) that must be shared with SNMP client. Ifthe ke is not
an emtpy string, it must be at least 6 characters long.
Priv Key
Synopsis: 31 character ASCII string
Default:
The secret encription key (password) that must be shared with SNMP client. Ifthe ke is not
an emtpy string, it must be at least 6 characters long.
1.12. RADIUS
RADIUS (Remote Authentication Dial In User Service) is used to provide centralized
authentication and authorization for network access. ROS assigns a privilege level of Admin,
Operator or Guest to a user who presents a valid user name and password. The number of
users who can access the ROS server is ordinarily dependent on the number of user records
which can be configured on the server itself. ROS can also, however, be configured to pass
along the credentials provided by the user to be remotely authenticated by a RADIUS server. In
this way, a single RADIUS server can centrally store user data and provide authentication and
authorization service to multiple ROS servers needing to authenticate connection attempts.
ROS® v3.10 User Guide
31
RMC30
1. Administration
1.12.1. RADIUS overview
RADIUS (described in RFC 2865 [http://tools.ietf.org/html/rfc2865]) is a UDP-based protocol
used for carrying authentication, authorization, and configuration information between a
Network Access Server which desires to authenticate its links and a shared Authentication
Server.
A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of
authentication servers.
Unlike TACACS+, authorization and authentication functionality is supported by RADIUS in
the same packet frame. TACACS+ actually separates authentication from authorization into
separate packets.
On receiving an authentication-authorization request from a client in an “Access-Request”
packet, the RADIUS server checks the conditions configured for received username-password
combination in the user database. If all the conditions are met, the list of configuration values
for the user is placed into an “Access-Accept” packet. These values include the type of service
(e.g. SLIP, PPP, Login User) and all the necessary values to deliver the desired service.
1.12.2. User Login Authentication and Authorization
A RADIUS server can be used to authenticate and authorize access to the device’s services,
such as HMI via Serial Console, Telnet, SSH, RSH, Web Server (see Password Configuration).
ROS implements a RADIUS client which uses the Password Authentication Protocol (PAP) to
verify access. Attributes sent to a RADIUS server are:
•
•
•
•
user name
user password
service type: Login
vendor specific, currently defined as the following:
vendor ID: RuggedCom Inc. enterprise number (15004) assigned by the Internet Assigned
Numbers Authority (IANA)
string, sub-attribute containing specific values:
subtype: 1 (vendor’s name subtype)
length: 11 (total length of sub-attribute of subtype 1)
ASCII string “RuggedCom”
Two RADIUS servers (Primary and Secondary) are configurable per device. If the Primary
Server is not reachable, the device will automatically fall back to the Secondary server to
complete the authorization process.
The vendor specific attribute is used to determine the access level from the server, which may
be configured at the RADIUS server with the following information:
• Vendor ID: RuggedCom Inc. enterprise number (15004) assigned by Internet Assigned
Numbers Authority (IANA)
• Sub-attribute Format: String
• Vendor Assigned Sub-Attribute Number: 2
• Attribute value – any one of: admin, operator, guest
ROS® v3.10 User Guide
32
RMC30
1. Administration
If no access level is received in the response packet from the server then no access
will be granted to the user
An Example of a RuggedCom Dictionary for a FreeRADIUS server:
VENDOR
RuggedCom 15004
BEGIN-VENDOR
RuggedCom
ATTRIBUTE
RuggedCom-Privilege-level 2 string
END-VENDOR
RuggedCom
Sample entry for user “admin” Adding Users:
admin Auth-Type := Local, User-Password == "admin"
RuggedCom-Privilege-level = "admin
1.12.3. Radius Server Configuration
Figure 1.20. RADIUS Server Summary
ROS® v3.10 User Guide
33
RMC30
1. Administration
Figure 1.21. RADIUS Server Form
Server
Synopsis: Any 8 characters
Default: Primary
This field tells whether this configuration is for a primary or a backup server
IP Address
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Default:
The RADIUS server IP Address.
Auth UDP Port
Synopsis: 1 to 65535
Default: 1812
The authentication UDP Port on the RADIUS server.
Auth Key
Synopsis: 31 character ASCII string
Default: None
The authentication key shared with the RADIUS server. It is used to encrypt any passwords
that are sent between the switch and the RADIUS server.
Confirm Auth Key
Synopsis: 31 character ASCII string
Default: None
Confirm input of the above authentication key.
1.13. TACACS+
TACACS+ (Terminal Access Controller Access-Control System Plus) is a TCP-based access
control protocol that provides authentication, authorization and accounting services to routers,
ROS® v3.10 User Guide
34
RMC30
1. Administration
network access servers and other networked computing devices via one or more centralized
servers. It is based on, but is not compatible with, the older TACACS protocol. TACACS+
has generally replaced its predecessor in more recently built or updated networks, although
TACACS and XTACACS are still used on many older networks. Note that RuggedCom’s
TACACS+ client implementation always has encryption enabled.
1.13.1. User Login Authentication and Authorization
A TACACS+ server can be used to authenticate and authorize access to the device’s services,
such as HMI via Serial Console, Telnet, SSH, RSH, Web Server (see Password Configuration).
User name and Password are sent to the configured TACACS+ Server.
Two TACACS+ servers (Primary and Secondary) are configurable per device. If the primary
server is not reachable, the device will automatically fall back to the secondary server to
complete the authorization process.
1.13.2. TACACS+ Server Configuration
Figure 1.22. TACACS+ Server Summary
ROS® v3.10 User Guide
35
RMC30
1. Administration
Figure 1.23. TACACS+ Server Form
Server
Synopsis: Any 8 characters
Default: Primary
This field indicates whether this configuration is for a primary or a backup server.
IP Address
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Default:
The TACACS+ server IP Address.
Auth TCP Port
Synopsis: 1 to 65535
Default: 49
The authentication TCP Port on the TACACS+ server.
Auth Key
Synopsis: 31 character ASCII string
Default:
The authentication key shared with the TACACS+ server. It is used to encrypt any
passwords that are sent from the switch to the TACACS+ server.
Confirm Auth Key
Synopsis: 31 character ASCII string
Default: None
Confirm input of the above authentication key.
ROS® v3.10 User Guide
36
RMC30
1. Administration
1.13.3. User Privilge Level Configuartion
The TACACS+ standard priv_lvl attribute is used to grant access to the device. By default, the
attribute uses the following ranges:
• priv_lvl=15 represents an access level of “admin”
• 1 < priv_lvl < 15 (any value from 2 to 14) represents an access level of “operator”
• priv_lvl=1 represents an access level of “guest”
You can also configure a different non-default access level for admin, operator or guest users.
If an access level is not received in the response packet from the server, access
is not be granted to the user.
1.13.4. TACACS+ Server Privilege Configuration
Figure 1.24. TACACS+ Server Privilege Form
Admin Priv
Synopsis: (0 to 15)-(0 to 15)
Default: 15
Privilege level to be assigned to the user.
Oper Priv
Synopsis: (0 to 15)-(0 to 15)
Default: 2-14
Privilege level to be assigned to the user.
Guest Priv
Synopsis: (0 to 15)-(0 to 15)
Default: 1
Privilege level to be assigned to the user.
1.14. Syslog
The syslog provides users with the ability to configure local and remote syslog connections.
The remote syslog protocol, defined in RFC 3164, is a UDP/IP-based transport that enables a
ROS® v3.10 User Guide
37
RMC30
1. Administration
device to send event notification messages across IP networks to event message collectors,
also known as syslog servers. The protocol is simply designed to transport these event
messages from the generating device to the collector.
The syslog client resides in ROS and supports up to 5 collectors (syslog servers). ROS Remote
Syslog provides the ability to configure:
•
•
•
•
•
IP address(es) of collector(s).
Source UDP port.
Destination UDP port per collector.
Syslog source facility ID per collector (same value for all ROS modules).
Filtering severity level per collector (in case different collectors are interested in syslog
reports with different severity levels).
1.14.1. Configuring Local Syslog
The local syslog configuration enables users to control what level of syslog information will
be logged. Only messages of a severity level equal to or greater than the configured severity
level are written to the syslog.txt file in the unit.
Figure 1.25. Local Syslog Form
Local Syslog Level
Synopsis: { EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE,
INFORMATIONAL, DEBUGGING }
Default: DEBUGGING
Syslog severity level - {EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE,
INFORMATIONAL, DEBUGGING}.
ROS® v3.10 User Guide
38
RMC30
1. Administration
1.14.2. Configuring Remote Syslog Client
Figure 1.26. Remote Syslog Client Form
UDP Port
Synopsis: 1025 to 65535 or { 514 }
Default: 514
The local UDP port through which the client sends information to the server(s).
1.14.3. Configuring the Remote Syslog Server
Figure 1.27. Remote Syslog Server Table
ROS® v3.10 User Guide
39
RMC30
1. Administration
Figure 1.28. Remote Syslog Server Form
IP Address
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Default:
Syslog server IP Address.
UDP Port
Synopsis: 1025 to 65535 or { 514 }
Default: 514
The UDP port number on which the remote server listens.
Facility
Synopsis: { USER, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5,
LOCAL6, LOCAL7 }
Default: LOCAL7
Syslog facility name - { USER, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5,
LOCAL6, LOCAL7 }.
Syslog Facility is an information field associated with a syslog message. The syslog facility
is the application or operating system component that generates a log message. ROS
maps all syslog logging information onto a single facility, which is configurable to facilitate
a remote syslog server.
Severity
Synopsis: { EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE,
INFORMATIONAL, DEBUGGING }
Default: DEBUGGING
Syslog severity level - {EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE,
INFORMATIONAL, DEBUGGING}.
The severity level is the severity of the generated message. Note that the selected severity
level is accepted as the minimum severity level for the system. For example, if the severity
level is set as “Error”, then the system sends any syslog message generated by Error,
Critical, Alert and Emergency events.
ROS® v3.10 User Guide
40
RMC30
1. Administration
1.15. Troubleshooting
Problem One
I have configured the IP address and a gateway. I am pinging the switch but it is not
responding. I am sure the switch is receiving the ping because its port LEDs are flashing
and the statistics menu shows the pings. What is going on?
Is the switch being pinged through a router? If so, the switch gateway address must be
configured. The following figure illustrates the problem.
Figure 1.29. Using A Router As A Gateway
The router is configured with the appropriate IP subnets and will forward the ping from the
workstation to the switch. When the switch responds, however, it will not know which of its
interfaces to use in order to reach the workstation and will drop the response. Programming a
gateway of 10.0.0.1 will cause the switch to forward unresolvable frames to the router.
This problem will also occur if the gateway address is not configured and the switch tries to
raise an SNMP trap to a host that is not on the local subnet.
ROS® v3.10 User Guide
41
RMC30
2. Serial Protocols
2. Serial Protocols
RuggedCom devices support the following serial protocols:
•
•
•
•
•
•
•
•
•
Raw Socket serial encapsulation
Preemptive Raw Socket
TCPModbus (client and server modes)
DNP 3
DNP packetization over Raw Socket
Microlok
WIN and TIN
Mirrored Bits
TelnetComPort (RFC2217)
2.1. Serial Protocols Overview
Serial interface bit rates can be configured in range of 100 to 230400 bps. A "turnaround"
time is supported to enforce minimum times between successive messages transmitted via
a serial port.
If a port is set to force half-duplex mode, while sending data, all received data will be discarded.
To set this mode, the port must natively work in full-duplex mode.
To transport protocol messages through the network, either TCP/IP or UDP/IP transport can
be used. The exception is the TCPModbus protocol, which cannot be employed over UDP.
The setting of Differentiated Services Code Point (DSCP) in the IP header is provided for TCP/
IP and UDP/IP transport in the egress direction only.
Debugging facilities include statistics and tracing information on a serial port and/or network
transport.
2.1.1. Raw Socket protocol features
• A means to transport streams of characters from one serial port, over an IP network to
another serial port.
• XON/XOFF flow control.
• Configurable local and remote IP port numbers per serial port.
• Many-to-many UDP transactions.
• TCP accept or request connection mode.
• Point-to-point TCP connection mode and a broadcast connection mode in which up to 64
remote servers may connect to a central server.
• Packetization and sending data on a specific packet size, a specific character, or upon a
timeout.
• Configurable “turnaround” time to enforce minimum time between messages sent out the
serial port.
2.1.2. DNP over Raw Socket protocol features
• Packetization and sending data per DNP 3 protocol specification.
ROS® v3.10 User Guide
42
RMC30
2. Serial Protocols
2.1.3. Preemptive Raw Socket protocol features
• A means to transport streams of characters from one serial port, over an IP network, to
another serial port.
• Configurable local and remote IP port numbers per serial port.
• TCP accept or request one permanent connection on configured IP address.
• TCP accept one dynamic connection from different IP address.
• Dynamic connection activity timer controlled.
• XON/XOFF flow control for permanent connection.
• ‘Packetization’ trigger based on a specific packet size, a specific character, or upon a timeout
for each connection.
2.1.4. Modbus protocol features
•
•
•
•
•
Operation in TCPModbus Server Gateway or Client Gateway mod.e
Multi-master mode on the server.
Configurable behavior for sending exceptions.
Full control over ‘packetization’ timers.
A configurable Auxiliary IP port number for applications that do not support port 502.
2.1.5. DNP protocol features
• ‘Packetization’ per protocol specification.
• CRC checking in message headers received from the serial port.
• Local and remote source address learning.
2.1.6. Microlok protocol features
• ‘Packetization’ per protocol specification.
2.1.7. WIN protocol features
• ‘Packetization’ following the protocol requirements.
• CRC checking for messages received from the serial port.
2.1.8. TIN protocol features
•
•
•
•
Support for two modes of TIN protocol.
‘Packetization’ following the protocol requirements.
CRC checking for messages received from the serial port.
Remote source address learning, specific for two different modes.
2.1.9. TelnetComPort protocol features
• RawSocket protocol with additional support for the serial break signal.
• Compliant with RFC2217.
ROS® v3.10 User Guide
43
RMC30
2. Serial Protocols
2.2. Serial Protocols Operation
2.2.1. Serial Encapsulation Applications
2.2.1.1. Character Encapsulation (Raw Socket)
Character encapsulation is used any time a stream of characters must be reliably transported
across a network.
Character streams can be created by any type of device. The baud rates supported at either
server need not be the same. If configured, the server will obey XON/XOFF flow control from
the end devices.
Figure 2.1. Character Encapsulation
2.2.1.2. RTU Polling
The following applies to a variety of RTU protocols, including Modbus ASCII and DNP.
If a given device or service employs a serial protocol that is supported by ROS®,
it is advised to configure ROS to use that particular protocol, rather than another
one (e.g. RawSocket) that can be made to be (partly) compatible.
Host equipment may connect directly to a RuggedServer™ via a serial port, may use a port
redirection package, or may connect natively to the (Ethernet / IP) network.
Figure 2.2. RTU Polling
ROS® v3.10 User Guide
44
RMC30
2. Serial Protocols
If a RuggedServer™ is used at the host end, it will wait for a request from the host, encapsulate
it in an IP Datagram and send it to the remote side. There, the remote RuggedServer will
forward the original request to the RTU. When the RTU replies the RuggedServer will forward
the encapsulated reply back to the host end.
RuggedServer maintains configurable timers to help decide if replies and requests are
complete.
RuggedServer also handles the process of line-turnaround when used with RS485. It is
important to mention that unsolicited messages from RTUs in half-duplex mode cannot be
supported reliably. Message processing time includes sending a message over RS485, a
packtimer and a turnaround time. In order to handle half-duplex mode reliably, the turnaround
time must be configured long enough to allow an expected response to be received. Any other
messages will not be sent to the RS485 line within the processing time. If such a message is
received from the network, it will be delayed. It is up to the application to handle polling times
on ports properly.
2.2.1.3. Broadcast RTU Polling
Broadcast polling allows a single host-connected RuggedServer to “fan-out” a polling stream
to a number of remote RTUs.
The host equipment connects via a serial port to a RuggedServer. Up to 64 remote
RuggedServers may connect to the host server via the network.
Figure 2.3. Broadcast RTU Polling
Initially, the remote servers establish connections with the host server. The host server is
configured to accept a maximum of three incoming connections.
The host sequentially polls each RTU. Each poll received by the host server is forwarded (i.e.
broadcast) to all of the remote servers. All RTUs receive the request and the appropriate RTU
issues a reply. The reply is returned to the host server, where it is forwarded to the host.
ROS® v3.10 User Guide
45
RMC30
2. Serial Protocols
2.2.1.4. Preemptive Raw Socket
Figure 2.4. Permanent and Dynamic Master Connection Support
Most SCADA protocols are master/slave and support only a single master device. Preemptive
Raw Socket offers the ability to have multiple masters communicate to RTUs/IEDs in a
protocol-independent manner. For example, the SCADA master polling device is the normal
background process collecting data from the RTUs/IEDs on permanent TCP connection.
Occasionally, RTU/IED maintenance configuration or control may be required from a different
master (on dynamic TCP connection).
This feature allows a dynamic master to automatically preempt a permanent master. A
connection request from the dynamic master would cause the permanent master to be
suspended. Either closing the dynamic connection or timing out on data packets causes the
permanent master session to be resumed.
The diagram, Permanent and Dynamic Master Connection Support shows the case where
all RTUs are connected to Preemptive Raw Socket ports of RuggedServer devices. The
permanent master is connected to the Raw Socket port of the RuggedServer. Raw Socket
is configured to be connected to all Preemptive Raw Socket ports where polled RTUs are
connected (multiple incoming connection). Preemptive Raw Socket configuration on all ports
connected to RTUs will point to that Raw Socket as a permanent master (IP address and
Remote IP port).
A dynamic master can establish a connection to any Preemptive Raw Socket port at any time
and temporarily suspend the polling process (until the dynamic connection is cleared or times
out).
ROS® v3.10 User Guide
46
RMC30
2. Serial Protocols
2.2.1.5. Use of Port Redirectors
Port redirectors refer to software packages that emulate the existence of serial
communications ports. The redirector software creates and makes these “virtual” serial ports
available, providing access to the network via a TCP connection.
When a software package uses one of the virtual serial ports, a TCP connection request is
sent to a remote IP address and IP port that have been programmed into the redirector. Some
redirectors also offer the ability to accept connection requests.
The RawSocket protocol is the one most frequently used on RuggedServer for connection
to serial port redirection software. The TelnetComPort protocol may be used in place of
RawSocket if the redirection software on the other end of the connection also supports
the serial break command, as defined in RFC2217. In TelnetComPort mode, a serial break
received from the remote RFC2217-compatible client will be transmitted as a serial break on
the configured serial port, and a break signal received on the serial port will be transmitted as
an RFC2217-compatible break signal to the remote client. Note that a break signal on a serial
port is defined as a condition where the serial data signal is in 'space', or logic zero, state for
longer than the time needed to transmit one whole character, including start and stop bits.
2.2.1.6. Message Packetization
The serial server buffers received characters into packets in order to improve network
efficiency and demarcate messages.
The server uses three methods to decide when to packetize and forward the buffered
characters to the network:
• Packetize on a specific character.
• Packetize on timeout.
• Packetize on a specific packet size.
If configured to packetize on a specific character, the server will examine each received
character and will packetize and forward upon receiving the configured character. The
character is usually a <CR> or an <LF> character but may be any 8 bit (0 to 255) value.
If configured to packetize on a timeout, the server will wait for a configurable time after receiving
a character before packetizing and forwarding. If another character arrives during the waiting
interval, the timer is restarted. This method allows characters transmitted as part of an entire
message to be forwarded to the network in a single packet, when the timer expires after
receiving the very last character of the message.
Some polling software packages which perform well under DOS have been
known to experience problems when used with Windows-based software or port
redirection software. If the OS does not expedite the transmission of characters
in a timely fashion, pauses in transmission can be interpreted as the end of a
message. Messages can be split into separate TCP packets. A locally attached
RuggedServer or a port redirector could packetize and forward the message
incorrectly. Solutions include tuning the OS to prevent the problem or increasing
the packetizing timer.
Finally, the server will always packetize and forward on a specific packet size, i.e. when the
number of characters received from the serial port reaches a configured value.
ROS® v3.10 User Guide
47
RMC30
2. Serial Protocols
2.2.2. Modbus Server and Client Applications
The Modbus Server and Client applications are used to transport Modus requests and
responses across IP networks.
The Modbus Client application accepts Modbus polls from a master and determines the
IP address of the corresponding RTU. The client then encapsulates the message in TCP
respecting TCPModbus protocol, and forwards the frame to a Server Gateway or native
TCPModbus RTU. Returning responses are stripped of their TCP headers and issued to the
master.
The Modbus Server application accepts TCP encapsulated TCPModbus messages from
Client Gateways and native masters. After removing the TCP headers, the messages are
issued to the RTU. Responses are TCP encapsulated and returned to the originator.
The following figure presents a complex network of Client Gateways, Server Gateways and
native TCPModbus devices.
Figure 2.5. Modbus Client and Server
2.2.2.1. TCPModbus Performance Determinants
The following description provides some insight into the possible sources of delay and error
in an end-to-end TCPModbus exchange.
ROS® v3.10 User Guide
48
RMC30
2. Serial Protocols
Client
Gateway
Master
Server
Gateway
RTU
Transmission time from
Master to Client Gateway
Network transmission time
1
1a
2
3a
3b
4
Queuing time
5
Transmission time from
Server Gateway to RTU
6
RTU "think" and transmission
times to Server Gateway
7
Network transmission time
9a
8
Transmission time from
Client Gateway to Master
9c
9b
9d
Time-out / Retransmissions
complete, Exception sent
Figure 2.6. Sources of Delay and Error in an End-to-End Exchange
In step 1, the master issues a request to the Client Gateway. If the Client Gateway validates
the message, it will forward it to the network as step 2.
The Client Gateway can respond immediately in certain circumstances, as shown in step 1a.
When the Client Gateway does not have a configuration for the specified RTU, it will respond
to the master with an exception using TCPModbus exception code 11 (“No Path”). When the
Client Gateway has a configured RTU but the connection is not yet active, it will respond to
the master with an exception using TCPModbus exception code 10 (“No Response”). If the
forwarding of TCPModbus exceptions is disabled, the client will not issue any responses.
Steps 3a and 3b represent the possibility that the Server Gateway does not have a
configuration for the specified RTU. The Server Gateway will always respond with a type 10
(“No Path”) in step 3a, which the client will forward in step 3b.
Step 4 represents the possibility of a queuing delay. The Server Gateway may have to queue
the request while it awaits the response to a previous request. The worst case occurs when a
number of requests are queued for an RTU that has gone off-line, especially when the server
is programmed to retry the request upon failure.
Steps 5-8 represent the case where the request is responded to by the RTU and is forwarded
successfully to the master. It includes the “think time” for the RTU to process the request and
build the response.
Step 9a represents the possibility that the RTU is off-line, the RTU receives the request in
error or that the Server Gateway receives the RTU response in error. The Server Gateway will
issue an exception to the originator. If sending exceptions has not been enabled, the Server
Gateway will not send any response.
ROS® v3.10 User Guide
49
RMC30
2. Serial Protocols
2.2.2.2. A Worked Example
A network is constructed with two masters and 48 RTUs on four Server Gateways. Each of the
masters is connected to a Client Gateway with a 115.2 Kbps line. The RTUs are restricted to
9600 bps lines. The network is Ethernet-based and introduces an on average 3 ms of latency.
Analysis of traces of the remote sites has determined that the min/max RTU think times were
found to be 10/100 ms. What time-out should be used by the master?
The maximum length of a Modbus message is 256 bytes. This leads to a transmission time of
about 25 ms at the Master and 250 ms at the RTU. Under ideal circumstances, the maximum
round trip time is given by: 25 ms (Master->client) + 3 ms (network delay) + 250 ms (server>RTU) + 100 ms (Think time) + 250 ms (RTU->server) + 3 ms (network delay) + 25 ms (client>Master). This delay totals about 650 ms.
Contrast this delay with that of a “quick” operation such as reading a single register. Both
request and response are less than 10 bytes in length and complete (for this example) in 1
and 10 ms at the client and server. Assuming the RTU responds quickly, the total latency will
approach 35 ms.
The server can already be busy sending a request when the request of our example arrives.
Using the figures from the above paragraph, the server being busy would increase the endto-end delay from 650 to 1250 ms (additional 250 ms (server->RTU) + 100 ms (Think time)
+ 250 ms (RTU->server)).
The preceding analysis suggests that the Master should time-out at some time after 1250 ms
from the start of transmission.
2.2.2.3. Use of Turnaround Delay
Modbus protocol uses the concept of a turnaround delay in conjunction with broadcast
messages. When the host sends a broadcast message (that does not invoke an RTU
response), it waits for a turnaround delay time. This delay ensures that the RTU has enough
time to process the broadcast message before it receives the next poll.
When polling is performed over TCP, network delays may cause the broadcast and next poll
to arrive at the remote server at the same time. Configuring a turnaround delay at the server
will enforce a minimum separation time between each message transmitted via the serial port.
Note that turnaround delays do not need to be configured at the host computer side and may
be disabled there.
2.2.3. DNP 3.0, Microlok, TIN and WIN Applications
RuggedServer supports a variety of protocols that specify source and destination addresses.
A destination address specifies which device should process the data, and the source address
specifies which device sent the message. Having both destination and source addresses
satisfies at least one requirement for peer-to-peer communication because the receiver knows
where to direct responses. Each device supporting one of these protocols must have a unique
address within the collection of devices sending and receiving messages to and from each
other.
ROS® v3.10 User Guide
50
RMC30
2. Serial Protocols
Figure 2.7. Source/Destination Two-Way Communication
Even if the protocol can distinguish between the server and client sides, RuggedServer does
not do so. Both sides need to know where on the network a given destination device is. If a
message is received from the network, the destination address must point to the serial port
on the receiving server. If a message is received from the local serial port, the destination
address must point to the IP address of the server where the addressed device is connected.
2.2.3.1. The Concept of Links
A communication link is established between two IP addresses. The addressing is described
below:
• The remote address is the source IP address in a message received over the network,
and also the destination address of a message received from a serial port and transmitted
on the network.
• The local address is the destination IP address in a message received over the network,
and also the source address of a message received from a serial port and transmitted on
the network.
For each link, a statistical record will be available to the user if link statistics collection is
enabled in the protocol configuration.
2.2.3.2. Address Learning
2.2.3.2.1. Address Learning for TIN
Address learning is implemented for the TIN protocol and learned entries are viewable in the
Dynamic Device Address Table.
ROS® v3.10 User Guide
51
RMC30
2. Serial Protocols
Address Learning for TIN Mode 1
When a message with an unknown source address is received from the IP network, it is learned
on the IP address and IP port. If a message with the same source address is received from
another IP address and/or IP port, the address will be relearned.
The aging time will be reset whenever a unicast TIN message is received from a particular
source address.
The address will be removed from the table when the aging time expires.
Address Learning for TIN Mode 2
When a message with an unknown source address is received from the IP network, it is learned
on the IP address. If a message with the same source address is received from another IP
address and/or IP port, it will be learned again, and another entry will be created in the Dynamic
Device Address Table (TIN addresses will be duplicated).
Aging time will be reset whenever a unicast TIN message is received from a particular source
address.
The address will be removed from the table when the aging time expires.
2.2.3.2.2. Address Learning for DNP
For the DNP protocol, both the local and remote concepts of address learning are
implemented. Source addresses are learned from messages received from the network for
specific IP Addresses. Source addresses from messages received from the serial ports are
learned for specific local serial ports.
Although the DNP protocol can be configured for TCP or UDP transport, UDP transport is used
during the address learning phase as it supports all types of IP addresses: unicast, multicast
and broadcast.
When a message with an unknown source address is received from the local serial port, the
address is learned on that port and the local IP address.
When a message with an unknown source address is received from the IP network, on IP
interface that is configured as learning interface, it is learned on the IP address of the sender
and serial port is unknown.
When a message with an unknown destination address is received from a serial port, a UDP
broadcast datagram is transmitted on the UDP port configured for the DNP protocol. The IP
interface that transmits this broadcast is the one configured as the learning interface.
When a message with an unknown destination address is received from the IP network, it is
sent to all DNP serial ports.
All learned addresses will be kept in the Device Address Table until they are active. They
will also be saved in non-volatile memory and recovered if the device reboots, so the
learning process does not have to be repeated because of, for example, an accidental power
interruption.
The aging timer is reset whenever a message is received or sent to the specified address.
This concept makes the DNP protocol configurable with the minimum number of parameters:
an IP port, a learning IP interface and an aging timer.
ROS® v3.10 User Guide
52
RMC30
2. Serial Protocols
2.2.3.2.3. Broadcast Messages
DNP Broadcast Messages
Addresses 65521 through 65535 are DNP 3.0 broadcast addresses. RuggedServer supports
broadcasts sending messages with those destination addresses received from serial ports to
all IP Addresses found in the Device Address Table (either learned or statically configured).
When a DNP broadcast message is received from the IP network, it will be distributed to all
ports configured to support the DNP protocol.
TIN Broadcast Messages
TIN broadcast messages can be received only from devices connected to the serial ports.
TIN Mode 1 Broadcast Messages
These messages will be sent to all TIN Address/Ports found in the Dynamic Address Table.
TIN Mode 2 Broadcast Messages
These messages will be sent according to the configuration: to all TIN addresses on every IP
address found in the Dynamic Address Table and/or to all Wayside Data Radio IP addresses
found in the Static Device Address Table.
2.2.3.3. Transport Protocols
For supported protocols, with exception of Modbus, either UDP datagram or TCP connection
packets can be used to transport protocol data over the IP network. The Modbus data can be
transported only using TCP connection, following TCPModbus protocol. UDP supports all the
addressing modes of IP – unicast, multicast and broadcast. Therefore, if address learning is
enabled, UDP broadcasts will be sent across the network.
2.2.3.3.1. Transport for Raw Socket
The TCP transport for RawSocket requires configuration of connection request direction,
remote IP address, and IP port for listening or requesting outgoing TCP connections. Only
one outgoing connection can be requested, but up to 64 connections can be accepted if the
port is configured to listen to incoming connection requests. For ports configured to request
connections and to listen to incoming connection requests, only one connection can become
active.
RuggedServer will attempt to connect periodically if the first attempt fails and after a connection
is broken.
RuggedServer can be used to connect to any device supporting TCP (e.g. a host computer’s
TCP stack or a serial application on a host using port redirection software).
If Raw Socket ports are configured to use UDP for transport, up to 64 remote hosts can
communicate with devices connected to local serial ports. Data in UDP packets from remote
hosts configured to communicate with a particular serial port will be forwarded to that port, as
long as the serial port is configured to listen on the UDP port to which the remote hosts are
transmitting. Data received from the serial port will be forwarded to all remote hosts configured
to communicate with that serial port.
The Raw Socket mechanism transparently passes data. It does not attempt to determine
where to demarcate packets in the data received from connected devices. Given this
transparency, any protocol can be encapsulated within Raw Socket.
ROS® v3.10 User Guide
53
RMC30
2. Serial Protocols
2.2.3.3.2. Transport for Protocols with Defined Links
All protocols with defined links (source and destination addresses are part of protocol) can
use either TCP or UDP to transport data.
The Device Address Table contains addresses and locations of devices configured (or learned)
for specific protocols.
If a protocol is configured to use TCP to transport data, the server will start listening to the
IP Port configured for the protocol. At the same time, TCP connections will be placed to all
IP addresses where devices for that protocol are attached. RuggedServer will keep only one
connection open to one IP Address on one IP Port.
2.2.3.3.3. Use of Differentiated Services Code Point (DSCP)
RuggedServer has the ability to set the DS byte in the IP header of outbound IP packets.
The value can be configured on an ingress serial port, and/or for a protocol. Which value will
be used depends on the protocol configured on a port and the transport configured for the
particular protocol.
UDP/IP transport supports a DSCP setting per serial port or per protocol. If a configuration
contains a DSCP setting per serial port as well as per protocol then the system will use
whichever setting has a higher DSCP value.
TCP/IP transport supports per protocol DSCP setting. RawSocket and Modbus Server protocol
properties are configured per port as well, so they always support DSCP setting per serial port.
2.2.4. Force Half-Duplex Mode of Operation
A "force half-duplex" mode of operation allows use of extensions that create echo loops (as
optical loop topology that utilizes the RMC20 repeat mode function).
Figure 2.8. Optical Loop Topology
The diagram: Optical Loop Topology illustrates a topology that utilizes the RMC20 repeat
mode function. The repeat function will optically retransmit any data received on the optical
receiver, in addition to any connected serial devices. As a result, any data transmitted from
the master will be retransmitted optically to all the slaves.
ROS® v3.10 User Guide
54
RMC30
2. Serial Protocols
This topology can be used for RS232, RS485, or RS422 multi-drop networks. In all cases, all
slaves have the repeat function (DIP position 4) ON, while the one connected to the RMC30 is
configured with the repeat function OFF. The port used on the RMC30 must be in full-duplex
mode, while the ForceHD (Force Half-Duplex) parameter must be turned ON.
2.3. Serial Protocol Configuration
The Serial Protocols menu is accessible from the main menu:
Figure 2.9. Serial Protocols Menu
ROS® v3.10 User Guide
55
RMC30
2. Serial Protocols
2.3.1. Serial Ports
Figure 2.10. Serial Port Table
Figure 2.11. Serial Port Configuration Form
Port
Synopsis: 1 to maximum port number
Default: 1
The port number as seen on the front plate silkscreen of the switch.
Name
Synopsis: Any 15 characters
ROS® v3.10 User Guide
56
RMC30
2. Serial Protocols
Default: Port 1
A descriptive name that may be used to identify the device connected on that port.
Protocol
Synopsis: { None, RawSocket, ModbusServer, ModbusClient, DNP,
WIN, TIN, MicroLok, MirroredBits,PreemptRawSocket }
Default: None
The serial protocol supported on this serial port.
Type
Synopsis: { RS232, RS485, RS422, FIBER }
Default: RS232
The serial port interface type.
ForceHD
Synopsis: { On, Off }
Default: Off
Enables forcing half-duplex mode of operation. While sending data out of the serial port, all
received data are ignored. This mode of operation is available only on ports that operate
in full-duplex mode.
Baud
Synopsis: 100 to 230400
Default: 9600
The baud rate at which to operate the port.
Data Bits
Synopsis: { 7, 8 }
Default: 8
The number of data bits to operate the port with.
Stop
Synopsis: { 1, 1.5, 2 }
Default: 1
The number of stop bits to operate the port with.
Parity
Synopsis: { None, Even, Odd }
Default: None
The parity to operate the port with.
Turnaround
Synopsis: 0 to 1000
Default: 0 ms
The amount of delay (if any) to insert between the transmissions of individual messages
via the serial port. For Modbus protocol this value must be non-zero. It represents the delay
between sending a brodcast message and the next poll out of the serial port. Because
RTUs do not reply to a broadcast, enough time must be ensured to process it.
PostTX Delay
Synopsis: 0 to 15
ROS® v3.10 User Guide
57
RMC30
2. Serial Protocols
Default: 15 bits
The number of data bits needed to generate required delay with configured baudrate after
the last bit of the packet was sent out before serial UART starts listening to the RX line.
This value is relevant for RS485 interfaces only.
Hold Time
Synopsis: 1 to 15000 ms or { off }
Default: off
The maximum amount of time, in milliseconds, that the serial packet can be held in the
queue before being sent to the serial line. Time is measured from the moment the packet
is received from the IP layer.
DSCP
Synopsis: 0 to 63
Default: 0
Sets the DS byte in the IP header. DS byte setting is supported in the egress direction only.
RXtoTX Delay
Synopsis: 0 ms to 1000 ms
Default: 0 ms
The minimum amount of time, in milliseconds, that the transmission of a new message
delays after the last message is received through the serial port. This parameter is
especially useful for half duplex transmission modes, such as the two-wire RS485 serial
protocol. It provides the connected device with time to turn off its transmitter and to turn on
its receiver, helping to ensure that the device receives the next message without data loss.
2.3.2. Raw Socket
Figure 2.12. Raw Socket Table
ROS® v3.10 User Guide
58
RMC30
2. Serial Protocols
Figure 2.13. Raw Socket Form
Port
Synopsis: 1 to maximum port number
Default: 1
The port number as seen on the front plate silkscreen of the switch.
Pack Char
Synopsis: 0 to 255 or { Off }
Default: Off
The character that can be used to force forwarding of accumulated data to the network.
If a packetization character is not configured, accumulated data will be forwarded based
upon the packetization timeout (Pack Timer) parameter.
Pack Timer
Synopsis: 3 to 1000
Default: 10 ms
The delay from the last received character until when data is forwarded.
Pack Size
Synopsis: 64 to 1400 or { Maximum }
Default: Maximum
The maximum number of bytes received from the serial port to be forwarded.
Flow Control
Synopsis: { None, XON/XOFF }
Default: None
The Flowcontrol setting for serial port.
Transport
Synopsis: { TCP, UDP }
ROS® v3.10 User Guide
59
RMC30
2. Serial Protocols
Default: TCP
The network transport used to transport protocol data over IP network.
Call Dir
Synopsis: { In, Out, Both }
Default: In
The Call direction for TCP Tranport. - Whether to accept an incoming connection or - to
place an outgoing connection or - to place outgoing connection and wait for incomming
(both directions).
Max Conns
Synopsis: 1 to 64
Default: 1
The maximum number of allowed incoming TCP connections (for configurations using
TCP).
Loc Port
Synopsis: 1024 to 65535
Default: 50000
The local IP port to use when listening for an incoming connection or UDP data.
Rem Port
Synopsis: 1 to 65535
Default: 50000
The remote TCP port to use when placing an outgoing connection. Note that this parameter
is applicable only to TCP connections. If the transport protocol is set to UDP, the remote
port is configured using the "Remote Hosts" table. For more information, see the Remote
Hosts section.
IP Address
Synopsis: ###.###.###.### where ### ranges from 0 to 255 or { }
Default:
For direction: 'Out' (client), the remote IP address to use when placing an outgoing TCP
connection request.
For direction: 'In' (server), the local interface IP address on which to listen for connection
requests. An empty string implies the default: the IP address of the management interface.
For direction: 'Both' (client or server), the remote IP address to use when placing an
outgoing TCP connection request. The listening interface will be chosen by matching mask.
Note that this parameter is applicable only to TCP connections. If the transport protocol
is set to UDP, the remote port is configured using the "Remote Hosts" table. For more
information, see the Remote Hosts section.
Link Stats
Synopsis: { Disabled, Enabled }
Default: Enabled
Enables link statistics collection for the protocol.
ROS® v3.10 User Guide
60
RMC30
2. Serial Protocols
2.3.3. Remote Hosts
Figure 2.14. Remote Hosts Table
Figure 2.15. Remote Hosts Form
IP Address
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Default:
The IP address of the remote host.
IP Port
Synopsis: 1 to 65535 or { Unknown }
Default: 50000
The IP port that remote host listens to. If this is zero (Unknown), the unit only receives from
the remote host but does not transmit to it.
Port(s)
Synopsis: Any combination of numbers valid for this parameter
Default: All
The local serial ports that the remote host is allowed to communicate with.
ROS® v3.10 User Guide
61
RMC30
2. Serial Protocols
2.3.4. Preemptive Raw Socket
Figure 2.16. Preemptive Raw Socket Table
Figure 2.17. Preemptive Raw Socket Form
Port
Synopsis: 1 to 4
Default: 1
ROS® v3.10 User Guide
62
RMC30
2. Serial Protocols
The port number as seen on the front plate silkscreen of the switch.
Pack Char
Synopsis: 0 to 255 or { Off }
Default: Off
The character that can be used to force forwarding of accumulated data to the network.
If a packetization character is not configured, accumulated data will be forwarded based
upon the packetization timeout parameter.
Pack Timer
Synopsis: 3 to 1000
Default: 10 ms
The delay from the last received character until when data is forwarded.
Flow Control
Synopsis: { None, XON/XOFF }
Default: None
The Flowcontrol setting for serial port.
Loc Port
Synopsis: 1024 to 65535
Default: 62001
The local IP port to use when listening for an incoming connection or UDP data.
Rem Port
Synopsis: 1 to 65535
Default: 62000
The remote TCP port to use when placing an outgoing connection.
IP Address
Synopsis: ###.###.###.### where ### ranges from 0 to 255 or
{ <EMTY STRING> }
Default:
The permanent master's IP address. Empty string represents management IP address of
this device.
Link Stats
Synopsis: { Disabled, Enabled }
Default: Enabled
Enables link statistics collection for this protocol.
Dyn Pack Char
Synopsis: 0 to 255 or { Off }
Default: Off
The character that can be used to force the forwarding of accumulated data to the
network for connection to a dynamic master. If a packetization character is not configured,
accumulated data will be forwarded based upon the packetization timeout parameter.
Dyn Pack Timer
Synopsis: 3 to 1000
Default: 10 ms
The delay from the last received character until when data is forwarded to the dynamic
master.
ROS® v3.10 User Guide
63
RMC30
2. Serial Protocols
Timeout
Synopsis: 10 to 3600
Default: 10 s
The time in seconds that is allowed for a dynamic master to be idle before its connection
is closed. The protocol listens to the socket open to the dynamic master, and if no data
are received within this time, the connection will be closed.
2.3.5. Modbus Server
Figure 2.18. Modbus Server Table
Figure 2.19. Modbus Server Form
Port
Synopsis: 1 to maximum port number
Default: 1
The port number as seen on the front plate silkscreen of the switch.
ROS® v3.10 User Guide
64
RMC30
2. Serial Protocols
Response Timer
Synopsis: 50 to 10000
Default: 1000 ms
The maximum allowable time to wait for the RTU to start to respond.
Auxiliary TCP Port
Synopsis: 1024 to 65535 or { Disabled }
Default: Disabled
The TCP Modbus Server always listens on TCP port 502. It may be additionally configured
to listen on this auxiliary port number, accepting calls on both.
Send Exceptions
Synopsis: { Disabled, Enabled }
Default: Enabled
This parameter enables/disables sending a TCP Modbus exception back to the master if
a response has not been received from the RTU within expected time.
Link Stats
Synopsis: { Disabled, Enabled }
Default: Enabled
Enables link statistics collection for this protocol.
2.3.6. Modbus Client
Figure 2.20. Modbus Client Form
IP Port
Synopsis: 1 to 65535
Default: 502
The remote port number at which the Modbus protocol makes TCP connection requests.
Forward Exceptions
Synopsis: { Disabled, Enabled }
Default: Enabled
ROS® v3.10 User Guide
65
RMC30
2. Serial Protocols
Enables forwarding exception messages to the Master as exception codes 10 (no path) or
11 (no response) When the Master polls for an unconfigured RTU or the remote Modbus
Server receives a poll for an RTU which is not configured or is timing out, it returns an
exception message. Disable this feature if your Master does not support exceptions but
recognizes failure by time-out when waiting for response.
Link Stats
Synopsis: { Disabled, Enabled }
Default: Enabled
Enables link statistics collection for this protocol.
DSCP
Synopsis: 0 to 63
Default: 0
To set the DS byte in the IP header. DS byte setting is supported in the egress direction
only.
2.3.7. WIN and TIN
Figure 2.21. WIN and TIN Form
TIN Mode:
Synopsis: 1 to 2
Default: 1
The TIN Protocol running mode.
ROS® v3.10 User Guide
66
RMC30
2. Serial Protocols
TIN Transport:
Synopsis: { TCP, UDP }
Default: UDP
The network transport used to transport protocol data over an IP network.
WIN Transport:
Synopsis: { TCP, UDP }
Default: UDP
The network transport used to transport protocol data over an IP network.
TIN IP Port
Synopsis: 1024 to 65535
Default: 51000
The local port number on which the TIN protocol listens for connections or UDP datagrams.
WIN IP Port
Synopsis: 1024 to 65535
Default: 52000
The local port number on which the WIN protocol listens for connections or UDP
datagrams.
Message Aging Timer
Synopsis: 1 to 3600 or { Disabled }
Default: Disabled
The Aging Time for TIN mode2 messages. It specifies how long a message should be
stored in the internal table. When the feature is enabled, any TIN mode2 message received
will be stored in an internal table which can be examined by using command 'SQL SELECT
FROM ItcsTin2Dup'. If the same message is received within the time window specified by
this parameter, the new message is considered duplicate, and thus discarded.
Address Aging Timer
Synopsis: 60 to 1000
Default: 300 s
The time of communication inactivity after which a learned TIN address is removed from
the device address table. Entries in the Link Statistics Table with the aged address will be
kept until statistics are cleared.
Broadcast Addresses
Synopsis: { Static, Dynamic, StaticAndDynamic }
Default: Static
The device address table in which addresses will be found for broadcast messages.
Unicast Addresses
Synopsis: { Static, Dynamic, StaticAndDynamic }
Default: Dynamic
The device address table in which addresses will be found for unicast messages.
Link Stats
Synopsis: { Disabled, Enabled }
Default: Enabled
Enables link statistics collection for this protocol.
WIN DSCP
Synopsis: 0 to 63
ROS® v3.10 User Guide
67
RMC30
2. Serial Protocols
Default: 0
To set the DS byte in the IP header. DS byte setting is supported in the egress direction
only.
TIN DSCP
Synopsis: 0 to 63
Default: 0
To set the DS byte in the IP header. DS byte setting is supported in the egress direction
only.
2.3.8. MicroLok
Figure 2.22. MicroLok Form
Transport
Synopsis: { TCP, UDP }
Default: UDP
The network transport used to transport protocol data over an IP network.
IP Port
Synopsis: 1024 to 65535
Default: 60000
A local port number on which the MicroLok protocol listens for UDP datagrams or TCP
connections.
Link Stats
Synopsis: { Disabled, Enabled }
Default: Enabled
Enables link statistics collection for this protocol.
DSCP
Synopsis: 0 to 63
Default: 0
ROS® v3.10 User Guide
68
RMC30
2. Serial Protocols
To set the DS byte in the IP header. DS byte setting is supported in the egress direction
only.
2.3.9. DNP
Figure 2.23. DNP Form
Transport
Synopsis: { TCP, UDP }
Default: TCP
The network transport used to transport protocol data over an IP network.
IP Port
Synopsis: 1024 to 65535
Default: 20000
A local port number on which the DNP protocol listens for UDP datagrams.
Learning
Synopsis: ###.###.###.### where ### ranges from 0 to 255 or
{ Disabled }
Default: Disabled
Enable or disable address learning. Learning can be disabled or enabled on a management
IP interface (empty string), or enabled on the interface with a specific IP address. If learning
is enabled and the remote address is not known, a UDP broadcast message will be sent
and source addresses will be learned on devices that run the DNP protocol. If the local
address is not known, a message will be sent to all serial ports running the DNP protocol.
Local addresses will be learned from local responses. If the TCP transport is configured,
a connection will be established to the devices with the corresponding IP address.
Aging Timer
Synopsis: 60 to 1000
ROS® v3.10 User Guide
69
RMC30
2. Serial Protocols
Default: 300 s
The time of communication inactivity after which a learned DNP address is removed from
the device address table. Entries in the Link Statistics Table with the aged address will be
kept until the statistics are cleared.
Link Stats
Synopsis: { Disabled, Enabled }
Default: Enabled
Enables link statistics collection for this protocol.
DSCP
Synopsis: 0 to 63
Default: 0
To set the DS byte in the IP header. DS byte setting is supported in the egress direction
only.
2.3.10. DNP over Raw Socket
Figure 2.24. DNP over Raw Socket Table
Figure 2.25. DNP over Raw Socket Form
ROS® v3.10 User Guide
70
RMC30
2. Serial Protocols
Port
Synopsis: 1 to 4
Default: 1
The port number as seen on the front plate silkscreen on the switch.
Transport
Synopsis: { TCP, UDP }
Default: TCP
The network transport used to transport protocol data over the IP network.
Call Dir
Synopsis: { In, Out, Both }
Default: In
The Call direction for TCP Tranport.
• In: accepts an incoming connection.
• Out: places an outgoing connection.
• Both: places an outgoing connection and waits for as incomming connection (both
directions).
Max Conns
Synopsis: 1 to 64
Default: 1
The maximum number of allowed incoming TCP connections.
Loc Port
Synopsis: 1 to 65535
Default: 21001
The local IP port to use when listening for an incoming connection or UDP data.
Rem Port
Synopsis: 1 to 65535
Default: 21000
The remote TCP port to use when placing an outgoing connection.
IP Address
Synopsis: ###.###.###.### (where ### ranges from 0 to 255) |
{ <empty string> }
Default: <empty string>
Defines the IP address based on the following:
• For outgoing TCP connection (client), this is the remote IP address to communicate with.
• For incoming TCP connection (server), this is the local interface IP address to listen to
for the local port for connection request. If an empty string is configured, the IP address
of the management interface is used.
• When both outgoing and incoming connections are enabled (client or server), this is
remote IP address to use to place an outgoing TCP connection request or from which
to accept calls.
• For UDP transport, this is the IP address of the interface to listen to for UDP datagrams.
ROS® v3.10 User Guide
71
RMC30
2. Serial Protocols
Link Stats
Synopsis: { Disabled, Enabled }
Default: Enabled
Enables links statistics collection for the protocol.
2.3.11. Mirrored Bits
Figure 2.26. Mirrored Bits Table
Figure 2.27. Mirrored Bits Form
Port
Synopsis: 1 to 4
Default: 1
The port number as seen on the front plate silkscreen of the switch.
ROS® v3.10 User Guide
72
RMC30
2. Serial Protocols
Transport
Synopsis: { TCP, UDP }
Default: UDP
The network transport used to transport Mirrored Bits protocol data over an IP network.
Loc Port
Synopsis: 1024 to 65535
Default: 61001
The local IP port to use when listening for an incoming connection or UDP data.
Rem Port
Synopsis: 1 to 65535
Default: 61000
The remote TCP port to use when placing an outgoing connection.
IP Address
Synopsis: ###.###.###.### where ### ranges from 0 to 255 or
{ <EMPTY STRING> }
Default:
For an outgoing TCP connection (client) and UDP transport, this is the remote IP address
to communicate with.
For an incoming TCP connection (server), the local interface IP address on which to
listen for connection requests. An empty string implies the default: the IP address of the
management interface.
When both outgoing and incoming connections are enabled (client or server), this is the
remote IP address to which to place an outgoing TCP connection request or from which
to accept an incoming request.
Link Stats
Synopsis: { Disabled, Enabled }
Default: Enabled
Enables link statistics collection for this protocol.
ROS® v3.10 User Guide
73
RMC30
2. Serial Protocols
2.3.12. TelnetComPort
Figure 2.28. TelnetComPort Form
Port
Synopsis: 1 to maximum port number
Default: 1
The serial port number as seen on the front plate silkscreen of the RuggedServer.
Pack Char
Synopsis: 0 to 255 or { Off }
Default: Off
The character that will be used to force the forwarding of buffered data to the network. If a
packetization character is not configured, buffered data will be forwarded based upon the
packetization timeout (Pack Timer) parameter.
Pack Timer
Synopsis: 5 to 1000
Default: 10 ms
The delay from the last received character until when data is forwarded to the dynamic
master.
ROS® v3.10 User Guide
74
RMC30
2. Serial Protocols
Pack Size
Synopsis: 64 to 1400 or { Maximum }
Default: Maximum
When this number of bytes is received on the serial port, buffered characters received on
the port are packetized and forwarded on the network.
Flow Control
Synopsis: { None, XON/XOFF }
Default: None
The Flowcontrol setting for serial port.
Call Dir
Synopsis: { In, Out, Both }
Default: In
The Call direction for TCP Tranport. - Whether to accept an incoming connection or - to
place an outgoing connection or - to place outgoing connection and wait for incomming
(both directions).
Loc Port
Synopsis: 1024 to 65535
Default: 50000
The local IP port to use when listening for an incoming connection.
Rem Port
Synopsis: 1 to 65535
Default: 50000
The remote TCP port to use when placing an outgoing connection. This parameter is
applicable only to TCP transport.
IP Address
Synopsis: ###.###.###.### where ### ranges from 0 to 255 or { }
Default:
For direction 'OUT' (client), remote IP address to use when placing an outgoing TCP
connection request. For direction 'IN' (server), local interface IP address to listen to the
local port for connection request. Empty string can be used for IP address of management
interface. For direction 'BOTH' (client or server), remote IP address to use when placing
an outgoing TCP connection requestListening interface will be chosen by matching mask.
This parameter is applicable only to TCP connections. If the transport protocol is set to
UDP, the remote port is configured using the "Remote Hosts" table. For more information,
see the Remote Hosts section.
Link Stats
Synopsis: { Disabled, Enabled }
Default: Enabled
Enables links statistics collection for this protocol.
2.3.13. Device Addresses
Up to 1024 entries can be created in this table.
ROS® v3.10 User Guide
75
RMC30
2. Serial Protocols
Figure 2.29. Device Address Table
Figure 2.30. Device Address Form
Protocol
Synopsis: { ModbusServer, ModbusClient, DNP, WIN, TIN, MicroLok }
Default: ModbusServer
The serial protocol supported on this serial port.
Address
Synopsis: Any 31 characters
Default:
The complete address of a device, which might be either local to the RuggedCom device
or remote.
A local address is one associated with a device connected to a serial port on this device.
The corresponding serial port must be configured to match this address specification.
ROS® v3.10 User Guide
76
RMC30
2. Serial Protocols
A remote address is the address of a device connected to a serial port on a remote host
over an IP network. In this case, "Remote Ip Addr" must also be configured.
The format and range of this address field is determined by the protocol:
• Modbus: 1 to 244
• MicroLok: 1 to 65535, or 8 to hexadecimal digits ‘1’ to ‘a’
• DNP 3.0: 1 to 65520
• WIN: 6 bits address (0 to 63)
• TIN: String 'wdr' for wayside data radio (TIN mode 2), or a 32 bit address (8 digits,
expressed in hexadecimal digits '0' through 'f'). An all-zero address is not allowed.
Remote IP Addr
Synopsis: ###.###.###.### where ### ranges from 0 to 255
Default:
The IP address of a remote host where a device with a configured remote address is
connected.
Port
Synopsis: 1 to maximum port number or {Unknown}
Default: Unknown
The serial port to which a device is attached. If the device with this address is attached to
the serial port of a remote host, the value of this parameter is 'Unknown'.
Name
Synopsis: Any 16 characters
Default:
The addressed device name.
2.3.14. Dynamic Device Addresses
This table provides the ability to view the TIN protocol’s device addresses from remote
locations that were learned dynamically.
Figure 2.31. Dynamic Device Address Table
ROS® v3.10 User Guide
77
RMC30
2. Serial Protocols
Figure 2.32. Dynamic Device Address Form
Protocol
Synopsis: { TIN }
The serial protocol supported on this serial port.
Address
Synopsis: Any 31 characters
The remote device address.
Location
Synopsis: ###.###.###.### where ### ranges from 0 to 255
The IP Address of the remote host.
IP Port
Synopsis: 1 to 65535
The remote port number from which a UDP datagram was received from a remote device,
or from which a TCP connection was established.
RSSI
Synopsis: -128 to 0 or { N/A }
The signal strength indicator received from wayside data radio. N/A for TIN Mode 1.
Aging Time
Synopsis: 0 to 1000
The amount of time since the last packet arrived from the device. Once this time exceeds
the Aging Timer setting for the protocol, the device will be removed from the table. This
value is updated every 10 seconds.
2.4. Serial Statistics
2.4.1. Link Statistics
This table presents detailed statistics for serial links between two devices.
ROS® v3.10 User Guide
78
RMC30
2. Serial Protocols
Figure 2.33. Link Statistics Table
Figure 2.34. Link Statistics Form
Protocol
Synopsis: { None, RawSocket, ModbusServer, ModbusClient, DNP,
WIN, TIN, MicroLok }
The serial protocol supported by devices that create this link.
Local Address
Synopsis: Any 27 characters
The address of the device connected to the serial port on this device.
Remote Address
Synopsis: Any 35 characters
The address of the device connected to the remote host's serial port.
Rx Local
Synopsis: 0 to 4294967295
ROS® v3.10 User Guide
79
RMC30
2. Serial Protocols
The number of packets received from the local address that were forwarded to the remote
side.
Rx Remote
Synopsis: 0 to 4294967295
The number of packets received from the local address that were forwarded to the local
serial port.
Erroneous
Synopsis: 0 to 4294967295
The number of erroneous packets received from the remote address.
2.4.2. Connection Statistics
This table presents statistics for all active TCP connections on serial protocols. The statistics
are updated once every second.
Figure 2.35. Connection Statistics Table
Remote IP
Synopsis: ###.###.###.### where ### ranges from 0 to 255
The remote IP address of the connection.
Remote Port
Synopsis: 0 to 65535
The remote port number of the connection.
Local Port
Synopsis: 0 to 65535
The local port number of the connection.
Rx Packets
Synopsis: 0 to 4294967295
The number of received packets on the connection.
Tx Packets
Synopsis: 0 to 4294967295
The number of packets transmitted on the connection.
ROS® v3.10 User Guide
80
RMC30
2. Serial Protocols
2.4.3. Serial Port Statistics
Figure 2.36. Serial Port Statistics Table
Port
Synopsis: 1 to maximum port number
The port number as seen on the front plate silkscreen of the switch.
Protocol
Synopsis: Any 15 characters
The serial protocol supported on this serial port.
Rx Chars
Synopsis: 0 to 4294967295
The number of received characters.
Tx Chars
Synopsis: 0 to 4294967295
The number of transmitted characters.
Rx Packets
Synopsis: 0 to 4294967295
The number of received packets.
Tx Packets
Synopsis: 0 to 4294967295
The number of transmitted packets.
Packet Errors
Synopsis: 0 to 4294967295
The number of packets received from this port and discarded (error in protocol, CRC or
routing information not found).
Parity Errors
Synopsis: 0 to 4294967295
The number of Parity Errors.
Framing Errors
Synopsis: 0 to 4294967295
The number of Framing Errors.
ROS® v3.10 User Guide
81
RMC30
2. Serial Protocols
Overrun Errors
Synopsis: 0 to 4294967295
The number of Overrun Errors.
2.4.4. Clearing Serial Port Statistics
Figure 2.37. Clear Serial Port Statistics Form
This command clears statistics on one or more serial ports. To clear statistics for one or more
ports, check the boxes corresponding to the selected ports and select "Apply".
2.4.5. Resetting Serial Ports
Figure 2.38. Reset Serial Port(s) Form
To reset one or more ports, check the boxes corresponding to the selected ports and select
"Apply".
2.5. Troubleshooting
Problem One
I configured a Serial IP connection to use the TCP transport (using either an inbound
or outbound connection) but nothing seems to be happening. What is going on?
Ensure that an Ethernet port link is up.
ROS® v3.10 User Guide
82
RMC30
2. Serial Protocols
The peer may not be requesting (accepting) connections. The Connection Statistics Table will
display whether the connection is active or not.
The peer may not be sending data. The Connection statistics Table will display the counts of
transmitted and received data packets via the IP network.
Watch the connection activity. For a detailed description of the TCP connection activity, turn
on tracing at the TRANSPORT level.
Problem Two
My connections (as shown in the Connection Statistics Table) go up and then
immediately go down again. What is going on?
If two ports (on the same or different RuggedServers™) are configured to call the same IP/
TCP port in the network, only the first one to call will be successful. All other ports will fail,
displaying the attempts as brief periods of connection in the Connection Statistics Table.
Problem Three
My Modbus polling is not working. I am sure that a connection is occurring but my
Master reports an error connecting to the device. What is happening?
Are framing, parity or overrun errors reported by either the client or server?
Is the Server Gateway set up for the correct baud, parity and stop bits? Is the RTU online?
Is an adequate response timer configured at the server? Is the master’s timeout long enough?
Is the master pausing in the middle of transmitting the request? Some versions of the Windows
OS have been observed to display this behavior as the load is increased.
Could the IP network be splitting the Modbus message into two TCP segments?
Ultimately, it may be necessary to view the contents of messages transmitted over TCP (by
activating tracing at the IP level) or by viewing messages at the serial port level (See the section
on tracing at the SERIAL level.) Start by tracing at the client side, ensuring that it is receiving
and forwarding the request over IP. Then, if need be, trace at the server side to ensure that it
is receiving the request and forwarding to the RTU. Verify that the RTU is responding properly.
Problem Four
How do I get figures (like those presented earlier in the chapter) for my own analysis?
Activating tracing at the IP level and serial port level. The trace package displays timestamps,
packet sizes, message directions and timeout event occurrences.
ROS® v3.10 User Guide
83
RMC30
3. Diagnostics
3. Diagnostics
ROS® provides the following diagnostics features:
•
•
•
•
•
•
Alarm System to view and clear alarms.
Viewing and clearing the system log.
Viewing CPU diagnostics.
Viewing the product information.
Loading the factory default configuration.
Resetting the device.
The Diagnostics menu is accessible from the main menu:
Figure 3.1. Diagnostics Menu
3.1. Using the Alarm System
Alarms are the occurrence of events of interest that are logged by the device. If alarms have
occurred, the device will indicate the number of alarms in the top right corner of all menu
screens.
There are two broad types of alarms - active and passive alarms.
3.1.1. Active Alarms
Active alarms are ongoing. They signify states of operation that are not in accordance with
normal operation. Examples of active alarms include links that should be up but are not or
error rates that are continuously exceeding a certain threshold.
Active alarms are removed (cleared) either by solving the original cause of the alarm or by
explicitly clearing the alarm itself.
ROS® v3.10 User Guide
84
RMC30
3. Diagnostics
3.1.2. Passive Alarms
Passive alarms are historic in nature. They signify events that represented abnormal conditions
in the past, and do not affect the current operational status. Examples of passive alarms
include authentication failures or error rates that temporarily exceeded a certain threshold.
Passive alarms are cleared through the Clear Alarms option under the diagnostics menu.
RMON generated alarms are passive.
3.1.3. Alarms and the Critical Failure Relay
All active alarms will immediately de-energize the critical fail relay (thus signifying a problem).
The relay will be re-energized when the last outstanding active alarm is cleared.
Alarms are volatile in nature. All alarms (active and passive) are cleared at startup.
3.1.4. Configuring Alarms
ROS provides a means for selectively configuring alarms in fine-grained detail. Some notes
on alarm configuration in ROS:
•
•
•
•
•
Alarms at levels CRITICAL or ALERT are not configurable nor can they be disabled.
The "Level" field is read-only; the preconfigured alarm level is not a configurable option.
Alarms cannot be added to or deleted from the system.
Alarm configuration settings changed by a user will be saved in the configuration file.
The "alarms" CLI command lists all alarms - configurable and non-configurable.
ROS® v3.10 User Guide
85
RMC30
3. Diagnostics
Figure 3.2. Alarm Configuration Table
ROS® v3.10 User Guide
86
RMC30
3. Diagnostics
Figure 3.3. Alarm Configuration Form
Name
Synopsis: Any 34 characters
Default: sys_alarm
The alarm name (e.g. as obtained via CLI:"alarms")
Level
Synopsis: { EMRG, ALRT, CRIT, ERRO, WARN, NOTE, INFO, DEBG }
Severity level of the alarm:
• EMERG - The device has had a serious failure that caused a system reboot.
• ALERT - The device has had a serious failure that did not cause a system reboot.
• CRITICAL - The device has a serious unrecoverable problem.
• ERROR - The device has a recoverable problem that does not seriously affect operation.
• WARNING - Possibly serious problem affecting overall system operation.
• NOTIFY - Condition detected that is not expected or not allowed.
• INFO - Event which is a part of normal operation, e.g. cold start, user login etc.
• DEBUG - Intended for factory troubleshooting only.
Latch
Synopsis: { On, Off }
Default: Off
Enables latching occurrence of this alarm in the Alarms Table.
Trap
Synopsis: { On, Off }
Default: Off
ROS® v3.10 User Guide
87
RMC30
3. Diagnostics
Enables sending an SNMP trap for this alarm.
Log
Synopsis: { On, Off }
Default: Off
Enables logging the occurrence of this alarm in syslog.txt.
LED & Relay
Synopsis: { On, Off }
Default: Off
Enables LED and fail-safe relay control for this alarm. If latching is not enabled, this field
will remain disabled.
Refresh Time
Synopsis: 0 s to 60 s
Default: 60 s
Refreshing time for this alarm.
3.1.5. Viewing and Clearing Alarms
Alarms are displayed in the order in which they occurred, even if the real time clock was
incorrect at the time of the alarm.
Figure 3.4. Alarm Table
Level
Synopsis: { EMRG, ALRT, CRIT, ERRO, WARN, NOTE, INFO, DEBG }
Severity level of alarm - refer to Level, above, for a detailed breakdown of the levels.
Time
Synopsis: MMM DD HH:MM
Time of first occurrence of the alarm.
Description
Synopsis: Any 127 characters
Description of the alarm; gives details about the frequency of the alarm if it has occurred
again since the last clear.
Alarms can be cleared from the Clear Alarms option.
ROS® v3.10 User Guide
88
RMC30
3. Diagnostics
3.2. Viewing CPU Diagnostics
Figure 3.5. CPU Diagnostics Form
Running Time
Synopsis: DDDD days, HH:MM:SS
The length of time since the device was last powered on.
Total Powered Time
Synopsis: DDDD days, HH:MM:SS
The cumulative powered up time of the device.
CPU Usage
Synopsis: 0 to 100
The percentage of available CPU cycles used for device operation as measured over the
last second.
RAM Total
Synopsis: 0 to 4294967295
The total number of bytes of RAM in the system.
RAM Available
Synopsis: 0 to 4294967295
The total number of bytes of RAM still available.
Temperature
Synopsis: -32768 to 32767 C
The temperature of the CPU board.
3.3. Viewing and Clearing the System Log
The system log records various events including reboots, user sign-ins, alarms and
configuration saves.
ROS® v3.10 User Guide
89
RMC30
3. Diagnostics
Figure 3.6. Viewing the System Log
The system log will continue to accumulate information until it becomes full. There is enough
room in the file to accumulate logs for months or years under normal operation.
The Clear System Log option will clear the system log. Clearing the log is recommended after
a firmware upgrade.
3.4. Viewing Product Information
Figure 3.7. Product Information Form
ROS® v3.10 User Guide
90
RMC30
3. Diagnostics
MAC Address
Synopsis: ##-##-##-##-##-## where ## ranges 0 to FF
Shows the unique MAC address of the device.
Order Code
Synopsis: 31 characters
Shows the order code of the device.
Serial Number
Synopsis: 31 characters
Shows the serial number of the device.
Boot Version
Synopsis: 47 characters
Shows the version and the build date of the boot loader software.
Main Version
Synopsis: 47 characters
Shows the version and build date of the main operating system software.
Hardware ID
Synopsis: { 47 characters }
Shows the type, part number, and revision level of the hardware.
3.5. Loading Factory Default Configuration
The Load Factory Defaults menu is used to reset the unit’s configuration to its factory default.
Optionally, it is possible to exclude parameters that affect basic connectivity and SNMP
management from the reset in order to be able to remain in communication with the device.
Specifically, configuration items in the following categories are not affected by a selective
configuration reset:
•
•
•
•
•
IP Interfaces
IP Gateways
SNMP Users
SNMP Security to Group Maps
SNMP Access
The menu presents a choice of whether to reset all or only the selected set of configuration
parameters to their factory default values:
ROS® v3.10 User Guide
91
RMC30
3. Diagnostics
Figure 3.8. Load Factory Defaults Dialog
Defaults Choice
Synopsis: { None, Selected, All }
This parameter allows the user to choose to load defaults to Selected tables (i.e. excluding
those listed above), which would preserve configuration of the tables that are critical for
basic communication and switch management applications, or to force All tables to default
settings.
It is possible to explicitly reset configuration items in the exceptional categories
listed above to their default values by using the “sql” command. Please refer to the
section entitled: “Upgrading Firmware and Managing Configurations”.
3.6. Resetting the Device
This operation will close all open Telnet connections and warm-start the device after the user
has confirmed the reset operation from the Reset Device option.
Figure 3.9. Reset Device Dialog
ROS® v3.10 User Guide
92
RMC30
4. Using the CLI Shell
4. Using the CLI Shell
ROS® Command Line Interface (CLI) support enables:
• Execution of commands from a CLI shell.
• Remote execution of commands using RSH or SSH.
• Switching between the CLI shell and the menu system.
Different commands may be available to users at different login session security
levels (guest, operator or administrator).
The ROS CLI shell may be accessed from a terminal session to the device. A terminal session
may be established in one of three ways:
• Direct cable, via RS-232.
• Remote via RSH.
• Remote via SSH.
When a terminal session is first established to the ROS device, the user interface presented
will be the full-screen menu interface. Please refer to Section Section 1.1, “The ROS® User
Interface” for more detail on the menu interface.
The Command Line Interface (CLI) shell may be accessed from any menu by pressing <CtrlS>. Any menu operation in progress, such as changing a configuration parameter, will be
terminated. You may return to the menu system by pressing <Ctrl-S> again or by entering
“exit<CR>” at the shell prompt.
This chapter describes a selection of the most useful commands in detail. For a complete list
of available commands, please refer to Appendix E, Command Line Listing.
4.1. Summary Of CLI Commands available in ROS®
Type “help” and press Enter to see the list of commands available at the current session
access level. For more information on the ROS CLI commands, see Appendix E, Command
Line Listing.
4.2. Obtaining Help For A Command
Help related to the usage of a particular command may be obtained by entering “help command
name <CR>” at the shell prompt.
>help type
Displays the contents of a text file.
Enter 'dir' for a directory listing of files.
TYPE filename
Figure 4.1. Displaying Help For A Command
4.3. Viewing Files
RuggedCom devices maintain a number of volatile and non-volatile files. These files can aid
in the resolution of problems and serve as a useful gauge of the device’s health.
ROS® v3.10 User Guide
93
RMC30
4. Using the CLI Shell
4.3.1. Listing Files
Enter “dir<CR>” to obtain a complete list of files and a description of each.
Each file has associated attributes, as described under the Attr column in “dir”
command. Files marked “R” are readable, i.e. may be uploaded by the user. Files
marked “W” are writable, i.e. may be modified (downloaded) by the user. Files
marked “B” are binary files, i.e. may be upgraded by the user.
The most useful files include config.csv, crashlog.txt and syslog.txt. These files may be viewed
by using the “type” command, specifying the desired filename.
>dir
Directory of RuggedSwitch
-------------------------------------------------------------------------------Free files:
21 of 32
Free handles: 31 of 32
Free blocks: 1024 of 1024
Block size:
4096
-------------------------------------------------------------------------------Filename
Size Hdls Blks Attr Description
-------------------------------------------------------------------------------dir.txt
0
1
1 R
Listing of files and attributes.
boot.bin
342930
0
0 RWB Boot firmware
main.bin
1424310
0
0 RWB Operating system firmware
fpga.xsvf
55921
0
0 RWB FPGA programming file binary file
factory.txt
161
0
0 RW Factory data parameters
config.csv
8555
0
0 RW System settings
config.bak
8555
0
0 RW System settings backup
crashlog.txt
0
0
0 RW Log of debilitating system events
syslog.txt
3105
0
0 RW Log of system events
sdram.bin
16777216
0
0 R B Image of entire SDRAM memory
flash.bin
4194304
0
0 R B Image of entire Flash memory
--------------------------------------------------------------------------------
Figure 4.2. Displaying The Directory Of A ROS Device
4.3.2. Viewing and Clearing Log Files
The crashlog.txt and syslog.txt files contain historical information about events that have
occurred.
The crashlog.txt file will contain debugging information related to problems that might have
resulted in unplanned restarts of the device or which may effect the device operation. A file
size of 0 bytes indicates that no untoward events have occurred.
The syslog.txt file contains a record of significant events including startups, configuration
modifications, firmware upgrades and database re-initializations due to feature additions.
Syslog.txt file will accumulate information until it fills, holding approximately 3 megabytes of
characters.
The “clearlogs” command resets these logs. It is recommended to run “clearlogs” command
after every firmware upgrade.
4.4. Managing The Flash Filesystem
The flashfiles command is an interface to three utilities for obtaining information about and
for managing the Flash filesystem maintained by ROS:
ROS® v3.10 User Guide
94
RMC30
4. Using the CLI Shell
• Flash filesystem statistics display.
• Detailed information about a specific file.
• Flash filesystem defragmentation tool.
>help flashfiles
A set of diagnostic commands to display information about the Flash filesystem
and to defragment flash memory.
flashfiles
When no parameters are provided, statistics about the Flash memory and
filesystem are printed.
flashfiles info [filename]
Provides information about a specific file in the Flash filesystem.
flashfiles defrag
Defragments files in the Flash filesystem.
Figure 4.3. Flashfiles command summary
4.4.1. Flash Filesystem Memory Mapping
When the flashfiles command is invoked with no arguments, a listing is displayed of files
currently in Flash memory, their locations, and the amount of memory they consume:
>flashfiles
-------------------------------------------------------------------------------Filename
Base
Size Sectors
Used
-------------------------------------------------------------------------------boot.bin
00000000 0C0000
0-11
748878
main.bin
000C0000 2A0000
12-53
2726050
fpga.xsvf
00360000 010000
54-54
55784
syslog.txt
00370000 050000
55-59
278721
banner.txt
003C0000 010000
60-60
256
crashlog.txt
003D0000 010000
61-61
256
config.bak
003E0000 010000
62-62
20456
config.csv
003F0000 008000
63-63
20456
factory.txt
003FC000 004000
66-66
512
--------------------------------------------------------------------------------
Figure 4.4. Flashfile Memory Mapping Summary
4.4.2. Obtaining Information On A Particular File
When the flashfiles command is invoked with the key word, info, followed by the name of a
file in memory as arguments, detailed information is displayed for the named file. For example:
ROS® v3.10 User Guide
95
RMC30
4. Using the CLI Shell
>flashfiles info main.bin
Flash file information for main.bin:
Header version
: 4
Platform
: ROS-CF52
File name
: main.bin
Firmware version : v3.8.0.QA3
Build date
: Oct 23 2009 13:32
File length
: 2726770
Board IDs
: ff
1
9
b
8
4
5 11 15 13
2
7
3 10
c
Header CRC
: 0827
Header CRC Calc : 0827
Body CRC
: a270
Body CRC Calc
: a270
a
14
d
19
f
12
17
18
16
Figure 4.5. Obtaining Information About "main.bin"
4.4.3. Defragmenting The Flash Filesystem
The flash memory defragmenter should be used in a case when not enough flash memory
is left for a binary upgrade. Fragmentation may occur, for example, when switching between
different firmware image versions that require different numbers of memory sectors. Sectors
of available memory can become separated by ones allocated to files. It may be, for example,
that the total available memory might be sufficient for a firmware update, but that memory may
not be available in one contiguous region, as is required by ROS.
Note that Flash memory defragmentation is implemented as an automatically invoked function
in bootloaders v2.15.1 and greater.
4.5. Pinging a Remote Device
The “ping” command sends an ICMP echo request to a remotely connected device. For each
reply received, the round trip time is displayed.
The command, “ping <IP address>”, will send a small number of pings to the device with this
IP address and display the results. The ping command can be used to verify connectivity to
the next connected device. It is a useful tool for testing commissioned links. This command
also includes the ability to send a specific number of pings with a specified time for which to
wait for a response.
The specification of a large number of pings and a short response time can “flood” a link,
stressing it more than a usual ping sequence. The command “ping 192.168.0.1 500 2” can be
used to issue 500 pings, each separated by two milliseconds to the next device. If the link used
is of high quality, then no pings should be lost and the average round trip time should be small.
The device to be pinged must support ICMP echo. Upon commencing the ping,
an ARP request for the MAC address of the device is issued. If the device to be
pinged is not on the same network as the device pinging the other device, the
default gateway must be programmed.
4.6. Tracing Events
The CLI trace command provides a means to trace the operation of various protocols
supported by the device. Trace provides detailed information including RSTP packet decodes,
IGMP activity and MAC address displays.
ROS® v3.10 User Guide
96
RMC30
4. Using the CLI Shell
Tracing has been designed to provide detailed information to expert users. Note
that all tracing is disabled upon device startup.
In order to display the current trace settings and discover the systems that are being traced,
enter the CLI command “trace ?”.
trace ?
Supported commands:
noclear
Starts the log without clearing it first
alloff
Disables all trace subsystems from tracing
allon
Enables all flags in all trace subsystems
stp
Traces STP operations
link
Displays switch fabric statistics
mac
Displays MAC Events
forward
Forwards trace messages to an IP:UDP address
igmp
Displays IGMP Snooping events
gvrp
Displays GVRP events
webs
Traces Web Server connections
dhcpra
Traces DHCP Relay Agent
802.1X
Traces 802.1X PAE
ip
Traces IP communications
Enter "trace command ?" for more information on a particular command.
STP :
LINK :
MAC :
FORW :
IGMP :
GVRP :
WEBS :
DHCPRA
802.1X
IP
:
Logging all conditions on port(s) 1-10
Logging is disabled
Logging is disabled
IP: 0.0.0.0 UDP: 0 (OFF)
Logging is disabled
Logging is disabled
Logging is disabled
: Logging is disabled
: Logging is disabled
Logging is disabled
Figure 4.6. Displaying Trace Settings
4.6.1. Enabling Trace
Tracing can be enabled on a per subsystem basis. Obtain detailed information about
individual subsystems by entering “trace subsystem_name ?<CR>”. Some subsystems offer
a mechanism to enable tracing only on certain ports.
ROS® v3.10 User Guide
97
RMC30
4. Using the CLI Shell
>trace stp ?
trace stp syntax:
stp [-|+] [all] [verbose] [packets] [timers] [actions]
[decodes] [ports[port_number|all]]
STP : Logging is disabled
>trace stp all
STP : Logging all conditions on port(s) 1-16
>trace link ?
trace link syntax
link changes | stats | allon | alloff | statsonce
LINK : Logging is disabled
>trace link changes
LINK : changes
>
Figure 4.7. Enabling Trace
4.6.2. Starting Trace
To start trace, enter “trace<CR>”. All historical trace messages may be displayed using “trace
noclear<CR>”. Since this may include many messages, it may be more desirable to use the
“trace clear<CR>” command instead. This command will automatically clear the trace buffer
as it starts the trace.
>trace stp - all
STP : Logging is disabled
>trace stp decodes
STP : Logging decodes
>trace stp port 7
STP
: Logging decodes on port(s) 7
> trace link changes
LINK : changes
>trace
Log has been cleared
009.445 IGMP TX General Query, VLAN
1, gr. 000.000.000.000,
to ports ALL VLAN PORTS
010.543 LINK Link 7 has risen.
000.550 RSTP TX port 7 RST BPDU: TCack 0 agg 1 lrn 0 fwd 0 role DP prop 1 TC 0
root 32768/0adc001000 cst 38, brdg 32768/0adc005000, prt 128/7
age 2.00, maxage 20, hello 2, fwddelay 15 V1Length 0
000.557 RSTP RX port 7 RST BPDU: TCack 0 agg 1 lrn 0 fwd 0 role DP prop 1 TC 0
root 32768/0adc004000 cst 0, brdg 32768/0adc004000, prt 128/14
age 0.00, maxage 20, hello 2, fwddelay 15 V1Length 0
Figure 4.8. Starting Trace
The trace package includes the “forward” subsystem, a remote reporting facility
intended to be used only under the direction of RuggedCom service personnel.
ROS® v3.10 User Guide
98
RMC30
4. Using the CLI Shell
4.7. Viewing DHCP Learned Information
The CLI command “ipconfig<CR>” will provide the current IP address, subnet mask and default
gateway. This command provides the only way of determining these values when DHCP is
used.
4.8. Executing Commands Remotely Through RSH
The Remote Shell (RSH) facility can be used from a workstation to cause the product to act
upon commands as if they were entered at the CLI prompt. The syntax of the RSH command
is usually of the form:
rsh ipaddr –l auth_token command_string
where:
• ipaddr = The address or resolved name of the RuggedCom device.
• auth_token = The authentication token, which for ROS rsh is the user name (guest,
operator, or admin) and corresponding password separated by a comma. For example,
to run a command as user - "admin" with password - "secret", the token would be:
"admin,secret".
• command_string = The ROS shell command to execute.
The access level (corresponding to the user name) selected must support the given command.
Any output from the command will be returned to the workstation submitting the command.
Commands that start interactive dialogs (such as trace) cannot be used.
4.9. Resetting the Device
The CLI command “reset<CR>” can be used to reset the device.
ROS® v3.10 User Guide
99
RMC30
5. Firmware Upgrade and Configuration Management
5. Firmware Upgrade and Configuration Management
ROS® provides flexible, powerful mechanisms for the bulk update and backup of system
firmware and of the configuration database. The ROS firmware and configuration database
are represented as files in the internal file system, and bulk update and backup consist of
simply transferring files to and from the ROS device, by one of the several means provided.
ROS also implements an SQL command language in order to provide the flexibility and power
of a database model when configuring ROS-based devices.
5.1. Files Of Interest
The files in ROS that may be updated and backed up are described below:
• main.bin: the main ROS application firmware image – Upgrades to ROS are made via
updates to this file.
• boot.bin: the boot loader firmware image – In normal practice, the boot loader does not
require updating.
• fpga.xsvf: the FPGA firmware binary image – not normally updated.
• config.csv: the complete configuration database, in the form of a comma-delimited ASCII
text file.
• banner.txt: contains text that appears on the login screen when ‘Custom’ is selected for the
Login Banner in the System Identification Table.
• logo.gif: the image, typically a company logo, that appears on the device’s log in page. The
maximum file size is 32K.
5.2. File Transfer Mechanisms
Several mechanisms are available to transfer these files to and from a ROS-based device:
•
•
•
•
Xmodem using the ROS CLI over a (telnet or RS232) console session.
TFTP client (using the ROS CLI in a console session and a remote TFTP server).
TFTP server (from a remote TFTP client).
SFTP (secure FTP over SSH, from a remote SFTP client).
5.3. Console Sessions
Console sessions may be established (depending on the settings in the IP Services menu)
by the following means:
•
•
•
•
RS232 direct RS232 serial connection to the ROS device.
telnet remote terminal protocol via TCP/IP (unencrypted).
RSH Remote SHell, the remote login shell protocol via TCP/IP (unencrypted).
SSH Secure SHell, the standard remote login shell protocol via TCP/IP – Both authentication
and session are encrypted.
5.4. Upgrading Firmware
Upgrading ROS firmware may sometimes be necessary in order to take advantage of new
features or bug fixes. In normal circumstances, only the main ROS application firmware is
updated; the boot loader and FPGA firmware remain invariant. The main ROS application
ROS® v3.10 User Guide
100
RMC30
5. Firmware Upgrade and Configuration Management
firmware image is a binary file available from RuggedCom. Please check the RuggedCom
web site, www.RuggedCom.com, for the availability of updates to ROS firmware or contact
RuggedCom support.
Firmware upgrades may be performed using any of the transfer methods and protocols listed
in Section 5.2, “File Transfer Mechanisms”.
5.4.1. Applying the Upgrade
Binary firmware images transferred to the ROS-based device are stored in non-volatile
memory and require a device reset in order to take effect. The “version” ROS shell command
will display any firmware updates that are pending. Currently running firmware is labeled
“Current”; pending upgrades are labeled “Next”:
>version
Current ROS-CF52 Boot Software v2.14.0 (Sep 29 2008 13:25)
Current ROS-CF52 Main Software v3.6.0 (Oct 03 2008 09:33)
Next
ROS-CF52 Main Software v3.7.0 (Jun 02 2009 08:36)
ROS firmware is provided as a compressed installation image. When this compressed image
is run for the first time, it decompresses itself and reinstalls the decompressed image to Flash
memory. Subsequent device reboots will use the decompressed image.
5.4.2. Security Considerations
File transfers using methods that require ROS login authentication, namely Xmodem, SFTP,
and the ROS TFTP client, are subject to the following conditions:
• transfers from the ROS-based device may be performed by any user with login privileges.
• transfers to the ROS-based device may only be performed by those with administrator
privileges.
The exception is that the SFTP server does not support transmission of the firmware or
configuration file using anything less than administrator privileges.
File transfers (in both directions) that make use of the ROS TFTP server do not require
authentication, since TFTP does not define an authentication scheme. Instead, the TFTP
server must be enabled from the IP Services Configuration Menu when it is needed.
It is recommended to use the ROS TFTP server (or any TFTP server) only on a
secure network, owing to TFTP’s lack of an authentication scheme. Even so, and
especially in a production environment, it is also recommended to leave the TFTP
server enabled for only as long as it is needed.
The following sections describe briefly how to upgrade the main application firmware using
each of the mechanisms provided by ROS.
5.4.3. Upgrading Firmware Using XModem
This method requires that the binary image file of the main ROS application firmware, along
with serial terminal or telnet software and the ability to do Xmodem transfers, be available
on a computer with an RS232 or network connection, respectively, to the ROS device to be
upgraded.
Establish a console connection with administrative privileges, either via the RS232 port or
via telnet. Enter the ROS command, “xmodem receive main.bin<CR>”. When ROS responds
ROS® v3.10 User Guide
101
RMC30
5. Firmware Upgrade and Configuration Management
with “Press Ctrl-X to cancel”, begin your Xmodem transmission, using the means provided by
your terminal software. After the file transfer has been completed, the device will provide an
indication that the file has been transferred successfully. The transcript of a sample exchange,
looking at the ROS CLI, follows:
>xmodem receive main.bin
Press Ctrl-X to cancel
Receiving data now ...C
Received 1428480 bytes. Closing file main.bin ...
main.bin transferred successfully
If possible, select the “XModem 1K” protocol for transmission; otherwise, select “XModem”.
The device must be reset in order for the new software to take effect. If you want to reset the
device immediately, enter “reset<CR>”. The device will reboot within a few seconds.
5.4.4. Upgrading Firmware Using the ROS TFTP Server
This method requires that the binary image file of the main ROS application firmware, along
with TFTP client software, be available on a computer with a network connection to the ROS
device to be upgraded.
The TFTP Server parameter in IP Services Configuration controls how a TFTP
client can access the device’s built-in TFTP server. A setting of “Disabled” prevents
all access, “Get Only” allows retrieval of files only, and “Enabled” allows both
storing and retrieval of files. Ensure that this parameter is set appropriately for the
type of access you wish to perform.
Enable TFTP transfers to the ROS device, as noted above. Begin a TFTP transfer in binary
mode to the device, specifying a destination filename of “main.bin”. A TFTP client utility will
provide an indication that the file was transferred properly, but it is recommended to also query
the device directly in order to verify successful transfer. Establish a console session to the
ROS device (using RS232, telnet, or SSH) and enter the “version” command, as described
in Applying the Upgrade, above. If the transfer was successful, the version of the firmware
file that was transferred will appear as the “Next” firmware version, i.e. that will appear after
the next reset.
The transcript of a sample TFTP transfer, looking at a DOS/Windows CLI, follows:
C:\>tftp -i 10.1.0.1 put C:\files\ROD-CF52_Main_v3.7.0.bin main.bin
Transfer successful: 1428480 bytes in 4 seconds, 375617 bytes/s
5.4.5. Upgrading Firmware Using the ROS® TFTP Client
This method requires that the binary image file of the main ROS application firmware, along
with a correctly configured TFTP server, be available on a computer with a network connection
to the ROS device to be upgraded.
Identify the IP address of the host providing the TFTP server capability. Ensure that the
firmware revision to be downloaded (e.g. ROS-CF52_Main_v3.7.0.bin) is present there.
Establish a console connection with administrative privileges to the ROS device to be
upgraded (i.e. via RS232, telnet, or SSH). Enter the CLI shell and run the TFTP client command
to receive the firmware image, for example:
tftp <TFTP server> get <remote filename> main.bin
ROS® v3.10 User Guide
102
RMC30
5. Firmware Upgrade and Configuration Management
where:
• TFTP server is the IP address of the TFTP server
• remote filename is the name of the binary image file of the main ROS application firmware
residing in the TFTP server outgoing directory
Verify, as above, the successful transfer via the ROS CLI “version” command. A sample
transcript from the ROS CLI:
>tftp 10.0.0.1 get ROS-CF52_Main_v3.7.0.bin main.bin
TFTP CMD: main.bin transfer ok. Please wait, closing file ...
TFTP CMD: main.bin loading succesful.
>version
Current ROS-CF52 Boot Software v2.14.0 (Sep 29 2008 13:25)
Current ROS-CF52 Main Software v3.6.0 (Oct 03 2008 09:33)
Next
ROS-CF52 Main Software v3.7.0 (Jun 02 2009 08:36)
5.4.6. Upgrading Firmware Using SFTP
This method requires that the binary image file of the main ROS application firmware, along
with SFTP client software, be available on a computer with a network connection to the ROS
device to be upgraded. SFTP is the Secure File Transfer Protocol (also known as the SSH
File Transfer Protocol), a file transfer mechanism that uses SSH to encrypt every aspect of
file transfer between a networked client and server.
Establish an SFTP connection with administrative privileges to the ROS device to be upgraded.
Begin a transfer to the device, specifying a destination filename of “main.bin”. An SFTP
client utility will provide an indication that the file was transferred properly, but, again, it is
recommended to also query the device directly in order to verify successful transfer. A sample
SFTP session to upgrade the ROS main firmware image from a Linux workstation follows:
[email protected]$ sftp [email protected]_ip
Connecting to ros_ip...
[email protected]_ip's password:
sftp> put ROS-CF52_Main_v3-7-0.bin main.bin
Uploading ROS-CF52_Main_v3-7-0.bin to /main.bin
ROS-CF52_Main_v3-7-0.bin
100% 2139KB
sftp>
48.6KB/s
00:44
5.5. Updating Configuration
ROS maintains its complete configuration in an ASCII text file, in CSV (Comma-Separated
Value) format. All configuration changes, whether they are performed using the web interface,
console interface, CLI, SNMP, or SQL, are stored in this one file. The file, named config.csv,
may be read from and written to the ROS device in all the same ways that firmware image
files can, as described in the preceding sections. The configuration file may be copied from
the unit and used as a backup, to be restored at a later date. Configuration files from different
units may be compared using standard text processing tools.
The transfer mechanisms supported for the update of config.csv are the same as for ROS
firmware image files:
• Xmodem using the ROS CLI over a console session.
• TFTP client (using the ROS CLI in a console session and a remote TFTP server).
• TFTP server (from a remote TFTP client).
ROS® v3.10 User Guide
103
RMC30
5. Firmware Upgrade and Configuration Management
• SFTP (secure FTP over SSH, from a remote SFTP client).
Please refer to the preceding section, Section 5.4, “Upgrading Firmware”, for examples of the
use of each of these mechanisms for transferring a file to a ROS device.
Configuration File Format
The format of the configuration file makes it simple to apply a wide variety of tools to the task
of maintaining ROS configuration. Among the applications that may be used to manipulate
ROS configuration files are:
• Any text editing program capable of reading and writing ASCII files.
• Difference/patching tools (e.g. the UN*X “diff” and “patch” command line utilities).
• Source Code Control systems (e.g. CVS, SVN).
ROS also has the ability to accept partial configuration updates. It is possible to, for example,
update only the parameters for a single Ethernet port. Transferring a file containing only the
following lines to a ROS device will result in an update of the parameters for Ethernet port 1
without changing any other parameters of the device’s configuration:
# Port Parameters
ethPortCfg
Port,Name,Media,State,AutoN,Speed,Dupx,FlowCtrl,LFI,Alarm,
1,Port 1,100TX,Enabled,On,Auto,Auto,Off,Off,On,
Applying the Configuration Update
Once a configuration file has been successfully transferred to a ROS device, irrespective of
the transfer method, the device will reset itself automatically. Note that this behavior differs
from that when upgrading firmware files, where a reset command must be issued by the
administrator.
Security Considerations
The same limitations apply to writing config.csv to the ROS device that apply to firmware
images. Refer to section Section 5.4, “Upgrading Firmware” for details on the permissions
necessary to write the ROS configuration file.
5.6. Backing Up ROS System Files
All of the same file transfer mechanisms discussed in the preceding sections may also be
used to transfer files from a ROS device, as well as to update firmware or configuration files.
It might be desirable, in addition to creating an archive of the device’s firmware files, to back
up the configuration database, config.csv, or system log file, syslog.txt, on a regular basis.
Type “dir” at the ROS CLI for a listing and description of files on the ROS device.
An example of backing up a file using SFTP follows. For descriptions on the use of the other
file transfer mechanisms, please refer to the examples in Section 5.4, “Upgrading Firmware”.
Note that only the direction of file transfer changes.
5.6.1. Backing Up Files Using SFTP
This method requires that SFTP client software be available on a computer with a network
connection to the ROS device that one wishes to back up. Establish an SFTP connection with
administrative privileges to the ROS device. Begin transferring the desired file from the device.
ROS® v3.10 User Guide
104
RMC30
5. Firmware Upgrade and Configuration Management
An example of using an SFTP session to create a local backup of the ROS main firmware
image to a Linux workstation follows:
user31host$ sftp admin31ros_ip
Connecting to ros_ip...
admin31ros_ip's password:
sftp> get main.bin
Downloading /main.bin
main.bin
sftp>
100% 2139KB
48.7KB/s
00:44
All files in ROS may be backed up using an SFTP session with administrative privileges.
5.7. Using SQL Commands
The ROS provides an “SQL-like” command facility that allows expert users to perform several
operations not possible under the user interface, namely:
• Restoring the contents of a specific table, but not the whole configuration, to their factory
defaults.
• Search tables in the database for specific configurations.
• Make changes to tables predicated upon existing configurations.
When combined with RSH, SQL commands provide a means to query and configure large
numbers of devices from a central location.
5.7.1. Getting Started
SQL information is obtainable via the CLI shell “SQL” command:
>sql
The SQL command provides an 'sql like' interface for manipulating all system
configuration and status parameters. Entering 'SQL HELP command-name' displays
detailed help for a specific command. Commands, clauses, table, and column
names are all case insensitive.
DEFAULT
Sets all records in a table(s) to factory defaults.
DELETE
Allows for records to be deleted from a table.
HELP
Provides help for any SQL command or clause.
INFO
Displays a variety of information about the tables in the database
INSERT
Allows for new records to be inserted into a table.
SAVE
Saves the database to non-volatile memory storage.
SELECT
Queries the database and displays selected records.
UPDATE
Allows for existing records in a table to be updated.
5.7.2. Finding the Correct Table
Many SQL commands operate upon specific tables in the database, and require the table
name to be specified. Navigating the menu system to the desired menu and pressing <CtrlZ> will show the name of the table. The menu name and the corresponding database table
name will be cited.
Another way to find a table name is to run the “sql info tables” command. This command also
displays menu names and their corresponding database table names depending upon the
features supported by the device:
Table
Description
-------------------------------------------------------------------------------
ROS® v3.10 User Guide
105
RMC30
5. Firmware Upgrade and Configuration Management
alarms
cpuDiags
ethPortCfg
ethPortStats
ethPortStatus
ipCfg
Alarms
CPU Diagnostics
Port Parameters
Ethernet Statistics
Port Status
IP Services
5.7.3. Retrieving Information
Retrieving a Table
The SQL select subcommand is used to retrieve table information. The command, “sql select
from ‘tablename’”, provides a summary of the parameters within the table, as well as their
values:
>sql select from ipcfg
IP Address Type IP Address
Subnet
Gateway
Management VLAN
Inactivity Timeout Telnet Sessions Allowed Web Server Users Allowed TFTP Server
ModBus Address SSH Sessions Allowed
Static
10.90.0.2
255.0.0.0
1
Disabled
8
16
Get Only
Disabled
8
1 records selected
Retrieving a Parameter from a Table
SQL select command may be used to retrieve a particular parameter from a table. SQL
command “sql select parameter_name from tablename” is used for this purpose. The
parameter name is always the same as those displayed in the menu system. If the parameter
name has spaces in it (e.g. “IP Address”) the spaces must be replaced with underscores or
the name must be quoted:
>sql select "ip address" from ipcfg
IP Address
192.168.0.8
1 records selected
Retrieving a Table with the ‘Where’ Clause
It is useful to be able to display specific rows of a table predicated upon the row having
parameters of a specific value. Addition of "where" clause to the "select" statement will limit
the results returned. For example, suppose that it is desirable to identify all ports on the device
operating in Auto Select mode:
>sql select from ethportcfg where Media_Type = Auto_Select
Port Name
5
Port 7
6
Port 8
Status
Enabled
Enabled
Media Type Flow Control FEFI
Link Alarms
Auto Select Enabled
Disabled Enabled
Auto Select Disabled
Disabled Enabled
2 records selected
It is also possible to select rows based on multiple parameters using "and" and "or" operations
between comparisons in the "where" clause. For example:
ROS® v3.10 User Guide
106
RMC30
5. Firmware Upgrade and Configuration Management
>sql select from ethportcfg where Media_Type = Auto_Select and Flow_control =
Disabled
Port Name
6
Port 8
Status
Enabled
Media Type Flow Control FEFI
Link Alarms
Auto Select Disabled
Disabled Enabled
1 records selected
5.7.4. Changing Values in a Table
The "where" clause can be used to select rows in a table and to modify the fields in that row.
As an example, suppose that it is desirable to identify all ports on the device operating in 100
Mbps full-duplex mode with flow control disabled, and to enable flow control on these ports:
>sql update ethportcfg set flow_control=enabled where ( media_type = Auto_Select
and flow_control = disabled )
1 records updated
5.7.5. Setting Default Values in a Table
It is sometimes desirable to restore one table to its factory defaults without modifying the
remainder of the configuration. The “sql default” command allows an individual table to be
defaulted.
>sql default into ethportcfg
5.7.6. Using RSH and SQL
The combination of remote shell scripting and SQL commands offers a means to interrogate
and maintain a large number of devices. Consistency of configuration across sites may
be verified by this method. The following presents a simple example where the devices to
interrogate are drawn from the file “Devices”:
C:> type Devices
10.0.1.1
10.0.1.2
10.0.1.3
c:\> for /F %i in (devices) do rsh %i -l admin,admin sql select from ethportcfg
where flow_control = disabled
C:\>rsh 10.0.1.1 -l admin,admin sql select from ethportcfg where flow_control =
disabled
Port Name
5
Port 5
Status
Enabled
Media Type Flow Control FEFI
Link Alarms
Auto Select Disabled
Disabled Enabled
1 records selected
C:\>rsh 10.0.1.2 -l admin,admin sql select from ethportcfg where flow_control =
disabled
0 records selected
C:\>rsh 10.0.1.3 -l admin,admin sql select from ethportcfg where flow_control =
disabled
Port Name
ROS® v3.10 User Guide
Status
Media Type
107
Flow Control FEFI
Link Alarms
RMC30
5. Firmware Upgrade and Configuration Management
3
7
8
13
Port
Port
Port
Port
3
7
8
13
Enabled
Enabled
Enabled
Enabled
Auto
Auto
Auto
Auto
Select
Select
Select
Select
Disabled
Disabled
Disabled
Disabled
Disabled
Disabled
Disabled
Disabled
Enabled
Enabled
Enabled
Enabled
4 records selected
C:\
ROS® v3.10 User Guide
108
RMC30
Appendix A. SNMP MIB Support
Appendix A. SNMP MIB Support
A.1. Standard MIBs
Module Name
Supported Groups
SNMP-FRAMEWORK-MIB
snmpEngineGroup
UDP-MIB
udpGroup
TCP-MIB
tcpGroup
SNMP-VIEW-BASED-ACM-MIB
vacmBasicGroup
SNMPv2-MIB
snmpGroup
snmpCommunityGroup
snmpSetGroup
systemGroup
snmpBasicNotificationsGroup
SNMP-USER-BASED-SM-MIB
usmMIBBasicGroup
RSTP-MIB
rstpBridgeGroup
rstpPortGroup
RS-232-MIB
rs232Group rs232AsyncGroup
RMON-MIB
rmonEtherStatsGroup rmonHistoryControlGroup
rmonEthernetHistoryGroup
rmonAlarmGroup
rmonEventGroup
Q-BRIDGE-MIB
qBridgeBaseGroup
qBridgeVlanGroup
qBridgeVlanStaticGroup
qBridgePortGroup2
qBridgeFdbUnicastGroup
qBridgeFdbMulticastGroup
LLDP-MIB
lldpConfigGroup
lldpConfigRxGroup
lldpConfigTxGroup
lldpStatsRxGroup
lldpStatsTxGroup
lldpLocSysGroup
lldpRemSysGroup
lldpNotificationsGroup
IEEE8023-LAG-MIB
dot3adAggPortListGroup
IP-MIB
ipGroup
icmpGroup
IF-MIB
ifGeneralInformationGroup
ifVHCPacketGroup
ifCounterDiscontinuityGroup
linkUpDownNotificationsGroup
BRIDGE-MIB
ROS® v3.10 User Guide
dot1dBaseBridgeGroup dot1dBasePortGroup
109
RMC30
Appendix A. SNMP MIB Support
Module Name
Supported Groups
dot1dStpBridgeGroup
dot1dStpPortGroup
dot1dTpBridgeGroup
dot1dTpFdbGroup
dot1dTpGroup
dot1dNotificationGroup
Table A.1. Standard MIBs
A.2. RuggedCom proprietary MIBs
Module Name
Supported Groups
RUGGEDCOM-TRAPS-MIB
ruggedcomGenericTrapGroup
ruggedcomPowerSupplyGroup
ruggedcomNotificationsGroup
RUGGEDCOM-SYS-INFO-MIB
System Error Objects Group,
System Status Objects Group,
System Objects Temperature Group,
System Status Power Supply Group,
System Info Device Info Group
RUGGEDCOM-SERIAL-MIB
rcSerialPortParamsGroup
rcSerialMbServerGroup
rcSerialMbClientGroup
rcSerialRawSocketGroup
rcSerialPreEmpRawSockGroup
rcSeriaTinAndWinGroup
rcSerialMicrolokGroup
rcSerialDnpGroup
rcSerialDnpRsGroup
rcSerialMirrBitsGroup
rcSrialTelnetComportGroup
rcSerialConnStatsGroup
rcSerialCommandsGroup
RUGGEDCOM-SYS-INFO-MIB
rcSysErrObjectsGroup
rcSysStsObjectsGroup
rcSysStsObjectsTemperatureGroup
rcSysStsPowerSupplyGroup
rcSysInfoDeviceInfoGroup
rcSysDeviceCommGroup
RUGGEDCOM-STP-MIB
rcRstpBaseStpTxHoldCountGroup
rcRstpBaseGrop
rcRstpNotifyGroup
RUGGEDCOM-POE-MIB
rcBasePoeGroup
rcBasePoeStatusGroup
rcPoeTableGroup
ROS® v3.10 User Guide
110
RMC30
Appendix A. SNMP MIB Support
Module Name
Supported Groups
rcPoePriorityGroup
rcPoeNotifyGroup
RUGGEDCOM-STP-MIB
rcRstpBaseStpTxHoldCountGroup
rcRstpBaseGrop
rcRstpNotifyGroup
Table A.2. TITLE
ROS® v3.10 User Guide
111
RMC30
Appendix B. SNMP Trap Summary
Appendix B. SNMP Trap Summary
The switch generates the standard traps summarized in the following table.
•
•
•
•
•
from IF-MIB: linkDown, linkUp
from SNMPv2-MIB: authenticationFailure coldStart
from BRIDGE-MIB: newRoot, topologyChage
from RMON-MIB: risingAlarm, fallingAlarm
from LLDP-MIB: lldpRemoteTablesChange
The switch also generates the proprietary traps which are summarized in this document with
their severity levels. These traps are described in the RC-TRAPS-MIB.
•
•
•
•
genericTrap,
powerSupplyTrap,
swUpgradeTrap,
cfgChangeTrap
Generic Traps carry information about event in severity and description objects. They are
sent at the time that an alarm is generated for the device. The following are examples of
RuggedCom Generic Traps, along with the severity of each one in brackets:
•
•
•
•
•
•
•
•
•
heap error (alert)
NTP server failure (notification)
real time clock failure (error)
failed password (warning)
MAC address not learned by switch fabric (error)
BootP client: TFTP transfer failure (error)
received looped back BPDU (error)
received two consecutive confusing BPDUs on port, forcing down (error)
GVRP failed to learn – too many VLANs (warning)
The switch generates the following traps on specific events:
• from RUGGEDCOM-STP-MIB: rcRstpNewTopology – generated after topology becomes
stable after a topology change occurs on a switch port.
• from RUGGEDCOM-POE-MIB: rcPoeOverheat and rcPoeOverload – generated by Power
over Ethernet (PoE) overheat and overload conditions, respectively. These traps are only
generated by RS900GP devices.
ROS® v3.10 User Guide
112
RMC30
Appendix C. List of Objects Eligible for RMON Alarms
Appendix C. List of Objects Eligible for RMON
Alarms
The following table lists ROS® database objects which are eligible for RMON alarms:
dot1dBasePortMtuExceededDiscards
The number of frames discarded by this port due to an excessive
size.
dot1dTpPortInFrames
The number of frames that have been received by this port from its
segment.
dot1dTpPortOutFrames
The number of frames that have been transmitted by this port to its
segment.
dot1qVlanNumDeletes
The number of times a VLAN entry has been deleted from the
dot1qVlanCurrentTable (for any reason). If an entry is deleted, then
inserted, and then deleted, this counter will be incremented by 2.
etherStatsBroadcastPkts
The number of good Broadcast packets received.
etherStatsCollisions
The best estimate of the total number of collisions on this Ethernet
segment.
etherStatsCRCAlignErrors
The number of packets received which meet all the following
conditions:1. Packet data length is between 64 and 1536 bytes
inclusive.2. Packet has invalid CRC.3. Collision Event has not been
detected.4. Late Collision Event has not been detected.
etherStatsDropEvents
The number of received packets that are dropped due to lack of
receive buffers.
etherStatsFragments
The number of packets received which meet all the following
conditions:1. Packet data length is less than 642. Collision Event
has not been detected.3. Late Collision Event has not been
detected.4. CRC invalid.
etherStatsJabbers
The total number of packets received that were longer than 1518
bytes and had either a bad Frame Check Sequence or Alignment
Error.
etherStatsMulticastPkts
The number of good Multicast packets received.
etherStatsOctets
The number of bytes in received good packets (Unicast+Multicast
+Broadcast) and dropped packets.
etherStatsOversizePkts
The number of packets received with data length greater than 1536
bytes and valid CRC.
etherStatsPkts
The number of received good packets (Unicast+Multicast
+Broadcast) and dropped packets
etherStatsPkts1024to1518Octets
The total number of received packets that were between 1024 and
1518 bytes long.
etherStatsPkts128to255Octets
The total number of received packets that were between 128 and
255 bytes long.
etherStatsPkts256to511Octets
The total number of received packets that were between 256 and
511 bytes long.
etherStatsPkts512to1023Octets
The total number of received packets that were between 512 and
1023 bytes long.
etherStatsPkts64Octets
The total number of received packets that were 64 bytes long.
etherStatsPkts65to127Octets
The total number of received packets that were between 65 and 127
bytes long.
etherStatsUndersizePkts
The number of received packets which meet all the following
conditions:1. Packet data length is less than 64 bytes.2. Collision
ROS® v3.10 User Guide
113
RMC30
Appendix C. List of Objects Eligible for RMON Alarms
Event has not been detected.3. Late Collision Event has not been
detected.4. Packet has valid CRC.
ifHCInBroadcastPkts
The total number of good packets received that were directed
to the broadcast address. This object is a 64 bit version of
ifInBroadcastPkts.
ifHCInMulticastPkts
The total number of good packets received that were directed to
multicast address.
ifHCInOctets
The total number of bytes received on the interface, including
framing characters. This object is a 64 bit version of ifInOctets.
ifHCInUcastPkts
The number of packets, delivered by this sub-layer to a higher
(sub-)layer, which, were not addressed to a multicast or broadcast
address at this sub-layer. This object is a 64 bit version of
ifInUcastPkts.
ifHCOutBroadcastPkts
The total number of packets transmitted that were directed
to the broadcast address. This object is a 64 bit version of
ifOutBroadcastPkts.
ifHCOutMulticastPkts
The total number of packets transmitted that were directed
to multicast address. This object is a 64 bit version of
ifOutMulticastPkts.
ifHCOutOctets
The total number of bytes transmitted out of the interface. This object
is a 64 bit version of ifOutOctets.
ifInBroadcastPkts
The total number of good packets received that were directed to the
broadcast address.
ifInDiscards
The number of received packets that are dropped due to lack of
receive buffers.
ifInErrors
The number of received packets that contained errors preventing
them from being deliverable to a higher-layer protocol.
ifInMulticastPkts
The total number of good packets received that were directed to
multicast address.
ifInNUcastPkts
The number of packets, delivered by this sub-layer to a higher
(sub-)layer, which, were addressed to a multicast or broadcast
address at this sub-layer.
ifInOctets
The total number of bytes received on the interface, including
framing characters.
ifInUcastPkts
The number of packets, delivered by this sub-layer to a higher
(sub-)layer, which, were not addressed to a multicast or broadcast
address at this sub-layer.
ifOutBroadcastPkts
The total number of packets transmitted that were directed to the
broadcast address.
ifOutMulticastPkts
The total number of packets transmitted that were directed to
multicast address.
ifOutNUcastPkts
The total number of transmitted packets which were addressed to a
multicast or broadcast address.
ifOutOctets
The total number of bytes transmitted out of the interface.
ifOutUcastPkts
The total number of transmitted packets which were not addressed
to a multicast or broadcast address. This object is a 64 bit version
of ifOutUcastPkts.
ifOutUcastPkts
The total number of transmitted packets which were not addressed
to a multicast or broadcast address.
ipForwDatagrams
The number of input datagrams for which this entity was not their
final IP destination, as a result of which an attempt was made to find
ROS® v3.10 User Guide
114
RMC30
Appendix C. List of Objects Eligible for RMON Alarms
a route to forward them to that final destination. In entities which do
not act as IP routers, this counter will include only those packets
which were Source-Routed via this entity, and the Source-route
option processing was successful.
ipFragCreates
The number of IP datagram fragments that have been generated as
a result of fragmentation at this entity.
ipFragFails
The number of IP datagrams that have been discarded because
they needed to be fragmented at this entity but could not be, e.g.,
because their Don't Fragment flag was set.
ipFragOKs
The number of IP datagrams that have been successfully
fragmented at this entity.
ipInAddrErrors
The number of input datagrams discarded because the IP address
in their header's destination field was not a valid address to be
received at this entity. This count includes invalid addresses and
addresses of unsupported Classes. For entities which are not
IP routers and therefore do not forward datagrams, this counter
includes datagrams discarded because the destination address was
not a local address.
ipInDelivers
The total number of input datagrams successfully delivered to IP
user-protocols (including ICMP)
ipInDiscards
The number of input IP datagrams for which no problems were
encountered to prevent their continued processing, but which were
discarded (e.g., for lack of buffer space). Note that this counter does
not include any datagrams discarded while awaiting reassembly
ipInHdrErrors
The number of input datagrams discarded due to errors in their
IP headers, including bad checksums, version number mismatch,
other format errors, time-to-live exceeded, errors discovered in
processing their IP options, etc.
ipInReceives
The total number of input datagrams received from interfaces,
including those received in error.
ipInUnknownProtos
The number of locally addressed datagrams received successfully
but discarded because of an unknown or unsupported protocol.
ipOutDiscards
The number of output IP datagrams for which no problem was
encountered to prevent their transmission to their destination, but
which were discarded (e.g., for lack of buffer space). Note that this
counter would include datagrams counted in ipForwDatagrams if
any such packets met this (discretionary) discard criterion.
ipOutNoRoutes
The number of IP datagrams discarded because no route could be
found to transmit them to their destination. Note that this counter
includes any packets counted in ipForwDatagrams which meet this
`no-route' criterion. Note that this includes any datagrams which a
host cannot route because all of its default routers are down.
ipOutRequests
The total number of IP datagrams which local IP user-protocols
(including ICMP) supplied to IP in requests for transmission. Note
that this counter does not include any datagrams counted in
ipForwDatagrams.
ipRasmReqds
The number of IP fragments received which needed to be
reassembled at this entity.
ipReasmFails
The number of IP datagrams successfully reassembled.
lldpStatsRemTablesAgeouts
The number of times the complete set of information has been
deleted from tables contained in lldpRemoteSystemsData objects
because the information timeliness interval has expired.
ROS® v3.10 User Guide
115
RMC30
Appendix C. List of Objects Eligible for RMON Alarms
lldpStatsRemTablesDeletes
The number of times the complete set of information has been
deleted from tables contained in lldpRemoteSystemsData objects.
lldpStatsRemTablesDrops
The number of times the complete set of information could not be
entered into tables contained in lldpRemoteSystemsData objects
because of insufficient resources.
lldpStatsRemTablesInserts
The number of times the complete set of information has been
inserted into tables contained in lldpRemoteSystemsData.
lldpStatsRxPortAgeoutsTotal
The counter that represents the number of age-outs that occurred
on a given port. An age-out is the number of times the complete
set of information advertised by a neighbour has been deleted from
tables contained in lldpRemoteSystemsData objects because the
information timeliness interval has expired.
lldpStatsRxPortFramesDiscardedTotal
The number of LLDP frames received by this LLDP agent on the
indicated port and then discarded for any reason. This counter
can provide an indication that LLDP header formatting problems
may exist with the local LLDP agent in the sending system or that
LLDPDU validation problems may exist with the local LLDP agent
in the receiving system.
lldpStatsRxPortFramesErrors
The number of invalid LLDP frames received by this LLDP agent on
the indicated port, while this LLDP agent is enabled.
lldpStatsRxPortFramesTotal
The number of valid LLDP frames received by this LLDP agent on
the indicated port, while this LLDP agent is enabled.
lldpStatsRxPortTLVsDiscardedTotal
The number of LLDP TLVs discarded for any reason by this LLDP
agent on the indicated port.
lldpStatsRxPortTLVsUnrecognizedTotal
The number of LLDP TLVs received on the given port that are not
recognized by this LLDP agent on the indicated port.
rcDeviceStsTemperature
The temperature measured in the device.
rs232AsyncPortFramingErrs
The total number of characters with a framing error, input from the
port since system re-initialization.
rs232AsyncPortOverrunErrs
The total number of characters with an overrun error, input from the
port since system re-initialization.
rs232AsyncPortParityErrs
The total number of characters with a parity error, input from the port
since system re-initialization.
snmpInASNParseErrs
The total number of ASN.1 or BER errors encountered by the SNMP
Agent decoding received SNMP messages.
snmpInBadCommunityNames
The total number of SNMP messages delivered to the SNMP Agent
which represented an SNMP operation which was not allowed by
the SNMP community named in the message.
snmpInBadCommunityNames
The total number of SNMP messages delivered to the SNMP Agent
which used a unknown SNMP community name.
snmpInBadVersions
The total number of SNMP messages which were delivered to the
SNMP Agent and were for an unsupported SNMP version.
snmpInPkts
The number of messages delivered to the SNMP Agent.
tcpActiveOpens
The number of times TCP connections have made a direct transition
to the SYN-SENT state from the CLOSED state.
tcpAttemptFails
The number of times TCP connections have made a direct transition
to the CLOSED state from either the SYN-SENT or the SYN-RCVD,
plus the number of times TCP connections have made a direct
transition to the LISTEN state from the SYN-RCVD.
tcpCurrEstab
The number of TCP connections for which the current state is either
ESTABLISHED or CLOSE- WAIT.
ROS® v3.10 User Guide
116
RMC30
Appendix C. List of Objects Eligible for RMON Alarms
tcpEstabResets
The number of times TCP connections have made a direct transition
to the CLOSED state from either the ESTABLISHED state or the
CLOSE-WAIT state
tcpInSegs
The total number of segments received, including those received in
error.
tcpOutSegs
The total number of segments sent, including those on current
connections but excluding those containing only retransmitted
bytes.
tcpPassiveOpens
The number of times TCP connections have made a direct transition
to the SYN-RCVD state from the LISTEN state.
tcpRetransSegsDescr
The total number of segments retransmitted - that is, the number
of TCP segments transmitted containing one or more previously
transmitted bytes.
udpInDatagrams
The total number of UDP datagrams received and delivered to UDP
users.
udpInErrors
The number of received UDP datagrams that could not be delivered
for reasons other than the lack of an application at the destination
port.
udpNoPorts
The total number of received UDP datagrams for which there was
no application at the destination port.
udpOutDatagrams
The number of sent UDP datagrams.
ROS® v3.10 User Guide
117
RMC30
Appendix D. ModBus Management Support and Memory
Map
Appendix D. ModBus Management Support and
Memory Map
ModBus management support in RuggedCom devices provides a simple interface for
retrieving basic status information. ModBus support simplifies the job of SCADA (Supervisory
Control And Data Acquisition) system integrators by providing familiar protocol for the retrieval
of RuggedCom device information. ModBus provides mostly read-only status information, but
there are also a few writable registers for operator commands.
The ModBus protocol PDU (Protocol Data Unit) format is as follows:
Function Code
Data
RuggedCom devices support the following ModBus function codes for device management
through ModBus:
1. Read Input Registers or Read Holding Registers – 0x04 or 0x03, for which the Modbus
PDU looks like:
Request
Function code
1 Byte
0x04(0x03)
Starting Address
2 Bytes
0x0000 to 0xFFFF
Number of Input Registers
2 Bytes
0x0001 to 0x007D
Function code
1 Byte
0x04(0x03)
Byte Count
1 Byte
2 x N*
Input Registers
N*X2 Bytes
Response
*N = the number of Input Registers
2. Write Multiple Registers – 0x10:
Request
Function code
1 Byte
0x10
Starting Address
2 Bytes
0x0000 to 0xFFFF
Number of Registers
2 Bytes
0x0001 to 0x0079
Byte Count
1 Byte
2 x N*
Registers Value
N* x 2 Bytes
Value of the register
*N = the number of Input Registers
Response
Function code
1 Byte
0x10
Starting Address
2 Bytes
0x0000 to 0xFFFF
Number of Registers
2 Bytes
1 to 121 (0x79)
Note that as RuggedCom devices have a variable number of ports, not all registers and bits
apply to all products.
ROS® v3.10 User Guide
118
RMC30
Appendix D. ModBus Management Support and Memory
Map
Registers that are not applicable to a particular product return a zero value. For example,
registers referring to serial ports are not applicable to RuggedSwitch® products.
No Ethernet port statistics are available for the Ethernet port on RMC30.
D.1. Modbus Memory Map
Address
#Registers
Description (Reference Table in UI)
R/W
Format
PRODUCT INFO (table Name: ProductInfo)
0000
16
Product Identification
R
Text
0010
32
Firmware Identification
R
Text
0040
1
Number of Ethernet Ports
R
Uint16
0041
1
Number of Serial Ports
R
Uint16
0042
1
Number of Alarms
R
Uint16
0043
1
Power Supply Status
R
PSStatusCmd
0044
1
FailSafe Relay Status
R
TruthValue
0045
1
ErrorAlarm Status
R
TruthValue
PRODUCT WRITE REGISTERS (table Name: various tables)
0080
1
Clear Alarms
W
Cmd
0081
2
Reset Ethernet Ports
W
PortCmd
0083
2
Clear Ethernet Statistics
W
PortCmd
0085
2
Reset Serial Ports
W
PortCmd
0087
2
Clear Serial Port Statistics
W
PortCmd
ALARMS (table Name: alarms)
0100
64
Alarm 1
R
Alarm
0140
64
Alarm 2
R
Alarm
0180
64
Alarm 3
R
Alarm
01C0
64
Alarm 4
R
Alarm
0200
64
Alarm 5
R
Alarm
0240
64
Alarm 6
R
Alarm
0280
64
Alarm 7
R
Alarm
02C0
64
Alarm 8
R
Alarm
R
PortCmd
ETHERNET PORT STATUS (table Name: ethPortStats)
03FE
2
Port Link Status
ETHERNET STATISTICS (table Name: rmonStats)
0400
2
Port 1 Statistics - Ethernet In Packets
R
Uint32
0402
2
Port 2 Statistics - Ethernet In Packets
R
Uint32
0404
2
Port 3 Statistics - Ethernet In Packets
R
Uint32
0406
2
Port 4 Statistics - Ethernet In Packets
R
Uint32
ROS® v3.10 User Guide
119
RMC30
Appendix D. ModBus Management Support and Memory
Map
Address
#Registers
Description (Reference Table in UI)
R/W
Format
0408
2
Port 5 Statistics - Ethernet In Packets
R
Uint32
040A
2
Port 6 Statistics - Ethernet In Packets
R
Uint32
040C
2
Port 7 Statistics - Ethernet In Packets
R
Uint32
040E
2
Port 8 Statistics - Ethernet In Packets
R
Uint32
0410
2
Port 9 Statistics - Ethernet In Packets
R
Uint32
0412
2
Port 10 Statistics - Ethernet In Packets
R
Uint32
0414
2
Port 11 Statistics - Ethernet In Packets
R
Uint32
0416
2
Port 12 Statistics - Ethernet In Packets
R
Uint32
0418
2
Port 13 Statistics - Ethernet In Packets
R
Uint32
041A
2
Port 14 Statistics - Ethernet In Packets
R
Uint32
041C
2
Port 15 Statistics - Ethernet In Packets
R
Uint32
041E
2
Port 16 Statistics - Ethernet In Packets
R
Uint32
0420
2
Port 17 Statistics - Ethernet In Packets
R
Uint32
0422
2
Port 18 Statistics - Ethernet In Packets
R
Uint32
0424
2
Port 19 Statistics - Ethernet In Packets
R
Uint32
0426
2
Port 20 Statistics - Ethernet In Packets
R
Uint32
0440
2
Port 1 Statistics - Ethernet Out Packets R
Uint32
0442
2
Port 2 Statistics - Ethernet Out Packets R
Uint32
0444
2
Port 3 Statistics - Ethernet Out Packets R
Uint32
0446
2
Port 4 Statistics - Ethernet Out Packets R
Uint32
0448
2
Port 5 Statistics - Ethernet Out Packets R
Uint32
044A
2
Port 6 Statistics - Ethernet Out Packets R
Uint32
044C
2
Port 7 Statistics - Ethernet Out Packets R
Uint32
044E
2
Port 8 Statistics - Ethernet Out Packets R
Uint32
0450
2
Port 9 Statistics - Ethernet Out Packets R
Uint32
0452
2
Port 10 Statistics - Ethernet Out Packets R
Uint32
0454
2
Port 11 Statistics - Ethernet Out Packets R
Uint32
0456
2
Port 12 Statistics - Ethernet Out Packets R
Uint32
0458
2
Port 13 Statistics - Ethernet Out Packets R
Uint32
045A
2
Port 14 Statistics - Ethernet Out Packets R
Uint32
045C
2
Port 15 Statistics - Ethernet Out Packets R
Uint32
045E
2
Port 16 Statistics - Ethernet Out Packets R
Uint32
0460
2
Port 17 Statistics - Ethernet Out Packets R
Uint32
0462
2
Port 18 Statistics - Ethernet Out Packets R
Uint32
0464
2
Port 19 Statistics - Ethernet Out Packets R
Uint32
0466
2
Port 20 Statistics - Ethernet Out Packets R
Uint32
0480
2
Port 1 Statistics - Ethernet In Octets
R
Uint32
0482
2
Port 2 Statistics - Ethernet In Octets
R
Uint32
0484
2
Port 3 Statistics - Ethernet In Octets
R
Uint32
ROS® v3.10 User Guide
120
RMC30
Appendix D. ModBus Management Support and Memory
Map
Address
#Registers
Description (Reference Table in UI)
R/W
Format
0486
2
Port 4 Statistics - Ethernet In Octets
R
Uint32
0488
2
Port 5 Statistics - Ethernet In Octets
R
Uint32
048A
2
Port 6 Statistics - Ethernet In Octets
R
Uint32
048C
2
Port 7 Statistics - Ethernet In Octets
R
Uint32
048E
2
Port 8 Statistics - Ethernet In Octets
R
Uint32
0490
2
Port 9 Statistics - Ethernet In Octets
R
Uint32
0492
2
Port 10 Statistics - Ethernet In Octets
R
Uint32
0494
2
Port 11 Statistics - Ethernet In Octets
R
Uint32
0496
2
Port 12 Statistics - Ethernet In Octets
R
Uint32
0498
2
Port 13 Statistics - Ethernet In Octets
R
Uint32
049A
2
Port 14 Statistics - Ethernet In Octets
R
Uint32
049C
2
Port 15 Statistics - Ethernet In Octets
R
Uint32
049E
2
Port 16 Statistics - Ethernet In Octets
R
Uint32
04A0
2
Port 17 Statistics - Ethernet In Octets
R
Uint32
04A2
2
Port 18 Statistics - Ethernet In Octets
R
Uint32
04A4
2
Port 19 Statistics - Ethernet In Octets
R
Uint32
04A6
2
Port 20 Statistics - Ethernet In Octets
R
Uint32
04C0
2
Port 1 Statistics - Ethernet Out Octets
R
Uint32
04C2
2
Port 2 Statistics - Ethernet Out Octets
R
Uint32
04C4
2
Port 3 Statistics - Ethernet Out Octets
R
Uint32
04C6
2
Port 4 Statistics - Ethernet Out Octets
R
Uint32
04C8
2
Port 5 Statistics - Ethernet Out Octets
R
Uint32
04CA
2
Port 6 Statistics - Ethernet Out Octets
R
Uint32
04CC
2
Port 7 Statistics - Ethernet Out Octets
R
Uint32
04CE
2
Port 8 Statistics - Ethernet Out Octets
R
Uint32
04D0
2
Port 9 Statistics - Ethernet Out Octets
R
Uint32
04D2
2
Port 10 Statistics - Ethernet Out Octets R
Uint32
04D4
2
Port 11 Statistics - Ethernet Out Octets R
Uint32
04D6
2
Port 12 Statistics - Ethernet Out Octets R
Uint32
04D8
2
Port 13 Statistics - Ethernet Out Octets R
Uint32
04DA
2
Port 14 Statistics - Ethernet Out Octets R
Uint32
04DC
2
Port 15 Statistics - Ethernet Out Octets R
Uint32
04DE
2
Port 16 Statistics - Ethernet Out Octets R
Uint32
04E0
2
Port 17 Statistics - Ethernet Out Octets R
Uint32
04E2
2
Port 18 Statistics - Ethernet Out Octets R
Uint32
04E4
2
Port 19 Statistics - Ethernet Out Octets R
Uint32
04E6
2
Port 20 Statistics - Ethernet Out Octets R
Uint32
SERIAL STATISTICS (table Name: uartPortStatus)
0600
2
ROS® v3.10 User Guide
Port 1 Statistics – Serial In characters
121
R
Uint32
RMC30
Appendix D. ModBus Management Support and Memory
Map
Address
#Registers
Description (Reference Table in UI)
R/W
Format
0602
2
Port 2 Statistics – Serial In characters
R
Uint32
0604
2
Port 3 Statistics – Serial In characters
R
Uint32
0606
2
Port 4 Statistics – Serial In characters
R
Uint32
0640
2
Port 1 Statistics – Serial Out characters R
Uint32
0642
2
Port 2 Statistics – Serial Out characters R
Uint32
0644
2
Port 3 Statistics – Serial Out characters R
Uint32
0646
2
Port 4 Statistics – Serial Out characters R
Uint32
0680
2
Port 1 Statistics – Serial In Packets
R
Uint32
0682
2
Port 2 Statistics – Serial In Packets
R
Uint32
0684
2
Port 3 Statistics – Serial In Packets
R
Uint32
0686
2
Port 4 Statistics – Serial In Packets
R
Uint32
06C0
2
Port 1 Statistics – Serial Out Packets
R
Uint32
06C2
2
Port 2 Statistics – Serial Out Packets
R
Uint32
06C4
2
Port 3 Statistics – Serial Out Packets
R
Uint32
06C6
2
Port 4 Statistics – Serial Out Packets
R
Uint32
D.1.1. Text
This format provides a simple ASCII representation of the information related to the product.
ASCII characters’ most significant byte of register comes first.
For example, consider a “Read Multiple Registers” request to read Product Identification from
location 0x0000.
0x04
0x00
0x00
0x00
0x08
The response may look like:
0x04
0x10
0x53
0x59
0x53
0x00
0x00
0x00
0x00
0x00
0x54
0x45
0x4D
0x20
0x4E
0x41
0x4D
0x45
In this example, starting from byte 3 until the end, the response presents an ASCII
representation of the characters for the product identification, which reads as “SYSTEM
NAME”. The length of this field is smaller than eight registers, so the rest of the field is filled
with zeros.
D.1.2. Cmd
This format instructs the device to set the output to either ‘true’ or ‘false’. The most significant
byte comes first.
• FF 00 hex requests output to be True.
• 00 00 hex requests output to be False.
• Any value other than the suggested values does not affect the requested operation.
ROS® v3.10 User Guide
122
RMC30
Appendix D. ModBus Management Support and Memory
Map
For example, consider a “Write Multiple Registers” request to clear alarms in the device.
0x10
0x00
0x80
0x00
0x01
2
0xFF
0x00
• FF 00 for register 00 80 clears the system alarms
• 00 00 does not clear any alarms
The response may look like:
0x10
0x00
0x80
0x00
0x01
D.1.3. Uint16
This format describes a Standard Modbus 16-bit register.
D.1.4. Uint32
This format describes Standard 2 Modbus 16-bit registers. The first register holds the most
significant 16 bits of a 32 bit value. The second register holds the least significant 16 bits of
a 32 bit value.
D.1.5. PortCmd
This format describes a bit layout per port, where 1 indicates the requested action is true, and
0 indicates the requested action is false.
PortCmd provides a bit layout of a maximum of 32 ports; therefore, it uses two Modbus
registers:
• The first Modbus register corresponds to ports 1 – 16.
• The second Modbus register corresponds to ports 17 – 32 for a particular action.
Bits that do not apply to a particular product are always set to zero.
A bit value of 1 indicates that the requested action is true. For example: the particular port
is “up”.
A bit value of 0 indicates that the requested action is false. For example: the particular port
is “down”.
Reading data using PortCmd:
For example, consider a Modbus Request to read multiple registers from location 0x03FE.
0x04
0x03
0xFE
0x00
0x02
The response depends on how many ports are available on the device. For example, if the
maximum number of ports on a connected RuggedCom device is 20, the response would look
like the following:
0x04
0x04
0xF2
0x76
0x00
0x05
In this example, bytes 3 and 4 refer to register 1 at location 0X03FE, and represent the status
of ports 1–16. Bytes 5 and 6 refer to register 2 at location 0x03FF, and represent the status
of ports 17–32. In this example, the device only has 20 ports, so byte 6 contains the status
ROS® v3.10 User Guide
123
RMC30
Appendix D. ModBus Management Support and Memory
Map
for ports 17-20 starting from right to left. The rest of the bits in register 2 corresponding to the
non-existing ports 21–31 are zero.
Performing write actions using PortCmd:
For example, consider a “Write Multiple Register” request to clear Ethernet port statistics:
0x10
0x00
0x83
0x00
0x01
2
0x55
0x76
0x00
0x50
A bit value of 1 is a command to clear Ethernet statistics on a corresponding port. A bit value
of 0 is a command to “do nothing” on a corresponding port.
The response may look like:
0x10
0x00
0x81
0x00
0x02
D.1.6. Alarm
This format is another form of text description. Alarm text corresponds to the alarm description
from the table holding all of the alarms. Similar to the ‘Text’ format, this format returns ASCII
representation of alarms. Note that alarms are stacked in the RuggedCom device in the
sequence of their occurrence. That is, the first alarm on the stack is Alarm 1, the next latched
alarm in the device is Alarm 2, and so on. You can return the first eight alarms from the stack,
if they exist. A zero value is returned if an alarm does not exist.
D.1.7. PSStatusCmd
This format describes a bit layout for providing the status of available power supplies. Bits 0–
4 of the lower byte of the register are used for this purpose.
Bits 0–1: Power Supply 1 Status.
Bits 2–3: Power supply 2 Status
The rest of the bits in the register do not provide any system status information.
Bit Value
Description
01
Power Supply not present (01 = 1).
10
Power Supply is functional (10 = 2).
11
Power Supply is not functional (11 = 3).
Table D.1. PSStatusCmd Bit Values
The values used for power supply status are derived from the RuggedCom-specific SNMP
MIB.
Read Power Supply Status from device using PSStatusCmd:
In this example, consider a Modbus Request to read multiple registers from location 0x0043.
0x04
0x00
0x43
0x00
0x01
Response may look like:
0x04
0x02
0x00
0x0A
The lower byte of the register displays the power supplies’ status. In this example, both power
supplies in the unit are functional.
ROS® v3.10 User Guide
124
RMC30
Appendix D. ModBus Management Support and Memory
Map
D.1.8. TruthValue
This format represents a true or false status in the device:
• 1 – indicates the corresponding status for the device to be true.
• 2 – indicates the corresponding status for the device to be false.
Read FailSafe Relay status from device using TruthValue:
For example, consider a Modbus Request to read multiple registers from location 0x0044.
0x04
0x00
0x44
0x00
0x01
Response may look like:
0x04
0x02
0x00
0x01
The register’s lower byte shows the FailSafe Relay status. In this example, the failsafe relay
is energized.
Read ErrorAlarm status from device using TruthValue:
For example, consider a Modbus Request to read multiple registers from location 0x0045.
0x04
0x00
0x45
0x00
0x01
Response may look like:
0x04
0x02
0x00
0x01
The register’s lower byte shows the alarm status. In this example, there is no active ERROR,
ALERT or CRITICAL alarm in the device.
ROS® v3.10 User Guide
125
RMC30
Appendix E. Command Line Listing
Appendix E. Command Line Listing
The following commands are available at the command line of ROS®-based RuggedSwitch®
and RuggedServer™ devices:
alarms
Displays list of available alarms.
Usage: alarms [all]
all - display all alarm instances
(default empty) - display one instance of each alarm type.
arp
Displays the IP to MAC address resolution table.
clearalarms
Clears all alarms
clearethstats
Clears Ethernet statistics for one or more port(s)
clearethstats ports|'all'
'ports' - comma separated port numbers (e.g. '1,3-5,7')
'all' - all ports
clearlogs
Clears the system and crash logs
clrcblstats
Clears Cable Diagnostics statistics for one or more port(s).
clrcblstats ports|'all'
ports - comma separated port numbers (e.g. '1,3-5,7')
'all' - all ports
clearstpstats
Clear all spanning tree statistics.
cls
Clears the screen
dir
Prints file directory listing
exit
Terminate this command line session
flashfiles
A set of diagnostic commands to display information about the Flash
filesystem and to defragment Flash memory.
Usage: flashfiles
Displays Flash memory statistics and Flash memory file system contents.
Usage: flashfiles info [filename]
Displays information about the specified file in the Flash filesystem.
Usage: flashfiles defrag
Defragments files in the Flash filesystem.
flashleds
Flashes the unit LED indicators for the specified number of seconds.
Usage: flashleds timeout
timeout: the number of seconds to flash the unit LED indicators. To stop
flashing the LEDs, set timeout to 0 (zero).
help
help [command name]
[command name] - Name of command for which to get help.
If no command is specified, a list of all available commands is displayed
along with a brief description of each one.
ipconfig
Displays IP configuration
loaddflts
Load Factory Default Configuration.
login
Login to the shell i.e. set the access level
logout
Logout of the shell
ping
Usage: ping {dest} [count] [timeout]
ROS® v3.10 User Guide
126
RMC30
Appendix E. Command Line Listing
dest Target IP address.
count Number of echo requests to send; default is 4.
timeout Timeout in milliseconds to wait for each reply;
range is 2-5000, default is 300 milliseconds.
purgemac
Purge the MAC Address Table.
reset
Perform a 'hard' reset of the switch
resetport
Reset one or more Ethernet ports which may be useful for forcing renegotiation of speed and duplex or in situations where the link partner has
latched into an inappropriate state.
RESETPORT ports|'all'
'ports' - comma separated port numbers (e.g. '1,3-5,7')
'all' - all ports will be reset
rmon
Displays names of RMON alarm eligible objects
route
Displays gateway configuration
sql
The SQL command provides an 'sql like' interface for manipulating
all system configuration and status parameters. Entering 'SQL HELP
command-name' displays detailed help for a specific command.
Commands, clauses, table, and column names are all case insensitive.
DEFAULT Sets all records in a table(s) to factory defaults.
DELETE Allows for records to be deleted from a table.
HELP Provides help for any SQL command or clause.
INFO Displays a variety of information about the tables in the database
INSERT Enables new records to be inserted into a table.
SAVE Saves the database to non-volatile memory storage.
SELECT Queries the database and displays selected records.
UPDATE Enables existing records in a table to be updated.
telnet
Usage: telnet dest
dest: Server's IP address.
NOTE: <Ctrl-C> closes telnet session
tftp
Usage: tftp server cmd fsource fdest
server: Remote TFTP server's IP address
cmd: put (upload) or get (download)
fsource: Source filename
dest: Destination filename
NOTE: <Ctrl-C> stops a tftp transfer.
trace
Starts event tracing. Run "trace ?" for more help.
type
Displays the contents of a text file.
Enter 'dir' for a directory listing of files.
type filename
version
Prints software versions
xmodem
xmodem direction filename
direction: send - send file to client
receive - receive file from client
filename: Enter 'dir' for list of all filenames
ROS® v3.10 User Guide
127
RMC30
Index
Index
Modbus Client Configuration, 65
Modbus Server Configuration, 64
A
P
Alarms
Active Alarms, 84
Critical Failure Relay, 85
Passive Alarms, 85
Using Alarms, 84
Passwords, 23
Preemptive Raw Socket Configuration, 62
C
CLI Shell Command
clearlogs, 94
dir, 94
Flashfile, 94
help, 93
ipconfig, 99
ping, 96
reset, 99
Summary, 93
trace, 96
type, 94
Configuration
Update, 103
D
Diagnostics
CPU Diagnostics, 89
Product Information, 90
System Log, 89
DNP Configuration, 69
DNP over Raw Socket Configuration, 70
F
Factory Default Configuration, Loading, 91
Firmware
SFTP Upgrade, 103
TFTP Client Upgrade, 102
TFTP Server Upgrade, 102
Upgrade, 100
XModem Upgrade, 101
R
RADIUS, 31
Raw Socket Configuration, 58
Reset, Device, 92
ROS
RS232 Console Interface, 11
Secure Shell Server, 13
Web Server, 14
RSH, 99
S
Serial Port Configuration, 56
Serial Protocols, 42
SNMP Management, 29
SQL
Default Command, 107
Info Command, 105
Select Command, 106
Update Command, 107
Using Commands, 105
’From’ Clause, 106
’Where’ Clause, 106
Syslog, 37
T
TACACS+, 34
Time Synchronization, 25
Troubleshooting
Serial Protocols, 82
W
WIN and TIN Configuration, 66
I
Interface, 11
M
MicroLok Configuration, 68
Mirrored Bits Configuration, 72
ROS® v3.10 User Guide
128
RMC30
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement