*BSD News Article 6201


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!uwm.edu!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ames!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Sep  5 15: 13:11  /386bsd: com1: silo overflow
Message-ID: <1992Oct8.021548.17587@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <1992Oct7.140840.1@vaxb.acs.unt.edu>
Date: Thu, 8 Oct 92 02:15:48 GMT
Lines: 83

In article <1992Oct7.140840.1@vaxb.acs.unt.edu> larry@vaxb.acs.unt.edu writes:
>I'm am having trouble getting a dialup line to work on com2.
>
>I altered the entry for com2 in /etc/ttys, but when the modem answers getty
>sends the login prompt, and that causes the modem to hangup.

That's easy.  Either you are forcing DCD high on the modem or ignoring the
fact that DCD isn't present on the device, or have jimmied your cable.  Also,
cheap internal modems will act this way too, because DCD on the UART isn't
"pulled down" bu a 150 ohm resistor like it's supposed to be, and sometimes
"floats high" -- making the computer believe DCD is present when it's
simply not asserted, but isn't being deassreted bu pull down.

In particular, this will cause a "ring" or "connect XXXX" message that is
send by the modem *BEFORE* it raises DCD to be seen by the computer, which
will interpret as data to either a "login:" or "password:" prompt and send
back "password:" or "Bad login\nlogin:".

If the modem gets data on it's serial port *after* connecting but *before*
raising DCD to the computer, it says to itself:

"Hmmmm.... let's see:

	1)	I have data coming in the serial port...
	2)	I have DCD on the line...
	3)	I haven't asserted DCD to the serial port...

 I know!  I'm dialing out and they want to cancel the call!  ...I'll just
 hang the phone up!"

This is a well known problem in the state transition tables in most Hayes
and compatable modems.


A similar problem will occur with "command echo" turned on on the modem,
especially, but also ocassionally with "result codes" turned on too.  The
"command echo" should never be turned on for a dial-in/dial-out modem on
a UNIX-like box, and the "result codes" should only be turned on if you
will use the modem for dial-out and have the DCD set correctly.  The problem
that shows up is the "login:" to the modem getting an error, that error
being interprted as a login attempt, the "password:" prompt coming up,
that getting an error from the modem, the "login attempt" failing, and
another "login:" coming up.... etc. etc..

This will cause SCO to shut the port down and 386BSD to get SIO errors.

Make sure your tty the modem is on is "-CLOCAL" and "HUPCL" and that you
are using a cable with 2,3,7,8, and 20 connected (4+5 should only be used
if you have rewritten the com driver to handle CTS/RTS and turned it on;
otherwise you will probably hang the port.  Best to tie 4+5 together on
the modem side of the cable and on the computer side of the cable with
no connections in between the computer and the modem for these pins).  The
modem should have DCD following Remote carrier and and on-to-off transition
of DTR causing the modem to reset (otherwise, on a multispeed modem, the
first dialing will set the speed and the speed will never be reset for
other callers at potentially different baud rates); the modem should also
have command echo off and result codes on and verbose on.

This should fix 90% of the problems you could have with your modem.  Others
include using a "9600 baud modem" that won't work without flow control
because the manufacturer skimped on the buffer area in the modem (Microcomm
modems are one of the few MNP modems with enough buffer space, which makes
sense, considering they own MNP), or a modem where you can't turn off
flow control if MNP or compression is turned on, or a modem that you can turn
the flow control off, but haven't because you think you need it (or you
really need it because the modem buffers are still too small)... Hint: the
packet sequence numbers on an Xmodem transfer for packets 17 and 19 are ^Q
and ^S respectively.

Anyway, happy modem'ing!


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------