Systech NDS Admin

Device Server
Administrator's
Guide
SYSTECH
C O R P O R A T I O N
Document number 80-001061-6

Revision D
Document part number 80-001061-6
Revision History
Date Revision Description

7/16/03 A Initial Release
11/17/03 B Add new features
3/8/04 C Add SSL and phone number
translation
2/10/05 D Add new features
Created 2003, and Protected Under the U.S. Copyright Act of 1976.
Copyright © 2003-2005, SYSTECH Corporation
All Rights Reserved
This document is subject to change without notice.
Table of Contents
CHAPTER 1: INTRODUCTION...................................................................................3
CHAPTER 2: CONFIGURATION................................................................................5
Device Server Configuration .......................................................................................... 5
Setting the IP Address .................................................................................................... 5
DHCP/BOOTP.............................................................................................................. 5
NativeCOM ................................................................................................................... 5
Assigning a Temporary IP Address via the Network ..................................................... 6
How to Use the Serial Ports ........................................................................................... 7
Configuring NativeCOM Ports for Windows .................................................................. 7
Configuring Printers (via LPR/LPD) .............................................................................. 7
Configuring Outgoing Network Connections ................................................................. 8
Configuring Incoming Network Connections via Telnet Server ..................................... 8
Configuring Modem Emulation...................................................................................... 9
Configuration via the Web Browser Interface ............................................................. 10
Serial Settings ............................................................................................................ 11
Port Services .................................................................Error! Bookmark not defined.
Service Types......................................................................................................................... 14
Phone Number Translation ......................................................................................... 17
Network Translation.................................................................................................... 19
Protocol Settings ........................................................................................................ 20
Raw or Secure TCP ............................................................................................................... 21
(Secured) Simple POS Terminal Protocols ............................................................................ 21
(Secured) Converted POS Terminal Protocols ...................................................................... 21
Paymentech™ NetConnect Conversion................................................................................. 22
First Horizon Internet Gateway............................................................................................... 22
SSL Options ........................................................................................................................... 23
Type of Peer ........................................................................................................................... 23
Peer Identity Verification......................................................................................................... 23
List of Allowable Ciphers ........................................................................................................ 24
Network Settings ........................................................................................................ 26
IP Address .............................................................................................................................. 26
IP Netmask ............................................................................................................................. 27
TCP Keep-Alive ...................................................................................................................... 28
DNS Settings .............................................................................................................. 29
IP Routing................................................................................................................... 31
Time Settings.............................................................................................................. 33
Security Settings......................................................................................................... 34
System Password................................................................................................................... 34
Network Isolation Configuration ............................................................................................. 35
Online Update............................................................................................................. 36
CHAPTER 3: EXAMPLE APPLICATIONS ...............................................................39

Connect Peripherals to a Windows Host..................................................................... 39
Connect Peripherals to a Unix Host............................................................................. 39
Setup a Terminal or Modem to Connect to a Host...................................................... 40
Ethernet-based Serial Multiplexer................................................................................ 40
Ethernet-based Console Server ................................................................................... 41
Replacing a Dial-Up Modem Connection..................................................................... 41
Accessing the Device Server from a Remote Network............................................... 42
CHAPTER 4: TROUBLESHOOTING AND UPDATING ...........................................43

System Log.................................................................................................................... 44
Serious System Error Codes ...................................................................................... 45
Port Status ..................................................................................................................... 46
OS Information .............................................................................................................. 48
Network Information ..................................................................................................... 49
Network Interfaces ........................................................................................................ 50
Log/Debug Settings ...................................................................................................... 51
Ping ................................................................................................................................ 53
Reset/Reboot ................................................................................................................. 54
Flash Management ........................................................................................................ 55
Flash Update .............................................................................................................. 56
Download Flash Information ....................................................................................... 56
Restore Factory Defaults ............................................................................................ 57
PDA Compaction ........................................................................................................ 57
Other Debugging ........................................................................................................... 58
CHAPTER 5: MODEM EMULATION ........................................................................59

Modes............................................................................................................................. 59
Escape Sequence.......................................................................................................... 59
Types of TCP/IP connections ....................................................................................... 59
Outgoing and Incoming Calls....................................................................................... 60
AT Commands ............................................................................................................... 60
Supported Commands................................................................................................ 61
S-Registers .................................................................................................................... 63
Supported S-registers................................................................................................. 63
Response Codes ........................................................................................................... 63
Modem Signal Behavior................................................................................................ 64
Phone Numbers............................................................................................................. 65
Port Settings.................................................................................................................. 65
CHAPTER 6: LICENSE INFORMATION ..................................................................66
INDEX ................................................................................................... 69
Chapter 1: Introduction
The NDS (Network Device Server) family provides communication between peripheral
devices and computers connected to a network. When a device server is connected to your
LAN and to one or more peripherals, it manages peripheral traffic over the network, routing
it to the correct device.
As system administrator, you will have responsibility for setting up and configuring the
device server to meet your usage requirements. The device server has been designed to
make your job easy. If you are using the serial port(s) from Systech's NativeCOM, you need
only set the IP address and related parameters. This can be done with DHCP/BOOTP or
with the NativeCOM utilities. The remaining configuration will be on the host or hosts that
are accessing the device server. The hardware is simple to install, and a browser interface
ensures that management is just as simple. In addition to configuration tools, the
communications server provides tools for monitoring and managing your port activity and
for diagnosing and troubleshooting system problems.
80-001061-6 Introduction Page 3

Device Server Administrator’s Guide
Chapter 2: Configuration
Device Server Configuration

Before configuring the device server, you must assign it an IP address as described below.
After it has an IP address, the device server is configured primarily through the web
browser interface. If you are using NativeCOM to access the serial ports, no other
configuration is necessary beyond setting the IP address and potentially the network mask
and gateway.
Setting the IP Address

The factory default configuration for the device server has no IP address. To use the device
server you must assign it an IP address. There are several ways to do this.
DHCP/BOOTP
If the device server does not have an IP address, or if it obtained a temporary one via the
temporary method described below, it will attempt to get one from a DHCP/BOOTP server
on the local network. If an IP address is obtained from a DHCP server, the device server will
also ask the DHCP server for a subnet mask, a default gateway, and a DNS name and server.
NativeCOM
You can also configure your device server’s IP address using NativeCOM. NativeCOM is a
Windows software package provided free of charge by Systech. The NativeCOM
Networked COM ports software makes remote serial communication ports (e.g. EIA-
232/485/422 ports on the device server) available to Windows programs as local COM
ports. Applications from a PC running Microsoft Windows 95, Windows 98, Windows NT,
Windows 2000 or Windows XP can access and use the remote serial ports. For further
information on configuring and using Networked COM ports and assigning an IP address to
your device server, see the NativeCOM manual. The NativeCOM software and manual are
available on the CD you received with your device server and from the Systech web site
(www.systech.com).
You can use the NativeCOM Configuration Utility, NativeCOM Port Server Utility, or
NCCTool to assign an IP address to your device server. Once you have done this,
DHCP/BOOTP is disabled. The NativeCOM Configuration Utility and the Port Server
80-001061-6 Configuration Page 5

Utility always use the default subnet mask for the given IP address class. If you are
subnetting your network, the NCCTool allows you to override the default subnet mask.
Assigning a Temporary IP Address via the Network

If your device server has booted without an IP address, you can assign it a temporary IP
address using another TCP/IP system on your network. All TCP/IP systems include a
standard utility called “ARP” that can be used to assign this IP address to the device server.
The ARP command allows you to manually associate your device server’s hardware
Ethernet address (the “MAC address”) with an IP address on your network. On most Unix
and Windows systems this command looks like this:
arp -s <IP> <Ethernet address>
<IP> is the IP address you want to assign to the device server and <Ethernet address> is the
unique Ethernet hardware address that is printed on the bottom of the device server (e.g.
“00:80:44:xx:xx:xx”). Note that under Windows, this address should be specified as “00-80-
44-xx-xx-xx” (dashes in between instead of ":" as on the label).
After you have established this ARP mapping, use ping, telnet, or a web browser to contact
the temporary IP address. The device server will see the network packets destined for its
hardware address and temporarily adopt the destination IP address from the packets. The
device server will always use the default netmask for the IP address’s class (see IP Netmask
for more information).
WARNINGS:
1. This method only temporarily assigns an IP address. The device server will lose this
IP address when it reboots. After you have set the temporary address, you should
use a web browser to access the
2. page and permanently set the IP address.
3. This method only works if the device server does not already have an IP address.
Once the device server obtains an IP address from any other source, this method will
no longer work. To re-enable this method, you must clear out the device server’s IP
address and reboot it.
After you have permanently set the IP address on the device server, it is a good idea to
remove the permanent ARP entry that you previously added to your system. To do this,
execute the following command:
arp -d <IP>
Removing the ARP entry will not affect your ability to communicate with the device in any
way.

