Brought to you by; www.conserver.com

Why modems are 'a whole other can of worms'

http://www.conserver.com/console/Clues/modems.html
(updated: Nov 06, 2005, 10:32 pm)

Rule #1: Adding a modem to the mix adds significant complication. Things will get worse before they get better. (But, after some hacking, things can get better!) This document is meant to provide some ideas to guide your hacking, so you can get your modems playing nicely with your serial consoles and console servers.

Summary for the Advanced Modem Geek; You know modems are hard. You need to know that you should set the modem for a few critical settings, and you can scan this page for the CLUE summaries, then look for these settings in your modem's configuration guide or manual. If it still doesn't work, check the modem's firmware version, and make sure that you're reading the correct version of that modem configuration guide.

If you're not an A.M.G., or you don't already understand why modems are hard, and you want to know more, then read on, and save a copy of the manual for all of those modems used in your shop!

Table of Contents
Why Modems Are Hard
AT Command Set Clues
Modem Connection Speeds
Dial-in versus Dial-out
Speed issues
Author Credits

(Not covered yet, but planned for later: Security issues and Secure modems, Assorted config examples, including some Modemcap entries to look at as a starting point.)

Why Modems are Hard

to Table of Contents

Modems are hard, for a few main reasons;

• AT compliant is a very small set of the AT commands
• AT compatible is a smaller subset of AT commands
• Vendors can choose what features they want to support
• Vendors can decide what they want &D to mean
• Vendors resell other vendor's products as their own
• There are "Standard" and "Proprietary" modem algorithms

The AT Command Set

to Table of Contents

The AT Command Set came from modem maker Hayes. Back in the days of the original SmartModem 300 (circa 1982, per the manual I have), Hayes introduced a method to pass data in the data stream to get the "Attention" of the modem, so you could send it more commands while the modem was still on-line. The AT [command][variable] syntax was adopted by many modem makers (after paying a fee to Hayes).

The term AT compliant meant that your commands matched the set of commands that Hayes recognized. This meant the commands and the variables were the same. In theory, your modem configuration strings should work across all Hayes Compatible modems. In Theory...

The term AT compatible meant that the Attention method was implemented, but not all of the commands. (Or, if the commands were all there, the variables may not invoke the same reaction as in a Hayes modem.) If you bought these, you were going to need to work on new configuration strings.

In both of these cases, the vendors were not restricted from adding more modem commands, or adding extra settings for some of the existing commands. And, as you may have guessed, the vendors didn't have to coordinate these extra settings with each other, in order to provide a uniform interface for end-users.

Commands are different, between different vendors At first thought, you my think this would be obvious. But modems are being made this year, and there is still no standard for modem configuration.

There is a classic Good News/Bad News scenario in this. On the Good News side, many vendors have adopted some of the more common of the extended "ampersand" (&) commands, such as &D for controlling how the modem handles the DSR hardware handshaking lead. The Bad News here is that, while the vendors use the same command, the variables for the command are not always the same. That is, &D0 for one vendor is invoked as &D3 by another vendor.

Clue: So, if you had a USR Courier config string, it probably wouldn't help you with a Global Village modem. In order to make the Global Village modem work properly, you would need to get a USR manual, figure out what each command in the USR string was invoking, and then go to your Global Village manual, and find out which commands made the G.V. modem invoke the same functions, and jot down those settings. In some cases, the commands would be different (in one modem it is an [amper] command, and in the other modem it is an S-register setting).

Some vendors sell the products from another vendor as their own. These modes were designed by some other company, but then a major modem vendor bought them, and put their own label on them. Some cases in point;

• Telebit Corp's Q-Blazer
• U.S. Robotics' early Sportster modems

These OEM modems often use a different processor, and were certainly coded by programmers at the company who made the original modem product. As a result, these OEM products rarely match the command arguments of the Vendor (e.g. Telebit or USR), at least in their first iterations.

The result is, if you have developed configuration strings for Vendor X's modems, you may buy that vendor's latest mini-modem, only to find out that your config doesn't work as planned...so, you go through the manual, figure out where the changes need to be made, and cobble up a new configuration string for the mini-modem...but as you buy more, you find out that the newer mini-modems don't seem to work right either. (This is because Vendor X has been absorbing the mini-modem, and tried to change the settings to better match the settings in the rest of their product line...without making this change visible to the end-user.)

Another side to this are companies like the Black Box Corp., who resell equipment, cables, adapters and converters from many other vendors, but they put their own label on them. Usually the original equipment maker will also make these versions in a black case. In regards to modems, it means that you would probably need a different config string for each model of Black Box modem, since each model probably comes from a different manufacturer.

Modem Connection Speeds

to Table of Contents

