rjg@sialis.Sialis.MN.ORG (Robert J. Granvin) (09/25/87)
This has probably been discussed before, but I am new here. :-)
Several folx around here now own AT&T 3b1's, thanks to the fire sale.
Recently, though, some of us discovered what we (at least) consider a
problem. The description is basically as such:
A remote terminal is attached to tty000. (These remote terminals
conist of a wide range of machines from Amigas to 'real' terminals to
a Dec III for amusement. :-)
The problem arises when uucico calls another system. Normally
everything works fine, but in some situtations, you are forced to send
a BREAK to cycle the answering machines modem to 1200 baud. The
instant you send the BREAK, tty000 goes out to lunch. All output to
the device is buffered, and not sent, and input is not accepted from
the terminal. If you don't send a BREAK, the terminal remains
(apparently) unaffected.
The remote terminal will 'return to life' when the call is complete
and uucico starts up _another_ call. (The terminal returns at the
exact same time you hear the relay click to disconnect the remote
phone. (One exception. One 3b1 (running v3.5 system and 3.5
utilities) returns the terminal at the end of the call, instead of at
the beginning of the next call).
This has been duplicated on 3b1's running 3.51 system and 3.51
utilities, 3.5 system/3.5 utilities, and 3.5 system/3.51 utilities
(yep. someone screwed up on the latter one. :-)
AT&T states they've never heard of this problem, and suggested an
upgrade to 3.51. The upgrade obviously won't help since it occurs on
3.51 machines as well.
I can't believe that no one else out there has run across this, and I
find it hard to believe that AT&T has no knowledge of it (even though
the person(s) on the phone may not have, though).
Does anyone have any insight/solutions to this?
Email, please. If there's interest, I'll post a summary.
P.S. I (unfortunately) missed the discussions regarding the 'can't
open /dev/tty' problem via ph1. Was there any resolution to this, and
if so, would someone be so kind as to email me a summary? Thanks.
--
Robert J. Granvin UNIVERSE: rjg@Sialis.MN.ORG
Programmer/Analyst - Technical Services UUCP: ihnp4!meccts!sialis!rjg
National Information Systems, Inc. ATT: (612) 894-9494
"Trust me. I know what I'm doing" shap@sfsup.UUCP (J.S.Shapiro) (09/28/87)
Now I think this one is pretty weird: I have a Macintosh (or at least I am trying) hooked up to my tty000 port. The problem is this: I connect up the cable and I see: .... login: I type my login and nothing happens. I disconnect and reconnect the cable and I see password: From here on everything behaves unless I try to do, say, su. Anyone know what's up? Jon
brad@bradley.UUCP (09/30/87)
I also use uucp (ported 4.3BSD uucp to unixpc) and find it works just
fine on tty000 (we use it over AT&T ISN network), and need to send
breaks to get attention of the ISN.
Bradley Smith UUCP: {cepu,ihnp4,noao,uiucdcs}!bradley!brad
Text Processing ARPA: cepu!bradley!brad@CS.UCLA
Bradley University PH: (309) 677-2337
Peoria, IL 61625allbery@ncoast.UUCP (Brandon Allbery) (10/01/87)
As quoted from <14@sialis.Sialis.MN.ORG> by rjg@sialis.Sialis.MN.ORG (Robert J. Granvin): +--------------- | A remote terminal is attached to tty000. (These remote terminals | conist of a wide range of machines from Amigas to 'real' terminals to | a Dec III for amusement. :-) | | The problem arises when uucico calls another system. Normally | everything works fine, but in some situtations, you are forced to send | a BREAK to cycle the answering machines modem to 1200 baud. The | instant you send the BREAK, tty000 goes out to lunch. All output to | the device is buffered, and not sent, and input is not accepted from | the terminal. If you don't send a BREAK, the terminal remains | (apparently) unaffected. | | The remote terminal will 'return to life' when the call is complete | and uucico starts up _another_ call. (The terminal returns at the | exact same time you hear the relay click to disconnect the remote | phone. (One exception. One 3b1 (running v3.5 system and 3.5 | utilities) returns the terminal at the end of the call, instead of at | the beginning of the next call). +--------------- And I thought this was a cabling problem--! I have had these symptoms as well. 3.51 system, 3.51 utilities. But I'm placing the data calls on ph0 instead of tty001, and the terminal on tty000 dies when the OBM goes off-hook. Well, guys? I still want to install my remote terminal, but I've been holding off because of this. HELP! -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> "`You left off the thunderclap and the lightning flash.', I told him. `Should I try again?' `Never mind.'" --Steven Brust, JHEREG
ford@crash.CTS.COM (Michael Ditto) (10/04/87)
In article <4782@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >As quoted from <14@sialis.Sialis.MN.ORG> by rjg@sialis.Sialis.MN.ORG (Robert J. Granvin): [ ... ] >| The instant you send the BREAK, tty000 goes out to lunch. [ ... ] I have a similar problem... I usually log in from a terminal on tty000. When I am using cu to call out on ph0, everything normally works fine. But when I press my BREAK key, OR use the ~%break command to cu, everything appears to hang (including cu; ^M~..^M does not even get echoed). Sometimes hanging up my terminal (dropping DTR for a moment) will get me back to login:, other times, I have go to the console and kill the cu from there. It sounds like TCSBRK on ph0 causes tty000 to get hosed, but that doesn't explain why it hangs when I hit BREAK, unless cu interprets BREAK and does a ~%break -- maybe it does. -- Michael "Ford" Ditto -=] Ford [=- P.O. Box 1721 ford@crash.CTS.COM Bonita, CA 92002 ford%oz@prep.mit.ai.edu
ditto@cbmvax.UUCP (Michael Ditto) (08/02/88)
In article <14@sialis.Sialis.MN.ORG> rjg@sialis.mn.org (Robert J. Granvin) writes: >The instant you send the BREAK, [ to the OBM ] > tty000 goes out to lunch. All output to >the device is buffered, and not sent, and input is not accepted from >the terminal. If you don't send a BREAK, the terminal remains >(apparently) unaffected. > >The remote terminal will 'return to life' when the call is complete >and uucico starts up _another_ call. I have seen this; it's quite easily reproducable. In particular, I often log in via tty000 and "cu" out via ph0. If I type ~%break to cu, my terminal (on tty000) freezes (no input or output). A bit of experimenting revealed that SETTING the stty settings of ph0 will cause tty000 to return to life (i.e., going to the console and running "stty 1200 < /dev/ph0" makes everything work again). I don't think I knew about the bug when I was covered by warranty, and my current solution is just to avoid typing ~%break. >I can't believe that no one else out there has run across this, and I >find it hard to believe that AT&T has no knowledge of it (even though >the person(s) on the phone may not have, though). If you think it will help, I'll call the hotline and complain. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
rjg@sialis.mn.org (Robert J. Granvin) (08/03/88)
>In article <14@sialis.Sialis.MN.ORG> rjg@sialis.mn.org (Robert J. Granvin) writes: Wow! This is an OLD (meaning nearly a year) message. Where did it resurface? Anyways, since it usually needs to be hashed out every once in a while anyways... >>The instant you send the BREAK, > [ to the OBM ] >> tty000 goes out to lunch. All output to >>the device is buffered, and not sent, and input is not accepted from >>the terminal. If you don't send a BREAK, the terminal remains >>(apparently) unaffected. >> >>The remote terminal will 'return to life' when the call is complete >>and uucico starts up _another_ call. > >I have seen this; it's quite easily reproducable. In particular, I >often log in via tty000 and "cu" out via ph0. If I type ~%break to >cu, my terminal (on tty000) freezes (no input or output). A bit of >experimenting revealed that SETTING the stty settings of ph0 will >cause tty000 to return to life (i.e., going to the console and running >"stty 1200 < /dev/ph0" makes everything work again). > >> [...] > >If you think it will help, I'll call the hotline and complain. No need to. This problem is a bug in various drivers on the Unix PC. The problem existed under OS 3.5. What I can't recall clearly anymore is whether 3.51 fixed it. I don't believe so. However, installing the 3.51 fixdisks (3.51a kernel) will solve this problem (if not solved by 3.51) as well as a few