|
This document is intended to bring together various sources of
information on the Datacryptor® Link units. It covers common configuration
issues and suggestions for troubleshooting.
- Datacryptor® Link Introduction
This section gives some background information on how the Datacryptor®
Link unit fits into common networking environments.

Click
on picture thumbnails to view diagrams
The diagram above illustrates a circuit without
the Datacryptor® in situ. On the left there is a DTE (Data Terminating Equipment)
device
- this could be a PC, a terminal etc. On the right there is
a DCE (Data Circuit Terminating Equipment) device - this could be
a modem,
a router, a multiplexor etc. The arrows beneath the diagram
indicate which devices drive which lines on the cable (or other communications
medium). These are:
- DTR - Data Terminal Ready
- RTS - Request To Send
- DSR - Data Set Ready
- CTS - Clear To Send
- DCD - Data Carrier Detect
Using these lines the DCE and DTE negotiate handshaking, data
transfer, flow control etc.

Click
on picture thumbnail to view diagram
The Datacryptor® is now put into the circuit. If you imagine the setup above
mirrored on the other side of the cloud we would have an encrypted
tunnel set between the Datacryptor® and the data from one DTE to the other
would be encrypted. You can see in the diagram that the Datacryptor® presents
a DCE interface on its host side and a DTE interface on its network
port. The Datacryptor® controls the communication between the DTE Terminal
and the DCE modem/router but also transparently encrypts the line
data. There is another issue to consider here; the Datacryptor® is operating transparently
here - the DTE terminal believes it is connected directly to the
DCE modem/router. However, there are occasions when the Datacryptor® must
interrupt this communication flow between the two devices. When the
Datacryptor® performs a key exchange or peer management (the management of
a remote unit via a local unit) it communicates directly with the
remote Datacryptor®. This activity temporarily prevents the Datacryptor® from passing
user data from the DTE Terminal. In its default mode the Datacryptor® will
drop CTS (Clear To Send) on its host port to tell the DTE Terminal
to hold off sending data whilst the Datacryptor® performs its key exchange
etc. Different DTE devices may react differently to this behaviour
but may start generating errors (as it is trying to send data but
it is being told that it cannot). The configuration options to change
this behaviour are discussed in the next section.
- Datacryptor® Link Comms Tab Options
This section contains information on the FPV configuration options
for using the Datacryptor® Link unit. The first tab is the Comms tab. Note
that this tab only appears when using v.24, v.35 or x.21 interfaces
(not E1/T1).

Click
on picture thumbnail to view diagram
As discussed above the Datacryptor® controls the communication lines between
the DTE and DCE device. The Comms tab allows you to configure this
behaviour to take into account different device behaviour. The page
is divided into two columns - Normal and Safetalk. The Normal column
allows you to configure the line state during normal operation (i.e.
when user data is being sent/received). The Safetalk column allows
you to configure the line state during key exchange/peer management
operation. The diagram above illustrates the default settings on the Datacryptor® (which
can be recalled by pressing the "Default" button). You
can see that the default is for all the signals to remain the same
during normal/safetalk operation except for the CTS/Indicate. You
can see that during safetalk the Datacryptor® will drop CTS on its host side.
This is the behaviour discussed above where the Datacryptor® will drop CTS
during key exchange to tell the DTE device on the host side to stop
sending data. It is possible to change this behaviour to tell the
Datacryptor® to keep CTS high during safetalk. You may wish to do this if
your DTE device relies on seeing CTS high at all times. If you do
this then the DTE device will just continue sending data even though
it will not reach the intended destination. This configuration relies
on higher level protocols to recover from such loss of data.
The Network Delay option allows you to configure the amount of time
the Datacryptor® will wait whilst doing a key exchange before reporting "No
response from peer" - you may need to increase this on slow
data lines.
- Datacryptor® Link Advanced Comms Options
By clicking on the Advanced button you will see this window:
See the section below on Datacryptor® clocking issues for information
about clock polarities. By clicking on the Data Gating tab you
will see this window:
The following is taken from the Datacryptor® help file on Data Gating;
In situations where the line may become inactive, in data terms,
but may still be transmitting a holding pattern, e.g. Mark
or Space which will continue to be encrypted (or decrypted) and
passed to other equipment. This encrypted data may cause connected
equipment to believe it is receiving erroneous data. Data Gating
can be used to transmit a stream of 1’s in place of the
erroneous data. To enable Data Gating decide on the direction
the data gating is required and select the line signal which
must go "low" in order to start the data gating,
e.g.: DTR or RTS.
- Datacryptor® Link Safetalk Options
Note that this tab only appears when using v.24, v.35 or x.21
interfaces (not E1/T1).
This section contains information on the configuration options
on the Safetalk tab. Safetalk is the name given to data sent between
Datacryptor® Link units for key exchanges, peer management etc (as opposed
to user data). This tab allows you configure how the Datacryptor® decides
what preconditions must be met before it will go into Safetalk
mode. This allows you to configure how much precedence is given
to Safetalk data in relation to user data.
As you can see below, the default setting is "Don't care" for
all preconditions - this means that if the Datacryptor® has some
Safetalk data to send it will send it regardless of the
status of the line
signals on the network/host side. This effectively means
that the Datacryptor® will always interrupt user data when it
wishes to send data
in Safetalk mode.