How to Use the Serial Ports
The device server serial port(s) can be used in several different ways:
• As Windows COM ports via NativeCOM
• As network printer ports via LPR/LPD
• They can initiate TCP/IP network connections to remote hosts (outgoing
connections) optionally using SSL security
• They can accept TCP/IP network connections from remote hosts (incoming
connections)
• They can simulate a dial-up modem connection over TCP/IP (via Modem
Emulation) also optionally using SSL security
The following sections describe each of these configurations in more detail.
If you will only be accessing the serial ports via NativeCOM, no further configuration is
necessary on the device server (unless you need to change the serial port electrical
interfaces). Otherwise, you will need to configure the desired service and set up the proper
serial parameters for your device (the device server serial ports default to 9600 baud, 8 data
bits, no parity, 1 stop bit, and no flow control).
For more information on configuring the serial settings, see the section entitled Serial
Settings.
Configuring NativeCOM Ports for Windows

The device server is pre-configured to work with NativeCOM. To use NativeCOM, select
the device server from the configuration utility and create a COM port as described in the
NativeCOM manual. NativeCOM controls the serial port settings from the host.
NOTE: NativeCOM overrides all the serial parameters set via the web browser, with the
exception of the “Require DCD” and “Electrical Interface” settings. NativeCOM requires
that the “Require DCD” setting be set to “no”, which is the default setting. If you change
this parameter, be sure to reset it for use with NativeCOM.
For more information on configuring NativeCOM ports, please see the NativeCOM
documentation.
Configuring Printers (via LPR/LPD)

All Windows and Unix systems support network-based printing via the LPD (or LPR)
protocol. Although you can also use NativeCOM or Systech RTN to indirectly set up a
network printer, it is usually preferable to use the LPD protocol because it is a simpler and
more efficient way to print. It is also easier to share a printer among multiple hosts when
using the LPD protocol.

When configuring an LPD printer, you must provide two pieces of information to the host:
the IP address of the device server and the name of the LPD print queue. The name of the
print queue for serial port 1 should usually be port1 (or portN for serial port N). If you are
printing simple text and want to enable extra character formatting for carriage-returns and
new-lines, use fport1 (or fportN for port N).
Before configuring your host system to use LPD, be sure to configure the correct serial
parameters on the device server (see the section on Serial Settings). All ports are
automatically accessible via LPR on port 515.
To configure a printer under Windows, follow the instructions for adding an “LPR port” in
the Windows Add Printer documentation. Although this process varies depending on
which version of Windows you have, in general you must:
1. Make sure that you have installed LPR/LPD printer support
2. Select Add Printer
3. Choose to add a Local Printer
4. Create a new LPR Port
5. Specify the IP address of the device server
6. Specify the name of the print queue on the device server
To configure a printer under Unix, follow the instructions for your Unix host.
Configuring Outgoing Network Connections

The device server can be configured to initiate TCP connections to remote hosts. This
configuration can be configured for both telnet- and raw-mode protocols (with or without
SSL security). It is generally used when the device server must initiate the network
connection to the remote host.
This option can provide telnet logins for terminals attached to the device server, or it can
establish raw data paths for other serial devices. To configure a port for outgoing TCP
network connections:
1. Configure the correct serial parameters on the serial port (see Serial Settings)
2. Configure the desired TCP session parameters (see Port Services)
Configuring Incoming Network Connections via Telnet Server

The device server is pre-configured to accept incoming TCP connections from Systech RTN
for Unix or other TCP socket-based applications. Each Systech serial port accepts incoming
TCP connections on two TCP ports: an 8000-series port (for raw data), and a 9000-series port
(for telnet data).
The 8000-series port (8001 for port 1, or 800N for port N) is a raw data path that passes all
data back and forth between the network and the serial device without further processing. It

should be used by applications that support simple TCP connections and do not implement
the telnet protocol. There is no protocol involved beyond TCP/IP.
The 9000-series port (9001 for port 1, or 900N for port N) implements the telnet protocol and
supports the following telnet options: SUPPRESS GOAHEAD, BINARY, ECHO, COM-
PORT-OPTION and TIMING MARK. It should be used by the Systech RTN utility, and by
other applications that support telnet.
Once you configure the serial parameters via the web browser, the port is ready for use by
RTN or your custom application (see Serial Settings). For more information on configuring
RTN, see the Systech RTN documentation.
Configuring Modem Emulation

The device server can be configured to allow legacy devices that interact with a Hayes-
compatible modem emulation interface to communicate over a TCP/IP network instead of a
phone line. When modem emulation is enabled, the device server will respond to AT
commands generated by the attached device. After receiving the dial command, the device
server will make a TCP connection to the specified host. The device server will also accept
incoming TCP/IP connections and generate the appropriate response codes. As with
incoming network connections, each Systech serial port accepts incoming TCP connections
on two TCP ports: an 8000-series port (for raw data), and a 9000-series port (for telnet data).
To enable modem emulation:
1. Configure the correct serial parameters on the serial port (see Serial Settings)
2. Enable modem emulation and configure the desired outgoing connection parameters
(see Port Services)
Once modem emulation is enabled, verify correct operation by connecting a terminal to the
appropriate serial port and issuing an 'AT' command. If the device server returns the 'OK'
result code, modem emulation is now functioning properly. You may now establish an
outgoing connection with the 'ATD' command (see Phone Numbers for more information
on IP address formats). A phone number translation table is also available to convert phone
numbers to IP Addresses or Hostnames.

Configuration via the Web Browser Interface
Once the device server has an IP address, you can use a web browser to monitor and
configure it. Simply specify the IP address of the device server as the address or URL in
your browser and you will see a web page that is similar to the following:

Select the section you wish to access from the menu of links on the left side. The following
pages discuss each of these sections.
Serial Settings
The Serial Settings page allows you to specify the baud rate, character size, parity, stop bits,
and flow control behavior for each serial port:
NOTE: NativeCOM, (or any RFC-2217 Telnet client with COM-PORT-OPTION

support) overrides the baud rate, size, parity, stop bits and flow control parameters.
The default port settings are as shown above.
Enabling flow control enables it on both input and output.
The inactivity timeout shuts down the service on the port if there is no input or output in the
specified timeout period.

Port Services
By default, all ports are configured to accept incoming TCP connections from TCP/telnet
clients and no outgoing service is configured. You may configure the ports to initiate
outgoing raw TCP or telnet connections to remote servers. In addition, the modem
emulation feature may be enabled to allow a serial port to mimic a modem interface.
For incoming connections, the ports are numbered as follows:
Incoming Raw TCP

Port Telnet Port Port
Port1 9001 8001
Port2 9002 8002
Port3 9003 8003
Port4 9004 8004
When using the modem service on a port, the phone number will be translated to a
host/port pair then a TCP connection will be established to the remote host.
When using outgoing connections on a port, the settings configured on the Serial Settings
page will be applied to the port, and a TCP connection will be established to the remote host.
If Require carrier/Generate hangups is set, the service will wait for the presence of the DCD
modem signal before connecting.
Once connected, data received on the port is sent to the remote server over the network
connection and data received on the network connection is sent out the port.
The following screen shot represents most of the options available for configuration.
Depending on the Service Type you have selected, not all of these options will be displayed.

Service Types
No Outgoing Service
Selecting this option disables outgoing port services on the specified port. Incoming
connections are still allowed. All port services options will reset to defaults.
Modem Service
Selecting this option will enable modem emulation on both the incoming and outgoing
network connections. See Modem Emulation for details on commands and responses. The
target peer (specified in the Phone Number Translation table and configured in the Protocol
Settings page) determines the type of outgoing connection that will be made.
When Modem Service is selected, you may also configure the Source TCP Port (see below)
and enable or disable automatically detecting the serial baud rate.
The Modem Emulation service has the ability to automatically detect when the baud rate of
the attached device is different from the one configured on the serial port. In many cases, it
is possible to guess the speed of the attached device and to automatically switch the serial
port to match that speed.
The downside of this functionality is that it is not always 100% reliable, and in some
instances can cause inappropriate baud rate changes to be made that will cause
communications to break down. In general, you should only enable this option if your
application uses multiple baud rates and requires autobauding support. Otherwise, it is best
to disable it.

Outgoing Network Connection
Selecting this option enables an outgoing connection to the specified host. The Network
Connection Options (below) identify the host.
Outgoing Telnet Connection

Selecting this option enables an outgoing telnet connection to the specified host. The
Network Connection Options identify the host and the Telnet Options (below) configure
the specific type of telnet connection.
Network Connection Options
Destination Hostname/IP Address

Specify the IP address or Host name of the remote host in the Destination IP Address field.
Destination TCP Port

Specify the destination TCP port. The default port for telnet servers is 23, but it is usually
different for other types of servers.
Source TCP Port

In most cases, the value used for the source port is arbitrary and you can leave this field set
to 0 for "any". However, if your server or firewall has specific requirements you may specify
an explicit source port number in the Source TCP Port field. If this port is not available
when the TCP service starts up, an error will occur and the TCP service will reset and try
again.
Require carrier/Generate hangups

If you have configured a serial port with an outgoing service, you may want to delay the
TCP connection establishment until an attached terminal is powered up or an attached dial-
in modem has received a call. In this case, select the Require carrier/Generate hangups
option. The TCP session will not begin until the device server senses the presence of DTR
(in DCE mode) or DCD (in DTE mode) on the port and it will close the TCP session if
DTR/DCD is lost.
Telnet clients usually do not want the operation of the port to be affected by the presence,
absence, or loss of modem signals. You probably do not want this option selected for those
applications.
Restart Delay
The Restart Delay keeps the TCP service from constantly retrying if the remote host
becomes unavailable, or in the event of network errors or other unexpected situations.
When the TCP session ends, it will pause for the number of seconds specified by the Restart
Delay. The default value (and minimum value) for the Restart Delay is 1 second.

