|
|
|
|
Help, I've FallenCopyright © 1999 Gary Kline, David Leonard, and Dirk Myers
Yet another one of our ventures into one of the dark realms of computers: getting your modem to begin to work; or
Q: My system recognizes my modem, so now what? What are all the steps to get it to dial out with tip and cu and ppp?A:
For FreeBSD, the modem devices are
/dev/tty0 <-/dev/cuaa0 /dev/tty1 <-/dev/cuaa1 /dev/tty2 <-/dev/cuaa2 ... For NetBSD and OpenBSD:
/dev/tty00 <-> /dev/cua00 /dev/tty01 <-> /dev/cua01 /dev/tty02 <-> /dev/cua02 ...
Having gotten your system to recognize that your modem is installed, say in /dev/tty1 or /dev/cuaa1 (or perhaps /dev/modem) the rest is fairly straightforward. All 3 flavors of BSD are fairly PNP-friendly and if you have an older modem plugged into a good serial port, changes are good that BSD knows it is there. A reminder warning: Trying to get a Windows-specific modem to work on your *BSD box simply will not work. Win-modems are a lose-lose proposition in the Berkeley Unix realm. So now what? Configuration. Let's assume that you are using a PC clone and that your internal modem is plugged into the second COM port, /dev/cuaa1 or /dev/cua01. As root, in /etc/remote, enter this line.
cuaa1:dv=/dev/cuaa1:br#28800:pa=none Your modem may well be faster than 28800 bps, and you should adjust that number later. If you are using a Hayes or Hayes clone modem and if you are using FreeBSD, you may need to rebuild tip by changing directories to /usr/src/usr.bin/tip/tip and editing the tip configuration file tipconf.h from
#define HAYES 0 to
#define HAYES 1 then cd .. to /usr/src/usr.bin/tip/ and doing a make clean followed by make and make install.
# make clean; make; make install There are relatively few modems defined in tipconf.h because this program is so old and rarely used. Still, the drivers for the USR Courier, the Multech, and the Hayes do cover the majority that are usable for BSD. Note that in OpenBSD -DHAYES is already in tip's makefile. Define the others and change the OpenBSD makefile if you have a Courier, Multech, or other kind of modem in the #definelist. For FreeBSD, if there is no cuaa1 device in /dev, cd to /dev, and as root, type
# ./MAKEDEV cuaa1 If you are running either NetBSD or OpenBSD and do not have a /dev/cua0N (where "N" is 1, 2, 3, ...), then
# cd dev; sh MAKEDEV tty00 Then you should be able to connect, thru the "direct" line in /etc/remote by typing:
# cu -l /dev/cuaa1 or
# cu -l /dev/cua01 and enter the generic Hayes AT command set. One of the best strategies is if you are running X as you do this configuration, in a separate xterm type the following AT commands:
ATE1 Q0 V1 X1 M1 L2 AT&W Some minimalist notes on the generic Hayes command-set follow. AT is the modem ATtention prefix E1 tells the modem to echo the results to the screen. Q0 enables result codes to the DTE (Default) QQQ X1 Disables monitoring of busy tones unless forced otherwise by country requirements; send only OK, CONNECT, RING, NO CARRIER, ERROR, NO ANSWER, and CONNECT 115200. Blind dialing enabled/disabled by country parameters. If busy tone detection is enforced and busy tone is detected, NO CARRIER will be reported instead of BUSY. M1 turns the speaker on during dialing, and until connection established, then off. V1 Enables long-form (verbose) result codes. L2 sets the speaker volume to ``medium'' AT&W (or &W, actually) writes these commands to the modem's non-volitile memory. If you enter these commands separately, the modem should answer with
OK after it completes each command. If you enter them all on one line you should see a single
OK Next see if the dial-out works--even if you have no phone line attached. Try:
# cu -l /dev/cuaa1 Connected ATDT5555555 and you should hear the modem dialing. Depending upon how cheap a modem you have and whether it is internal or external, you should hear either tinny clicks and beeps or tones like your telephone makes when you auto-dial a number. To stop your modem during an ATD command, just type some random letters. Space bar is usually sufficient. The modem will abort what it was doing (dialing or sending spacey tones), hang up and say 'OK'.
If you do have your phone line hooked into the modem
the ATDT
Then you can do something like ``tip -115200 5551234''. If you
prefer cu over tip, use a generic cu entry:
and type ``cu 5551234 -s 115200''.
The point-to-point protocol comes in two flavors, user-side, and in-kernel.
The user-side ppp is easier to use than the kernel level ppp. Which to use
is entirely up to you. You probably should check up on both types and
decide.
Brian Somers is responsible for the user-side ppp. The documentation
for this is very good. Check out Brian's Web site User PPP tutorial links.
The following is an outline of the in-kernel support for ppp.
While ppp(8) is completely implemented as a user program
and uses the tunnel (tun) device
to get packets into the kernel, pppd(8) is a program to
invoke the PPP code within the kernel.
In-kernel PPP is implemented as a tty line discipline. Normally, ttys are in
`tty' or `termios' discipline so that you can type things like control-C and
an interrupt signal gets sent to your process. Line disciplines are
the glue between the low level (com port) device driver code and the
read() and write() operating system routines.
The pppd program puts a tty into `ppp' line discipline, which means that
it stops responding to control-C etc, and begins to process PPP packets
using software within the kernel.
The main difference between using ppp and pppd is that the former
is subject to process scheduling. This may be what you want for a more
reliable, debuggable and controllable system. The latter is much more
lightweight since it incurs less CPU overhead, which may be important
for your circumstances. Although it doesn't support as rich an interface
as user-ppp does, in-kernel ppp is certainly smaller and extremely
well suited to simple dial-up circumstances.
Since in-kernel ppp is solely concerned with encapsulating network
traffic into PPP traffic, and not with dialing a modem or authentication,
pppd provides some hooks so that you can run external programs to do this.
The simplest modem-dialing program is chat(8).
The chat program takes a sequence of expect/send pairs of strings.
For example, a simple login script might be:
Here, the chat program waits for '' (ie it doesn't wait) then it sends AT.
Next, it waits for OK then it sends ATDT1234567. Next, it waits for login:
and sends 'myname', and so on.
Chat has a mechanism for timing-out and re-sending, as well as a way
of aborting if it sees a string like 'NO CARRIER'. This is well documented
in the chat(8) manual page.
Briefly, to use chat and pppd, you issue a command like this:
It's convenient to store all these settings in /etc/ppp/peers/<name>
where <name> is the name of my ISP. For example, to dial the university (UQ),
simply type
with a file called /etc/ppp/peers/uq containing lines like:
On some systems, pppd is configured via /etc/ppp/options to automatically
try and use PPP-level authentication. This can be defeated by adding
to the command line. pppd usually needs superuser priviliges to run,
but this need not be the case if configuration files in /etc/ppp are
set up properly. This allows you to let unprivileged users start ppp
when they want. Finally, pppd supports a 'demand' option which is much
like ppp's -auto option in that it only connects when there is traffic
on the interface.
When using chat, you can see exactly what is going on by
giving it a -V option. Note though, that if chat gets stuck
at a prompt (like "annex") you won't see it, since the
debugging messages on what chat receives are only printed when
it gets a newline character!
The following will give you a bit of in-depth background about baud parity,
character width, and stop bit.
You may see references to settings such as 38400 baud, 8N1 or 9600 7E1.
These refer to the encoding of characters into digital pulses being sent
out over the serial data interface (ie the wire between your computer and
your modem).
8N1 means 8 bits per character, no parity (N) and one stop bit.
This is pretty much today's standard.
Parity is the inclusion of an extra bit to make the total number of 1 bits
an even or odd number.
7E1 means 7 bits per character, plus one parity bit
to make the total number of 1 bits even, followed by a final bit to mark
the end of the character.
BSD Unix systems traditionally configured their ttys to be 9600 7E1, which
means that an 9600 8N1 system would see 'loçií:' instead of
'login:'. This tradition is still with us today, although the login
system (getty) also tries to be smart about figuring out the correct
parity when you enter your username.
(Some unlucky
users have usernames with characters that all have even parity already,
and this confuses getty, and the poor user, no end.)
Baud rate means the maximum number of signal state changes per second.
With 8N1 encoding, this means that for each character sent over
the wire, there is a start bit, then 8 bits are used to encode the character
and finally there is stop bit used to end the frame; ie 10 bits in total.
So, on a 38400 baud line, 8N1 will
give you a theoretical maximum of 38400/10 = 3.84 kB/sec.
(kilo means 1000 in communications, not 1024!)
This is a theoretical maximum, because there can be a short delay
between the end of the stop bits and the start of the next start bit.
This one is going to seem fairly common sense, but this is where the old
saw that common sense is altogether uncommon fits!
Hardware problems with modems are fairly rare, but certainly not unknown.
If your modem is some cheap no-name generic brand, it may need
some generally unknown sequence to work. The manufacturer
will surely have the modem working with a floppy disk auto-
configuration program for the DOS market, but not for Unix.
With modems especially an investment in reliable hardware makes sense.
Gary D. Kline, kline@thought.org
|
||