|
Version 4.34 NetSerial
Users Guide
NetSerial is software for Windows that creates virtual serial communication
(COM) ports.
All 3 modes can support either Raw TCP or the Telnet Protocol, and
several telnet options can be uniquely configured for each COM port. Features:
Operating System Software:
Before installing the NetSerial Software:
Run the NetSerial installer to begin the Installation Wizard. It will take you though the following steps:
The installation should only take a moment to finish. Once the installation completes, you will automatically be taken to the NetSerial"Select Ports" window shown below (if this is a first time installation). NetSerial can create from 1 to as many as 256 virtual COM ports, which are each redirected by NetSerial to a remote server or client on the network (or over the internet). The first Step is to select which virtual COM ports you wish have the NetSerial create. When NetSerial is installed for the first time, it will automatically take you to the Select Ports dialog.
The first time NetSerial is installed it starts at the Select Ports dialog, and after you select least one virtual COM port and clicked OK , it opens the NetSerial Configuration Window.
4. Configuration Basics You can run the NetSerial Configuration by right clicking the NetSerial
Tray Icon The NetSerial Configuration window allows you manage the settings for
each virtual COM port individually.
The connection type you select should match the connection type used
by the remote site. Raw TCP/IP ignores any telnet commands which appear in the data stream, and leaves all the data "as is". When either Telnet opton is selected, some of these options
will appear below it: (The last one only appears when standard "Telnet" is selected.) These options deal with how the Telnet protocol negotiates with the remote connection during the initial connection. Request Remote Telnet Echo - This causes NetSerial to ask the remote connection to echo back any characters that are sent. Default=Disabled. Accept Local Telnet Echo - This causes NetSerial to tell the remote connection that this end (the application software using the COM port) will agree to echo characters received back to the remote connection. Default=Disabled. Request Binary Connection - This will cause NetSerial to ask the remote connection to transfer data in binary mode. Default=Enabled.
Port Modes:
The Outbound Mode allows NetSerial to act as a client, which
connects to the defined Server IP address and TCP port each time the
virtual COM port is opened, and data is redirected between the TCP connection
and the COM port. The Virtual Modem is used to fool application software into thinking that they are communicating with an analog modem, which recognizes modem AT commands such as ATD to dial an outgoing connection, or ATA to Answer an incoming connection. The Virtual Modem dial's the IP Address of a server. A Virtual Modem can also be configured to accept Inbound TCP connections, causing the appliation software to think it is recieving/answering a modem based phone call but it is actually answering a TCP connection. The following 3 chapters describe how to configure these 3 Port modes.
In the above configuration, COM3 is set to Outbound Port Mode. The following COM port options are available in Outbound mode: The DSR/CTS/DCD/DTR options are only used if the COM Port Control protocol
is not available on the other end of the connection. They are explained
below: The following command buttons are found at the bottom of the NetSerial
Configuration window: Once you have assigned the correct Server IP address, TCP Port, and redirect method to each of the virtual COM ports, you should verify that each virtual COM port can communicate with the Serial Server by selecting the COM port, and clicking the Test Server Connection Button.
If your virtual COM ports tested with similar results as above, then you have successfuly configured the COM port for outbound use.. If the result says "Connection Failed" then either
the remote server is not accepting connections for some reason, or there
is a firewall blocking access. See the
Troubleshooting Chapter. Once you have successfully configured the virtual COM ports which were created, and you Save or Close the NetSerial Configuration window. If you defined any Outbound mode ports, you will be provided with a reminder to install modem drivers which will guide you through the process.
6. Configuring a virtual COM port for Inbound
The following command buttons are found at the bottom of the NetSerial
Configuration window: Note: When Using NetSerial to answer inbound calls coming into a Cisco router (or access server) with digial modems, see Chapter 15.5.
7. Configuring a virtual COM port as a Virtual Modem
The following port options are available in Virtual Modem mode: The following command buttons are found at the bottom of the NetSerial
Configuration window:
Once you have configured a Virtual COM port for inbound or Outbound
mode, you can use it by simply selecting to use that COM port number
from within your application software. The COM port used by an application is generally defined in the "settings"
or "configurations" section of the application software. Your application software can now use this COM port as if it was talking to a local COM port. When using NetSerial virtual COM ports, you can open the NetSerial
Monitor to see the real-time Status of each Virtual COM port,
such as current baud rate, connection state, and what IP address it
is connected to.
NetSerial Virtual Modems can be configured to allow outbound and inbound
connections. NetSerial's Virtual Modem allows you to connect to a remote system by telling your communication software to "Dial" the IP address of the remote system you wish to connect to, rather then a phone number. In some cases you can specify a hostname instead of an IP address, but often this will not work because communication programs usually don't expect a phone number to contain non-numeric values.
Some application software will only allow digits to be passed in a "Dial" command, so other characters such as the periods found in an IP Address would be stripped out. To avoid such issues, the recomended method is to define the IP address in a 12-digit format which can be passed unaltered to NetSerials Virtual Modem from the application software. The 12-digit IP format A standard IP address consists of 4 numbers each between 0-255, so
they are each up to 3 digits long. To convert to the 12-digit format, pad each of the 4 numbers with leading
zeros as needed so that each of the numbers is exactly 3 digits long.
Then remove the periods between the numbers, so that only the 12 digit
number remains.
IP addresses converted to the 12-digit format look like phone number to the application software, and are converted back to the IP address by NetSeral when it is told to "Dial" the number. The 17-digit IP format NetSerial's Virtual Modems connect to the telnet port (TCP port 23)
by default, but the application software can specify an alternative
TCP port to connect to by adding 5 more digits to the 12-digit format,
for a total of 17 digits alltogether. The last 5 digits represent the
TCP port to connect to, which also needs to be padded with leading zeros
so thatit is exactly 5 digits.
Other formats
Either of these methods will default to using TCP port 23 (the Telnet
port), unless another TCP port is specified. This can be done by adding
a colen followed by the TCP port number to the end of the IP or hostname.
For example to connect to TCP port 1000 you could use 1.2.3.4:1000 or
domain.com:1000. NetSerial's Virtual Modems can be optionally be configured to allow inbound connections. To allow Inbound Connection via a Virtual Modem, the following must be done:
If the application is a BBS software operating with NetSerial performing as a telnet server, the following settings are suggested: Connection type: Telnet The suggested BBS Init string is AT&D2
Each Virtual COM port created by NetSerial is Listed under "Ports"
in the Status screen. Baud: The number of times per second that an RS-232 serial signal
can change on this port. Encryption: When Encryption is enabled on an open COM port, the Encryption field will display the current Encryption Cipher.
Configure: Opens the NetSerial Configuration Window. (This button may be removed by the Administrator to prevent users from making changes to the configuration). Help: Opens the Users Guide. About: Displays the copyright and contact information. You can monitor the Data Flow occurring on all of the Virtual COM ports by selecting the Trace Tab in the NetSerial Monitor.
The trace Window normally only displays messages when virtual COM ports are created or removed, or the virtual serial port driver is restarted. When you select the Enable Trace checkbox, you are shown the
serial data moving to and from the client and server along with the
timestamp and name of the COM port. You can also enabled the Hex
Display checkbox to show the data in hexadecimal numeric format
instead of the default ASCII code format, and you can enable Auto
Scroll checkbox to have the window scroll as more data is logged.
There are three color codes used in the trace data:
There are four buttons used to control the trace log: Clear: Erases the entire log from the window. Save Log: Saves the log file in either ASCII format (.log) or binary format (.trc) Open Log: Opens a binary format (.trc) trace file that was previously
saved. Trace Options: The following Trace Options are available:
DebugView is an application that lets you monitor debug output
on your local system, or any computer on the network that you can reach
via TCP/IP. DebugView is a free product from Sysinterrnals, which can
be downloaded here:
http://www.microsoft.com/technet/sysinternals/miscellaneous/debugview.mspx
Credentials are a username and password which can be provided when
connecting to a remote server in Outbound mode.
Once you have enabled one of the Credential options in the NetSerial
Configuration, you should run the "Test Server Connection"
to make sure that the security handshaking between the client and server
are sucessful.
|
and selecting Status.
|
Each Virtual Phone book is stored in a flat text file, defined in the "Phone Book Location" field.. |
 |
When the "Use Virtual Phone Book" checkbox is enabled on a Virtual Modem, this configures NetSerial to process ATD dial commands by translating a dialed Phone Number to a hostname or IP address. A TCP port can optionally be included in the translation as well.
In the above image, there are two virtual phone numbers defined. If the dialed phone number begins with either of these phone numbers, NetSerial will translate it to the defined hostname and TCP port.
The dialed phone number is compared starting at the first numeric digit
after the ATD command, and ending prior to a space, comma, colen, or
Carrage Return character.
If a dialed number does not begin with a digit, or contains a dotted
ip address, then the translation is not performed.
The remote Computer name can contain letters, digits, dash or period
characters.
The remote TCP port can be left blank (which defaults to TCP Port 23
the dialed phone number does not include a colen followed by the TCP
port value), or it can contain a value up to 99999.
14. Using Multiple Servers for Failover
If you have multiple device servers or modem servers installed, you can allow NetSerial to maintain a list of servers to attempt to connect to each time a Virtual COM port is opened. If the first server on the list is either full or unreachable for any reason, the client tries the next Server on the list.
|
The Client Configuration Screen looks different when Use Multiple Server failover is enabled. The usual input fields for IP Address, Port, and Pool are replaced with the Server List options. These allow you to choose from several different lists of servers, and will allow you to edit any one of those lists. Up to 20 Server Lists can be defined, and each server list allows
up to 5 Servers to be specified. |
 |
