There are some common setup problems people typically have with modems under UNIX®. They have to do with DTR, DCD, flow control, "speed conversion", modem set up, and login concerns specific to modem logins. We hope to minimize or solve those problems with the information below.
UNIX® Dial-in/Dial-out Primer
All UNIX® platforms support concurrent dial-in and dial-out on a common serial port, they just implement it differently from platform to platform. The point behind this is to conserve modems and phone lines when possible. Using this feature allows modems to be used for outbound connections such as FAX, cu, tip, uucp, etc. when nobody is currently logged in via that line.
Some platforms implement it by having two (or more) device nodes built for a common serial port, while others implement it in software with some intelligence built into the operating system regarding tty opens (lock files and such).
The idea is that you have some process, say a login, running on a serial port connected to a modem, but you don't want the login to prompt (and confuse) the modem, and you want to be able to dial out of the modem when there isn't somebody logged in via that port (waste not, want not).
Modems use the DCD signal to let a serial port know whether there's a connection or not, so this is the signal used to tell the login to go ahead and send out the login prompt. In the mean time, the open() to the port "blocks". This frees up the port for other programs to use, since nobody currently owns the port, because the open() hasn't completed yet.
Examples of dial-out programs would be cu, uucp, tip, kermit, etc..
A lot of people get confused about why they get garbage right after a connect with modem logins. Most likely, this is caused by the login running at a different speed than the "DTE" interface on the modem (the port connected to the workstation).
This can happen if you have accessed the modem at any time, say, to set it up, at a different baud rate than you plan on for the login. The modem will "auto-baud" to the speed last used in "command-mode" (any communications to the modem without an actual connection). Further, the modem, if configured correctly, will not change that rate at any time after that, and will actually lock that rate after the connection is made.
Example: User sets up the modem via kermit at 9600 baud, but then configures a login running at 38400. Whoops!
To fix it, all you have to do is run tip, cu, kermit, or whatever at the same speed the login will run at, and type "AT" to the modem. You will see an "OK" come back, which means the modem has now set its DTE port to the rate you're currently using, which matches your login set up, which will fix everything.
Example: User sets up the modem via kermit at 38400 baud, and then configures a login running at 38400. Done deal.
- First, DCD. This signal is used to tell UNIX when there's a valid modem connection at the phone line. Some modem vendors disable this feature by default, telling the modem to simply drive this signal all the time. This will prevent the modem from working properly under UNIX. In most cases, the solution is to send the AT&C1 command to the modem, but check your manual to be sure.
If this is not correct, a security problem ensues. You could lose your connection in the middle of a terminal session, or attempt to break it by hanging up your local end, but your user session at the other end will still be live, since you didn't specifically "log out". Anyone else can then dial up that modem, connect, and be YOU.
- Next, DTR. This signal is used by UNIX to tell the modem there's somebody waiting for a connection at the serial port it's connected to. It's also the signal UNIX uses to tell the modem to hang up the phone and drop any connection. Modems obviously also use this signal as a way to be told to hang up the phone and drop the connection, but also to decide whether or not to answer the phone when they are set to Auto-Answer (AA). Some modem manufacturers set this to "assumed driven all the time, and ignore state changes" by default.
The problem ignoring DTR is less significant than DCD, but nevertheless should be corrected. It simply means the only way the modem will drop the connection, is if the remote modem hangs up the phone. Normally, logging out should also force the connection to be broken, as the close() will drop DTR. This will not work if the modem is ignoring this signal. The way to correct this is typically to send the modem an AT&D2 command, but check your manual to be sure.
Others surely also exist, such as specific baud rate indications, FAX indications, synchronous link indications, and possibly some other modem model-specific feature indicators.
Flow Control
All today's modems support both hardware flow control based on RTS and CTS, as well as software flow control based on START and STOP characters (also called XON and XOFF respectively).
The key here, is to make sure your modem is configured to match your UNIX serial (tty) port.
If you want to use hardware flow control, make sure the modem is configured for RTS/CTS flow control in its configuration. It's also sometimes described as something like "Pass received data only on RTS high" and "Hardware (CTS) flow control". You will need to make sure both are set if they are not both set in the same modem command.
- Hayes and compatibles: &K3 (Hardware (RTS/CTS) flow control)
- Multitech: &E3 (Hardware (RTS/CTS) flow control) and &E13 (Enable Pacing... must be set for reliable operation). Also note that some Multitech modems may have a switch set to ignore RTS, which must be changed for hardware flow control to work.
- US Robotics: &H1 ("Hardware (CTS) flow control") and &R2 ("Pass recv data only on RTS high").
- Telebit: ATS58=2 (Hardware (RTS/CTS) flow control).
- ZyXEL: &H3 (Hardware (RTS/CTS) flow control).
If you want to use software flow control, you want to make sure the modem is set for "Software flow control (XON/XOFF)". This is how we've seen it described (or something very close) in all modem manuals we've seen. RTS can be used for other things, which is why it can sometimes be a separate setting as opposed to simply having one setting for software flow control and another for hardware flow control.
- Hayes and compatibles: &K4 (Software (XON/XOFF) flow control).
- Multitech: &E5 (Software (XON/XOFF) flow control) and &E13 (Enable Pacing... must be set for reliable operation).
- US Robotics: &H2 ("Software (XON/XOFF) flow control") and &R1 ("Ignore RTS").
- ZyXEL: &H4 (Software (XON/XOFF) flow control).
The commands that enable the different methods of flow control will vary greatly from manufacturer to manufacturer, so you'll have to consult your modem manual for the correct commands.
Speed Conversion
Today's modems are very smart. They have a feature that may have slightly varying names, but that always means the same thing... speed conversion. Some call it "speed locking", or "fixed DTE rate", or whatever. This feature greatly simplifies UNIX modem configuration.
What this does, is tell the modem to lock the serial port connected to the workstation to a certain bit rate regardless of the modem-to-modem connect rate. This means that all the administrator need do, is set up a functioning login at the highest possible rate (38400, 57600, or 115200 in most cases), and forget about it. The modem will simply communicate with the workstation at a that bit rate regardless of the modem-to-modem connect rate.
Some modems are configured by default to adjust the serial port bit rate based on the analog connect rate of a particular connection to another modem. This is getting much less common as a default, but should be checked anyway.
Here are some example modem specific settings:
- Hayes and compatibles: Doesn't seem to be an option.
- Multitech: $BA0 (Speed Conversion/DTE rate locking).
- US Robotics: &B1 (Speed Conversion/DTE rate locking).
- Telebit: ATS181=1 (Speed Conversion/DTE rate locking).
- ZyXEL: &B1 (Speed Conversion/DTE rate locking).
Without this feature, the administrator has to set up a table of login entries using "next labels" that point to other entries with different bit rate settings. Every time the serial port receives a BREAK character, it knows to try the next label. The user would then have to keep transmitting BREAK characters until they saw a legible login message. Setting something like this up is no longer necessary in most cases.
Quiet Answer
Another thing that can be VERY helpful when using modems for dialin access to UNIX is to set a thing called "quiet answer" or "silent answer". This is typically a Q command such as Q1 (never return result codes) or Q2 (only return result codes when dilaing out (originate mode)). If your modem supports Q2, this is better, as you can see codes when you're dialing out, which is about the only time you might need them. Some cu and PPP chat scripts depend on this output as well.
The reason this is good, is that it prevents your UNIX login from seeing any of these connect commands and treating them as login attempts. Also, since they're all in CAPS, some UNIX systems may incorrectly modify the login behavior based on that. Not fun. This doesn't happen on all systems and may even depend on specific login configuration, as the system is supposed to ignore all input prior to DCD going true, but eliminating this as an issue simplifies troubleshooting and improves reliability, which is always good.
Summary and Checklist
- Make sure the last time the modem was sent any command, it was at the same speed as the login you wish to configure or already have running.
- Make sure DTR and DCD options are set correctly (typically &C1 and &D2).
- Make sure you have a match between the flow control set at the modem and the login or whatever communications utility you wish to use.
- Make sure you have "speed conversion" or "dte rate locking" enabled. This is always helpful no matter what you're doing with the modem.
- Consider setting "quiet answer" mode if you're using the modem primarily for dialin connectivity (typically Q1 and/or Q2)
Last updated:
Aug 23, 2018