Tactical Software Tech Note
Troubleshooting Redirectors as "Software Cables"
When troubleshooting an application using a modem or other device, there are only three things to consider: the modem or device itself, the COM port and cable, and the PC application software. When a redirector and a modem/serial server enter the picture, the number of potential error sources increases. This technical note suggests a logical approach to the diagnosing problems in this environment.
The Software Modem Cable Concept
A redirector has one simple function: to pass data between a remote TCP/IP connection and a virtual COM port on a client PC. The analogy of a "software modem cable" is appropriate, as the redirector's primary mission is to pass data and (optionally) control signals between the PC and the modem.
This important point it is worth repeating: all the redirector does is pass data between the PC and the modem.
When you suspect problems lie with redirector configuration, first consider if the types of problems that are occurring would happen if a faulty modem cable were suspected on a local modem.
Software Modem Cable Limitations
When a redirector is used with a server that does not support COM Port Control, this software modem cable is similar to a hardware modem cable that has only three wires: TD, RD and ground. In other words, there is no provision for control/status lines such as CD, DTR and DSR to pass data between the PC and the modem. So, for example, the client PC raising or dropping DTR has no effect on the actual DTR pin on the modem.
In addition, when used without COM Port Control, the redirector is forced to live with one other limitation: baud-rate and framing information cannot be controlled over the TCP/IP connection. For example, if the client PC opens the port at 38400 8-N-1, but the modem pool's hardware port is configured to be 9600 7-E-1, then the physical modem will not communicate using 38400 8-N-1.
None of these limitations exist when the redirector is used with a modem-sharing server that does support COM Port Control. But if COM Port Control is not present in a misbehaving equipment configuration, it is important to understand these limitations and to investigate their impact on the client applications being used.
How the Redirector Fits In
The redirector sits "underneath" the COM port API in Windows. It takes data that is directed to a COM port using this API and sends it over the network. Data from the network is passed back through this API as though it came from a hardware COM port.
Unimodem is the part of the Windows operating system that maintains the list of modem devices which have been installed in the system. It sits "above" the COM port API in Windows. Using these modem devices it initializes and dials modems by sending data to the COM port API and watching for appropriate responses from this COM port API. When an application uses Unimodem to open a modem device on a local COM port (COM2 for example), it sends/receives data from hardware. When an application opens a modem device on a redirected COM port, it still sends/received data from hardware, but it is up to the redirector to move the data to the actual hardware elsewhere on the network.
This raises another important point: it is Unimodem that actually interacts with the modem when it is time to initialize and dial. The redirector is simply a conduit for Unimodem, just like a physical modem cable. If dialing fails, it is often because Unimodem is receiving unexpected responses from the modem.
The Configuration Wizard as a Litmus Test
The Configuration Wizard in Tactical Software redirector products is a very helpful tool to ensure that the redirector is configured for a clear data path to the modem. If the Configuration Wizard runs successfully, the chances are high that the redirector itself is configured properly. To continue the analogy, if this test proves the "modem cable" is plugged in properly, then problems from then on are likely to lay elsewhere.