Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ncsu.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!mcnc!ncsu!mark
From: mark@ncsu.UUCP (Mark Lanzo)
Newsgroups: net.unix-wizards
Subject: Need help with modems under Ultrix
Message-ID: <3097@ncsu.UUCP>
Date: Tue, 5-Aug-86 10:00:23 EDT
Article-I.D.: ncsu.3097
Posted: Tue Aug  5 10:00:23 1986
Date-Received: Thu, 7-Aug-86 03:21:32 EDT
Organization: N.C. State University, Raleigh
Lines: 76

Well, I did so well with my last question to this group (thanks folks!)
that I'm gonna try again with a new one!

The situation:  
    I am trying to hook up a modem to a MicroVax II running
Ultrix-32m V1.2.  The modem needs to be usable for both incoming and
outgoing use.

The problem:
    Nothing I or anyone at our site has been able to do has worked to
convince the system to handle the line properly.  We had no problems 
before when we were running under V1.1 of the OS, but apparently V1.2
handles terminals in a significantly different fashion.
The problems we have are (a) baud-rate switching does not seem to work
very well for dial-in users, (b) system tends not to know if the phone line
has been disconnected, and hence doesn't log you off if you hang up or get
cut off.


Specifics for the problem:

   MicroVax II running Ultrix32m Version 1.2
   Modem is a Hayes Smart-modem 2400 baud variety.
   Everything worked fine under V1.1.  Hence, I don't think it's the
   modem cable or anything like that.
   The modem should rotor around from 2400 to 1200 to 300 baud.
   Normal dial-out use is with the C-Kermit program, but we also want UUCP
   to understand how to use the line.

   I have tried all the tricks I could think of in the /etc/termcap file,
   /etc/gettytab, etc.
   The only way I have been able to get the system to use the modem control
   lines (ie, sense the carrier) is by writing a program which performed 
   ioctl calls on the modem line (/dev/tty01 if it matters).  Specifying
   the "modem" field in the gettytab entry didn't seem to affect this.
   (So what action DOES this flag control?).

   Dial-in use:
       Usually you can get connected (get a carrier), but once you get it
   you have a very hard time getting logged in.  Hitting the BREAK key
   at your remote terminal is supposed to cause the baud rate to switch
   around, but it rarely does.  Usually the system prints garbage on your
   screen (apparently the login prompt being spewed at you at the wrong
   baud rate), and hitting BREAK key more than once either (a) gets you
   no response at all, in which case the only way to ever get the system
   to pay attention again is to hang up and call again, or (b) just 
   re-prints the aforementioned string of garbage.  If you are a stubborn
   sort, and keep calling in, you may eventually get on.
   As already mentioned, if you DO get on, and get disconnected, the system
   won't log you off.  Definitely a security problem!

   Dial-out use:
       Actually, dial out use has been fairly well behaved.  I've written 
   programs which stop/start the getty on the line, then connect you to
   the modem (via C-Kermit).  Here I would just like to know if anyone has
   a GOOD system for doing this, or a better approach.  My routines are
   just simple programs which win no awards for robustness.  For instance,
   if the user aborts the communications program, the system won't restart
   the getty on the line.

So...

    Is there anyone out there who has experience with this and who could
lend a hand?  Are they any common packages out there which make the 
line conveniently useful for both ingoing and outgoing operation?

Thanks in advance...


Mark Lanzo
Communication Unlimited, Inc.   (NOT NC State Univ!)


PS:  please send replies via email (path = ...decvax!mcnc!mark ?) as I
have not subscribed to this newsgroup (and I'm a couple of hundred articles
backlogged in those groups I *am* subscribed to!)