Wait for Keyboard Hit
You may configure the TCP connection to wait for a “keyboard hit” before starting the TCP
session. Enabling this mode will display a message on the serial port (after DCD is present if
DCD is required to use the port) asking the user to type a character to begin the TCP session.
Telnet Options
The following options apply only if an Outgoing Telnet Connection is configured.
Telnet Mode
The TCP service can connect to a server using the telnet protocol in either Binary mode (8-
bit) or Human mode (7 bit, performs line and character processing for terminals). The telnet
client will negotiate telnet parameters with the remote telnet server. The parameters that it
will request are as follows:
• Binary mode: DO BINARY, WILL BINARY
• Human mode: DO SUPPRESS GOAHEAD, WILL SUPPRESS GOAHEAD
The device server also supports the following telnet modes if negotiated by the remote telnet
server: ECHO, COM-PORT-OPTION, TERMINAL-TYPE, and TIMING MARK. (Note that
the device server does not support local echo. However, it will accept a WILL ECHO
request for remote echoing and will respond with DO ECHO.)
Terminal Type
If the remote host requests the DO-TERMINAL-TYPE telnet option, and the Terminal Type
field is configured, the device server will respond with this value. This field is useful when
you are connecting serial terminals to the device server and the remote host needs to know
how to format output to the terminal. Otherwise, you can leave this blank.
Quiet Mode
By default, the telnet session will display various status messages as it makes, loses, or
breaks connections to the remote server. Selecting Quiet Mode will suppress these
messages. This is useful when using serial devices that may be confused by these status
messages.
Telnet Escape Character

When the telnet client is in the 7-bit “Telnet mode”, it parses serial input for a special escape
character. The default escape character is “CTRL-]” (or ASCII 29). If it sees this character, it
breaks into the telnet command mode and displays a command prompt that allows the user
to execute some telnet session commands. You may specify a different character (as decimal
ASCII) to use as the Telnet Escape Character, or specify -1 to disable this feature entirely.

Phone Number Translation
This table can be used to translate phone numbers into IP addresses or Hostnames. If an
attached device dials one of the specified telephone numbers, the corresponding IP address
and port are used to make the TCP connection. Note that all non-numeric characters except
the “,” (comma) in the phone number are ignored.
When modem emulation is enabled, detect the phone number from ATD commands.
Although the IP address of the remote host can be embedded directly into the ATD
command, certain devices can't always be easily configured to do this.
The Default Translation entry is used if the dialed phone number is not found in the list.
(The dial backup number is not used in the NDS product.)
The phone number table has a number of features to ease initial configuration. When an
attached device dials a number that is not in the table, the device server creates a dummy
entry in the table. This entry will consist of just the phone number. Until you fill in the
remainder of the entry (IP Address/Hostname and Port) and save it, this entry will not be
used.
Once you have created and saved an entry in the table, a link to the associated entry on the
Protocol Settings page appears on the right. If the protocol is not yet defined, this link,
“Define protocol”, will create a new entry on the Protocol Settings page, otherwise the link
will be “Edit protocol”.

The translation table screen allows you to add up to 5 new entries at a time. A total of 64
entries may be configured including the default entry.
In the example above, if the attached device dials 18005551212, the port will be connected to
the host at 192.168.1.100 on TCP port 5004. This host is not yet defined, so it will use the
default TCP protocol. If the attached device dials any other number, the port will be
connected to host.testloc.com:5003, whose protocol is defined. And the terminal has actually
dialed 555-1212, generating an automatic, but not yet saved, entry.

Network Translation
The device server is capable of accepting incoming TCP connections and redirecting them to
remote TCP hosts. This functionality is called network translation and behaves much like a
TCP "pipe" between two systems.
It is also possible to modify the network protocol traveling through the TCP pipe by using
the Protocol Settings page to define the remote host's protocol requirements. The most
common use for this functionality is to add SSL encryption to an incoming TCP connection
prior to sending it along to the remote host.
The Network Translation table is used to define network mappings for TCP pipes. You must
first specify the incoming TCP port to which your device or application will connect. Then,
you must specify the outgoing hostname and destination TCP port for the TCP pipe.
You may also specify the source TCP port for the outgoing TCP connection. Usually, this
should be set to 0 to allow automatic selection of the source port. However, if you have a
firewall that imposes limits on source TCP ports then you may need to set this to something
specific. Note that if you specify something other than 0, you will be limited to only 1 TCP
pipe at-a-time for any given destination port.
In the example above, if the device server receives an incoming TCP connection on TCP port
5000, a TCP pipe will be established to www.myhost.com on TCP port 443. Since the TCP
source port is 0, any number of simultaneous connections are allowed and the TCP source
port will be automatically chosen for each one.
As in the phone number translation table, the protocols for the outgoing Host and TCP Port
combinations are defined in the Protocol Settings page.

Protocol Settings
For each host (peer) you will make an outgoing connection to, you need to specify the
protocol options used for that host. For each host, select the Host from the “Edit settings for
a different peer” selection box. Select “Add a new peer definition” link to add a new host.
The hosts are identified by their IP address or Hostname and TCP port. You may also specify
wild cards. Specific host names and/or port numbers take precedence over the wild cards.
An asterisk for the IP address/hostname (for instance “*:443”) means any other host when
connecting on port 443. An asterisk for the port number (for instance “host.peer.com:*”)
refers to any other port on that host. And a double asterisk (“*:*”) refers to all other hosts.

For each host, select the protocol to use for the connection and the options for that
connection. The available options vary depending on the protocol chosen. You may select
either:
• Non-Secure Protocols for Private Networks - The options in this column are only for
use with Private Network connections such as Satellite, Frame Relay or VPN. These
are non-secure protocols.
or
• SSL-Secured Protocols for Internet Connections - The options in this column use SSL
to securely send transactions over public Internet connections. These connections
generally go to SSL gateway sites that have their own private connection to the
payment processors.
To remove a host from the list, select “Delete this peer”.
Raw or Secure TCP
In Raw or Secure TCP mode, the device server establishes a TCP connection to the host but
does no additional processing. Data arriving from either the terminal or the host is sent to
the other side as soon as it is detected.
(Secured) Simple POS Terminal Protocols
With Simple POS Terminal Protocols, the device server establishes a pass-through
connection with a payment authorization server that communicates directly with a local POS
terminal. The device server does recognize Visa2 packet formats will wait for an entire STX
… ETX LRC bounded packet from the terminal before forwarding terminal data to the host.
Data not in packet boundaries are forwarded as soon as they are detected.
When using the Simple POS protocol, the device server will send data over the network in
one of two formats… either with the data encoded with 7 bits, even parity or as raw, 8-bit
data. Note that this setting is independent of the serial settings for the port.
(Secured) Converted POS Terminal Protocols
Most point-of-sale terminals expect their dial-up host to provide ENQ/EOT/ACK/NAK

synchronization. These terminals send their transaction requests to the dial-up host using a
common packet format, defined as follows:
[STX]transaction data[ETX][LRC]

However, many network hosts don't provide ENQ/EOT/ACK/NAK synchronization and
use packet protocols that are slightly different from those used by POS terminals.
The device server is capable of converting standard POS terminal packets into network
packets that are suitable for use with several types of network transaction authorization
protocols.
In addition, the device server also emulates the appropriate ENQ/EOT/ACK/NAK
behavior locally to provide a seamless connection between a dial-up POS terminal and a
networked transaction-processing host.
The following Converted POS Terminal Protocols are supported:
• ADS Format: Remove STX/ETX/LRC and add a two byte length header before each
terminal packet.
• Buypass Format: Remove STX/ETX/LRC headers from each terminal packet.
• Concord EFS Format: Enclose the entire terminal packet within a Concord EFS packet
header.
• Tandem Online System Format: Remove STX/ETX/LRC and insert a Tandem packet
header.
Paymentech™ NetConnect Conversion
Sends secured payment transactions to Paymentech™ Network Services using the

NetConnect protocol. Dial-up behavior is emulated for the local POS terminal. This option
is not available for private IP connections.
You will need a Paymentech Netconnect account to use this option. Enter the username and
password for the account in the fields provided:
First Horizon Internet Gateway
Sends secured payment transactions to Merchant Link via the First Horizon Internet
Gateway protocol. Dial-up behavior is emulated for the local POS terminal. This option is
not available for private IP connections.

