This document is about some unusual (to some) behavior which can occur in environments where the Realport driver is installed for use with a Portserver TS line or Digi One RealPort(DORP) product.

The symptoms of this behavior are that setting changes made to the TS or DORP via the root account appear to be made, but when checked again at a later time they have changed. This is not a problem, but normal operation for a TS or DORP in a Realport environment.

In operation, the Realport driver's task is to take control of the physical ports of a TS or DORP, and then create psuedo devices to be used by the operating system (OS) hosting the RealPort driver. In a Windows environment, these appear as Com ports while in Unix, tty devices are created.

Once the RealPort driver is installed, all further port configuration is done at the OS level. Changes to things like flow control, baud rate, parity, forcedcd, altpin, etc. which are done on the com port/tty device at the OS level are actually being done to the TS or DORP as well. This is why it may seem like manual settings on the TS or DORP are changing, when in reality it is the driver changing them to match device configuration on the OS. In other words, the RealPort driver has control of the TS or DORP unit in all respects.

Example: A Portserver TS16, by default, has a baud rate of 9600 baud on its physical ports, as revealed by doing the command "set line range=*". If you configure port 1 on the Portserver TS16 with "set port range=1 dev=rp", it allows port 1 to be controlled by the RealPort driver. RealPort is then installed on an AIX server and configured to control port 1, now known to AIX as tty6. If the baud rate on tty6 is changed to 19200, doing a "set line range=1" will show that the baud rate on the TS port 1 has now changed accordingly.

In short, this behavior is not a bug, but is the way RealPort is intended to work so as to ease the task of port configuration for a sysadmin. The reason this feature was not available on the Portserver or Portserver II was due in part to the fact that earlier Portserver models were not as tightly integrated with the RealPort driver as the TS/DORP line of today. 

Related Information: