root@brain.UUCP (Chuck Shotton) (02/02/90)
segedy@cspi.com (Cathy Segedy) writes: >Hello. For those of you who have already seen my cry of help last time >I posted, sorry, but I still don't have a solution. Here's my problem. >I have a 1200 baud modem attached to my mac. I would like to have a getty >running on it, under aux (either 1.1 or 1.1.1, I forget. I think 1.1.1) >anyway. I would like to call in from somewhere else, have the modem answer, >get the getty and login. Unfortunately, when I turn on the getty in the >inittab, it keeps killing the getty and restarting it. Please help!! >I have tried what I consider to be everything, but I can't believe that >this doesn't work!! > thanks a million, > cathy segedy Make sure you set the modem up so it's "quiet". That is, use ATE0Q1 to keep it from echoing commands or responses. Sounds like your problem is that the modem is echoing the login prompt, A/UX takes it as a username/password pair and tries to log it in. ALSO, your cable must support the DSR/DCD signal from the modem and the modem must be configured to follow the transitions of the DTR signal and drop (or enable) carrier accordingly. (AT&C1, perhaps?) Chuck cshotton@girch1.hsch.utexas.edu ...!buster!brain!root
time@oxtrap.aa.ox.com (Tim Endres) (02/07/90)
This topic needs a little more discussion.
The way the distribution getty for A/UX works is as follows:
. getty is invoked by init with parameters from inittab.
. getty resolves the parameters and gets more from /etc/gettydefs.
. getty call open() on the serial line (/dev/.....).
This asserts the DTR line on the port.
. open() BLOCKS until the CARRIER DETECT comes high.
This is a result of using "modem" control on the device which can
be specified with "stty modem". This also causes Kermit to hang if
the modem is not yet connected, which is why "stty -modem" exists.
. When the CARRIER DETECT line is asserted, the open() call succeeds
and getty proceeds with the login: prompt.
Now, if you either (1) don't have modem control set [a gettydefs parm]
-or- (2) your cable does not pass the CD line properly, then getty's
open() succeeds immediately, and the modem gets the *command* login:
which of course it does not like so it says "ERROR" which, of course,
gets a "password:" from the spawned login process. Finally, the login
attempt of ERROR with password ERROR fails, and the cycle repeats
itself causing the "blinking lights" problem many people have.
Another problem exists when the modem (as many HAYES like to do)
asserts CD all the time on its own. This is provided for brain dead
applications that can not deal with the fact that CD is low. This is
usually a DIP switch setting on the Hayes.
Finally, if you can not get getty to block on CD, then you can use the
technique of putting the modem into "quiet" mode, thus avoiding the
input from the modem (i.e. RING, RING, CONNECT). This is not an
optimal solution, but it gets the job done most of the time.
Also, drop of DTR should drop a connection and should reset the modem
if possible. Further, calls should not be accepted with DTR low.
[Cathy, I tried e-mail, but it bounced.]
tim.dab@myrias.com (Danny Boulet) (02/21/90)
In article <TIME.90Feb6171340@oxtrap.aa.ox.com> time@oxtrap.UUCP writes: > >Finally, if you can not get getty to block on CD, then you can use the >technique of putting the modem into "quiet" mode, thus avoiding the >input from the modem (i.e. RING, RING, CONNECT). This is not an >optimal solution, but it gets the job done most of the time. When I was setting up my machine for UUCP, I finally had to put my modem into "really quiet" mode. I disabled the "RING, RING" stuff, turned off the "OK" stuff and turned off command echoing. This ensured that no junk of any sort would be sent back to my machine by the modem. Until I did this, the problems I ran into included: - the serial port would get into an echo-enabled mode. Any character sent by the machine would be echoed by the modem which would be echoed by the machine which would be echoed by the modem which would be echoed by the machine which would consume lots and lots of CPU resources. - the getty would read the "RING" or the "CONNECT" stuff as an attempt to login and prompt for a password. Since this wasn't repeatable, I was never able to come up with a login handshake sequence to put into the /usr/lib/uucp files that would work reliably. If you're having these or similar problems with serial lines, try convincing your modem to completely shut up. It may do the trick. One of the side effects of this "really quiet" mode was that it was a bit tricky to use the modem for dialing out since it gave no feedback whatsoever. A bit of practice and placing the modem where I could see the lights pretty well solved this problem.
paul@taniwha.UUCP (Paul Campbell) (02/22/90)
Here's a note I posted last May, since there seem to be a number of people going through the hoooking-modems-to-getty process here's a fix for a bug you may or may not have stumbled onto yet Paul A number of people have reported problems trying to get incoming serial lines to autobaud under A/UX. The problem seems to be that the A/UX /etc/getty does NOT respond to incoming line breaks, parity errors and most importantly framing errors (all these ought to cause it to switch speeds). [A good example of this problem can be seen if you set PARMRK in the 'initial-flags' field in /etc/gettydefs and then run '/etc/getty -c']. What follows is a simple patch to fix the worst of this problem, the patch works for (and applies ONLY to) A/UX 1.0 and 1.1, it may NOT work for future A/UX releases. Since it is a 3rd party patch to Apple software it is not waranteed by anyone (on the other hand it does make things work). To make the patch do as follows logged on as root: mv /etc/getty /etc/getty.old # backup /etc/getty cp /etc/getty.old /etc/getty # [works even if getty running] adb -w /etc/getty 10c0?x # should print '0x100' # if not STOP HERE!! ?w 0x108 # make the patch ^D vi /etc/gettydefs then change lines like co_9600# B9600 # B9600 SANE2 TAB3 # ~MODEM ~DTR ~FLOW #\r\n\nMy System\r\n\nlogin: #co_4800 to co_9600# B9600 PARMRK # B9600 SANE2 TAB3 # ~MODEM ~DTR ~FLOW #\r\n\nMy System\r\n\nlogin: #co_4800 Finally kill off all your gettys so that they restart with the new /etc/getty. You can also make this patch to a copy of /etc/getty and try it on a single line if you want to test it without letting it loose on your system Of course this patch works on Taniwha's CommCards (<- plug). I hope this helps anyone having problems in this area. My thanks to Malcom Duncan for reporting this bringing this problem to my attention and testing the fix. Paul Campbell -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P You know there's something wrong when 100,000 people marching in Moscow make page 1 and 400,000 in Washington don't .....