SSL Options
When SSL is configured on an outgoing connection, you must also specify the SSL
connection parameters for each SSL peer. An SSL peer is the remote system that will be on
the other end of the secure SSL connection.
Type of Peer
For an outgoing connection the SSL Peer is normally an SSL Server. However, either side
can be a server or client. This option decides which is which during the SSL handshake.
Peer Identity Verification
This field can be used to enable verification of the remote peer's identity. Peer identity
verification must be enabled in order to guarantee that your secure data is not being
intercepted by an unwanted third-party. If you have specified the fully qualified domain
name (FQDN) in the peer address and this matches the SSL peer’s certificate, then click the
‘Certificate must match peer “”’ button. If you are using an IP address for the peer address,
check the ‘Certificate must belong to’ button and enter the FQDN. Or you may select ‘Don’t
verify peer’s identity’.
Caution: choosing ‘Don’t verify peer’s identity’ opens the possibility for an unwanted third-
party to masquerade as a given peer on the Internet and intercept transactions. Normally
you should not choose this option.
SSL verifies peer identity by using signed certificates. To verify a remote peer's identity:
1) The remote peer must provide a valid certificate.
The remote peer must be configured to provide a valid certificate that proves its
identity.
2) The certificate must be signed by a trusted certification authority (CA).
Certification authorities, or CAs, are organizations that issue and sign digital
certificates. To verify the integrity of a remote peer's certificate, its digital signature is
compared with the signatures of the CAs that are trusted by your application.
All trusted CAs must be pre-configured in the /usr/local/ssl/cert.pem file found in
the device server’s local filesystem. This file contains certificates for trusted CAs and
is used to verify the integrity of remote peer certificates.
3) The certificate must be owned by the correct DNS domain.
For optimum security, signed certificates should contain a fully qualified domain
name (or FQDN) that ties the certificate to a particular host or domain. Otherwise,
anyone with a valid certificate from one of your trusted CAs could intercept your
secure transmission.
This field allows you to specify which domain name to expect in the certificate. If the
certificate does not contain the expected domain name, the connection will be
aborted.
Example
Supplying a peer FQDN of ssl.yourdomain.com will require that the remote peer provide a
certificate registered to ssl.yourdomain.com, and that the certificate is signed by one of the
certification authorities found in the device server's /usr/local/ssl/cert.pem file.
List of Allowable Ciphers
This field specifies which authentication and encryption protocols will be allowed for this
SSL connection. To maintain maximum security, it is important to allow only those ciphers
that are sufficiently secure.
The default cipher list allows only reasonably secure ciphers to be used. If the remote peer
does not support sufficiently modern ciphers, you may need to enable some of the less-
secure ciphers.
The cipher list is specified using the same format as the standard OpenSSL cipher lists. This
list is a set of cipher strings, separated by colons, that represents the available cipher suites:
ALL: All ciphers
HIGH: High-encryption ciphers (more than 128-bits)
MEDIUM: Medium-encryption ciphers (equal to 128-bits)
LOW: Low-encryption ciphers (56- and 64-bits, excluding export ciphers)
EXP: Export encryption ciphers
TLSv1: Transport Layer Security v1.0
SSLv3: Secure Sockets Layer v3.0
SSLv2: Secure Sockets Layer v2.0
DH: Diffie-Hellman Ciphers (including anonymous DH)

ADH: Anonymous Diffie-Hellman Ciphers
kRSA: RSA Public Key Exchange
aRSA: RSA Authentication
3DES: Triple DES Encryption
DES: DES Encryption
RC4: RC4™ Encryption
RC2: RC2™ Encryption
MD5: MD5 128-bit Message Digest
SHA1: SHA1/DSS1 160-bit Message Digest
Each cipher may also be prefixed with one of the following operators:
-: Exclude cipher from list (may be re-added by later options)
+: Move cipher to the end of the list
!: Permanently exclude cipher from this list
Finally, the @STRENGTH cipher string may be appended to the end of the list to specify that
SSL negotiations give preference to higher-strength ciphers.
Click the help associated with this field to find the set of ciphers currently supported in the
software on your Device server.
Example
The cipher string ALL:!SSLv2:!ADH:!LOW:!EXP:!MD5:@STRENGTH is commonly used to
disallow all the ciphers that are considered unacceptably weak. This cipher string enables all
the supported SSL ciphers except for: SSL version 2 handshaking, Anonymous Diffie-
Hellman, low-encryption ciphers, export encryption ciphers, and MD5. In addition, the SSL
negotiation is instructed to choose the strongest ciphers supported by both SSL peers.

Network Settings
The Network Settings page allows you to set the IP address, the IP netmask, and the TCP
keep-alive settings:
IP Address
You may permanently assign the IP address of the device server by specifying it in this field.
Doing so will disable BOOTP/DHCP.
If you want to re-enable BOOTP/DHCP, you can do so by setting the IP address to 0.0.0.0, or
by restoring the default configuration (see the section called Restore Factory Defaults).

IP Netmask
Every IP address contains two pieces of information: the network number and the host
number. A network number is assigned to each local area network and is shared by all the
network devices on that network. Each network device, or “host”, is assigned a unique host
number. The IP netmask defines which portion of an IP address contains the network
number, and which portion contains the host number. The default netmask depends on the
“class” of the IP address that you are using. These classes are defined in Table 2-1.
Class IP Address Default Netmask Network Number Host Number

A 0.0.0.0 to 255.0.0.0 n.0.0.0 0.h.h.h
127.255.255.255
B 128.0.0.0 to 255.255.0.0 n.n.0.0 0.0.h.h
191.255.255.255
C 192.0.0.0 to 255.255.255.0 n.n.n.0 0.0.0.h
223.255.255.255
Table 2-1: Default Netmasks
It is often desirable to partition larger networks into a series of smaller networks that are
separated by routers (also called “gateways”). This process is called “subnetting” and is
accomplished by extending the default netmask. Some examples of common netmasks can
be found in Table 2-2.
IP Address IP Netmask Network Number Host Number

192.168.10.1 255.255.255.0 192.168.10.0 0.0.0.1
10.11.12.13 255.0.0.0 10.0.0.0 0.11.12.13
10.11.12.129 255.255.255.0 10.11.12.0 0.0.0.129
10.11.12.129 255.255.255.248 10.11.12.128 0.0.0.1
Table 2-2: IP Netmask Examples
If you are not using DHCP/BOOTP and your network uses subnets (or supernets), you can
override the default net mask by specifying it in this field. Once you click the "Save IP
Address/Netmask" button these parameters will be saved. They will take effect on the next
reboot (see the Reset/Reboot section).

TCP Keep-Alive
TCP keep-alive is a standard feature of TCP/IP that can be configured to automatically

monitor the state of TCP connections. If one end of an idle TCP connection is severed (like
by a network or power failure), it is possible for the other end to remain open indefinitely. If
a network host fails while it has an open TCP connection to one of the device server’s serial
ports, that serial port might remain unavailable until it is manually reset.
The optional TCP keep-alive feature sends special “keep-alive” packets to the remote TCP
host in order to detect the situation where the remote host fails. If a failure is detected, the
TCP connection is reset to allow other hosts to access the serial port.
To enable TCP keep-alives on serial-related network connections, enter the total time (in
seconds) that you will allow TCP connections to remain idle before resetting them. The first
keep-alive packet will be sent after the connection has been idle for half of this total time.
After that, four more TCP keep-alive packets will be sent at regular intervals until a TCP
response is received from the remote host. If no response is received before the total keep-
alive time runs out, the TCP connection will be reset.
WARNING: Enabling TCP keep-alives will increase the amount of network traffic on your
network. Unless you have a specific need for this feature, it is best to leave it disabled. If
you do enable it, it is best to make the keep-alive timeout larger to reduce network traffic.
Note that if you are using NativeCOM, it implements its own independent keep-alive
mechanism as part of the NativeCOM protocol.

DNS Settings
The DNS Settings page allows you to specify a DNS name for your unit, specify the
addresses of DNS servers to resolve names, and to pre-define some host names. The DNS
name and servers can also be derived from a DHCP server.

If the device server is configured to use DHCP, it will try to get DNS configuration
information from the DHCP server. You may also manually set up static DNS entries on this
page. Having DNS configured allows you to specify names in place of IP addresses in your
configuration.
The DNS Domain Name is used as the default domain for any names you specify. For
instance, if you specify the name “foo” in the ping command and the domain name
“company.com” in the DNS Domain Name above, the ping command will do a DNS lookup
on the name “foo.company.com”.
The DNS Server IP Addresses are used to specify the addresses of one or more machines that
can be used to resolve names to IP addresses.
The Static Hosts entries are used to define local host name to IP address mappings.

IP Routing
The IP Routing page lets you configure network routes for accessing remote networks:
If the device server is configured to use DHCP, it will try to get IP configuration information
from the DHCP server. You may also manually set up static routes on this page.
Each IP route consists of a destination IP address, a netmask, and a gateway IP address.
Depending on the netmask, the destination IP can specify one of two route types:
• Host route: This is a route to a specific IP host. The netmask is always
255.255.255.255.
• Network route: This is a route to an IP network. The netmask defines which portion
of the destination IP address contains the network number.

The special destination IP address of 0.0.0.0 specifies a default route, which is used
whenever a more specific route does not exist. This is all summarized by the examples in
Table 2-3.
Destination IP Netmask Gateway Meaning

192.168.2.100 255.255.255.255 192.168.2.1 Host route: Send all packets destined for
IP address 192.168.2.100 to the router at
192.168.2.1
192.168.2.0 255.255.255.0 192.168.2.2 Network route: Send all packets destined
for the network 192.168.2.x to the router
at 192.168.2.2
0.0.0.0 ignored 192.168.2.3 Default route: Send all other packets to
the router at 192.168.2.3
Table 2-3: Examples of IP Route Types
For each route you wish to add, specify a destination address, select a destination netmask
and specify the gateway address. To specify a default route, set the destination address to
the word default or to the IP address 0.0.0.0, and select the Net destination netmask.
Some examples of valid routes are:
Destination Address Destination Netmask Gateway Address

