Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!ub!csn!boulder!hartzell
From: hartzell@boulder.Colorado.EDU (George Hartzell)
Newsgroups: comp.sys.mips
Subject: Re: uugetty and /usr/spool/locks (another try)
Message-ID: <1991Jan16.230015.3287@csn.org>
Date: 16 Jan 91 23:00:15 GMT
References: <9101162234.AA07103@fernwood.mpk.ca.us>
Sender: news@csn.org
Organization: MCD Biology, U. of CO, Boulder, CO
Lines: 52
In-Reply-To: jns@fernwood.mpk.ca.US's message of 16 Jan 91 22:39:05 GMT
Nntp-Posting-Host: beagle.colorado.edu

In article <9101162234.AA07103@fernwood.mpk.ca.us> jns@fernwood.mpk.ca.US (Jerry Sweet) writes:

   I didn't mean to confuse y'all about the nature of my continuing
   problems with uugetty at this point.  I appreciate all the helpful
   suggestions.

   George Hartzell asked if there was a problem because of tip vs. cu.
   The answer is probably not, partly because tip and cu are linked
   together---they're the same program---and partly because some progress
   has been made, although it's not entirely satisfactory progress.

There is one tip (/bsd43/bin/tip) and two cu's (/usr/bin/cu and
/bsd43/bin/cu).  The two /bsd43/bin programs are indeed linked but
they are quite different from /usr/bin/cu.  user emptor.

   Here's how it went down:

   1. I attached a modem (a Telebit T1600) with the correct DCD behavior to
	   the line (&C1, for those of you with similar modems).

   2. I created the necessary tty devices, with the magic minor device numbers
	   that make the kernel's device drivers do the right thing vis a vis
	   modem control (see my previous posting of the script to do that
	   in comp.sys.mips).

   3. Uugetty now properly steps aside for tip, but it won't deliver a login
	   prompt for dial-in connections, although DCD is definitely doing
	   the right thing.  I don't know for certain whether to blame uugetty
	   or the modem.  I am leaning toward blaming the modem, because Trevor
	   Cotton assures me that everything is working for him, whereas the
	   T1600 that I'm using is now exhibiting strange behavior, even
	   when attached to another system with which it was working correctly
	   before this experiment.

   I don't really know what to think at this point, except that I have
   some serious hours of diagnostic work ahead of me to figure out what
   may be wrong with the modem.

Good luck.  I have had very little success with reliably running
modems on my M--2000.  I've tried several modems, more cables
configurations than I want to think about, [absence of] magic minor
device numbers, and prayer.  At this point I wouldn't be surprised if
someone from MIPS found some sort of a glitch with how there
drivers/streams code handles lines that are not CLOCAL.

Please let me know what you find.

g.
--
George Hartzell			                  (303) 492-4535
 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309
hartzell@Boulder.Colorado.EDU           ..!ncar!boulder!hartzell