HOW TO SETUP A MODEM FOR IP USE tomj@wps.com (Tom Jennings) 23 Feb 94 T of C @0: INSTANT SOLUTIONS FOR SOME MODEMS @1: ASSUMPTIONS @2: THE GOAL HERE @3: YOU KNOW ABOUT "AT" COMMANDS, RIGHT? @4: BEFORE YOU START @5: BASIC SETTINGS @6: CONTROL/STATUS SIGNALS @7: FIXED DTE RATE @8: BASIC MODEM BEHAVIOR @9: LAST AND MOST DECIDEDLY NOT LEAST -- SAVE! @A: ADDITIONAL SETTINGS FOR SPECIFIC APPLICATIONS @B: URBAN LORE DEP'T @C: AUTOMATIC MODEM LINK MAINTENANCE @0: INSTANT SOLUTIONS for the following modems. Otherwise read on. Sets modem to no result codes, no command echo, auto answer on first ring, reset on DTR. To skip-auto-answer, leave out S0=1. ZyXEL: AT&F&D3&W Intel: AT&F2&D3&W This is a how-to of modem setup, for TCP/IP use on unix systems and related hardware and software. It is not a modem tutorial. It is restricted to "AT"-command type modems. The assumption is you want to get the damned thing working and online, not discover the wonderful world of modeming. This advice is based upon my 10 years of BBSing in the DOS world, and excessively broad experience with AT-type modems. @1: ASSUMPTIONS With few enough exceptions that I can safely ignore them, the TCP/IP world does not directly support modems. All that is tolerated is a clean RS-232 interface, with varying degrees of functionality -- from a full interface with all control and status signals, to a simple "three wire" interface of send, receive and signal ground. I assume you know that using PEP protocol for IP is not a good thing. I assume you have KERMIT or a DOS or Mac with a terminal program to command the modem, and if all else fails, you may be able to use TIP. @2: THE GOAL HERE To manually initialize a pair of modems for IP use, for the most common setup: one modem dials and initiates the connection, the other modem answers and accepts the connection. The interface is fixed at some data rate higher than the modem's advertised throughput; likely (for Dec93) this is 19,200 or 38,400 baud. I strongly suggest that you manually initialize your modem(s) by hand, once, store the settings within the modem, usign the DIP switches and/or NVRAM. "Online" initialization can then be done if necessary (or even possible) by issuing a reasonably universal "ATZ" command, or toggling the DTR signal, in cases where you have explicit control over it (rare). THERE'S ALWAYS EXCEPTIONS -- Some systems that have explicit modem support -- like Livingston Portmasters and the like -- will use and recognize status and control lines like DTR and CD. Generic (if you can use that word here) TCP/IP networking software like SLIP/PPP drivers under unix, know zip-zero about them. It is still quite possible to have robust, automatic modem-based links under these conditions. Since these are somewhat generic instructions, you'll have to fine tune them to suit. If your system needs/hates CD, you'll have to figure that out and adjust accordingly. @3: YOU KNOW ABOUT "AT" COMMANDS, RIGHT? I hope so, like I said, this is not a modem tutorial. @4: BEFORE YOU START You'll probably insist you did not, but I bet you did -- set crazt settings into your new modem. I insist you reset the modem to factory default. This is usually the AT&F command. Please do this first. Then apply settings as necessary. @5: BASIC SETTINGS There are four big chunks of functionality you have to set: * Control/status signals * Fixed DTE rate * Basic modem behavior * Save these settings! CRITICAL! ENTER ALL THESE COMMANDS AT THE EXACT SPEED YOU WILL USE LATER! Until recently, modems used the "last sent AT command speed" as the rate used for fixed-DTE rate. This was automagically remembered when settings were saved. Some (ZyXEL, Telebit) have commands to explicitly set the DTE rate. Unless you feel like researching all this, do it this way! @6: CONTROL/STATUS SIGNALS These are: DTR (Data Terminal Ready), CD (Carrier Detect), and hardware handshake signals, RTS/CTS. Some modems have fancier settings than simply on/off; check your modem manual to see if you want to play with those. DTR options are usually: ignore, break connection, break connection and reset modem. For BSD-like SLIP drivers, pick ignore; if you use one program to initiate the link (say KERMIT), then another to perform SLIP protocol over the modem link (say SLATTACH), when KERMIT terminates, it closes the tty device, DTR goes false, which will disconnect the modem. When SLATTACH runs, it will raise DTR, but by that time it's too late. SLATTACH doesn't know how to use DTR anyways, and it has no reason to. For a Livingston Portmaster type installation, set DTR=reset, since the Portmaster gives you explicit control over DTR. For other installations, you're on your own. ignore disconn reset ZyXEL 1496 series &D0 &D2 &D3 USR Courier series ---------- use DIP switches --------- USR Sportster ---------- use DIP switches --------- Intel CD is usually required, or ignored. So might as well set it to follows true connect state. Some few need it spoofed on always. always true follows connect ZyXEL 1496 series &C0 &C1 USR Courier series ---------- use DIP switches --------- USR Sportster ---------- use DIP switches --------- Intel Hardware handshake signals are always required. ZyXEL 1496 series &H3 USR Courier series &H2 USR Sportster &H2 Intel \Q3 (see text) @7: FIXED DTE RATE This is the single most commonly screwed up and hard to decipher function in the manual. We always want fixed-DTE rate. I always have to search high and low through the idiot manuals, looking for this week's confusing euphemism to avoid saying "DTE". (I agree, this stuff is horrible to describe to non-RS232 junkies.) ZyXEL 1496 series &B1 S20=n { see below for values of n! } USR Courier series &B1 { note! } USR Sportster &B1 { note! } Intel \J0 { note! } NOTE! These modems simply remember the last-used AT command speed for fixed DTE! ZyXEL: values for n (see manual) 1=57600, 2=38400, 3=19200, etc. @8: BASIC MODEM BEHAVIOR These last commands are trivial; every modem I've used since 1985 uses the same commands to set basic modem behavior. Pick from this list as necessary. These are given last because ATQ1 and ATE0, if needed, turn off character echo and the "OK" result codes (desired result!), so that you end up typing blindly; best to do them last. FOR ALL MODEMS: ATM0 (zero not Oh) Speaker off ATE0 (zero not Oh) don't echo commands ATQ1 Quiet! No result codes! ATS0=1 Auto answer on 1st ring US Robotics NOTE: The Sportster model especially, there is a confusing interaction between NVRAM-stored settings and DIP switch settings. This is a misfeature, really. What happens is, the DIP switches provide power-on defaults. Commands entered after power-on (duh) may override the DIP switch settings -- BUT THEY ARE NOT STORED IN THE NVRAM! Moral: if there is a DIP switch for a given function, use that. Ignore the command. @9: LAST AND MOST DECIDEDLY NOT LEAST -- SAVE! SAVE YOUR RESULTS! If you issued the E0 Q1 commands, you won't see an "OK" result, nor even the characters you're typing. This is a feature, not a bug. Because of this, I religiously and superstitiously issue the "save" command below a number of times. ZyXEL 1496 series &W &W0 &W1 { has many profiles! } USR Courier series &W { don't forget the switches! } USR Sportster &W { don't forget the switches! } Intel &W @A: ADDITIONAL SETTINGS FOR SPECIFIC APPLICATIONS For blind autoanswer use, the above settings, plus S0=1, is perfect. This works for smarter boxes like the Portmaster, too, as well we brick-dumb drivers like getty. For call-originate with dialing scripts, using KERMIT or TCL or EXPECT, you might try leaving result codes enabled (Q0), though usually echo off (E0) is a good idea. Some modems even have extended Q commands, like Q3 or something, that suppress result codes from things like incoming calls (generally what's desired) but still returns results on issued commands. Having command-echo ON is usually *disastrous* for doorknob-stupid drivers; if carrier is lost for any reason, the modem reverts to command mode, where it echoes every character typed to it -- every udp packet, every ICMP, every TCP... your machine will be eaten by an endless flood of dreck. Symptom: both modem Rx and Tx lights burn real bright. @B: URBAN LORE DEP'T Contrary to popular opinion, there is no danger to the "+++" disconnect sequence. There is no need to disable it. Even if, even if the modem should mistakenly go into command state via a spuriously-detected +++ sequence, tricky crackers cannot possibly enter commands from phone line side of the connection -- in command state, it accepts commands only from the serial-port side (remote modem commanding is another unrelated subject). Even for the case where, someone dials into your dialup line, manually types a "+++", the modem drops into command state -- and the link is stuck until reestablished. @C: AUTOMATIC MODEM LINK MAINTENANCE I have a simple system (aren't they all... it works for me...) that uses KERMIT and PING running under cron on BSD unix that periodically checks the modem link and reestablishes the connection if necessary. It tests the link by pinging the very other end, usually a router. It assumes that if it cannot get a response, the modem link has died. This is usually the case. If so, it kills of any running slattach program (said program having no clue if the modem link even exists, it refuses to let go), uses kermit to drive the modem, then reinvokes slattach. You can ftp the whole thing from tlg.org. No warrenty, implied or expressed.