default Net 192.168.2.1
10.10.10.0 Net 192.168.2.200
10.10.10.13 Host 192.168.2.201
10.0.0.0 Custom (255.255.255.0) 192.168.2.202
You must click the "Save Gateways" button to save any changes you make. The new route
configuration will take effect on the next reboot (see the Reset/Reboot section).
To remove a static route, check the Delete box next to the entry then click the "Save
Gateways" button.

Time Settings
The Time Settings page allows you to configure NTP or HTTP time-servers to get the
system time from. If you are using SSL for peer verification, the device server must obtain a
valid time from an external time-server to verify the peer.
If the device server is configured to use DHCP, it will try to get NTP server information from
the DHCP server. You may also manually set up the addresses on this page. The NTP
service uses UDP port 123. If your device server is behind a firewall you may need to allow
accesses to this port through the firewall. Adding or changing the NTP server will trigger
the NDS to get the time again.
The HTTP server you specify need not be a designated time server – just a reliable server.
The device server derives the system time from the HTTP header the server returns. Adding
an HTTP server will not automatically trigger getting the time. You must reboot for this to
take effect.

Security Settings
The security settings link includes settings for the System Password and Network Isolation
as defined in the following sections.
System Password
The device server’s administrative functions can be protected by a system password:
By default, no system password is configured. Once a password is set, your web browser
will prompt you for the system password whenever you try to access sensitive configuration
pages. The browser will ask for a username and password. The username is always
“admin”. The password will be what you configured above. This password is also used by
Systech host utilities that manage the device server.

Network Isolation Configuration
By default, all network services are enabled. However, for security, any or all listening
services may be disabled. Unselect any services that you wish to disable. These changes
will not take effect until the next reboot.

Online Update
You may configure your device server to make a connection to an update server and obtain
updated software or configuration information from the server or send information to the
server. If your device server supports SSL, this update will be over a secure SSL connection.
You may schedule the updates to happen periodically, or on every startup, or only when
manually selected. The automatic update capability can be used along with Network
Isolation to provide a way for the device server to “call out” to get updates if all the
incoming connections are disabled.
To configure updates, first, select the update server to use and the SSL parameters for
connecting to it. You may specify both the server name and the path for obtaining the
updates. If the server requires HTTP authentication from the device server, specify the
username and password to use.

Then select when and what to update. Select “Perform update at startup” to have the device
server check for updates every time it is booted. (Note: this will cause the startup to take
longer than normal. Do NOT interrupt the unit when it is updating or flash memory may be
corrupted. The unit will blink the status LED at four times the normal rate when it is
updating flash.) Or select a frequency and time of day to periodically check for updates.

Then configure which items to send to the server or update from the server.
Items to send:
• Product Data – manufacturing configuration data, error records
• Configuration Database – current settings on the unit
• System Log – trace activity
Items to Upload:
• Operating Software – the software running in the unit
• File System – SSL certificates
• Current Configuration – current settings on the unit
Finally, you can

• Test Configuration – check to make sure the settings are right and the server is
available. This will contact the server and go through the communication necessary
to send and receive the files without actually doing so.
• Update Now – contacts the server and sends and updates the files now.
• Save Changes – save changes for later.

Chapter 3: Example Applications
The device server may be used in a number of ways to provide Ethernet-to-serial

connectivity. The following examples show how you might set up the device server for
various applications.
Connect Peripherals to a Windows Host

Using Systech's NativeCOM software in conjunction with the device server allows Windows
applications to access these serial ports via the standard Windows COM port interface. This
makes the device server’s serial ports almost indistinguishable from the standard serial ports
found on the back of most PCs. In RS-232 mode, the DB9 ports also have the same connector
pinouts as standard PC serial ports, so that virtually any serial device that can be attached to
a local PC serial port can be easily moved to a remote Systech device server port.
Using the serial ports on the device server allows you to add more serial ports to your
Windows host and to physically locate those serial ports anywhere your TCP/IP network
reaches. You can locate your serial devices on your local network, across a WAN, or
anywhere on the Internet. Using NativeCOM, your Windows-based server can use standard
Windows COM port devices (e.g. COM3, COM20, etc.) to access device server serial ports
located all over the world.
To set up a device server to work with NativeCOM, just give it an IP address (and optionally
set the netmask and gateways). NativeCOM takes care of the rest. Refer to the NativeCOM
documentation from Systech for information on setting up NativeCOM ports on the host
computer.
Connect Peripherals to a Unix Host

Systech's RTN utility allows you to create pseudo-tty ports on your Unix host system that
connect to serial ports on device servers. This is similar in function to NativeCOM for
Windows systems. The primary difference is that RTN does not support controlling the
physical characteristics of the port (baud rate, character size, parity, stop bits and flow
control). Once configured, you can use the pseudo-tty device for logins or open it like other
tty devices.
To set up a device server to work with RTN, give it an IP address, and optionally set the
netmask and gateways. Then use the Serial Settings web page on the device server to set up
the physical characteristics of the port. Require DCD to Use Port should not be selected
80-001061-6 Example Applications Page 39

(the default value). Refer to the RTN documentation from Systech for information on setting
up RTN on the host computer.
Setup a Terminal or Modem to Connect to a Host

You can setup the device server to automatically connect a terminal or dial-in modem to a
host on your network. This allows you to set up network-based terminal connections to
Unix hosts or other terminal based applications such as Pick.
To set up a device server to do this, use the Serial Settings page to set up the physical
characteristics of the port, the Port Services page to setup an outgoing raw TCP or telnet
connection, and the Protocol Settings page to specify the host connection information. You
can specify a fixed IP address to connect to, or you can configure the telnet client to prompt
the user for the IP address each time it connects.
If you are setting up a terminal, you may want to select Require carrier/Generate hangups
and Wait for Keyboard Hit on the Port Services page. If you are setting this up for a dial-in
modem, select Require carrier/Generate hangups on the Port Services page.
Ethernet-based Serial Multiplexer

You can connect two serial devices to each other through a pair of device server serial ports
across a TCP/IP network. To do this, set up one device server to use an outgoing connection
to connect to the other device server set up for an incoming connection.
For example, say you have a terminal attached to a local device server at address 192.168.1.1
and you have a device attached to a remote device server at address 10.10.10.1. To configure
the multiplexer:
1. Make sure that both device servers have been configured with the proper network
and routing information (see Network Settings and IP Routing).
2. On the local device server, use the Serial Settings page to set up the physical
characteristics of the port.
3. On the local device server, use the Port Services page to specify 10.10.10.1 as the
Destination IP Address, 8001 as the Destination TCP Port (for serial port 1), select
Require carrier/Generate hangups, and select Quiet Mode. In the Protocol Settings
page, set Peer Protocol Type for the 10.10.10.1:8001 host to Raw TCP.
4. On the remote device server, use the Serial Settings page to set up the physical
characteristics of the port.
Now, when the local terminal is powered on (asserting DCD), it will be appear to be
physically connected to the device attached to the serial port at the remote site.

Ethernet-based Console Server
You can use one or more device servers to give virtual access to devices that have serial
consoles, such as routers, Unix servers, etc. This allows you to monitor multiple consoles
from a single terminal or from a remote location.
To set up a device server to attach to a serial console, give it an IP address, and optionally set
the netmask and gateways. Then use the Serial Settings page on the device server to set up
the physical characteristics of the port. In the Port Services page select No Outgoing
Service. Do not select Generate hangups (the default value).
You can now use telnet on a host computer to connect to the serial console. For example:
telnet 192.168.1.1 9001
Replacing a Dial-Up Modem Connection

You can replace a pair of dialup modems with a pair of device server serial ports connected
via TCP/IP. To do this, set up two device servers to communicate using modem emulation.
For example, say you have a device at a remote site that dials a local server, and you want to
replace this with a TCP/IP connection. You install a remote device server at address
10.9.22.1 and a remote device server at address 192.168.40.2. To configure the connection:
Make sure that both device servers have been configured with the proper network and
routing information (see Network Settings and IP Routing).
1. On the local device server:
a. Use the Serial Settings page to set up the physical characteristics of the port.
b. Use the Port Services page to enable modem emulation.
c. Make sure the server is configured to accept incoming calls, either by issuing
the ‘ATA’ command after receiving a ‘RING’ response code, or automatically
by setting register S0 on the device server to a non-zero value.
2. On the remote device server:
a. Use the Serial Settings page to set up the physical characteristics of the port.
b. Use the Port Services page to enable modem emulation.
c. Use the Phone Number Translation page to translate the dialed phone
number to 192.168.40.2 port 8001.
d. Use the Protocol Settings page to configure host 192.168.40.2:8001 for “Raw
TCP”.
Now, when the remote device attempts to establish a connection by dialing out, it will be
connected via TCP/IP to the server attached to the serial port at the local site.