Connection speeds, and protocol compatibility are determined by the communications protocols that govern the modem connections. There are the standards (V.32bis) and then there are proprietary methods that some vendors implement to make their modems talk to each other better (such as US Courier's V.Anywhere) line).

Common sense would tell you that you can only connect at the highest connection speed common to both modems, but that is only the best case that you can hope for. Usually your connections will be slower, for the following reasons:

• Proprietary protocols may be given preference, so that one modem will prefer a proprietary protocol over the "Standard" protocols. This may mean that the modem will try to negotiate the proprietary protocol(s) first, but the other modem may time out while waiting to hear a protocol that it recognizes.
• One modem may be requiring a higher protocol than the other modem can use, because of a register setting or a switch setting. This can cause the modem to hang up on a call because it cannot connect at the required speed.
• Line noise can cause errors during negotiation, which can cause the modems to negotiate at a lower speed than they might be able to use, if the line had no noise. (This can be a problem, even if the noise is brief, but it occurs during the negotiation phase between the modems.)
• Line delays on long-distance/transcontinental calls are caused by one direction of the call using a satellite connection path. While the path may have no noise, the timing delay may cause the modems to miss negotiating at a higher-speed protocol, due to the delay, and the modems will establish a lower-speed connection. (You could try to require the modems to use a higher speed, but if the modems cannot negotiate the high speed with the delay on the line, the modems will hang up and try again.)
• Line noise during a call can also lower your speed. On older modems, this is a one-way change, meaning that the modems detect the line errors, and renegotiate at a slower speed, hoping for better communication. But, once they slow down, they won't try to test higher speeds again later.

Dial-in, versus Dial-out

to Table of Contents

Modems often default to auto-baud, which is a way to automatically determine the communications speed of the attached computer. This is usually done by looking at the incoming AT commands. (If the modem receives garbage, it changes it's speed, and waits for garbage or an AT command.)

If a modem is being used for dial-out, you are sending an AT command to make the modem dial, so you are setting the port speed whenever you talk to the modem.

Many modems are capable of changing the serial port speed to match the speed of the modem connection. However, once you get faster than 9600, you can have problems like this, because some modem speeds do not have a corresponding serial speed. (Example; 14.4 is a valid modem connection speed, but not a valid serial port speed.)

(This is a legacy feature from the Old Days, because this is how the early BBS could could tell what the connection speed was...so, the BBS would auto-detect the modem's serial port speed during login. Why did the BBS care? So it could estimate how long a file transfer might take.)

The common problem with dial-in modems is that the modem is set to change it's port speed to match the incoming connection, and either the attached device cannot auto-detect the new speed, or the modem connection has changed the port speed to a modem-only speed, and the attached device cannot match it. At that point, the modem calling in cannot establish communications, they hang up, and they redial...at this point, the attached device should detect the call has ended, and it should then try to send the init string. Sending the AT commands should reset the modem, but the problem is likely to re-occur on the following call.

CLUE: Disable Serial Port Auto-Speed Detection

CLUE: Set/Lock both serial port speeds to the highest speed that is common between the modem and the attached device. (Set both the modem and the attached device to this same speed!)

CLUE: Disable Port Speed Matches Connection Speed

Serial Port Speed Issues

to Table of Contents

Do you need compression on your calls? If you expect to use any modem-to-modem compression protocols, you need to enable the protocols on both modems, and you need to make sure that your serial port speeds are at least 2x (and preferably 4x) faster than the expected modem connection speeds. This is because the compression and decompression of the data both take a bit of time to process, and the modems may not try to use the compression if they can't get the data fast enough.

CLUE: Set your serial port speeds to a workable high bitrate. (This includes the modem serial port, as well as the attached computer or console port.)

Is compression a Must Do or a Want To Do? There are usually three setting for the in-modem compression protocols...and each modem probably has these options;

• I Won't means that you can't make me.
• I Will If You Want To means I'll do it if you ask me.
• I Must means 'If you won't, I'll hang up!'.

As a default, most modems default to 'If You Want To', which will allow them to use compression, if one of them thinks to ask the other to do it. However, only some vendor's implementations will ask the other modem to try compression...but if neither modem asks, then they will not use compression.

If you have a central modem core that other modems dial into, then these modems should be set for "Must" compress, while all of the modems that will dial in should be set for "Will" compress. This way, the core will always as the modems calling in, giving you the best chance at using modem-to-modem compression.

One Potential Problem: If the core is set to "Must", and a remote user's modem cannot (or is set to "Won't"), then the core will hang up, and the remote modem will keep dialing in, only to have the core hang up again. If the core "Must", then all remote modems must be set for "Will" or for "Must".

Copyright 1996-2007, David K. Z. Harris, N6UOW  
Questions? Comments? Additions? Email consoles at conserver.com.
(Don't harvest my address, I don't want SPAM!)
How does he do it? And Why?