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
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project
advertisement
© 2021