Greetings sun managers:
First and foremost many many sincere thanks to the sun managers who helped
me through this difficult and confusing ordeal of adding modems for both
dial-in and dial-out.
Very briefly, I was having a great deal of trouble getting my modem to allow
dial-ins. When I would edit the /etc/ttytab and HUP the init (kill -HUP 1)
my CPU would go nuts. After I got past that problem (thanks to many helpful
suggestions) I had a second problem of not seeing a login prompt from getty,
only the CONNECT result messagae. My host is a Sun 4/280 server running
SunOS 4.1.3.
The replies I received were many and varied. I like to summarize my journey
to salvation in the form of a 'Gotcha List - mistakes I made'. Its a long
list. I put *'s next to the ones that were critical to me. Gotcha's 2, 11,
and 14 were show-stoppers for me. I hope others will find this list
interesting and helpful.
DAN'S GOTCHA LIST FOR ADDING A MODEM FOR DIAL-OUT
-------------------------------------------------
GOTCHA#1: Although I had taken care of this before posting my question
others may not be aware of the jumbo patch 100513-4. Before you even
attempt to add modems, install this patch! It fixes numerous tty related
bugs. I believe I got my patch from the site mentioned in the FAQ:
ftp.uu.net, in the directory /systems/sun/sun-dist.
*GOTCHA#2: Data Carrier Detect (DCD) Control. The default is of modems is
generally to leave DCD on. This is what causes getty to start talking to
the modem, then the modem talks to getty, and back and forth into an
infinate loop. This is why my CPU went nuts! I can't speak for all modems
but on my Telebit Worldblazer this is &C, which by default is set to &C0.
It needs to be &C1 which causes DCD to turn on after receiving the CONNECT
result code. Some other modems, such as the Telebit 2500, use register S131
for this. They call it Data Carrier Detected Interpretation. (ats131=1)
One user told me to turn echo off (ate0) to fix this problem. When I set
ate0 my cpu did go back to normal (because the modem shut up!) but this
only cures the symptom not the disease.
GOTCHA#3: Save modem changes to non-volital memory. Usually this is at&w0
or at&w1, check your manual. I was dumb enough to overlook modem flags and
registers because I knew I had already set them, but I hadn't saved them.
The first time the modem was power cycled everything was broken again. This
may be obvious but it got me.
GOTCHA#4: Because I want people to be connecting with MNP (can't use PEP
because not all field modems are Telebit) error correction and compression.
There were specific flags and registers that were critical. I want my users
running at 9600 baud (modem to modem) (because that's the maximum speed for
PC-NFS's SLIP) but with a throughput of 19200 baud. This means you have to
set the DTE speeds at 19200. Here are the related settings on the Worldblazer.
S180=3 (MNP Error Control), S190=1 (Compression enabled), S191=6 (Disable
Telebit LZ Compression), S050=6 (Modulation Speed - modem to modem at 9600),
S051=5 (DTE - Serial Speed modem to terminal at 19200). There are auto speed
detection values which may be preferable but I chose to hard code the speeds
I wanted. Assuming the Worldblazer is on the server and non Telebit modems
are out in the field, there will be analogous setting which must be set on
those modems to get MNP working. Expect those flags and registers to vary
greatly from modem model to modem model. Note: V.42bis LAP-M is an alternative
to MNP for many, but not for me. Too many various, older 9600 baud modems in
the field.
GOTCHA#5: Make sure you are using a full 25-pin modem cable. You may want
to test continuity to be sure it's not a null-modem and that all pins are
working. One person told me that a cable without all 25 pins may allow
dial-out capability but cause trouble with dial-in capability.
GOTCHA#6: Several suggestion to use flexfax, from sgi.com:/sgi/fax. It
comes highly recommended to ease configuration of fax-in, fax-out, dial-in,
and dial-out (and I hear you don't have to make cu devices!) I didn't try
flexfax but I suspect I should have in the beginning! :-)
GOTCHA#7: I had suggested, INCORRECTLY, in my original query, that getty
shouldn't start up until a carrier is detected at the modem. In fact, getty
should be running, quietly, at all times (at boot time or after kill -HUP 1).
Getty should sit out there and monitor the line for the DCD and only then
prompt for login. You may want to ps -ax |grep getty to make sure it is
running but not using cpu. If the DCD is left on (at&c0) the modem and
getty fall into what one manager referred to as 'a login-error spiral!'.
GOTCHA#8: An obvious one... register S0 has to be greater than 0 in order
to answer at all. Setting it to 1 causes it to answer on the 1st ring.
The default is 0.
GOTCHA#9: One user suggested I call Telebit and get the ROM upgrade for my
modem. He says v7.05 may be the most recent (obviously subject to rapid
change!) and that fixes are frequently made. I did not do this.
GOTCHA#10: Permissions on the dial-in and dial-out devices can make a
difference. I had intended to, but forgot, to include my file attributes
for my cu device in my original query. Here are the correct attributes:
crw-rw-rw- 1 root wheel 12, 129 May 18 15:01 /dev/cua1
crw--w--w- 1 root wheel 12, 1 May 20 11:04 /dev/ttyd1
The group isn't too important. Some people suggest the cu device should be
owned by uucp because tip is owned by uucp. Good point but not necessary.
Also note the major and minor device numbers; the cu major device number
matches the tty device number and the cu minor device number is 128 greater
than the tty device number. I'll assume all readers know or can look up
how to mknod, chown, and chmod.
*GOTCHA#11: Get the /etc/ttytab entries correct. The tty should be 'on' and
'remote'. The cu should be 'off'. The tty type should be 'dialup and the cu
type should be 'unknown'. The getty speed represents the serial DTE speed,
not the modulation (modem-to-modem) speed. See GOTCHA#4.
ttyd1 "/usr/etc/getty cfcg.19200" dialup on remote
cua1 "/usr/etc/getty std.19200" unknown off remote secure
You may notice my tty speed 'cfcg.19200' is not standard. It's specially
defined for our site. It is defined in /etc/gettytab. Here's the entry:
#
G|cfcg.19200:\
:p8:lm=\r\n%h login\72 :sp#19200:
#
The p8 code made a very big difference! It is what tells getty to use
no parity, 8 data bits, 1 stop bit. I don't know what the default without
p8 was but it didn't work! The symptom is a partially or completely garbled
LOGIN: and PASSWORD: prompt at the terminal from getty.
The 'lm=\r\n%h login\72' tells getty to prompt for login using the machine
host name in the prompt. The sp#19200 obviously sets the speed.
GOTCHA#12: Make sure the Sun port (not to be confused with the modem) has
Carrier Detect off. User ttysoftcar -n /dev/<device> to set is or
ttysoftcar /dev/<device> to display the status. This is the purpose of
the 'remote' flag on the tty entry in /etc/ttytab. It says 'At boot time
or at kill -HUP 1 make sure that this device has Carrier Detect off'. The
ttysoftcar is a way to manually set it or display it. On some machines
this is set a eeprom level. Several people suggested I use the eeprom
command to set the following configuration:
ttya-ignore-cd-=false
ttya-rts-dtr-off=true
These were not valid for my sun 4/280 but are for most desktops. See the
man pages on eeprom for full details. Seems like I saw this in a FAQ
recently and it was suggested that the Carrier Detect issue on the Sun port
should most correctly be addressed by using the 'remote' flag in /etc/ttytab.
GOTCHA#13: Set the modem Q flag to 2 (ATQ2) which means 'Modem reports
result codes when originating a call but does not return result codes when
answering a call. If this is set to Q0, the default, the result code can
be confused by getty as a login id or password!!!
*GOTCHA#14: Two very useful tools to figure out why you can't access your tty
or cu devices: (1.) /usr/kvm/fuser (2.) lsof
Both utilities can tell you if another process is holding your device and
if so the pid and owner. The utility fuser comes with SunOS and seems to
work pretty well. Type: fuser -u /dev/<device> and it will return the pid
and owner, if any, holding your device. I understand lsof is to list open
files and is more powerful than fuser. It is available by ftp from:
vic.cc.purdue.edu as /pub/lsof236tar.gz
That's about it. Those were the issues that came up for me. Some I found
in documentation along the way. Most I still have seen documented anywhere!
I do have another question I'd like to slip in if anyone knows the answer.
I'd like to be able to log in as root (as apposed to logging in as me and
then su'ing). I was under the assumption that putting a 'secure' flag on
the tty entry in the /etc/ttytab was the answer. Apparently not. Anyone???
Again, many, many thanks to contributers. Here they are:
ice@syrinx.umd.edu (Fredrik Nyman)
raoul@MIT.EDU (Nico Garcia)
szh@zcon.com (Syed Zaeem Hosain)
David Gilinsky <dave@gaspra.pd.com>
"A. Bryan Curnutt" <bryan@Stoner.COM>
Richard Crane crane@cadlab.ece.drexel.edu
weitzel@burke.com (David Weitzel)
bmecca@ralph.wea.com (Buddy Mecca)
Dan Jiracek <djiracek@fnbc.com>
anne@cs.sunysb.edu (Anne Kilarjian)
-drp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| _/ _/ _/_/_/_/ _/_/_/ _/_/_/_/ | Dan Penrod - Unix Administrator |
| _/ _/ _/ _/ _/ | USGS Center for Coastal Geology |
| _/ _/ _/_/_/_/ _/ _/_/ _/_/_/_/ | St. Petersburg, FL 33701 |
| _/ _/ _/ _/ _/ _/ | (813)893-3100 ext.3043 |
|_/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/_/ | penrod@whiplash.er.usgs.gov |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:01 CDT