Advanced Serial Configuration Settings
Click here to see this page in full context

Generate/SecureFXsysicon.jpg  Advanced Serial Configuration Settings

The following information may be helpful to users who need a lower level of control over the serial connection.

The INI options mentioned below are found in the session's .ini file, for example <hostname>.ini in the Sessions subfolder of the Config folder. For ad hoc connections, the Default.ini file should be edited.

To avoid the possibility of damaging the INI files, close SecureCRT before editing INI files.

The location of your installation's Configuration folder is found in the General / Configuration Paths category of SecureCRT's Global Options dialog.

In SecureCRT, the serial protocol provides some config file options (INI only, but can be manipulated through scripting prior to establishing a serial connection). These options allow for finer-grained control over some of the hardware flow control lines.

Most individuals on Windows should probably use DTR/DSR flow control. Individuals should probably not use RTS/CTS in combination with DTR/DSR flow control.

Serial options which are configurable by way of the SecureCRT graphical user interface (Session Options dialog) include:

Generate/BULLET.gif    DTR/DSR hardware flow control (not available in SecureCRT for macOS and Linux platforms)

Generate/BULLET.gif    RTS/CTS hardware flow control

Generate/BULLET.gif    XON/XOFF software flow control

The two hardware flow control options are described in more detail below.

DTR/DSR Hardware Flow Control

This flow control option is NOT applicable to SecureCRT on macOS or Linux platforms.

Typical serial cables will have SecureCRT's DTR pin crossed onto the remote device's DSR pin. The device's DTR pin will be crossed onto SecureCRT's DSR pin as well. This means that a wire connects SecureCRT's DSR pin to the device's DTR pin.

When DTR/DSR flow control is on, SecureCRT monitors the DSR pin to determine whether or not the remote side can receive data. Physically, this pin has the same state as the DTR pin on the remote device, because they are connected by a wire. When the remote device can receive data, it turns on its DTR pin which turns on SecureCRT's DSR pin, and allows SecureCRT to proceed with sending data.

The same process is used in reverse. When SecureCRT can receive data, it turns on its DTR pin, which turns on the device's DSR pin. When SecureCRT is not able to receive data, it turns off its DTR pin, which turns off the device's DSR pin.

When DTR/DSR hardware flow control is enabled, SecureCRT:

Generate/BULLET.gif    Monitors the state of the DSR pin. SecureCRT stops sending data when it detects the DSR pin has been turned off.

Generate/BULLET.gif    Manipulates the state of the DTR pin. When SecureCRT cannot receive any more data, it turns off the DTR pin.

Generate/BULLET.gif    Ignores data received when the output DTR pin is off.

SecureCRT does not do this directly, but instructs the serial driver to act accordingly.

When DTR/DSR hardware flow control is NOT enabled, SecureCRT:

Generate/BULLET.gif    Ignores the state of the DSR pin.

Generate/BULLET.gif    Turns the DTR pin on, and does not change it.

Individuals who wish to override this behavior can set:

D:"DTR Flow Control"=0000000x

...where x is one of the following:

0 - Set DTR off, and leave it

1 - Set DTR on, and leave it (user interface DTR/DTS option = off)

2 - DTR hand-shake (user interface DTR/DTS option = on)

The setting of the INI "DTR Flow Control" variable only controls the way SecureCRT handles the DTR pin. It does not affect whether SecureCRT is sensitive to the DSR pin. This continues to be controlled by the user interface DTR/DTS option on the Session Options / Connection dialog.

RTS/CTS Hardware Flow Control

There are several different ways that RTS/CTS can be wired in serial cables, along with several different ways that the signals can be used.

RTS/CTS was originally a one-way flow control mechanism. The computer would turn RTS on when it wanted to send some data, and the device would respond by turning CTS on when it was ready to receive the data.

However, such a setup doesn't make much sense when communicating between two computers, or if a device is actually faster than the computer to which it is connected.

Modern NULL modem cables will probably do one of two things:

Generate/BULLET.gif    RTS/CTS is cross-linked -- the wire from the RTS on one side is connected to the other side's CTS pin. This causes RTS/CTS to work much like DTR/DSR.

Generate/BULLET.gif    The CTS pin can be physically connected to the RTS pin within the connector itself, making RTS/CTS flow control essentially a NO-OP.

When RTS/CTS hardware flow control is enabled, SecureCRT:

Generate/BULLET.gif    Monitors the CTS pin and suspends output whenever it is turned off.

Generate/BULLET.gif    Turns on the RTS pin whenever the input buffer is less than 1/2 full.

Generate/BULLET.gif    Turns off the RTS pin whenever the input buffer is more than 3/4 full.

When RTS/CTS hardware flow control is NOT enabled, SecureCRT:

Generate/BULLET.gif    Ignores the CTS pin.

Generate/BULLET.gif    Turns the RTS pin on and leaves it on.

Individuals who wish to override this behavior can set:

D:"RTS Flow Control"=0000000x

...where x is one of the following:

0 - Set RTS off, and leave it off.

1 - Set RTS on, and leave it on (use interface RTS/CTS option = off).

2 - RTS hand-shake (user interface RTS/CTS option = on).

3 - RTS toggle: RTS is on/high if there are bytes to send. Otherwise it is off/low. This corresponds to the original way RTS/CTS worked. This option is only available under NT/2000/XP, not on Windows 95 and derived systems (e.g., 98, 98se, ME, etc.).

In summary, the INI "RTS Flow Control" variable does not affect SecureCRT's sensitivity to the CTS pin. It only affects the way SecureCRT manipulates the RTS pin.