Date: Sat, 20 May 95 14:17:57 MDT From: terry@cs.weber.edu (Terry Lambert) To: msmith@beta.tricity.wsu.edu (Mark Smith) Cc: freebsd-questions@freefall.cdrom.com Subject: Re: setup modem for dialin Message-ID: <9505202017.AA06468@cs.weber.edu> In-Reply-To: <9505200747.AA22544@beta.tricity.wsu.edu> from "Mark Smith" at May 20, 95 00:47:06 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm trying to set up my modem to answer and allow dialins automatically.
> I'm running FreeBSD 2.0. Does anybody have step by step instructions?
> I have Terry Lambert's state machine description of what goes on, but no
> directions on how to actually set it up and what settings need to be in
> what files.
Yet more diatribe on modems... unfortunately not everything is really
"Hayes compatible" like they claim, and factory default setting are
usually not the settings you want. Also unfortunately, the settings
you want are pretty zero-tolerance for driver/cable errors.
1) Use a straight cable
The exception to this rule is if you know that the system does
not correctly recover DCD loss in all states of CTS/RTS (Sun
machines without the advanced serial driver option ($1500)
that is actualy derived from the old Berknet serial driver
will lock up, for instance, requiring a reset).
If you know your system has this problem, pins 4+5 should be
tied together (RTS/CTS: assumes 25 pin RS232C connector) in
the cable hood on each end, with no wire going through.
2) Avoid ground loops.
Any cable with two or more wires is a dipole based LC tank
circuit. Since the RS232/434 standards use +/- 11 volt
differentials about a digital ground (which may, in fact,
not be 0 volts at all), this avoid most problems.
The one remaining potential problem is if you connect pin 1
(Chassis ground: assumes 25 pin RS232C connector) on both
ends, you have a potential to greate what is called a "ground
loop", which will introduce current and therefore error in
your connection (depending on how close to the comparator
zero crossing boundry the signals from the line drivers
normally are).
To avoid this, pin 1 (all unused wires in the cable, actually)
should be connected on the side with the best frame ground --
this is most frequently the computer. Doing this can reduce
noise significantly and will avoid the ground loop problem
(in effect, you are providing a farady cage for the cable).
3) Set the modem correctly
A) DCD follows remote carrier
B) On-to-off transition of DTR causes modem to go on hook
and reset as if powered off-then-on.
C) Modem recognizes commands
D) Modem does *not* have in-band flow control turned on
between the computer and the modem (in-band flow control
is XON/XOF start/stop signalling).
E) Modem does *not* have in-band flow control turned on
between the modem and the remote mode.
F) Command echo is off by default (a dialer can change
this if necessary, but it should be temporary until
the next reset by power cycle or on-to-off DTR).
G) Result codes are on by default ("RING" "CONNECT" "OK",
etc. are to be returned).
H) Result codes are verbose by default (non-verbose result
codes are typically unexpected by most dialer software).
I) If it is settable, DCD should be raised *after* the
connect message instead of before. The default for
most Bell compliant modems is *after* (103/212 standards).
J) Autoanswer should be enabled. The number of rings is
irrelevent.
Potential problems:
A) Internal modems prequently do not have a 150 Ohm pull
down resistor on the DCD level. This can cause problems
in the disconnected state. For this reason, I always
recommend external modems, where possible.
B) Internal modems with discrete UARTs typically have the
same problem with CTS/RTS.
C) US Robotics Sportster 14.4 Fax modems are known to lock
up when communicating at high data rates with modems
that use the Rockwell 14.4/28.8 chipset. A firmware
fix is available from US Robitcs if you have a problem
with this. Newer US Robotics modems should not have
this problem.
D) Modems that use MNP, especially older modems manufactured
by someone other than Microcomm, can not have MNP enabled
and in-band flow control disabled (it will show as disabled
but is implied by the use of MNP). This is because the
manufacturers wanted to undercut Microcomm's prices, so
they reduced the amount of RAM in the modem for buffering.
If you have one of these modems, disable MNP or expect
to be unable to send binary data without protocol quoting
(ie: like Kermit).
E) It is imperitive that you get the DTR signals set up
correctly in the modem settings. Modems from several
manufacturers (Avatek, for example) will not retrain the
baud rate unless reset. The first caller will "stick"
the baud for subsequent calls until the modem is reset.
F) On a related note, if you are going to buy a serial board
or terminal server, make sure it supports the modem control
lines if you plan to use it for modems.
G) A lightening arrestor is cheaper than a computer.
H) If you have a Telebit modem, look up S53 in your manual
before starting.
I) If you use mgetty/vgetty, you will want to disable the
autoanswer, since they react to the "RING" by sending
an ATA command (Hayes modems).
J) Locking your baud rate(between the modem and the computer)
can be good. You won't need to go through the getty break
switch sequence to get a login.
K) Locking your baud rate can be bad. If you do lock your
baud, be prepared for a delay in all control signals,
like ^S, ^Z, ^Z, ^T, etc.. This is because you will have
to wait for the modem buffers to flush, since they will
fill in the process of baud rate matching. It can also
be bad if you forget to disable the break switch rotor
list for the baud rate in /etc/gettytab. It can really
be bad if there are flow control problems in the driver.
Most people like the locking feature. I personally hate
hardware that lies to me.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505202017.AA06468>