==============================================
== 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 <options> <pathname of .hxc file> <devices>
   (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 <devices>
   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 <Y>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 <device> 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.
 