Click
on picture thumbnail to view diagram
You may not wish this happen, you may wish for certain preconditions
to be met before entering Safetalk mode, for example you may want
to wait for CTS/Indicate to be high before entering Safetalk mode
(see below). This means that the Datacryptor® will wait for the CTS signal
on its network side to go high before entering Safetalk mode.

Click
on picture thumbnail to view diagram
The Operator section at the bottom allows you to combine different
combinations of settings using the AND or OR operators. For example
you could specify that CTS must be high AND DCD must be high before
Safetalk mode can be entered into. Or you could specify that that
CTS must be high OR RTS must be low before Safetalk mode can be entered
into. These settings assume that you have a good knowledge of the
attached DCE/DTE devices and how they behave. The Time Out setting at the top is a value in seconds which describes
how long the Datacryptor® will wait for these pre-conditions to be met. If
this time limit is exceeded the Datacryptor® will enter Safetalk mode regardless
of the preconditions specified.
- Datacryptor® setup using Cisco routers
The example below shows how to set up a Datacryptor® Link circuit using
Cisco routers and a null modem device.

Click
on picture thumbnail to view diagram
The null modem acts as the WAN link between the two Datacryptor®s and the
routers act as the LAN interface at each end of the link. The only
configuration of the routers that is needed is to add the IP addresses
on the diagram above and also to add static routes (e.g. ip
route 192.168.0.0 255.255.255.0 s0/0 on Router_01 and the equivalent on
Router_02). If you find that the Serial interface on the routers
flap (i.e. go up and down constantly) you can try turning off keepalives
on the Serial interface with the command no keepalive. - Datacryptor® clocking issues
When two synchronous devices (such as two Datacryptor®s) are connected to
each other a clock signal is required to synchronize the sending
and receiving of data between the two devices. The two devices need
to be synchronized to the same clock speed so that they send and
receive at the same rate (measured in bits per second). DTE devices
will often provide their own clock but the Datacryptor® does not and relies
on the existence of an external clock source. It is usual to derive
the clock source from the network side of the Datacryptor® although it is
possible to derive the clock source via the host port (see "get
clock sync from host" mode on the Comms tab). If the Datacryptor® Link
does not see a clock signal on the network LED will flash on and
off, a solid network LED means that Datacryptor® has detected a clock signal.
The network LED will also flash if the clock speed is out of range
(too fast) for the Datacryptor® - e.g. if you presented a clock speed of
4Mb/sec to a Standard speed Datacryptor® Link. You would also see an error
in the Datacryptor® log saying something like "Encrypt clock out of
range".
In our test example above we use an x.21 null modem to generate the
clock signal, in a real network environment the clock would probably
be provided by a router, modem or mux.
Problems can occur when the clock is generated at one end of the
link and, because of the delay caused by the link, the clock signal
is delayed when it reaches the other end. This can cause the Datacryptor®s
to become out of sync because they are not using the same clock signal
to sample the data. This is where the "invert clock" settings
(see Advanced settings on the Comms tab) come in - by inverting the
clock on either the network/host port tells the Datacryptor® to sample the
data on the opposite transition of the clock signal. There are no
hard and fast rules for how the "invert clock" settings
should be used as it is dependant on how the system is set up (where
the delay is, speed of the link etc.).
|