[net.unix-wizards] getty speed switching under Ultrix v1.2

iglesias@ICS.UCI.EDU (Mike Iglesias) (08/13/86)

I've set up /etc/gettytab on our Microvax II running Ultrix v1.2 to
switch line speeds on breaks.  However, it doesn't seem to be very
reliable.  It appears that Ultrix is seeing one break as several, so
it skips past the correct speed about half the time.  Repeatedly
banging on the break key will get the correct speed sometimes, usually
after going past it 3 or 4 times, which can get frustrating.  Does
anybody have any ideas on what can be done to fix it?  Is it something
to do with the way the DHV-11 sees breaks?


Thanks,

Mike Iglesias
University of California, Irvine
iglesias@ics.uci.edu
...ucbvax!ucivax!iglesias

chris@umcp-cs.UUCP (Chris Torek) (08/14/86)

In article <2996@brl-smoke.ARPA> iglesias@ICS.UCI.EDU (Mike Iglesias) writes:
>I've set up /etc/gettytab on our Microvax II running Ultrix v1.2 to
>switch line speeds on breaks.  However, it doesn't seem to be very
>reliable.  It appears that Ultrix is seeing one break as several, so
>it skips past the correct speed about half the time. ...

Well, if you have source (this is one reason everyone should insist
on source!) you can fix it yourself.  If not, perhaps you can
convince DEC to do it for you.  The `fix' is to use a different
method entirely:  We auto-baud on carriage returns.  The code
below is for 4.3BSD, but should be easy to convert to 4.2 or Ultrix.

Another possible fix is to add a `sleep(2)' (or so) and a line
flush (if necessary) after detecting a break.

==> /usr/src/etc/getty/subr.c
RCS file: RCS/subr.c,v
retrieving revision 1.1
diff -c2 -r1.1 subr.c
*** /tmp/,RCSt1017315	Thu Aug 14 10:14:34 1986
--- subr.c	Sat Oct  5 06:40:21 1985
***************
*** 417,420 ****
--- 417,422 ----
  }
  
+ #ifdef notdef
+ 
  /*
   * This auto-baud speed select mechanism is written for the Micom 600
***************
*** 469,470 ****
--- 471,608 ----
  	return (type);
  }
+ 
+ #else
+ 
+ /*
+  * Try to figure out what speed the terminal is set to based on what
+  * a carriage-return or newline looks like at 2400 baud.  5/18/82 FLB
+  *
+  * N.B.: some of the table entries for \n collide with those for \r.
+  * Only the first one in the table will be matched.
+  */
+ 
+ #include <sys/types.h>
+ #include <sys/time.h>
+ #include <signal.h>
+ #include <setjmp.h>
+ 
+ struct autobaud {
+ 	char *s_speed;
+ 	char *s_string;		/* first byte is length */
+ } a_tab[] = {
+ 	/* carriage-return */
+ 	"110-baud",	"\3\000\000\000",	/* also \n */
+ 	"300-baud",	"\3\200\200\000",	/* collides with 600 \n */
+ 	"300-baud",	"\3\200\000\000",
+ 	"300-baud",	"\3\000\200\000",	/* also \n */
+ 	"600-baud",	"\3\000\376\000",
+ 	"1200-baud",	"\2\346\200",
+ 	"1200-baud",	"\2\346\340",
+ 	"1200-baud",	"\2\367\300",
+ 	"1800-baud",	"\2\000\376",		/* also \n */
+ 	"1800-baud",	"\2\000\377",
+ 	"2400-baud",	"\1\015",
+ 	"2400-baud",	"\1\215",
+ 	"4800-baud",	"\1\361",		/* needed for Gandalf */
+ 	"4800-baud",	"\1\362",
+ 	"4800-baud",	"\1\363",		/* needed for Gandalf */
+ 	"4800-baud",	"\1\371",		/* needed for Gandalf */
+ 	"4800-baud",	"\1\375",		/* needed for Gandalf */
+ 	"4800-baud",	"\1\376",		/* needed for Gandalf;
+ 						   collides with 9600 \n */
+ 	"9600-baud",	"\1\377",		/* needed for Gandalf */
+ 
+ 	/* newline */
+ 	"600-baud",	"\3\200\000\000",	/* collides with 300 \r */
+ 	"1200-baud",	"\2\230\200",
+ 	"2400-baud",	"\1\012",
+ 	"4800-baud",	"\1\370",
+ 	"9600-baud",	"\1\376",		/* collides with 4800 \r */
+ 
+ 	/* The next entry must be the last entry in the table. */
+ 	0,		"\1\0",			/* BREAK: handled specially */
+ 
+ 	0,		0
+ };
+ 
+ char *
+ autobaud()
+ {
+ 	register struct autobaud *tp;
+ 	register int i;
+ 	struct sgttyb ttyb;
+ 	static char buf[10];
+ 
+ 	extern jmp_buf timeout;	/* from main.c */
+ 	extern int dingdong();	/* from main.c */
+ 
+ 	if (TO) {
+ 		if (setjmp(timeout)) {
+ 			/*
+ 			 * Drop DTR for a while.  This is important
+ 			 * for Gandalf lines which must be told to
+ 			 * disconnect.
+ 			 */
+ 			ttyb.sg_ispeed = ttyb.sg_ospeed = 0;
+ 			(void) ioctl(0, TIOCSETP, &ttyb);
+ 			sleep(3);
+ 			exit(1);
+ 		}
+ 		signal(SIGALRM, dingdong);
+ 		alarm(TO);
+ 	}
+ 
+ 	/*
+ 	 * The following hack sets BREAK to sequence to the next
+ 	 * gettytab entry.
+ 	 */
+ 	a_tab[(sizeof (a_tab) / sizeof (a_tab[0])) - 2].s_speed =
+ 	    NX && *NX ? NX : 0;
+ 
+ 	ttyb.sg_ispeed = ttyb.sg_ospeed = B2400;
+ 	ttyb.sg_flags = ANYP|RAW;
+ 
+ 	for (;;) {
+ 		(void) ioctl(0, TIOCSETP, &ttyb);
+ 		input(buf, sizeof buf);
+ 
+ 		for (tp = a_tab; tp->s_speed; tp++) {
+ 			for (i = 0;; i++) {
+ 				if (buf[i] != tp->s_string[i])
+ 					break;
+ 				if (i == buf[0]) {
+ 					alarm(0);
+ 					return (tp->s_speed);
+ 				}
+ 			}
+ 		}
+ 	}
+ 	/*NOTREACHED*/
+ }
+ 
+ input(s, n)
+ 	char *s;
+ 	register int n;
+ {
+ 	register char *cp = s + 1;
+ 	fd_set rfds;
+ 	struct timeval timeout;
+ 
+ 	FD_ZERO(&rfds);
+ 	FD_SET(0, &rfds);
+ 	timeout.tv_sec = 0;	/* .15 seconds */
+ 	timeout.tv_usec = 150000;
+ 	n--;			/* first byte is for length */
+ 	(void) read(0, cp, 1);	/* wait for something */
+ 	n--, cp++;
+ 	while (--n >= 0) {
+ 		if (select(1, &rfds, (fd_set *)0, (fd_set *)0, &timeout) <= 0)
+ 			break;
+ 		if (read(0, cp, 1) != 1)
+ 			break;
+ 		cp++;
+ 	}
+ 	*s = (cp - s) - 1;
+ }
+ 
+ #endif
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