Accessing the Device Server from a Remote Network
When attaching TCP/IP devices to a local Ethernet network, all that is required for basic
communication is to assign an IP address to the network device. However, if your network
devices need to communicate with remote networks, you must also configure IP routing
information to tell TCP/IP where to send these remote network packets.
A remote network is a network that must be reached via one or more routers. To send
packets to a remote network, you must configure the following information:
1. IP Netmask: The IP netmask defines how your network is subnetted. See the section
called IP Netmask for more information.
2. IP Routes: The IP routes define where your routers are and when to use them. See
the section called IP Routing for more information.

Chapter 4: Troubleshooting and
Updating
There are a number of tools built into the device server to facilitate troubleshooting problems
and managing the unit. These are accessible via the web browser interface under the menu
sections Status and Logs and Commands.
• System Log displays informational and error messages from the unit and can also be
configured to display debug trace data
• Port Status displays the current state of the serial port(s)
• OS Information displays the state of the onboard software tasks
• Network Information displays the status of network services and current connections
• Network Interfaces displays the status of the currently active network interfaces
• Log/Debug Settings configures the type of trace data to collect in the System Log
• Ping can be used to test network connections
• Reset/Reboot can be used to clear errors on individual ports or to reboot the device
server
• Flash Management allows you to update the unit’s software, save and update
configuration information, and manage the error history of your device server
80-001061-6 Troubleshooting and Updating Page 43

System Log
By default, the device server stores informational and error messages in the system log. You
can also configure the device server to record debug trace data in this system log buffer (see
the section entitled Log/Debug Settings). To display the system log and trace information
in your browser window, select the System Log link in the menu:
This will open a connection to the device server that will display the current contents of the
system log buffer. As long as you keep this window open in your browser, new messages
added to the buffer will automatically be sent to your web browser.

You can select the text data in the system log display with your mouse and copy it to a file or
email message. Usually, you will want to send this data, along with a description of the
problem, to Systech support ([email protected]) for analysis.
You can also view and save the system log using a telnet client. To do this, connect to the IP
address of your device server on TCP port 9096. Data in the trace buffer will be
automatically formatted and displayed in your telnet window. For example:
telnet 192.168.1.1 9096
You can also use the r4000 host utility –s or –t options. –s gets the log and –t gets the log
continuously.
Serious System Error Codes

If your device server encounters a serious system error, it will display an error condition on
the status LED and attempt to log an error code to the system log. For more information on
the LED conditions, see the Hardware Manual.
The error message recorded to the system log will look similar to the following:
382 log-error[10]: Serious system error 1
The serious system error codes are defined in Table 4-1.
Error Code Meaning Action

1 Ethernet MII communication error Call Systech support
2 Corrupt configuration database. Restore the default configuration
4 Unknown backplane ID Call Systech support
8 Unknown network module Call Systech support
Table 4-1: Serious System Error Codes
The actual error code may be a combination of these.

Port Status
The Port Status page shows the current state of the serial port(s):
The DCD, RTS, CTS, DTR, DSR, and RI columns indicate the status of the modem signals
for the specified port. If the modem signal is present (either asserted if it is an outgoing
signal, or detected if it is an incoming signal) its name will appear in the corresponding
column.
The State column indicates whether the port is open, closed, waiting for DCD, or
experiencing any notable conditions (such as flow control). The Serial Parameters column
indicates the current settings for the port.

NOTE: The Serial Parameters column reflect the actual, real-time serial settings in
use by the port. The settings that are specified via the serial configuration pages are
applied each time the port is opened. If the port is closed, the serial parameters
reported by Port Status may not necessarily match the settings you configured until
the port is re-opened. Furthermore, some clients (like NativeCOM) can override the
configured settings.
The Input, Output, Parity Errors, Framing Errors, and Overrun Errors columns are tallies of
activity on the port.
Under each port row is a field indicating the current TCP connection status on the port.
The display will update automatically every few seconds. You can stop the automatic
update by selecting "Stop" from your browser. To restart the updating, select "Refresh" or
"Reload" from your browser.

OS Information
The OS Information page shows the current state of system and application tasks as well as
memory usage information:

Network Information
The Network Information page displays the status of network services and current
connections. The TCP Sockets section shows current connections and TCP listeners. The
UDP Listeners section shows UDP ports that are active.

Network Interfaces
The Network Interfaces page displays the status of the currently active interfaces on the
unit. This is similar to the “ipconfig” command on a Windows machine or the “ifconfig”
command on a Unix machine.

Log/Debug Settings
By default, the device server stores informational and warning messages in the system log.
You can also configure the device server to save trace data in this system log buffer:
Tracing is generally used for troubleshooting problems. You can enable tracing on
individual ports – selecting low-level serial events or higher-level port service events (like
telnet or LPD). Or you can enable tracing on system services such as HTTP (the web
browser interface), DHCP, SDP (Systech Device Protocol - used by Systech utilities to find
Systech device servers on the network), and SSL.
For port tracing, you must select both the port(s) and the events that you want to trace.
Note that unlike most other options, the logging configuration will not be saved after a
reboot unless you explicitly check the Remember this configuration after reboot box.
Selecting “Record modem negotiations to WAV files” will record the latest modem
negotiation from the Terminal ports (from the time it dials until it completes negotiation).
This can then be saved to a standard WAV file for later analysis.
Refer to the chapter on Troubleshooting and Updating for information on how to access
and capture the contents of the system log or the recorded modem data.

From the Log/Debug page you can also configure the unit to save a dump of system
memory under some circumstances. Scroll the page down to the dump configuration:
A memory dump may be obtained either manually using the Initiate Dump button on this
page or pressing the reset button or automatically when the unit encounters a catastrophic
error that causes it to reboot. No dump will occur with any of these methods unless the
dump is first configured.
The Device Server IP Address specifies the IP address the unit should use as its own when
initiating a dump. If left blank, the unit uses it’s currently configured IP address. The TFTP
Server IP Address and Filename specify the host and filename on that host to send the
dump to. If the server address is left blank, the unit uses the TFTP server address obtained
from DHCP. The filename must be specified. If any of these parameters are invalid at the
time of the dump, the dump will be aborted. The filename must be that of a writeable file on
the TFTP server. The two IP addresses must be on the same segment (the dump facility does
not support routing). The r4000 utility can be used to configure and initiate a dump. This
utility can also act as the TFTP server for this purpose.

Ping
You can use the Ping command to test a network connection:
Enter the IP address to Ping or a Hostname and the Number of Pings then press the Ping
button. The command will display the results as follows:
Sending 10 PINGs to 209.75.217.6...
Response from 209.75.217.6: icmp_seq=0, time=10.0 ms
10 packet(s) transmitted, 10 packet(s) received, 0% packet loss.
Not all hosts accept ICMP pings even if they are present on the network. However, the ping
command can serve two functions: 1) to test your general network settings – IP address,
network mask, gateway and DNS server and 2) whether the device server can reach a given
host. Simply resolving a name to an IP address effectively tests the first function.

Reset/Reboot
The Reset/Reboot page lets you reset individual ports, or the entire device server:
You can reset an individual serial port or ports by selecting the desired port(s) and pressing
the Reset Port(s) button. This will kill whatever service was on the port and reset it back to
the current configuration settings.
You may reboot the entire device server by pressing the Reboot button. This is the
equivalent of power cycling the unit.

Flash Management
The Flash Management page allows you to maintain your device server’s software,
configuration information, and error history:

Flash Update
The Flash Update command allows you to update the device server’s software or
configuration segment across the network. You can determine the device server’s software
revision by looking at the Welcome page, or by using any of the NativeCOM host utilities
(NativeCOM Configuration Utility or Port Server Utility).
You will need ONE of the following tools on your local network to perform the update:
1. Web browser
2. Systech’s Port Server Utility for Windows (included with NativeCOM)
3. Systech’s command-line r4000 utility (available for Windows and Unix systems)
To use the Web Browser, type in the BDNL filename to upload or click the Browse button to
select the file from your local machine. Then click the Update Flash button. To use one of
the Systech utilities, refer to the appropriate documentation.
DANGER: SPECIAL CARE MUST BE TAKEN WHEN UPDATING THE
SOFTWARE. REGARDLESS OF WHICH UPDATE METHOD YOU USE, DO NOT
INTERRUPT THE UPDATE ONCE IT HAS BEGUN. LOSING POWER DURING
THE UPDATE WILL RISK CORRUPTING THE SOFTWARE IMAGE AND MAKING
THE DEVICE SERVER UNUSABLE. If this does happen, call Systech to arrange for
the device server to be returned and reprogrammed at the factory.
Note: you may only download an OS image that will fit in the flash memory. Units with
1MB flash will not accept images that require the 2MB flash. The “Firmware flash space”
value on this page indicates the largest OS image that will fit in this unit.
Download Flash Information

You can use the links in this section to download information about the device server to
BDNL or text files on your system. Right-click on one of the links and save the link to a file:
• Configuration Database: Contains configuration information (text or BDNL)
• Product Data Area: Contains product information and error history log (BDNL-only)
Once saved to the host, the configuration BDNL file can be restored to a device server using
the Flash Update method above.