|
In the Edit Server List you can defined up to 5 servers to be specified, in the order you want the client to connect to. A Server list needs at least two servers defined. Each Server entry must have the IP Address (or hostname) of the Server, and the TCP Port. A Pool Name is optional, if no Pool Name is defined, the default pool will be accessed. When an application opens a COM port that is configured to use multiple servers, NetModem Client first attempts to connect to the first server on the list. If that server is either full or unreachable, the client attempts to connect to the next server on the list. This continues until a server with an available modem is reached, or until all the servers have failed. |
 |
Each Server List is stored in an ASCII text file in the NetSerial folder, allowing lists to be pre-installed by the administrator. The list files are named as serverX.txt, where X= the list number.
When using multiple servers, you can fine tune how long NetSerial waits for each server to respond when the Client requests a COM port from a server. By default it waits up to 3 seconds for the server to respond, and if there is no response then it switches to the next server in the list. The settings can be found under the "Advanced" button in the NetSerial Configuration window. The value is in milliseconds (1/1000th of a second), so the default value of 3000 = 3 seconds maximum. On a slow Network you might need to increase this value, and on a Network in which Several Failover Servers are defined, you might need to decrease the value in order to speed up the search.
15. Troubleshooting and Technical Notes
|
|
15.1. If Outbound Mode connections fail.
First run the NetSerial Configuration and check that the virtual COM port being used has the correct IP address (or hostname) and TCP port defined for the remote server.
Next run the "Test Server Connection" in the NetSerial
Configuration. This is an simple way of determining if NetSerial is
able to connect to the remote server.
If the Server Connection Test fails to connect, it indicates that either
the server is not accepting incoming connections from the NetSerial
PC or there is a network/firewall issue blocking the connection. You
can confirm this using telnet.exe from the NetSerial PC by opening
a Command Prompt and typing in the following command line and
pressing [Enter] :
telnet 192.168.0.1 23
(replace 192.168.0.1 with the IP address of the server, and replace
23 with the TCP port to connect to)
If the telnet connection is sucessful, the screen will be cleared to
all black, and the remote server may or may not display some text or
prompts afterwards. Otherwise Telnet.exe will display an error message
such as
"Could not open connection". If telnet.exe fails to
connect to the remote server, then NetSerial will also fail to connect.
If The Server Connection Test sucessfully connects, yet your application
software is still not functioning properly you should create a trace
log to determine the cause.
Review the Monitoring Activity on the Virtual COM ports
chapter for further information.
15.2. If Inbound
Mode Connections Fail.
Take the following steps to determine why an Inbound Mode connection
fails.
- Open the NetSerial Monitor and view the Status tab to verify that
the virtual COM port has been opened by your application software.
If the COM ports Baud and State fields in the below image are empty then the COM port is not open. In the above example COM4 is open and has received a connection, and COM5 is closed. If a COM port is closed then NetSerial can not accept incoming connections for this COM port.
- Check if you are able to connect to the TCP port locally using telnet.exe
from the same computer which NetSerial is installed on. Do this
by opening a Command Prompt (Click on Start > Accessories
> Command Prompt) and type in the following command line and
press [Enter]:
telnet localhost 23
(Replace 23 with the actual TCP port number you defined in the NetSerial Configuration)
If the connection is sucessful, the NetSerial Status monitor will show the IP address 127.0.0.1 (which means it's a localhost connection).
- If you connected sucessfully using telnet.exe from the local
computer, then try the same test from a remote computer (perferably
the remote computer you will be using to connect to NetSerial from),
but use the IP Address of the Netserial PC instead of using
the word localhost. For example:
telnet 192.168.0.1 23
If the telnet test fails remotely, but connected sucessfully during the local test, then the cause is either a firewall setting or a network issue. Review the Firewall Configuration Chapter for assistance.
- If you connected sucesfully using telnet.exe from the remote computer,
then any other application on this remote computer should also be
able to connect to NetSerial. To further diagnose the cause you will
need to create a trace log of a failed session. Review the Monitoring Activity on the Virtual
COM ports chapter for information on creating a trace log.
15.3. If
Virtual Modem Connections Fail.
Virtual Modem Mode can support both inbound and outbound connections.
If an Inbound Virtual Modem connection
fails, check the following:
- If you are running a firewall, it needs to be configured to allow
inbound access.
- The COM port configured for "Virtual Modem" mode
must have the "Accept Inbound connections" option
checkmarked, and must also have the the Inbound TCP Port field defined.
- The Application software must open the COM port and send one of
the following modem commands to:allow the Virtual Modem to accept
an incoming connection.
ATS0={any non-zero value} This command enables auto-answer mode.
ATA This forces the Virtual Modem to manually answer an incoming call.
You can confirm that your appliaction software sends one of these modem
commands to the Virtual Modem by creating a trace log of a failed session.
Review the Monitoring Activity on the Virtual COM ports
chapter for information on creating a trace log.
If an Outbound Virtual Modem connection fails, check the following:
- The Application software must open the COM port and send a Dial
command to the Virtual Modem's COM port in order to establish an outbound
connection. A Dial command contains the letters ATD
followed by either a hostname or a properly formatted IP address and
tcp port.
- The NetSerial PC must be able to reach the remote IP address and tcp port.
You can confirm that your application software sends a Dial
command by creating a trace log of a failed session. Review the Monitoring
Activity on the Virtual COM ports chapter for information on
creating a trace log. Review the Using
a Virtual COM port as a Virtual Modem chapter for information
on proper IP address formats.
You can confirm that the NetSerial PC can reach the remote IP address by using the telnet.exe tool, as described in the If Outbound Mode connections fail chapter.
15.4. Advanced
configuration options
To access the NetSerial advanced configuration options, click on the
Advanced button from the NetSerial Configuration screen.
The following options are found under the Options tab:
- Delay closing COM port for [7500] ms.
When this option is enabled, it causes NetSerial to remain connected to the server for the specified amount of time in milliseconds that begins when the virtual COM port is closed by the application. This ensures that the modem or other remote device is not assigned to another client while a client application closes and reopens the virtual COM port, and ensures that an active connection is not lost if one application or process hands off a COM port to another one.
By default this option is Enabled, with a value of 7500 ms. (7.5 seconds).
- Show message if port not available
When this option is enabled, NetSerial will display a pop-up message when an application attempts to open a NetSerial Virtual COM port and Server is unable to provide access to the remote device. The pop-up message displayed to the client user says "Server reports COM port not available"..
By default this option is Enabled.
- Update Routing Table if needed
When this option is enabled, NetSerial will add a direct route to the server when a virtual COM port is opened, if the server is not on the same subnet as the NetSerialt PC and there is not already a direct route defined. Once the virtual COM port is closed, the added route will then be removed. The reason for adding a direct route, is that some PPP applications such as Windows Dial-Up Networking will change the computer's default route in the IP routing table when they have established a connection to the remote network. Once this change is made, the NetSerialPC will no longer have a route to the server PC if the two PC's are not on the same subnet. Without a valid route, the client will lose its connection to the Server.
Some third-party VPN software will not permit changes to the routing table. If the NetSerial PC is connected to a remote modem on a Server PC through a VPN, this option may need to be disabled. In such a case, the VPN users would be unable to use NetSerial to establish a dial-up networking connection.
By default this option is Enabled.
- Maximum time to wait for a Failover Server
When this option is enabled, and the NetSerial virtual COM port (Outbound mode) is configured to use Multiple Server Failover this option will limit the time that NetSerial waits for each server to respond before it gives up and attempts to connect to the next server in the failover list.
By default this option is Enabled, with a value of 3000 milliseconds (3 seconds).
- Synchronize with server during COM port open
When this option is enabled, each time an application requests to open
a virtual COM port, the
COM port open request is not completed until the following events occur
between the client and server:
1. The TCP connection to the server is established.
2. The SSL/TLS encryption negotiation is established (if encryption
is used).
3. The COM Port Control protocol is negotiated.
4. The user authentication is sucessful (if security is used).
Some applications may require that the COM port open function will synchronize
with the server by waiting until the server provides the modem before
returning a sucess status, or returning a fail status otherwise.
By default this option is Enabled.
15.5. How to answer calls through a Cisco router with digital modems
Cisco routers and access servers with digital modems (such as the AS5xxx
series, and 2800/3800 series with PVDM) are not able to accept incoming
calls while there is a reverse-telnet session to the modem. This means
that NetSerial can not use the Outbound mode to allow dial-in
connections to reach the NetSerial PC.
Instead, you must configure a NetSerial virtual COM port for Virtual Modem mode. Virtual Modem mode won't let you make outbound calls to a Cisco, so you can configure a seperate virtual COM port for Outbound mode in order to also do that.
Configuring the Cisco device
The Cisco device must be configured to make a TCP/IP connection to
the NetSerial PC when the incoming call is received by a specific modem.
In our example, the IP address of the NetSerial PC is 192.168.0.10 and
the TCP port number is 6000. The IOS configuration for the Cisco device
to allow this on line 1 is:
autocommand telnet 192.168.0.10 6000 /stream
Here is how the IOS Line Configuration would look:
line 1
modem inout
transport input telnet
modem autoconfigure type mica
autocommand telnet 192.168.0.10 6000 /stream
escape-character NONE (this line is only needed for an AS5350 / AS5400)
line 2 47
modem inout
transport input telnet
modem autoconfigure type mica
rotary 1
escape-character NONE (this line is only needed for an AS5300 / AS5400)
For each additional incoming phone line that you wish to redirect to a NetSerial Virtual Modem, another "autocommand telnet" line will need to be added in the Cisco IOS configuration.
Configuring the NetSerial Virtual Modem
The PC with the IP address used above (192.168.0.10) will need to have NetSerial installed and have a Virtual COM port configured for "Virtual Modem" mode, and the NetSerial Modem driver will need to be installed on the virtual Modem(s) that you create with NetSerial.
In the NetSerial Configuration, you will want to set the virtual COM
port for the following settings:
Port Mode: Virtual Modem
[x] Accept incoming connection
TCP Port: 6000
Connection Type: Telnet
This will allow the application software installed on the PC to use the NetSerial Modem driver (which is connected to the NetSerial virtual modem's COM port), to receive an incoming call from the Cisco device.
15.6. Preventing accidental client configuration changes.
If an Administrator is concerned about the possibility of a client user misconfiguring the virtual com port settings, there are two ways they can prevent the user from making changes to the Client configuration:
- The user can be given a limited account type in Windows.
This is done from the "User Accounts" option in the Windows
control panel.
- If the user requires an Administrator account, then the configure.exe
file can simply be removed from the NetSerial folder. This is usually
located in c:\program files\NetSerial\
This will also prevent the configure option from appearing in the system tray menu or on the NetSerial Monitor window.
15.7. Configuring a Firewall to work with NetSerial
If a firewall is being used on your network, and NetSerial needs to
accept incoming connections (Inbound mode, or Virtual Modem mode allowing
Inbound) then you need to configure your firewall to allow the incoming
connections.
This is done by permitting network traffic on the specific TCP port(s)
configured in NetSerial (TCP port 23 by default).
Some software firewalls (for example the Windows XP Firewall) can be
configured to allow incoming connections to a particular application
specifically. This feature will not work if the application is a Windows
Service (such as NetSerial is). Instead, you will need to allow incoming
connections on a specific TCP port.
How to configure the Windows XP Firewall to allow incoming connections
to NetSerial:
(This Firewall is only included with Windows XP Service Pack 2 or
later)
- From the Windows Control Panel, select the Security Center
icon.
- Select the Windows Firewall link under "Manage security
settings".
- Select the Exceptions Tab.
- To allow incoming connections only on the the TCP port used
by NetSerial:
- Select Add Port
- Type in the application Name (ie: NetSerial)
- Type in the Port number NetSerial uses (usually 23).
- Leave the TCP option selected (not UDP).
- Optionally you can select Change Scope to limit where the clients can connect from.
- Select OK
- Select Add Port
NetSerial never accepts connections on any TCP port other then the ones defined for each Inbound virtual COM port, and each Virtual Modem configured to accept inbound connections. Only a single TCP connection is used to carry both data and control information between each virtual COM port and the remote location.
Windows XP Firewall only blocks incoming connections, so it does not
need to be configured to allow NetSerial to make outbound connections.
If there is other firewall software installed on the NetSerial PC's
which block outgoing connections, it should be be configured to allow
the NetSerial COM ports to reach the outbound destinations.
15.8. NetSerial Support for DOS applications
NetSerial is compatible with Windows applications and also DOS applications
running under Windows.
Generally a DOS application which uses a COM port will do so by accessing
the serial port hardware directly. This hardware is called a UART,
which stands for Universal Asynchronous Receiver-Transmitter.
32-bit versions of Windows include a subsytstem to run DOS applications
known as the NTVDM, which stands for NT Virtual DOS
Machine. The NTVDM monitors the standard UART I/O ports for activity
by DOS applications on COM1, COM2, COM3, and COM4. The NTVDM redirects
any activity on these ports to the Windows COM port of the same name.
For this reason, DOS applications can only be used with NetSerial on
COM1-COM4 (Unless a Windows based FOSSIL driver is used and your DOS
application supports this).
Some DOS applications allow you to configure the UART settings for the
COM ports. The NTVDM only works with the standard UART settings shown
below:
| Serial Port | Base Address | Interupt |
| COM1 | 3F8 | IRQ4 |
| COM2 | 2F8 | IRQ3 |
| COM3 | 3E8 | IRQ4 |
| COM4 | 2E8 | IRQ3 |
While most DOS applications communicate with a COM port directly through the UART, there are a few DOS applications that can communicate by using the PC's BIOS Interrupt 14h or an enhanced version of the Interrupt 14h interface called a FOSSIL driver. If your DOS application says that it is compatible with Interrupt 14h or a FOSSIL, then you can install a third-party driver called ADF which will enhance performance of your DOS communication software. ADF is a free program which can be downloaded from: http://digsys.se/adf.html
An example command line to load ADF on COM4 would be:
ADF.exe COM4 2E8 3 57600 4096 1024
This should be loaded in the same DOS window that your DOS application
is started from afterwards, which can be easily done in a batch file.
For more information on ADF, please refer to the ADF documentation.
ADF is a DOS based FOSSIL driver, so it is limited to only working on
COM1 thru COM4. There are some Windows based FOSSIL drivers available
(such as WinFossil, NTFos, INT14) which can be used to support up to
256 COM ports.
15.9. Using NetSerial under Terminal Services or Citrix XenApp.
Windows Terminal Services and Citrix XenApp are both multi-user environments which can be used with NetSerial. When using either of these to allow "Thin-Clients" to access the Virtual COM Ports, you should use the following procedure:
- Install the NetSerial on the Terminal Server or Citrix XenApp PC.
- Select 1 virtual COM port in the NetSerial configuration, and configure
this port as needed. For example if this is an Outbound Mode port
you should assign the IP address and TCP port of the remote server.
- Next select as many additional Virtual COM ports as needed. (Usually
you will want to select one virtual COM port for each thin-client
user). Up to 256 Virtual COM port can be selected. All the additional
virtual COM ports will default to using the same configuration settings
as you assigned in step 2..
- When you click either the Save or the Close button,
all the virtual COM ports you selected are created, and you will be
guided to install a modem driver. If your application software does
not require a modem driver you can skip this step. If you do install
a modem driver, you will save time by selecting all the COM
ports you created to have the modem driver installed to all of them.
- Assign one of the virtual COM ports to each thin-client user. Just
like a real hardware COM port, each virtual COM port my only be opened
by one user/application at any given time. Therefore a unique virtual
COM port should be created for each user.
- Under the Advanced options in the NetSerial configuration, disable the "show message if COM port not available" checkbox, as otherwise these messages would be sent to every terminal services user.. If no COM port is available on the remote server, the thin client will be informed by an error message in their application software attempting to use a COM port.
Remapping COM ports in Windows Server 2003 / 2008 / 2012
Windows Server 2003 and 2008 (all versions except the Web Edition)
includes a command line utility called change.exe which can map
any COM port to a different port number under the current user's Terminal
Server session.
For example, a Terminal Services user could enter this command line:
change port COM12=COM1
This allows the current user to access COM1 in their application software, which is redirected to COM12 by Windows Server. COM12 could be either a physical COM port, or a virtual COM port created by NeSerial.
A second Terminal Services user could enter this command:
change port COM13=COM1
Now both users can access COM1 at the same time in their application
software, and they will really be using COM12 and COM13 respectively.
This allows all users to use application software configured for a particular
COM port, and allows legacy applications that only supported COM1-COM4
(or in some cases COM1-COM9) to be used by more then 4 or 9 Terminal
Services users at the same time. However, this will not work with TAPI,
so applications that need to communicate with a Modem Driver name rather
then a COM port value can not take advantage of this feature.
The change port command can be used as part of each users login
script to map COM1 to a specific NetSerial virtual COM port which is
reserved for that user. For example if COM99 is reserved for a particular
user, the following would be added to that users login script: change
port COM99=COM1
You can run change port without any parameters to display the available
COM ports and the current COM port mappings.
Limitations under Terminal Server, Remote Desktop, and Citrix XenApp
- Only one outbound PPP (Point to Point Protocol) modem connection
can be made at a time from any Windows PC, even under a multiuser
operating system such as Terminal Server, Remote Desktop, and Citrix
XenApp. This is not a limitation of NetSerial, but rather a limitation
within Windows.
For example, A Dial-Up Networking connection to an ISP uses the PPP protocol. This causes the Windows routing table to be changed so that all TCP packets that are sent outside of the local subnet are directed to this PPP connection. If another PPP connection is created, Windows again changes the routing table which causes the first PPP connection to fail. If you need to allow multiple users to use NetSerial's Virtual COM ports to make simultanious outbound PPP modem connections, you will need to install the NetSerial software on each users PC instead.
- Citrix XenApp prevents more then one outbound VPN (Virtual Private
Networking) Connection to be made using a modem.
- If a VPN connection is used to connect to the network containing NetSerial, then it is not possible to make a secondary VPN connection on a modem, (including a remote Modem accessed by NetSerial). This is due to a limitation in the VPN protocol.
15.10. Virtual Modem AT Command List
The following Modem AT commands are supported by the NetSerial Virtual Modems:
A - Answer
Manually accept an incoming connection. The Answer command is normally
sent to the modem after the application software receives a "RING"
response from the virtual modem. When the connection is sucessfuly established,
the application software recieves a "CONNECT" response from
the virtual modem.
D, DT or DP - Dial
Dial the following network (or internet) address. With a real modem,
this command is followed by a phone number to dial, but with the Virtual
Modem a network IP address or hostname is used instead. If the connection
is sucessful the application software recieves a "CONNECT"
response from the virtual modem, otherwise it receives a "NO CARRIER"
response.
E0 or E1 -Command Mode local Echo
Turns local character echoing on or off while the virtual modem is in
Command Mode. E0 disables echoing, E1 enables echoing. Command mode
means the modem is not online, so it is accepting AT commands. Default
= Enabled.
F0 or F1 - Online Mode local Echo
Turns local character echoing on or off while the virtual modem is in
Online Mode. F0 disables echoing, F1 enables echoing. Online mode means
the modem is connected to a remote location. Default=Disabled
H or H0 - Hook
Disconnects the current connection. If there is not an active connection
this is ignored.
O - Online
If a connection has been established, this causes the modem to exit
"Command Mode" and resume the telnet connection. Otherwise
this command is ignored.
Sr=n - S-Register Write
Set S-register number {r} to the value {n}. The supported set of S registers
is given below.
Sr=? - S-Register Read
Display the current value (setting) of S-register number {r}.
V0 or V1 - Verbose Responses
Sets the modem to use Verbose (text) or Numeric responses. V0 sets numeric
responses (ie: "0" instead of "OK"), and V1 sets
text responses. Default=V1
Z - Reset
This resets the virtual modem to use all the default settings.
&C0, &C1 or &C2 - Data Carrier Detect (DCD) Options
Controls how the the DCD signal is provided by the virtual modem:
&C0 forces the DCD signal to always be ON.
&C1 causes the DCD signal to indicate the true state of the remote
carrier signal.
&C2 causes the DCD signal to always be OFF except while a connection
is being established.
Default = C1.
&D0, &D1, &D2 or &D3 - Data Terminal Ready (DTR)
Options
Controls how the virtual modem reacts to the DTR signal provided by
the application software:
&D0 ignores the DTR signal.
&D1 causes the modem to return to command mode when the DTR signal
is changed from ON to OFF.
&D2 and &D3 causes the modem to close an active connection and
return to command mode when the DTR signal is changed from ON to OFF.
Default = D0.
&F or &F1 - Factory Defaults
Resets the virtual modem to use all the default settings. (Same as the
"Z" command).
&S0, &S1, &S2 - Data Set Ready (DSR) Options
Controls how the Data Set Ready signal is provided by the virtual modem:
&S0 forces the DSR signal to always be ON.
&S1 causes the virtual modem to turn the DSR Signal OFF when there
is no connection opened, turns it ON when attempting to open a connection,
and turns it OFF when the connection is closed.
&S2 causes the virtual modem to turn DSR signal OFF while there
is no connection opened, turns it ON when a connection is opened, then
OFF again once the connection is closed.
The default is &S0.
&V - View Profile
Displays the current settings used by the virtual modem.
&T - Terminal Type string
Allows specification of a quoted string that Virtual modem will report
to a remote as the terminal type for Telnet sessions. ie AT&T"ANSI".
This setting is reset to "ANSI" when ATZ is executed.
15.11. Virtual Modem S-Register List
The following Modem S-Registers are supported by the NetSerial Virtual Modems:
S0 - Auto-Answer
When this register is set to a non zero value, this is the number of
RING's that occur before this virtual modem will Auto-Answer an Inbound
Connection (This is ignored If Inbound Connections have been not been
enabled for this virtual Modem or its inbound TCP port was not defined).
When this register is zero, Auto-Answer mode is disabled.
When a virtual modem has been configured to accept inbound connections,
and an inbound connection is detected on the defined TCP port the following
occurs:
The virtual modem sends a RING message to the application software every
2 seconds, and waits for either auto-answer to occur or for the application
software manually answers by sending the ATA command to the COM port.
Once either of these occur, the virtual modem sends a CONNECT message
to the application software, accepts the inbound connection and switches
from command mode to online mode. If the connection does not occur by
the 9th RING, then the connection fails.
S1 - Ring Counter
This register is usually zero, but is incremented each time a RING message
is sent by the virtual modem, until the Inbound Connection is answered
or aborted.
S2 - Escape Character
This register contains the decimal value of the ASCII character used
in the escape sequence. The escape sequence consists of a period of
inactivity (defined in register S12) followed by three escape characters,
followed by an equal period of inactivity. If the modem is in online
mode this switches it to command mode. The default is 43 (ASCII character
"+" ).
S3 - Carriage Return Character
This register contains the decimal value of the ASCII character used
as a command line and result code terminator. The default is 13.
S4 - Line Feed Character
This register contains the decimal value of the ASCII character used
for a line feed. The default is 10.
S5 - Backspace Character
This register contains the decimal value of the ASCII character used
for a backspace. The default is 8.
S7 - Wait for Carrier after Dial
This register contains the number of seconds to wait for a connection
when dialing. The default is 20.
S12 - Escape Sequence Guard Time
This register contains the the decimal value of the period of inactivity
required when issuing an escape sequence, in 1/50th of a second increments.
The default is 50 (1 second).
S19 - Idle Timeout
When this register is set to a non-zero value, it sets the inactivity
timer to disconnect after this many minutes of inactivity. This is currently
ignored.
S32 - XON Character
This register contains the decimal value of the ASCII character used
for XON. The Default is 17.
S33 - XOFF Character
This register contains the decimal value of the ASCII character used
for XOFF. The Default is 19.
S95 — Extended Result Codes
When this register is set to a non-zero value, it is used to override
some of the Wn command options. A bit Set to 1 will enabled the corresponding
result codes:
Bit 0 - Connect message indicates
DCE speed
Bit 1 - Append /ARQ to CONNECT XXXX
Bit 2 - Enable CARRIER XXXX message
Bit 3 - Enable PROTOCOL message
Bit 4 - Reserved
Bit 5 - Enable COMPRESSION XXXX
Bit 6 - Reserved
Bit 7 - Reserved
The default is 0.
S100— S100 RING Message Interval
This register specifies (in 1/10th second units) the interval between RING
messages sent to the application when a connection is received. After 7 RING
messages, NetSerial will close the incoming connection. The default value is
30, causing a delay of 3 seconds.
S101— Answer CONNECT delay
This register contains the decimal value of the number of milliseconds
that NetSerial should wait after an inbound virtual modem answer command
(ATA) is received, before the CONNECT message is sent to the application.
It's also used in autoanswer mode. Lowering this value will allow some
BBS software to connect sooner. The default is 1000, causing a delay
of 1 second.
15.12. Virtual Modem Result Codes
The following Modem Result codes are supported
by NetSerial's Virtual Modems:
NO CARRIER
This result is is returned when a dialing timeout occurs or when an
established connection terminates. The timeout interval is specified
in register S7.
NO DIALTONE
This result is returned when the virtual modem could not obtain address
information from the name server (or HOSTS file), or that the given
Internet address is invalid. This result code is also returned if TCP/IP
is not responding.
BUSY
This result is returned when a connection to the virtual modem port
was established at the remote site. However, no available communications
ports (COM1, COM2 etc) were available to assign the connection to.
CONNECT 57600/ARQ
.This result means the dialing and session establishment occurred without
problems and is ready for user
data flow using the Virtual Modem Protocol. The given bit rate of 57600
is given only to satisfy the application program.
16. Request Technical Support
You can request technical support by filling out a request form at http://pcmicro.com/netserial/support.html
Usual response time is well under 2 hours during normal business hours,
Pacific Standard Time, and may be longer during evenings and weekends.
If you purchased or are evaluating NetSerial through another reseller
or a consultant, they may provide an additional level of technical support.
17. Update the License Key
NetSerial allows a fully functional 30 day evaluation if no license
key is entered into the NetSerial. If you decide to purchase a license
key, you are provided with an electronic license certificate (PDF file)
which contains a license key that can be entered into the NetSerial
to unlock the 30 day limitation. Each PC which NetSerial is installed
on requires a seperate license key.
To update your NetSerial License Key, do the following:
- Open the NetSerial Monitor window by double clicking on the system
tray icon.
- Select the License button. The current license information
is displayed, including how many days are left if the software is
running in evaluation mode.
- Select the Change button.
- Type in your License Key in the field titled License Key.
- The User Name and Company Name. These fields must
be entered, but any name can be used.
- Select OK to accept the new information.
18. Uninstalling the NetSerial Software
To Uninstall the NetSerial software do the following:
If using Windows XP, 2003, or 2000:
- Navigate to the Windows Control Panel and select the "Add
or Remove Programs" Icon.
- Select NetSerial in the list of installed programs.
- Click the Change/Remove button to begin the Uninstall process.
- Select Uninstall, and click Next
If using Windows 10, 8, 7, Vista, or Windows Server 2008 or later):
- Navigate to the Windows Control Panel and select the "Programs
and features" Icon.
- Select NetSerial in the list of installed programs.
- Select Uninstall, and click Next
Windows does not need to be restarted after installing or uninstalling the NetSerial software.
Copyright © 1997-2020 PC Micro Systems. Portions Copyright © 1997-2020 Microsoft Corporation. Portions Copyright © 1998-2020 The OpenSSL Project. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org). All Rights Reserved. NetSerial and NetModem are TradeMarks or Registered Trademarks of PC Micro Systems, Inc.. Windows and Microsoft are Trademarks or Registered Trademarks of Microsoft Corporation. Citrix and XenApp are Trademarks or Registered Trademarks of Citrix Systems, Inc. RC2 and RC4 are Trademarks of RSA Security, Inc. VMWare is a Trademark or Registered Trademark of VMware, Inc. PC Micro is a Trademark or Registered Trademark of PC Micro Systems, Inc.