Tenon Intersystems : PPP : MachTen Modem Interfacing

MachTen and Modem Interfacing

The proper configuration of both MachTen and an attached modems is important in getting the most effective data transfer speeds for PPP data. Mis-configuration of MachTen or a modem, unfortunately, can result in what appears to be successful data transfer. However, mis-configuration can result in "slow" or only partial setup of a link.

See MachTen Modem Configuration for basic discussion of MachTen modem configuration.

For an understanding of the kind of transfer performance that should be available to a MachTen system, a few transfer measurements were performed with different modems under different conditions. See MachTen PPP Performance for more information.

Below are some of the known mis-configurations, how to recognize them and what to do to reconfigure your system to remove them.

"Slow" Effective Data Transfer

Mis-configuration of modem flow control in both the modem and MachTen can result in data loss and what looks like "slow" operation. The slow operation is due to the need to retransmit data that has been lost. If flow control is not set up properly, effective data transfer can sometimes only approach one-half of the bit signaling rate. For example, if a modem is configured to run a 28.8K bits-per-second and a PPP link has been successfully established. During heavy data transfer, the data is received at between 11K and 12K bits-per-second. It is probable that data is being lost and that the MachTen and modem configuration should be investigated.

When MachTen is to use a modem operating at more than 14.4K bits per second, MachTen should be configured to use the "/dev/ttyfa" or "/dev/ttycfa" for modems connected to the Macintosh modem port or MachTen should be configured to use the "/dev/ttyfb" or /dev/ttycfb" for modems connected to a Macintosh printer port. This will cause MachTen to use the RTS/CTS hardware flow control signals to "pace" data transfer between the attached modem and MachTen.

The attached modem should also be configured to use hardware (RTS/CTS) flow control. This setting varies with different modem manufacturers and the modem reference manual should be consulted to verify the proper setting. In standard Hayes modem command terms, the &K3 command should be included in the attached modems opreational setting. See Modem Configuration for more information about viewing an existing modem configuration and for resetting parts of that configuration from MachTen.

Link Reset

Mis-configuration can also result during what appears to be good data transfer at good effective data rates, but the link will be reset during heavy data flow.

This can be caused by the modem mistakenly interpreting a modem control as a request from a MachTen system to reset the connection.

The attached modem should be confitured to ignore DTR (Data Terminal Ready) with the use of the &D0 Hayes modem command. In many Macintosh-to-modem cables, the DTR signal is tied to the HSKo (pin 1) of the Macintosh. The HSKo signal is used by a Macintosh to flow control data from a Macintosh to a modem. If this signal is mistakenly interpreted as a request to "enter command mode" or to "hang up", a modem will work very well setting up a PPP connection and even initializing the first few commands necessary to make a PPP link operational. However, when data is to be transmitted, even in modest quantity, a Macintosh may change the state of the HSKo pin to indicate a Request to Send since a change in state of that signal may cause DTR to be interpreted as changing in state, a mis-configured modem may hang up or simply enter command state. Either situation interrupts an ongoing transfer and looks to an end user as if the link went down.

See Modem Configuration for more information about viewing an existing modem configuration and for resetting the &D0 configuration from MachTen.

Carrier (DCD) Reset

DCD mis-configuration can result in partial success in configuring a modem and in even dialing and establishing a remote conversation. However, when the "chat" portion of the link setup is complete no further data is received from the remote side. When debug information is printed with the /etc/pppclient debug flag, the link appears to connect, dial and configure the modem properly. It even converses with the remote server to login and establish PPP operations. However, when the first PPP specific command is sent, the LCP ConfReq command, no communication is returned from the remote end. The link behaves as if the remote end has gone deaf to local modem transmission.

In MachTen any change in the DCD Carrier signal is used to signal the termination of a session with a modem. In many Macintosh-to-modem cables the Macintosh input, the GPi input (pin 7), is left unconnected and does not reflect the true state of the modem DCD signal. MachTen misinterprets transitions on this unconnected signal and at random time can cause a connection to be reset.

There are two courses of action in this situation. First a Macintosh-to-modem cable can be obtained for about $15 that has the GPi to DCD signal connected and therefore modem DCD signalling will be properly transmitted to MachTen. See GPi Serial Cable for more information. Second, MachTen can be reconfigured to use "/dev/ttyfa" or "/dev/ttyfb" instead of "/dev/ttycfa" or "/dev/ttycfb". Using "/dev/ttyfa" or "/dev/ttyfb" will cause MachTen to ignore transitions of the GPi input and treat the status of the DCD as if it were always active. See Serial Device Files for more information.