Restore Factory Defaults
Clicking the Restore Defaults button will set the configuration back to the factory default
values. You can also restore the device server’s factory default configuration by pressing
and holding the "Reset" button for a little over 5 seconds. The device server will initially
blink the status LED red and yellow to notify you that the configuration is about to be
restored. After it changes to blinking green and yellow, release the “Reset” button. The
factory default configuration is restored and the unit reboots. Either method will reboot the
device server.
PDA Compaction
The device server stores factory configuration information, boot time information, and error
records in the Product Data Area (or PDA). This information is stored in flash memory and
can fill up over time. You can use the Compact Flash command to reclaim Product Data
Area space. There are two types of compaction operations:
• Standard Compaction: only removes old records
• Total Compaction: removes old records and error records
Each Compaction method will list the number of bytes that can be reclaimed by selecting
that method. In general, you should never need to do this unless directed to by Systech

support. The flash used by the PDA is independent of the rest of system memory, and has
no effect on system performance or resources.
If you select Total Compaction, you should save the PDA to a host file before compacting.
The error records may be useful to Systech support personnel for debugging hardware and
software problems on your device server. Select the type of compaction you would like and
press the Compact Flash button.
Other Debugging
Refer to the hardware manual for a description of the LED activity during operation of the
device server.
If you are using NativeCOM or RTN on the host system, you can also use the debugging
tools in those products with the device server.

Chapter 5: Modem Emulation
The device server can be configured to allow legacy devices that interact with a Hayes
compatible modem to function over a TCP/IP network. When modem emulation is enabled,
the device server will respond to AT commands generated by the attached device. After
receiving the dial command, the device server will make a TCP connection to the specified
host. The device server will also accept incoming TCP/IP connections and generate the
appropriate response codes. As with incoming TCP connections, each Systech serial port
accepts incoming TCP connections on two TCP ports: an 8000-series port (for raw or SSL
data), and a 9000-series port (for telnet data).
Modes
A port with modem emulation enabled can be in one of two modes: command or data. The
port starts out in command mode. In command mode, the port is only interacting with the
host/device connected to the serial port. It accepts AT style command interaction and
responds appropriately. Successfully making an outgoing connection, ("dialing" with the
ATD command) or accepting an incoming connection ("answering" with the ATA command)
switches the port to data mode. In data mode, characters received on the serial port are
transmitted to the TCP connection and vice versa.
Escape Sequence
When in data mode, the device server looks for an incoming escape sequence on the serial
port. The escape sequence consists of a one second pause, three break characters ('+'), and a
final one-second pause. Receipt of this sequence results in the port switching to command
mode. Neither the escape character ("+") nor the pause timing is programmable.
Types of TCP/IP connections

TCP/IP connections may be in raw TCP mode (with or without SSL security), telnet or telnet
binary mode. These are the same settings available for the Incoming/Outgoing network
connection services on the device server. In raw mode, TCP data is passed to/from the
TCP/IP connection without any modification. In telnet and telnet binary mode, data
coming in the TCP/IP connection is scanned for telnet sequences that are handled
appropriately. In telnet binary mode, outgoing TCP/IP connections attempt to negotiate
telnet binary mode. Telnet/telnet binary connections may negotiate RFC 2217 mode for
support of clients like Systech's NativeCOM.
80-001061-6 Modem Emulation Page 59

Outgoing and Incoming Calls
After automatically accepting an incoming connection, the device server will begin
generating "RING" response codes to the device at 6-second intervals. Incoming network
data is buffered until the device completes the connection by entering data mode. The
device may enter data mode either manually by issuing the "ATA" command, or
automatically after receiving the number of rings specified in register S0. If the device server
is configured such that DCD will follow the connection status (AT&C1), DTR will remain
low until the connection is completed. If not(AT&C0), DTR will remain asserted at all times.
Outgoing calls are made by the ATD command. This initiates an attempt to make a
connection to the specified IP:port pair (see Phone Numbers below). A successful
connection will send the "CONNECT" result code out the serial port and enter data mode.
However, if the dialstring was suffixed with a ';', the modem will return to command mode
after establishing a connection. If the connection fails for any reason, the "NO CARRIER"
result code is returned.
AT Commands
All AT command strings, with the exception of the break sequence ("+++") and the repeat
command ("A/"), must be terminated with the command line termination character, defined
in S3 (default is CR). All characters before 'AT' are ignored. Unsupported commands are
ignored and generate an "OK" result code. Multiple commands may be combined on a
single line, however the AT command string is currently limited to 40 characters.
Example:
AT&FE0V0

Supported Commands
Command Function Result

/ Repeat last command Varies
Note: command executes upon "/"
character. CR not needed.
<blank> Attention OK(0)
A Answer OK(0), NO CARRIER(3)
Dial CONNECT(1), NO CARRIER(3)
D If suffixed with ";" character, will return to
command mode upon connection.
Echo Mode OK(0)
En 0=Turn command echo off
1=Turn command echo on (default)
Hn Hangup OK(0)
Terminate connection.
Optional argument has no function
In Information
0=Serial Port Speed 33600 (Note: Actual value equals current
port speed)
3= Model and Version NDS/5102 (2 Port, RJ-45) v01A
O Return to data mode from command
mode
Result Codes
Qn 0=Enable result codes (default) OK(0)
1=Supress result codes <blank>
Sn=mm Set register to specified value (see OK(0)
Sn? below)
Return current value formatted as 3
digit decimal
Result Code Format
Vn 0=Numerical result codes 0
1=Verbose result codes (default) OK
Result Code Format
0="CONNECT" upon entering OK(0)
Xn online data state
1-4="CONNECT <text>" upon
entering online data state
Zn Load factory default settings OK(0)
&Cn DCD Control OK(0)
0=DCD always on
1=DCD follows connection status

(default)
&Dn DTR Control OK(0)
0=ignore
1=loss of DTR switches to command
mode and leaves connection open
2=loss of DTR switches to command
mode and closes connection
(default)
&F Load factory default settings OK(0)
&Fn Equivalent to ATZ without dropping
the connection. This command does
not affect the flash configuration for
the port.
&V Display S-register values Ex:
&V0 E0 Q1 V0 &C1 &D2
S00:002 S02:043 S03:013 S04:010 S05:008
&V1 Status Returns reason for the last disconnect:
TERMINATION REASON......DTR LOSS
TERMINATION REASON….CARRIER LOSS
&W Write current configuration to flash OK(0)
&W1
&Xnnn Change baud rate. OK(0)
Nnn Baud
3 300
12 1,200
24 2,400
48 4,800
96 9,600
14 14,400
19 19,200
28 28,800
38 38,400
57 57,600
115 115,200
&x Any other & command is ignored OK(0)
%x Any % command is ignored OK(0)
+x Any + command is ignored OK(0)
$xn Any $ command is ignored OK(0)
including 0 or more digits after the
command.

S-Registers
S Registers are 1 byte, volatile registers used to store configuration data. They are reset to
the default state whenever modem emulation is enabled, or the ATZ/AT&F command is
received. They can be saved to flash memory with the AT&W command. When the port is
opened, the saved parameters are applied to the port.
Supported S-registers
Register Contents Default

