robert@gitpyr.UUCP (Robert Viduya) (05/12/85)
We just got a few 3B2s donated from AT&T and I'm trying to get the tty ports
to talk to an Ungermann-Bass network using hardware flow-control. The network
implements hardware flow-control using the standard EIA-RS232 lines RTS and CTS
in a non-standard way (the standard allows only one way flow-control; the UB
equipment needs two way flow-control). Basically, RTS is used to control the
data flow from the network box to the terminal (or 3B2, in this case). CTS is
used to control data flow from the terminal (3B2) to the network box. The two
lines are independent of each other (deviating from the RS232 standard).
The 3B2s use an 8-pin modular jack (kinda looks like a phone jack). Two of
the pins are marked as "Reserved" (pins 2 and 8), but they are wired to the
RTS and CTS lines (pins 4 and 5) on RS232 25-pin connector.
Now, what I need is some way to control and query the lines. Unfortunately,
AT&T did not distribute the source code the the tty device driver, nor any
documentation on the tty hardware. Can anyone give me any information on this?
On a side note, in /usr/include/sys/termio.h, in the #define's for the
c_cflag field in the termio structure, there are two undocumented flags:
RCV1EN and XMT1EN. Anyone know what these do? Are they related to the above?
robert
--
Robert Viduya
Georgia Institute of Technology
...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert
...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robertlarrys@ihlpa.UUCP (Larry Schroeder ) (05/14/85)
> Now, what I need is some way to control and query the lines. Unfortunately, > AT&T did not distribute the source code the the tty device driver, nor any > documentation on the tty hardware. Can anyone give me any information on this? Assuming the tty ports in question are those of the 3B2 "ports" card, the tty ports are controlled by the ppc driver and standard Sys V tty line discipline through the Ports board firmware. Standard Sys V tty control flags and requests do not specify any features for access to RTS and CTS for a port. Therfore as for most UNIX Sys V systems the user can not specify their control, the 3B2 "Ports" firmware and driver Does Not provide any user accessable control for RTS and CTS (May be a problem to your U-B controller !?). > On a side note, in /usr/include/sys/termio.h, in the #define's for the > c_cflag field in the termio structure, there are two undocumented flags: > RCV1EN and XMT1EN. Anyone know what these do? Are they related to the above? These two cflags in termio.h define setup for an AT&T tty interface to Teletype's SSI protocol terminals. (This interface is not used on a AT&T 3B2 at this time, but is shown in standard termio.h for most AT&T 3B computers) The SSI ("standard synch. interface") protocol provides a synchronous communication frame which may contain one or two bytes of data or control characters. The RCV1EN flag identifies when set one-byte per frame on receive (two bytes per frame if not set). XMT1EN is similar for transmit... Larry Schroeder AT&T Information Systems -- Network Architecture Department
phil@amdcad.UUCP (Phil Ngai) (05/16/85)
In article <388@gitpyr.UUCP> robert@gitpyr.UUCP (Robert Viduya) writes: > >We just got a few 3B2s donated from AT&T and I'm trying to get the tty ports >to talk to an Ungermann-Bass network using hardware flow-control. The network >implements hardware flow-control using the standard EIA-RS232 lines RTS and CTS >in a non-standard way (the standard allows only one way flow-control; the UB >equipment needs two way flow-control). Basically, RTS is used to control the >data flow from the network box to the terminal (or 3B2, in this case). CTS is >used to control data flow from the terminal (3B2) to the network box. The two >lines are independent of each other (deviating from the RS232 standard). That's gross. You should use XON/XOFF for flow control. -- I speak for myself and no one else. Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
skip@gatech.CSNET (Skip Addison) (05/16/85)
In article <1345@amdcad.UUCP> Phil writes: >In article <388@gitpyr.UUCP> robert@gitpyr.UUCP (Robert Viduya) writes: >> >>We just got a few 3B2s donated from AT&T and I'm trying to get the tty ports >>to talk to an Ungermann-Bass network using hardware flow-control. The network >>implements ... the standard EIA-RS232 lines RTS and CTS >> ... > >That's gross. You should use XON/XOFF for flow control. > ... > Phil Ngai (408) 749-5720 We normally use XON/XOFF flow control, but uucp is gross. It expects a full 8-bit data path. So do some some other applications, particularly graphics. We'd still like to hear about possible solutions. -- "Here I stand, for I can do no other." -- Martin Luther The Office of Telecommunications and Networking Georgia Tech, Atlanta GA 30332 Southern Bell, AT&T, MCI, etc: (404) 894-6866 CSNet: Skip @ GATech ARPA: Skip.GATech @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!skip
robert@gitpyr.UUCP (Robert Viduya) (05/16/85)
> > > >We just got a few 3B2s donated from AT&T and I'm trying to get the tty ports > >to talk to an Ungermann-Bass network using hardware flow-control. > > That's gross. You should use XON/XOFF for flow control. > Unfortunately, using XON/XOFF for flow control means that the user has to go through all sorts of contortions to send an ^S or ^Q untranslated across the network. Besides, in my opinion, flow control should be as transparent as possible to the data being transmitted. It has nothing to do with the content of the data. robert -- Robert Viduya Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
lcc.jbrown@UCLA-LOCUS.ARPA (Jordan Brown) (05/18/85)
>From: phil@amdcad.UUCP (Phil Ngai) >> [ wants to use RTS/CTS for bidirectional flow control ] >That's gross. You should use XON/XOFF for flow control. No, _that_ is gross. Quite a number of things require a full 8-bit data path to the terminal (uucp, kermit in some modes, emacs, umodem, graphics devices), and having an intermediary eat two of the characters is terrible. Wire-based handshaking several advantages - it can be implemented in the hardware and is completely transparent. On the other hand, it doesn't propagate through networks and modems. What would be nice, in these days of intelligent terminals and reasonable tty drivers, would be for somebody to develop a transparent flow-control mechanism based on characters, so that it would pass through nets and modems but be added and stripped by low-level software (maybe even hardware??) so that an 8-bit data path is maintained. A simple example would be, say, to define that ^Vx means that x is not special. Thus, when told to send ^S, the tty driver (or whatever) would magically turn it into ^V^S, and the other driver (at the other end) would strip the ^V. (Of course, ^V^V is used to send ^V.) Another, and perhaps better, method would be to define a single line-control character (say, ^\), and ^\x is a command of some form. ^\^\ should mean ^\, ^\^S mean stop, and so on. NOTE: I don't particularily care what scheme is chosen, but people should agree on _one_ scheme so we don't have six incompatible ones next year. Whew, that was more than I meant to write, but it's a subject I'd like to see addressed. (I would like to use emacs, but my terminal needs ^S^Q so I can't reasonably do so.)
phil@amdcad.UUCP (Phil Ngai) (05/18/85)
In article <67@gatech.CSNET> skip@gatech.UUCP (Skip Addison) writes: > >We normally use XON/XOFF flow control, but uucp is gross. It expects a full >8-bit data path. So do some some other applications, particularly graphics. >We'd still like to hear about possible solutions. Yeah, uucp is gross and so is emacs. But I thought I heard something about an "f" protocol for uucp which uses 7 bit data paths. Programs like kermit know about such things too. Finally, most of the modern graphics protocols are reasonable and have an option restrict themselves to 7 bit mode too. I run a terminal network at AMD and deal with this issue all the time. In addition, there are new, error correcting modems which usurp XON/XOFF for their intended purpose, flow control (isn't that terrible :-). I am getting ready to try the "f" protocol in uucp. I hope it works. We have two VAXen sitting 10 feet apart which use the switched telephone network to talk to each other. Gross... -- What do you do the day after a peak experience? Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
MRC@SU-SCORE.ARPA (Mark Crispin) (05/18/85)
Re: transparent flow-control mechanisms based on characters. It's been done. How about bisync? It's only one of many. -------
root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr) (05/19/85)
> Comments about there ought to be an escape mechanism to allow > transfer of entire character set (re: Ungermann/Bass tty net) In fact, ^P (ASCII DLE) does 'escape' the special chars on the U/B net exactly as you had hoped. On the other hand, you are correct, no tty driver support exists to effect this automatically although we have considered it here. We live with the XON/XOFF flow control, it's not nearly as painful as people make it sound, you change a few key-bindings in EMACS and make sure things are CBREAK and everything starts to work (except things like XMODEM and UUCP which should really be fixed in my opinion, KERMIT works fine.) -Barry Shein, Boston University
honey@down.FUN (Peter Honeyman) (05/20/85)
how do you figure that it's "gross" for uucp to expect an 8-bit data path? what can we say about networking hardware that is incapable of providing transparent connections? peter
schnable@ihuxo.UUCP (Andrew T. Schnable) (05/21/85)
> how do you figure that it's "gross" for uucp to expect an 8-bit data > path? what can we say about networking hardware that is incapable of > providing transparent connections? > peter that's life. It's easier to accomidate imperfection than to change the world. andy ihbee!schnable
robert@gitpyr.UUCP (Robert Viduya) (05/22/85)
> > Comments about there ought to be an escape mechanism to allow > > transfer of entire character set (re: Ungermann/Bass tty net) > > In fact, ^P (ASCII DLE) does 'escape' the special chars on the > U/B net exactly as you had hoped. On the other hand, you are correct, > no tty driver support exists to effect this automatically although > we have considered it here. We live with the XON/XOFF flow control, > it's not nearly as painful as people make it sound, you change a > few key-bindings in EMACS and make sure things are CBREAK and > everything starts to work (except things like XMODEM and UUCP which > should really be fixed in my opinion, KERMIT works fine.) > Actually, it's pretty painful when you want to UUCP over the network. I don't know the protocol definition for UUCP, but I've played around with looking at the data it sends with a line monitor and it seems that an UUCP uses an ^P as some kind of 'start of packet' character. Naturally, the U/B eats them. We don't have the source to UUCP, so we can't modify it. Anyway, fixing UUCP to handle it is, in my opinion, is a kludge. There are reasons why flow control should not be implemented as part of the data path of a transmission link, the main being that it preempts certain bit sequences from being sent without special casing them (kludge). I have yet to hear of a good reason for not implementing flow control via hardware lines (other than it not being the accepted standard). If I had my way, everything would use hardware flow control and each terminal would have one more key that would toggle start/stop control to give humans access to flow control. Unfortunately, this isn't the case. robert -- Robert Viduya Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
honey@down.FUN (Peter Honeyman) (05/24/85)
robert's point is well taken: U/B is hamstrung by its inhospitability toward 8-bit virtual circuits. in fact, the very first byte sent by a slave uucico is ^P == SYN. uucico uses SYN to synchronize message handling before cutting into 'g', which is reliable and flow-controlled. as a veteran uucp hacker, i say to U/B: thanks, but no thanks. peter
robert@gitpyr.UUCP (Robert Viduya) (05/24/85)
> how do you figure that it's "gross" for uucp to expect an 8-bit data > path? what can we say about networking hardware that is incapable of > providing transparent connections? > peter The U/B network is perfectly capable of providing transparent conditions. The problem lies in the fact that we want to operate the lines at at least 9600 baud (preferably 19200) and the 3B2 can't handle that without some type of flow control. robert -- Robert Viduya Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
spaf@gatech.CSNET (Gene Spafford) (06/04/85)
It's been a while since the last posting on this subject, but I thought
some of you might be interested.
We have gotten UUCP working over an Ungermann-Bass Net/One virtual
circuit using the "g" protocol. It took a bit of struggle, but it
works great. In short, we define the port at each end so it ignores
the ^P (used by UB as an escape) and so it ignores ^S/^Q. The
port is flow controlled using ^S/^Q but the buffers are set to around
150 characters -- the UUCP "g" protocol uses 64 byte packets with
"acks" -- so there is never any danger of triggering the flow control
mechanism.
Under regular terminal use, if the computer output threatens
to overrun the buffer, the ^S/^Q protocol damps the flow in a manner
transparent to the user. In this mode, users typing ^S/^Q see it
work normally for them too.
The lack of an "escape" character doesn't seem to be a major loss
to the average user. And we can direct connect any two Unix systems
on campus this way if their ports are configured correctly.
That still doesn't solve Robert's 3b2 problem, but....
--
Gene "3 months and holding" Spafford
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332
CSNet: Spaf @ GATech ARPA: Spaf%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spaf