grandi@noao.UUCP (Steve Grandi) (08/15/86)

In article <2996@brl-smoke.ARPA> iglesias@ICS.UCI.EDU (Mike Iglesias) writes:
>I've set up /etc/gettytab on our Microvax II running Ultrix v1.2 to
>switch line speeds on breaks.  However, it doesn't seem to be very
>reliable.  It appears that Ultrix is seeing one break as several, so
>it skips past the correct speed about half the time.

4.2BSD has an undocumented field in /etc/gettytab called pf.  This
field gives the number of seconds to wait before flushing input at the
login prompt.  When I put a 'pf#1' field in the "rotary" dial-up entries in 
gettytab the similar problems we were having zeroing in on a speed with 
breaks went away; presumably the "pseudo" breaks get flushed before they 
are detected.  Maybe the same field is hiding in Ultrix 1.2?

I have also added a to#180 field to the gettytab entries for our dial-up
lines so that the speed gets reset to "normal" every three minutes.
Our users were getting confused when they called in and found the line
set at 2400 bps; especially upset were those who couldn't send
breaks!
-
Steve Grandi, National Optical Astronomy Observatories, Tucson, AZ, 602-325-9228
{arizona,decvax,hao,ihnp4,seismo}!noao!grandi  grandi%draco@Hamlet.Caltech.Edu

hurf@batcomputer.TN.CORNELL.EDU (Hurf Sheldon) (08/15/86)

	We have been using 'S1200' in /etc/ttys with no problems-
 <cr> or break will make them work - reading /etc/gettytab this round
 robins the 'std' settings(causing a slight delay) & the list seemingly 
 could be expanded to all the pertinent speeds. We go 1200 - 2400 - 300
 and all the speeds select fine - it does seem on occaision that if 'getty'
 has handed over to 'login' & a break is issued things get weird.

     Hurf Sheldon			Arpa.css: Hurf@ionvax.tn.cornell.edu
     Lab of Plasma Studies	
     369 Upson Hall			phone: 607 255 7267
     Cornell University
     Ithaca, N.Y. 14853

pavlov@hscfvax.UUCP (840033@G.Pavlov) (08/16/86)

In article <2996@brl-smoke.ARPA>, iglesias@ICS.UCI.EDU (Mike Iglesias) writes:
> I've set up /etc/gettytab on our Microvax II running Ultrix v1.2 to
> switch line speeds on breaks.  However, it doesn't seem to be very
> reliable.  It appears that Ultrix is seeing one break as several, so
> it skips past the correct speed about half the time.  .......

 Well, this probably shouldn't have anything to do with it, but including
 "fd#5" (or 2,3,4,whatever) in the default section of gettytab cleared up
 similar break recognition/speed switch problems for us (on uVax II's).


      greg pavlov, fstrf, amherst, ny.

dougm@ico.UUCP (Doug McCallum) (08/19/86)

I had the same problem with trying to use BREAK on our Ultrix 1.2
system and found quite by accident that just using a carriage return
seemed to work.  I've only tried it between 9600 and 4800 baud so it
could be coincidence.