S0 Automatic Answer(# of RING's) 0(disabled)
S1 Number of RING's Received 0
S3 Command Line Termination Character CR(13)
S4 Response Formatting Character LF(10)
S5 Command Line Editing Character BS(08)
S12 Guard time on either side of the +++ 50
sequence to break into command
mode. Specified in 50ths of a second.
Response Codes
Result Code Numeric Reason

(ATV1) (ATV0)
OK 0 Command Successful
CONNECT 1 Connection Established
RING 2 Incoming connection awaiting answer
NO CARRIER 3 Connection Terminated
ERROR 4 Error in AT command string
CONNECT 1200 5 Connected – Serial Port Speed is 1200 baud
NO DIALTONE 6 Not Used
BUSY 7 Not Used
NO ANSWER 8 Not Used

Modem Signal Behavior

The device server is not a modem (a DCE device), but is a terminal (DTE) device. It is
designed to be connected to another DTE device via a crossover or null-modem cable.
Specifically, the DTR, DSR and DCD signals should be crossed with the device as follows:
Device Device Server
DCD,DSR DTR
DTR DCD,DSR
The RI (Ring Indicator) signal does not have a corresponding outgoing signal so it is not
supported.
Refer to the device server hardware manual for specific pinout information for your unit.
To emulate a modem properly, the device server does the following:

Mode Modem DCD Behavior
Settings
Command/Data Always on DTR is asserted
(&C0)
Follow DTR is asserted only when TCP/IP connection is
connection present and has been accepted via ATA or auto-answer.
(&C1) DTR is de-asserted when connection is lost
The device server monitors its DCD signal in order to detect changes in the device's DTR
signal. The following behaviors occur on loss of DCD only.
Mode Modem DTR Response to loss of DCD
Settings
Offline AT&D0 Ignore
AT&D1 Ignore
AT&D2 Ignore
Online AT&D0 Ignore
AT&D1 Drop to command mode, preserving connection
AT&D2 Drop to command mode, terminating any connection

Phone Numbers
The "phone number" used in an outgoing connection for an "ATD" command may be a real
phone number that is translated to an IP/port pair (see Phone Number Translation) or it
consists of an IP address and optional port number. All leading non-numeric characters
(such as the T or P dial modifiers) are ignored. A number of formats are accepted for the
“IP” phone number.
Format Example Notes
Dotted decimal a.b.c.d Numbers are from 0 to 255
192.168.1.1
Comma decimal a,b,c,d For programs that don't allow dots in phone numbers
192,168,1,1
Fixed format aaabbbcccddd 12 digit IP address, each number is three decimal digits
192168001001 with leading zeroes
Optional port :xxxxx Decimal TCP port number from 0..65535
number
• If no phone number (IP address) is specified, the Destination IP Address configured

for the port is used.
• If no port number is specified, the Destination TCP Port configured for the port is
used.
• The source port for the TCP connection follows the Source TCP Port configured for
the port.
Port Settings
Most of the serial port settings (like baud rate) are controlled by the configured port settings
on the device server. Modem emulation does not support changing these from AT
commands.

Chapter 6: License Information
This product incorporates software from "eCos, the Embedded Configurable Operating
System, Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003 Red Hat, Inc." The eCos software
used by this product is licensed under "The eCos license version 2.0". As such, certain
portions of this product's software are covered by the GNU General Public License and are
available from Systech Corporation upon request.
For more information about eCos licensing, please see the following:
http://www.gnu.org/licenses/ecos-license.html
http://sources.redhat.com/ecos
---------------------
/* ====================================================================
* Copyright (c) 1998 The OpenSSL Project. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. All advertising materials mentioning features or use of this
* software must display the following acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)"
*
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
* endorse or promote products derived from this software without
* prior written permission. For written permission, please contact
* [email protected].
*
* 5. Products derived from this software may not be called "OpenSSL"
* nor may "OpenSSL" appear in their names without prior written
* permission of the OpenSSL Project.
*
* 6. Redistributions of any form whatsoever must retain the following
* acknowledgment:
* "This product includes software developed by the OpenSSL Project
* for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)"
*
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
80-001061-6 License Information Page 66

* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
* ====================================================================
*
* This product includes cryptographic software written by Eric Young
* ([email protected]). This product includes software written by Tim
* Hudson ([email protected]).
*
*/
__________________________________________________________________________
Original SSLeay License

__________________________________________________________________________
Copyright (C) 1997 Eric Young ([email protected])

All rights reserved.
This package is an SSL implementation written by Eric Young ([email protected]).

The implementation was written so as to conform with Netscapes SSL.
This library is free for commercial and non-commercial use as long as

the following conditions are aheared to. The following conditions
apply to all code found in this distribution, be it the RC4, RSA,
lhash, DES, etc., code; not just the SSL code. The SSL documentation
included with this distribution is covered by the same copyright terms
except that the holder is Tim Hudson ([email protected]).
Please note that MD2, MD5 and IDEA are publically available standards
that contain sample implementations, I have re-coded them in my own
way but there is nothing special about those implementations. The DES
library is another mater :-).
Copyright remains Eric Young's, and as such any Copyright notices in

the code are not to be removed.
If this package is used in a product, Eric Young should be given attribution
as the author of the parts of the library used.
This can be in the form of a textual message at program startup or
in documentation (online or textual) provided with the package.
Redistribution and use in source and binary forms, with or without

modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
"This product includes cryptographic software written by
Eric Young ([email protected])"
The word 'cryptographic' can be left out if the rouines from the library
being used are not cryptographic related :-).
4. If you include any Windows specific code (or a derivative thereof) from
the apps directory (application code) you must include an acknowledgement:
"This product includes software written by Tim Hudson ([email protected])"
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND

ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
License Information 67
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
The licence and distribution terms for any publically available version or
derivative of this code cannot be changed. i.e. this code cannot simply be
copied and put under another distribution licence
[including the GNU Public Licence.]
The reason behind this being stated in this direct manner is past
experience in code simply being copied and the attribution removed
from it and then being distributed as part of other packages. This
implementation was a non-trivial and unpaid effort.
68 License Information
Index
Errors
A Framing, 47
ARP, 6 Overrun, 47
AT commands, 59 Parity, 47
escape character, 16
B example applications, 39
baud, 11 F
bits per character, 11
BOOTP, 5 factory default, 57
browser, 10 Flash Management, 55
Flash Update, 56
C flow control, 11
DTR/DSR, 11
character size, 11 RTS/CTS, 11
class, IP, 27 XON/XOFF, 11
COM port, 39 FQDN, 23, 24
compaction, 57
configuration, 5 G
console server, 41
gateway, 31
D
H
DCD, 15
debugging, 58 host route, 31
default configuration, 57
I
default gateway, 32
default route, 32 incoming connection, 8, 12, 60
destination IP address, 15 IP
destination TCP port, 15 address, 26
DHCP, 5 class, 27
dialup modem, 41 destination address, 15
DNS, 29 netmask, 27, 42
domain name, 30 route, 31, 42
DTR/DSR, 11 temporary address, 6
dump memory, 52
K
E
keep-alive, 26, 28
eCos license, 66 keyboard hit, 16
error code, 45
Index 69
L response codes, 63
restart delay, 15
license, 66
restore default configuration, 57
log, 44
RFC-2217, 11
Log/Debug, 51
routes, 42
LPR/LPD, 7
RTS/CTS, 11
M
S
memory dump, 52
S Registers, 63
modem, 40, 41
serious system error, 45
response codes, 63
SSL mode, 23
modem emulation, 9, 14, 59
status, port, 46
modem signals, 46, 64
stop bits, 11
multiplexer, 40
system log, 44
system password, 34
N
name server, 29 T
NativeCOM, 5, 7
task, 48
NativeCOM Configuration Utility, 56
TCP, 26
netmask, 6, 26, 27, 42
destination port, 15
network route, 31
keep-alive, 28
network settings, 26
port 8000-9000, 8, 59
NTP, 33
port 9096, 45
telnet, 16
O
telnet binary mode, 16
outgoing connection, 8, 12, 14, 15, 60 telnet escape character, 16
telnet mode, 16
P Telnet Mode, 16
parity, 11 temporary IP address, 6
password, 34 terminal, 40
peripherals, 39 terminal type, 16
phone number, 65 TFTP server, 33
Ping, 53 time server, 33
Port Server Utility, 56 troubleshooting, 43, 51
port services, 12
port status, 46 U
Product Data Area, 56 Unix, 39
update software, 43, 56
Q utility
quiet mode, 16 NativeCOM Configuration, 56
Port Server, 56
R r4000, 45, 56
r4000 utility, 56 W
reboot, 6, 54
remote network, 31, 42 wait for keyboard hit, 16
Require carrier, 15 web browser, 5, 10, 56
require DCD, 15 Windows, 5
reset ports, 54
70 Index
X XON/XOFF, 11
Index 71

Systech NDS Admin

Uploaded by

Copyright:

Available Formats

Systech NDS Admin

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Systech NDS Admin

Uploaded by

Copyright:

Available Formats

Device Server

Document number 80-001061-6

Date Revision Description

CHAPTER 3: EXAMPLE APPLICATIONS ...............................................................39

CHAPTER 4: TROUBLESHOOTING AND UPDATING ...........................................43

CHAPTER 5: MODEM EMULATION ........................................................................59

CHAPTER 6: LICENSE INFORMATION ..................................................................66

80-001061-6 Introduction Page 3

Device Server Configuration

Setting the IP Address

80-001061-6 Configuration Page 5

Assigning a Temporary IP Address via the Network

80-001061-6 Configuration Page 6

Configuring NativeCOM Ports for Windows

Configuring Printers (via LPR/LPD)

80-001061-6 Configuration Page 7

Configuring Outgoing Network Connections

Configuring Incoming Network Connections via Telnet Server

80-001061-6 Configuration Page 8

Configuring Modem Emulation

80-001061-6 Configuration Page 9

80-001061-6 Configuration Page 10

NOTE: NativeCOM, (or any RFC-2217 Telnet client with COM-PORT-OPTION

80-001061-6 Configuration Page 11

Incoming Raw TCP

80-001061-6 Configuration Page 12

80-001061-6 Configuration Page 14

Outgoing Telnet Connection

Network Connection Options

Destination Hostname/IP Address

Destination TCP Port

Source TCP Port

Require carrier/Generate hangups

80-001061-6 Configuration Page 15

Telnet Escape Character

80-001061-6 Configuration Page 16

80-001061-6 Configuration Page 17

80-001061-6 Configuration Page 18

80-001061-6 Configuration Page 19

80-001061-6 Configuration Page 20

Raw or Secure TCP

(Secured) Simple POS Terminal Protocols

(Secured) Converted POS Terminal Protocols

Most point-of-sale terminals expect their dial-up host to provide ENQ/EOT/ACK/NAK

80-001061-6 Configuration Page 21

Paymentech™ NetConnect Conversion

Sends secured payment transactions to Paymentech™ Network Services using the

First Horizon Internet Gateway

80-001061-6 Configuration Page 22

Peer Identity Verification

List of Allowable Ciphers

80-001061-6 Configuration Page 24

80-001061-6 Configuration Page 25

80-001061-6 Configuration Page 26

Class IP Address Default Netmask Network Number Host Number

Table 2-1: Default Netmasks

IP Address IP Netmask Network Number Host Number

Table 2-2: IP Netmask Examples

80-001061-6 Configuration Page 27

TCP keep-alive is a standard feature of TCP/IP that can be configured to automatically