Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site pyramid.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!lll-crg!dual!pyramid!csg
From: csg@pyramid.UUCP (Carl S. Gutekunst)
Newsgroups: net.bugs.uucp
Subject: One-second break is too long
Message-ID: <24@pyramid.UUCP>
Date: Fri, 13-Sep-85 04:22:58 EDT
Article-I.D.: pyramid.24
Posted: Fri Sep 13 04:22:58 1985
Date-Received: Sat, 14-Sep-85 17:00:28 EDT
Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst)
Organization: Pyramid Technology, Mountain View, CA
Lines: 49

I encountered a bizarre problem with UUCP recently on which I'd appreciate
comments from UUCP wizards.

The situation: machine pyramid (a Pyramid 90x) polling a customer's system
under 4.2bsd, via their Gandalf port selector. Both ends use Hayes 1200
Smartmodems. It was necessary to go through a dialog with the Gandalf, then
send a BREAK to the Pyramid to make getty step to 1200 baud (they chose to
default to 2400). The L.sys entry was: 

    customer  Any  ACU  1200 555-5555 "" \d\r class-\d\r-class \dp1 \
	      start "\b\c" ogin:--ogin:--ogin: Upyramid assword: passwd

In brief, our system sent a break immediately after seeing "start", and then
expected to see a login: prompt at 1200 baud.

But instead, the remote Pyramid almost always got TWO breaks, causing it to
step back around to 2400. I had never seen this happen before on any system,
including on other Pyramids.

The 4.2 UUCP break generation code in conn.c (stripped for readability) is:

	genbrk(fn, bnulls)
	int fn, bnulls;
	{
		ioctl(fn, TIOCSBRK, NULL);
		write(fn, "\0\0\0\0\0\0\0\0\0\0\0\0", bnulls);
		sleep(1);
		ioctl(fn, TIOCCBRK, NULL);
	}

where _bnulls_ is user supplied in L.sys and defaults to 3. Figuring that a
write followed by a sleep was redundant, I commented out the sleep. And it
worked perfectly. Commenting out the write also worked, but not as well. Note
that on a Pyramid the ioctl is synchronized to the write, so a 3-character-
length break occurs, regardless of the baud. 

Has anyone else ever encountered this? Is one or two seconds too long for a
break? (Remember that sleep(1) can last as long as two seconds.) I think of
Ye Goode Olde Days on an HP2000 when a two-second break caused a hangup. Is
the break ioctl synchronous with regular I/O on other systems? 

BTW, 4.3bsd UUCP and tip both use only a 1-second sleep between the ioctl
calls. V.2.2 UUCP sends a single null character at 150 baud, followed by an
'@' at the normal baud. 
-- 
      -m-------   Carl S. Gutekunst, Software R&D, Pyramid Technology Corp.
    ---mmm-----   P.O. Box 7925    {allegra,decwrl,dual,nsc,sun}\
  -----mmmmm---   Mt. View, CA      {ihnp4,uiucuxa,uwvax}!pyrchi >!pyramid!csg
-------mmmmmmm-   415/965-7200                       topaz!pyrnj/