============================================== == MR9600 version 2.54.00 release information == ============================================== Contents --------------------------------------- 1. Changes in 2.54.00 2. MR9600 MIB 3. Update 4. Known Limitations 5. New Controller Commands --------------------------------------- -- 1. Changes in 2.54.00 ----------------- This is a feature release of the CommPlete Communications Server. Support has been added to email faults to as many as 5 email addresses. Email recipients are setup using the SMTPSETUP command. Designating a fault to trigger an email notification is done via the SETFAULTS command. The UPTIME and VER commands have been expanded to return information about devices. A new help operator ? has been added. Usage is ?# where # is any alphabetic character. The result of this command will be to list all controller commands that begin with that character. Support has been added for V.110 connections. Support has been added for E1 cards. This includes the ability to configure or monitor a card's status. The -v (version), -u (uptime) and -? (help) options have been added to the get device commands (GETDEVICES, GETMODEMS, GETRAS, GETT1, etc.). New built-in IP Query modules have been added. When loaded they allow a remote MCM supervisor to obtain pre-defined information about the controller. These modules may be modified or new ones added if additional information is desired. -- 2. MR9600 MIB --------------------- The MIB can be found on the MultiCommManager release disk 7.xx or on the Multi-Tech FTP site ftp.multitech.com in the file MMM/SOFTWARE/MIB/MULTI1.MIB -- 3. Update -------------------------- UPDATE is used to send new firmware to the controller or a device. The -BOOT option is used to write the boot code area of the device. -BOOT should only be used when it is necessary to update the device boot code along with the device firmware. This is because if the device is interrupted (i.e. reset) while the boot code area is being written, the device may be in an unrecoverable state. Requesting the device version may be used to determine the boot code version. For the T1 and PRI firmware the boot code is embedded in the firmware hex file. For the Modem, the boot code is a separate hex file. General: Make sure there is enough room on the drive to hold the hex file. FTP the hex file to the controller (B drive). Telnet to the controller. Type UPDATE (Use -BOOT only when it is necessary to update boot code.) To view progress, type UPDATE To abort ALL devices, type ABORT To abort only selected devices, type ABORT When update is complete, the hex file may be deleted. Controller: (.hxc) Make sure there is enough room on the B drive before FTPing the file. When update is complete, answer es to reboot the controller. Modem(s): (.hex) Earlier Commplete modem cards had a boot code prom that was smaller than the current one. Modems with boot code versions from 1.1 to 1.3 have a 2 meg boot code prom. Version 1.3 is the latest boot code for these modems. Modems with 1.5 to 2.0 have a 4 meg boot code prom. If version 1.5 to 2.0+ boot code is flashed into one of these early version modems, the boot code prom will be destroyed. The modem card may be examined to determine the boot code prom size (by checking the boot code version indicated on sticker applied at the factory. To get the boot code version (from the supervisor) Reset the modem and immediately request the Modem Version. The Version reported from 0 to 22 seconds after a modem is reset is the boot code version. Technical support can also look up the information using the modem serial number. T1(s): (.hxt) Type T1STATUS to get the boot code version (for 1.06 and above) the format is firmware_version/boot_code_version (1.07c/1.06) Use the -BOOT option if the boot code needs to be updated. The boot code is embedded in the .hxt file. PRI(s): (.hxp) Prior to version 2.46.43 the PRI boot code was a separate file. In versions 2.46.43 and above the PRI boot code is embedded in the .hxp file. -- 4. Known Limitations --------------- When an E1 is moved from one segment to another. The saved settings on the E1 are not preserved. The E1 settings must be loaded and saved again using E1SETUP. - Only one telnet session and only one ftp session can be active at once to the controller (one of each is OK). - The MR9600 must be managed by the MultiCommManager versions 7.xx or later - It is best when updating devices that call traffic is kept to a minimum. If during an update of the boot code area of the device, the update errors, or the device is reset, it is remotely possible the boot code would be destroyed requiring that the boot code prom be replaced. For this reason we recommend flashing devices at off peak hours, on an (ideally) idle system. Successfully updating one card at a time is also a good practice. - PRI version 2.49.43 requires CC9600 version 2.42 or greater to operate. This version of the PRI will cause earlier versions of the CC9600 controller to reb oot. - RAS version 5.40 requires PRI version 2.50 or greater to operate. RAS 5.40 RASEXP.EXE should fail on startup if it sees an old version (pre 2.49.43) PRI. It is recommended that the CC9600 be updated to version 2.50 first, followed b y updating the PRI to 2.49.43, and finally updating the RAS to 5.40. -- 5. New Controller Commands --------- E1SETUP Supervisor level command used to setup the E1 configuarion parameters on a controller E1CFG Operator level command that sends the E1 configuration information to the E1 device. E1CHSTATUS, E1CHANNELSTATUS Guest level command that displays the state of each E1 channel and modem,and fla gs any channels that seem to be in an inconsistent state. It uses E1 channel information reported to the controller by the E1. The interval at which the E1 reports the channel status is controlled by the E1CHPOLL command. E1STATUS Guest level command that displays the E1 configuration setup information. E1CHPOLL Supervisor level command used to setup the polling interval and threshold for E1CHANNELSTATUS command. It is available for E1 firmware versions greater than 1.06A. This polling interval defines the interval (in seconds) in which the E1 will report channel status information to the controller. The threshold is the number of times an inconsistent state is recognized before the E1 channel and modem are reset. Three pieces of information are compared to determine if a channel is in an inconsistent state: the Central Office state; the E1 to modem state; and the controller modem state. NOTE: The threshold (default 6) * polling interval (default 16 seconds) should be > 90 seconds as a modem will not accept a call for 90 seconds after a reset to allow the E1 channel to clear. E1SIGPOLL Supervisor level command used to setup the polling interval and threshold used to look for inconsistent E1 channels. It is available for E1 firmware versions greater than 1.05. It is similar in function to E1CHPOLL in that finds inconsistent E1 channels and resets them after a threshold is reached. The main difference is that the E1 sends slightly different information (i.e. signal bits data) in order to make the determination. GETE1 Operator level command that displays the status of an E1. GETRASOperator level command that displays the status of a RAS. LISTMOD Supervisor level command that lists all currently loaded modules. LOADMOD Supervisor level command that loads a module. The module file should be named [ModuleName].MLM where ModuleName must be 8 characters or less. The module should reside in the A:MODULES directory. RUNMOD Supervisor level command that loads (if the module is not loaded) and runs the specified module. This has no use for the existing IP query modules, but may be useful in the future as new modules are implemented for the controller. UNLOADMOD Supervisor level command that unloads a module that was previously loaded. An error is returned if the given module is not currently loaded. SETRESETPING Supervisor level command that can be used to set the packet sizes of three consecutive pings which will cause the controller to reboot. This mechanism forr emotely resetting the controller can be used as a last resort if the telnet orSN MP interfaces are not responsive. GETRESETPING Supervisor level command that displays the packet sizes of three consecutiveping s which, when received, will result in a controller reboot. SMTPSETUP Supervisor level command that configures the controller's email information. It allows the controller to inform administrators of faults via email, Up to five recepients may be setup. Faults triggering email notifications can be set up on an individual basis using the SETFAULTS command.