jr@amanue.UUCP (Jim Rosenberg) (08/20/87)
OK, I give up. How do you get a getty on /dev/tty000 to change the baud rate
in response to a BREAK? I have a new 3B1 and would like to put an external
2400 baud modem on the serial port. I have folks dialing me with 1200 baud
modems who don't have 2400, but don't have a separate line for the two baud
rates. I changed /etc/gettydefs so 1200 goes to 2400 next and vice versa.
Connecting the 3B1 to a PC-type machine and trying to log in with both PRO-YAM
and PC-VT, the 3B1 would not toggle baud rates when sent a break no matter what
I tried. This was a direct serial cable with 4-5 and 6-8-20 tied together at
each end, 2, 3 reversed. It works fine as long as I don't try to change
baud rate.
Paul Homchick (cgh!paul) is in exactly the same boat. I tried uucp'ing to
his system with a 2400 baud modem on the serial port, and she wouldn't change
baud rate from 1200 to 2400. The same L.sys entry expect-send sequences *do
work* when I uucp to maxepr, which has a 2400 baud modem starting off at 1200
on an *expansion port*. Paul tells me Kathy Vincent had the exact same problem
and finally just gave up. (Any news on that Kathy?)
So, halp! It says right there in black and white on the man page for getty(1)
she's suposed to flip to the next baud rate when receiving a break. One thing
I've noticed is that even though BRKINT is in the pre-login gettydefs field,
getty -c shows 0 for iflag, and stty shows -brkint. On my VENIX machine I
don't have BRKINT in gettydefs, and it will change speed with a break, so
maybe this is a red herring. But if getty is not responding to iflag settings
why did someone put them there in gettydefs?
On many machines, including my VENIX machine, there is a way to tell the driver
to ignore hardware handshake lines, like the dip-switch settings on most
modems. The 3B1 doesn't seem to have this. Are you supposed to go completely
through the termio(7) struct to enable and disable modem control? ATE has a
form somewhere talking about modem control. Anybody know how ATE does it?
On my VENIX machine I have a script that will disable the getty and tell the
line to ignore the fact that it hasn't got carrier detect. This lets me
call out under control of shell scripts, then bring back the getty when the
call is done. I'm not sure how to do this on the 3B1.
Any help *GREATLY* appreciated. This is one snazzy machine, but I gotta get
these points figured out before moving all my modem traffic over to it.
--
Jim Rosenberg
CIS: 71515,124 decvax!idis! \
WELL: jer allegra! ---- pitt!amanue!jr
BIX: jrosenberg seismo!cmcl2!cadre! /kathy@bakerst.UUCP (Kathy Vincent) (08/20/87)
In article <232@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes: >OK, I give up. How do you get a getty on /dev/tty000 to change the baud rate >in response to a BREAK? I have a new 3B1 and would like to put an external >2400 baud modem on the serial port. I have folks dialing me with 1200 baud >modems who don't have 2400, but don't have a separate line for the two baud >rates. I changed /etc/gettydefs so 1200 goes to 2400 next and vice versa. > ...the 3B1 would not toggle baud rates when sent a break no matter what >I tried. It works fine as long as I don't try to change >baud rate. > >Paul Homchick (cgh!paul) is in exactly the same boat. I tried uucp'ing to >his system with a 2400 baud modem on the serial port, and she wouldn't change >baud rate from 1200 to 2400. The same L.sys entry expect-send sequences *do >work* when I uucp to maxepr, which has a 2400 baud modem starting off at 1200 >on an *expansion port*. Paul tells me Kathy Vincent had the exact same problem >and finally just gave up. (Any news on that Kathy?) Well, let's don't say I gave up - let's just say I put the problem on hold. How's that? :-) I didn't know Paul was having the same problem. And I hate to admit this, but it hadn't occurred to me that one of the reasons why the *same modem* I have and the same dipswitch, software switch, and gettydefs settings I'm using on bakerst are working on Ken Brassler's machine (maxepr) *and* Gary Smith's machine (ethos) might be because they're using their modems on expansion ports and not on the RS-232 port. Ah. OK. I feel a little better now. And actually, I had two problems. The second problem was that, when I tried calling out on the modem (AT&T 4024), the modem did not appear to be sending connect codes the *first* try. In other words, I'd make a uucp call to ethos and watch the diagnostics. Everything proceeds just fine - up to the point where the system is waiting on the connect code from the modem. If the call connected, I'd hear the other end answer, but no code appeared on the screen, and everything just hung. Finally uucico would time out and try again, and the second time, lo, the code arrived just as it was supposed to. Now. I thought that might be the modem, but apparently it wasn't: I recently received a new test version of HDB, and that problem *seems* to have disappeared, except for the very first call I make after connecting the modem to my voiceline. (I use the modem occasionally for outgoing calls, but I'm not committing my dataline to it until I know everything is working.) I can't say I've tested it extensively enough that I don't still hold my breath when the remote end connects. [ Note: Sorry, but the HDB isn't available - yet? - for distribution. ] Gary and Ken both helped me a lot with testing things right after I got the modem and before I set up this version of HDB. More recently when I played with it, Larry Lippman (kitty) called in with cu. The modem was set to answer at 2400, and gettydefs entries pass off from 2400 to 300 to 1200 - this time around. When Larry called in at 2400, everything was fine. But when he called in at 1200, he said that the breaks were, in fact, changing the speed (or *some*thing anyway) - but to WHAT speed, he couldn't figure, because nothing intelligible ever came thru, no matter how many breaks he sent. We didn't have time to play with it a lot, so I didn't get into changing the 2400-300-1200 sequence - and I have to say I don't really think that's going to solve the problem anyway: When Gary and Ken and I tested before, the speed at which the modem answered didn't make any difference, nor did the sequence in gettydefs. That's the news - such as it is. If someone gets this one figured out, please post to the net or send mail! Kathy Vincent ------> Home: {ihnp4|mtune|codas|ptsfa}!bakerst!kathy ------> AT&T: {ihnp4|mtune|burl}!wrcola!kathy
jhc@mtune.ATT.COM (Jonathan Clark) (08/21/87)
In article <232@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes: >OK, I give up. How do you get a getty on /dev/tty000 to change the baud rate >in response to a BREAK? You probably did this already, but in /etc/gettydefs put: 1200 # B1200 HUPCL # B1200 HUPCL SANE TAB3 # login: # 2400 2400 # B2400 HUPCL # B2400 HUPCL SANE TAB3 # login: # 1200 Connect to the port at 2400, send a BREAK, and away you go. Running '/etc/getty -c /etc/gettydefs' may prove helpful. I suspect that your PC terminal emulators are actually not sending a real BREAK (0 bits for 1/2 a second, close enough). The key is in the following sentence: >The same L.sys entry expect-send sequences *do work* when I uucp to maxepr, >which has a 2400 baud modem starting off at 1200 on an *expansion port*. Now I *know* that the s4's tty driver sends a real BREAK. I also have a few hundred s4's around here which switch speeds quite happily. On all their ports, before you cavil. >On many machines, including my VENIX machine, there is a way to tell the driver >to ignore hardware handshake lines, like the dip-switch settings on most >modems. The 3B1 doesn't seem to have this. It's called CLOCAL. >Are you supposed to go completely >through the termio(7) struct to enable and disable modem control? Sure, this isn't BSD you know. You could always use stty(1). >ATE has a >form somewhere talking about modem control. Anybody know how ATE does it? via CLOCAL. Backwards. The stock tty driver defaults to CLOCAL *set*, and fooling with this option in the ATE *unsets* it. Various of the HFC drivers start out with CLOCAL *unset* like the manual says. 3.51 has it set because the printer software breaks without this. >On my VENIX machine I have a script that will disable the getty and tell the >line to ignore the fact that it hasn't got carrier detect. This lets me >call out under control of shell scripts, then bring back the getty when the >call is done. I'm not sure how to do this on the 3B1. /usr/bin/getoff.sh. You'll find that the line works very happily without CD providing you aren't running the HFC drivers. If you *are* then you'll need to fiddle with a second program to do an NDELAY open, or just let the open hang and do an stty clocal from elsewhere. Or wait for the latest HDB which has an NDELAY open as an option (this isn't available outside AT&T yet, alas). -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
pjc@pbhye.UUCP (Paul Condie) (08/21/87)
>On my VENIX machine I have a script that will disable the getty and tell the >line to ignore the fact that it hasn't got carrier detect. This lets me >call out under control of shell scripts, then bring back the getty when the >call is done. I'm not sure how to do this on the 3B1. /usr/bin/setgetty 000 1 This will turn the getty on for /dev/tty000. /usr/bin/setgetty 000 0 Turns is back off. The second arg is the tty port so this would also work for expansion slots 001-xxx.
gmark@ihuxv.ATT.COM (Stewart) (08/21/87)
I head about the DOS-73 board for the Unix-PC. Just wondering, how far or close does this board come to IBM compatibility for the Unix-PC? Regarding applications programs, hardware (speed, etc.)? - Mark (ditto) Stewart ATT-BL Naperville, ixlpq!gms
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (08/24/87)
One common cause of trouble is that PC terminal emulators don't generate
a real break. To get around this problem place your highest speed first,
so that a RETURN at the wrong speed will look like a BREAK (actually a
framing error). You may also want to double your highest speed to insure
that line noise doesn't downshift the line to the wrong speed. Just
duplicate your high speed entry and give it another name, then change
the pointer to the initial speed.
The BBS I run for *IX uses 2400x -> 2400 -> 1200 -> 300 -> 2400
and I don't have any problems. Trying to put the "most common" speed
first will cause a lot of grief, at least on the 7300 and Xenix systems
I've used. If people don't like hitting return so many time, let'm get a
faster modem. (I had someone download the MicroEMACS source at 300 baud
one day, using Kermit. Effective line speed was 18cps).
--
bill davidsen (wedu@ge-crd.arpa)
{chinet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me