chris@umcp-cs.UUCP (Chris Torek) (08/20/86)
I have a few points to make. Overall, Dave's article is no doubt very useful to Ultrix 1.1 sites. In article <282@cirl.UUCP> das@cirl.UUCP (Dave Steffens) writes: >Ultrix as supplied does NOT support modem control on ANY terminal lines. A nit: it is not `does not support', but rather `ignores'. Ah well. >In order to enable modem control you **must** do a sysgen. Not so! You can use adb on the kernel image. It is possible to change either the running kernel, or the flags in the boot image, or both. The first is the easiest, as the boot-time flags are rather well buried. And in any case, after doing this, you should adjust your configuration file so that you need never do it again. Assuming that you wish to enable modem signals on DZ1, line 3: % adb -w /vmunix /dev/kmem dz_flags/x _dz_flags: _dz_flags: f3ff [N.B.: the above number may vary; but the idea is to clear bit eleven.] dz_flags/w 0ff3f _dz_flags: ffff = f3ff % I do not know the proper offsets for the boot-time flags---indeed, I cannot know them, as they are configuration-dependent as well as system dependent---but the procedure is similar: ubdinit+<n>*<sizeof struct (ubadevice)>+<offset to ui_flags>?x ...?w f3 The flags are stored separately for each DZ, thus the f3 above. In the DZ driver they are collected together into one array, thus the f3ff earlier. The value of <n> can be found by looking at ioconf.c from a previous sysgen. Alternatively, it may be divined by certain Elvish arts, whose details are too complex to explain here. I daresay a reconfiguration and recompile is far easier for most. >Find the entry in the configuration file.... The bit in "flags" >corresponding to each line which has a modem on it must be zero >in order to get the driver to use the modem control signals. If >the bit is one, modem control is disabled (Ignored: though this distinction matters only in the driver itself.) >on the corresponding line. The "flags" are in HEX (base 16). Only because they are written as `0x...'. Be sure not to delete those first two characters! >NOTE: you cannot just set the all the bits to zero because once >a line is configured to use modem signals it will not be usable >with a directly-connected terminal! This is my real point of contention. This is not in fact the case! We run most of our terminal lines wired as follows: 1-----1 2-----3 3-----2 4-+ +-4 5-+ +-5 6-+--20 8-+ 7-----7 20--+-6 +-8 Some terminals demand different configurations; but typically, both the host and the terminal are properly configured to plug right into a modem. The above constitutes a `null modem' cable, crossing various signals around such that, while the terminal is on, the host sees a modem `carrier detect' signal. With this set-up, you need disable modem control on no lines--- that is, use `flags 0x0', or no `flags' word at all---and, more importantly, one can turn off a terminal to break its connexion. (Some people think this is a bad idea, but `naive users' tend to believe that turning terminals off is just as good as logging out. This seems intuitively correct to me, and it has not proven a problem at other times, as one can always use `stty mdmbuf'....) -- 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
hurf@batcomputer.TN.CORNELL.EDU (Hurf Sheldon) (08/22/86)
I would like to pick one small nit with Chris's reply & that is that
setting modem control on all ttys may not be so hot an idea. Without modem
control we are able to restrict our cabling to pins 2,3 & 7 which cuts down
considerably the number of wires you have to fool with & makes conversion to
fiberoptics (which we do for RF protection in our labs) also very simple.
Another nit with article 3250 re 4.3/Ultrix1.2 ttys 'shared' field -
The flags must still be set in the driver for this to work correctly and the
Modem must be set so dsr goes high in 'data mode' & cts goes high only when
ready to transmit. Having these lines always held high will make the line
look busy to 'tip' & fail to suppress looping to getty using 'kermit'.
Looping in 'kermit' will also take place if the flag is not set in the driver.
This whole discussion has been very worthwile - I had similar
problems some time ago & Fred Avolio from decuac answered most of these
same questions here on the net - but the nature of my need was such that
much of the detail provided by this discussion never came up. A useful
service...
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. 14853gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/23/86)
Chris Torek says that one can safely configure all terminal ports as though modems were going to be attached, and he's right. I never understood why some people keep trying to build the distinction into their operating systems. If DTE acts like DTE and DCE acts like DCE, everything works great. Simply jumpering the direct- line terminal port cables correctly will suffice.
greg@ncr-sd.UUCP (Greg Noel) (08/23/86)
In article <121@grebyn.UUCP> karl@grebyn.UUCP writes: > [ discussing modem control on lines] .... The standard configuration > is for hardwired terminals, not modems. Another way (kludge) is to > wire your modems up so that DTR is always present. A nit, but that should be DCD (Data Carrier Detect) instead of DTR (Data Terminal Ready). The modem looks at DTR to see if the computer is active, while the computer looks at DCD to see if the modem has a data connection. The computer will provide DTR to the modem even if it is ignoring DCD. (The modem also provides DSR (Data Set Ready) to say that it is powered on and ready; this could be used for controlling access to an auto-dialer, but it usually isn't.) > This is a REALLY BAD THING to do, but doesn't require you to > reconfigure your system ...... I agree strongly. See below. In article <282@cirl.UUCP> das@cirl.UUCP (Dave Steffens) says the same thing, in a slighly different context: [ talking about how to assign the per-device modem control bits ] >NOTE: you cannot just set the all the bits to zero because once >a line is configured to use modem signals it will not be usable >with a directly-connected terminal! In article <3030@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) replies: >This is my real point of contention. This is not in fact the case! >We run most of our terminal lines wired as follows: (I have annotated this below) > 1-----1 (Shield Ground) > 2-----3 (i.e., cross Transmit Data (TD) with > 3-----2 Receive Data (RD)) > > 4-+ +-4 (Jumper Request To Send (RTS) into Clear > 5-+ +-5 To Send (CTS)) > > 6-+--20 (Convert Data Terminal Ready (DSR) into Data Set > 8-+ Ready (DSR) and Data Carrier Detect (DCD)) > > 7-----7 (Signal Ground) > > 20--+-6 (DTR becomes DSR and DCD again) > +-8 > >....... The above constitutes a `null modem' cable, >crossing various signals around such that, while the terminal is >on, the host sees a modem `carrier detect' signal. Chris then points out that this permits \all/ lines to be treated as modem lines and some rationale as to why this is a good idea. In this he is absolutely correct, and I would have quoted it as well except that I'm already quoting too much. I will only add that treating all lines as modem lines is a big plus to system security. I wish that this diagram would be taken down and added to every SAs little bag of Elvish tricks -- it's amazing how often this is done wrong. The fundamentals of this are simple: TD at one end becomes RD at the other, and DTR at one end becomes DSR and DCD at the other. A lot of people seem to think that because most DTEs always provide RTS at the same time as DTR that these signals are equivalent. This is just flat wrong, and will someday lead you into trouble. (Er, oops, DTE is Data Terminal Equipment, something that "looks like" a terminal or a computer port. The other partner is a DCE for Data \Communications/ Equipment, something that "looks like" a modem. The theory is that a DTE can be connected to a DCE by a straight cable.) About the only thing I do differently is to cross RTS and CTS instead of jumpering them. This is useful on those terminals that will do hardware flow control (I'm not a fan of terminals that sent ^S and ^Q for flow control) and usually harmless otherwise. Other notes: Depending upon circumstances, you can frequently get by without connecting pin #1, or by jumpering it to pin #7 -- computer boards often connect them internally. And often in a direct computer- to-terminal connection, the terminal doesn't care if DSR/DCD is set, so you can do without that wire. Thus is it possible to run a hard-wired terminal cable with only three wires plus a ground. In fact, if the computer end is connected to the same board, the ground can be shared -- I have connected eight terminals to a DH on a PDP-11 over a standard 25-wire cable. (I don't recommend this, and there were unusual circumstances that forced me to do it, but it does show that it is possible to have a secure terminal connection with a very modest investment in wires.) I am considered somewhat of a security fanatic, but the additional security aspects alone are sufficient reasons for me to recommend that you turn on modem control on all your ports, and then wire your connections to fit that paradigm, rather than treating "modem" ports as a special case. Believe me, it's worth it. See Chris's article for human-engineering reasons; if my recomendation doesn't sway you, then those should. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
csg@pyramid.UUCP (Carl S. Gutekunst) (08/23/86)
In article <1149@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >About the only thing I do differently is to cross RTS and CTS instead >of jumpering them. This is useful on those terminals that will do >hardware flow control (I'm not a fan of terminals that sent ^S and ^Q >for flow control) and usually harmless otherwise. Unfortunately, a lot of terminals use DTR for their flow control, and RTS as 'power on' (including all Wyse and Liberty terminals). For these you have to either give up on hardware flow control (bad, especially when trying to use Gosling EMACS) or break the rules, and wire RTS through to DCD and DSR (almost as bad). When connecting to device that does DTR and RTS correctly, you get a cable that isn't symetric. But since most terminals also use the wrong DB-25 connector (a DTE is supposed to be male), at least you can't plug it in the wrong way. (*SIGH*) Note that using RTS and CTS for full-duplex flow control isn't technically correct either, but that's a lot better than using DTR.... FYI: DEC and AT&T are the only terminal manufacturers I've worked with that consistently get their RS232 connections correct (or close to). >Other notes: Depending upon circumstances, you can frequently get by >without connecting pin #1, or by jumpering it to pin #7 -- computer >boards often connect them internally. No! NEVER jumper #1 and #7 together!! I realize a lot of equipment does this, but just because the machine is wrong it doesn't mean the mistake should be duplicated in the cable. #1 is supposed to go to earth ground, the same as the round pin on the power cable. Pin #7 is the signal ground, the same ground as used by the equipment's DC power supplies. In properly designed equipment, there will be no electrical connection between these grounds. Connecting them introduces radiated noise problems, creates a possible shock hazard, and makes the equipment much more vulnerable to nearby lightning strikes. <csg>
mangler@cit-vax.Caltech.Edu (System Mangler) (08/25/86)
In article <3030@umcp-cs.UUCP>, chris@umcp-cs.UUCP (Chris Torek)
advises configuring all ports for modem control (flags=0x0) and
using null modems for directly-connected terminals.
Chris, as usual, has exactly the right idea (if we ignore DMF's).
The problem is all those improperly wired cables out there.
For instance, the BC22D null modem cable that DEC used to sell for
the DZ11 connects DTR to DSR, leaving CXR (carrier) open. But the
DZ11 wants CXR and doesn't even have a wire connecting to DSR.
Most tty interfaces are similar.
To clarify:
DTR (pin 20) Tells the modem that the terminal/computer is alive.
DSR (pin 6) Tells the terminal/computer that the modem is alive.
CXR (pin 8) Tells the terminal/computer that carrier is present.
What Unix cares about is Carrier (CXR), i.e. whether a connection is
present. How many of your cables have pin 8 connected to anything?
Oh, all your cables have only 3 wires (like ours)?
If you can connect CXR to DTR, even if it just loops back in the
connector, you will most likely still save yourself all this grief
with carrier detect. Just one jumper from pin 20 to pin 8 - that
isn't too hard.
(DMF's have to use carrier flags no matter what, because the wires
just aren't there to jumper).
Don Speck speck@vlsi.caltech.edu seismo!cit-vax!speckphil@amdcad.UUCP (Phil Ngai) (08/26/86)
In article <1149@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >A nit, but that should be DCD (Data Carrier Detect) instead of DTR (Data >Terminal Ready). The modem looks at DTR to see if the computer is active, >while the computer looks at DCD to see if the modem has a data connection. Hardly a nit, rather, that is an important point. >The computer will provide DTR to the modem even if it is ignoring DCD. In at least one version of 4.2 BSD, this is not true. When the system is configured to ignore modem controls, it fails to turn on DTR. I have a friend who can testify to this. I verified it with a breakout box. This was important because his terminals expected DCD and his wiring system connected DTR from his VAX to DCD on his terminals. It didn't work and he couldn't understand why. I agree with all the comments about the value of modem control. I would like to add a few comments of my own. 1) If you require DTR from the terminal, then you won't get burned by the following scenario: user disconnects vax cable to connect to local computer. VAX cable floats and picks up noise on input lines. VAX spends all its CPU cycles trying to login noise. The loss of DTR allows the VAX to consider the cable disconnected and it will ignore noise on the cable. 2) DTE does stand for Data Terminal Equipment but "Terminal" is not strictly a thing you type on but simply something that you connect to a modem. Real terminals (VT100) do fall into this class but so do VAXen and statistic muxes. A number of computer manufacturers have designed their serial ports to be DCE for convenience but this was not the intent of the spec. Large companies which tend to be better about conformance to specs like DEC and IBM usually make their computers DTE. 3) We take the attitude that wire is cheap and use lots of it. In fact, we run a 25-pair cable for 6 terminals, or 8 wires per terminal. This lets us use cheap Western Electric 258A outlet devices. 4) Why complain about Ultrix when Berkeley Unix told you no more about modem control? -- Rain follows the plow. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
phil@amdcad.UUCP (Phil Ngai) (08/26/86)
In article <584@pyramid.UUCP> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >FYI: DEC and AT&T are the only terminal manufacturers I've worked with that >consistently get their RS232 connections correct (or close to). Yes, DEC and ATT get their connectors right more often than anyone else I have seen. However, IBM has gotten much better. Their 3101 terminal is female but the (25 pin) PC serial interfaces, the 7171 and their new terminals are all male like they should be. Some bad guys are Wyse, Televideo and (surprise!) HP. They all make their terminals female. -- Rain follows the plow. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
greg@ncr-sd.UUCP (Greg Noel) (08/29/86)
In article <584@pyramid.UUCP> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >Unfortunately, a lot of terminals use DTR for their flow control, and RTS as >'power on' (including all Wyse and Liberty terminals). For this, and other kinds of braindamage, I resort to specialized short cables (about two inches long, like a sex converter) that makes the necessary changes. In this case, a simple one that swapped DTR and RTS would suffice. (Actually, my null modem cables are the same length -- any cable I have that's over a foot long is straight pin-to-pin with at least the nine standard signals being carried. That way I never have to test a cable to see what it does -- if it's long, it's straight; if not, it had better be labled with what it does.) >Note that using RTS and CTS for full-duplex flow control isn't technically >correct either, but that's a lot better than using DTR.... Truth. (Enter lecture mode for those that don't know the history.) RTS and CTS are intended for half-duplex flow control -- that's where they get their names. (A half-duplex line is one where only one side is sending data at a time and if data is to flow in both directions, the two ends must alternate. A line where data flows in only one direction is a simplex link, and a line where data can flow in both directions at the same time is a full-duplex link.) If somebody on a half-duplex connection wants to talk, they raise Request To Send to indicate this. When the other end is ready to accept data, it raises Clear To Send. On a full-duplex line one doesn't have to worry about line turnarounds, but the flow-control/handshaking tradition remains, so the signals are often adapted for out-of-band flow control. (Hey! OK, I'll stop now -- give me back my soapbox!) >No! NEVER jumper #1 and #7 together!! I realize a lot of equipment does this, >but just because the machine is wrong it doesn't mean the mistake should be >duplicated in the cable. ....... I should have been clearer. Carl is correct, and I would only jumper them together if I had verified that both ends made this mistake and the equipment absolutely needed to be grounded. Often the cable shield can be used instead for this pin instead of an actual wire, but again, circumstances vary, and what is reasonable under one circumstance is not reasonable under another. If you are not knowledgable in this area, get help. (I consider myself only semi- knowledgable in this area, enough to know the options and potential problems, but not enough to know the correct solutions, so I \always/ get an expert to look at my wiring plans before I commit.) -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
greg@ncr-sd.UUCP (Greg Noel) (08/29/86)
In article <1149@ncr-sd.UUCP> I write: >The computer will provide DTR to the modem even if it is ignoring DCD. In article <12834@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >In at least one version of 4.2 BSD, this is not true. When the system >is configured to ignore modem controls, it fails to turn on DTR. ..... Humpf. I was about to write a reply that pointed out that I probably had a lot more experience in this than Phil did, and that I had never had a port fail to turn on DTR, but I though I should check first. It turns out that he's right -- it's done on a per-driver basis, and I have never used any hardware/driver combination that did it wrong. Mea culpa. I'm puzzled, though -- the RS-232 (et.seq.) protocol is \not/ that complicated, but by the number of supposedly knowledgable people that get it just flat wrong, there must be something subtle in it that causes confusion. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
dave@murphy.UUCP (Lerxt) (09/15/86)
Summary: Please don't force modem control on me! Line eater: enabled In article <1163@ncr-sd.UUCP>, greg@ncr-sd.UUCP (Greg Noel) writes: >In article <42@houligan.UUCP> dave@murphy.UUCP (me) writes: >>Two problems with this: 1: Some older async interfaces, like the DZ11, do >>not have interrupts for the modem control lines, so the driver has to poll >>them. If you have 80 async ports and most of them are direct-connect, you >>probably don't want the driver polling all 80 of them for ring indicator >>continuously. 2: What about current-loop or other non-RS232 interfaces? >1. No matter how many ports you have, if \one/ of them has modem control, > you have to take the polling interrupt, so you may as well poll them > all -- the additional cost is negligible; the expensive part is taking > the interrupt. (Note to anyone who just joined in: this whole section of the discussion is applicable to older devices like DZ11's, which do not have the capability to issue an interrupt when a modem control signal changes.) It's true that the bulk of the overhead is probably in servicing the actual interrupt. Still, it seems like a waste of processing time to poll 60+ lines for modem signals when only one or two of them actually has a modem. Some async devices have registers that take considerably longer to respond to a read request than memory does. It seems like if the system was configured with all of the modem lines in a certain range, the driver could take advantage of this and set up a for-loop to poll only that range, and then maybe have flag bits for turning modem control on/off within that range. Still, I'm willing to admit that checking the flag bits could take as long as the actual polling. That isn't the major problem, though. >2. What about them? The point that I was trying to make is that there some terminal interfaces which simply don't support modem control. True, some of them are exotic devices, but some are quite common: there is a widely used version of the DZ11 that doesn't support modem control signals, and I believe that ports 2-7 on a DMF32 are also of the "transmit-and-receive-only" variety. What I'm trying to avoid is having some software developer read this discussion, decide that modem control should *always* be on, and remove the configuration option for turning it off. That would cause two problems, one minor, one major; the minor one is that all lines not actually using modem control will have to have null-modem cables or adaptor plugs; the major one is that devices that don't do modem control will be unusuable -- an open on such a line will never succeed, because it will hang waiting on a carrier signal that will never appear! I agree that there should be a way to turn modem control on/off on a line while the system runs (through some method other than adb :-). I also agree that in environments where physical security of the lines is a problem, modem control should be used on all lines. At our site, it isn't a problem, so everything is wired using 3-conductor cable. As the average terminal line run is about 1000', and there are probably at least 250 terminal lines in the building, I doubt that I could convince anyone to rewire the building for modem control on all lines. The point is that modem control simply isn't apporpriate in some environments. Please don't remove the option to disable it. --- It's been said by many a wise philosopher that when you die and your soul goes to its final resting place, it has to make a connection in Atlanta. Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL UUCP: ...{sun,pur-ee,brl-bmd}!gould!dcornutt or ...!ucf-cs!novavax!houligan!dcornutt ARPA: wait a minute, I've almost got it... "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."
greg@ncr-sd.UUCP (Greg Noel) (09/24/86)
In article <59@houligan.UUCP> dave@murphy.UUCP (Lerxt) writes: >(Note to anyone who just joined in: this whole section of the discussion is >applicable to older devices like DZ11's, which do not have the capability to >issue an interrupt when a modem control signal changes.) Curiously enough, the DZ11 is the newer device, not the older. The DH11 (or actually, its associated DM11) provided modem control interrupts. I'm told that RSX-11 was better at polling than responding to interrupts, so I suspect that the DZ was designed around its limitations. >...... I also agree >that in environments where physical security of the lines is a problem, modem >control should be used on all lines. ........... >The point is that modem control simply isn't apporpriate in some environments. >Please don't remove the option to disable it. I think you miss the point. I'm not saying that the option to ignore modem control should be eliminated -- far from it. And it's not just the physical security of the lines, either. But when you \can/ use modem control, do it. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
mouse@mcgill-vision.UUCP (09/26/86)
In article <1154@ncr-sd.UUCP>, greg@ncr-sd.UUCP (Greg Noel) writes: > I'm puzzled, though -- the RS-232 (et.seq.) protocol is \not/ that > complicated, but by the number of supposedly knowledgable people that > get it just flat wrong, there must be something subtle in it that > causes confusion. RS232 is not complicated. BUT, it is usually possible to get by with a small subset (pins 1, 2, 3, 7, with maybe 2 and 3 crossed), which leads people to avoid learning more than that small subset. For example, I know what the basic difference between DTE and DCE is supposed to be, but I couldn't tell you the details like which one is supposed to transmit on pin 2. I have learned enough about RS232 to make terminal cables that work, and that's about it. Also, I don't think I have *ever* seen the RS232 protocol explained. I expect this is because nobody has needed to bother to go look it up; the "small subset" above is small enough to be passed on verbally -- so there are no sheets lying around with the explanation on them. This leads to the mystique surrounding anything undocumented. der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu Aren't you glad you don't shave with Occam's Razor?
henry@utzoo.UUCP (Henry Spencer) (09/27/86)
> Curiously enough, the DZ11 is the newer device, not the older. The DH11 (or > actually, its associated DM11) provided modem control interrupts. I'm told > that RSX-11 was better at polling than responding to interrupts, so I suspect > that the DZ was designed around its limitations. My understanding is slightly different, based on some DEC documentation of the time. The problem was not that DHs were too fancy for RSX, but that DHs were too expensive and too bulky for a lot of people who wanted terminal multiplexors. A Dec DH was a 9-slot backplane full of boards, and cost accordingly. The point of the DZ was to capture the minimum necessary features in a much cheaper implementation. Well, they sort of succeeded. No DMA, for cost reasons, and if you read the documents (at least the early ones) they cautioned you that the total expected throughput of a DZ was about 9600 baud -- that's *total*, not per line. No split speeds, because virtually none of the DH customers ever used the DH split-speed capability. Minimal modem control, because almost none of the DH customers used the extra modem-control lines. Only 8 lines, because that's what fit on a board. I don't think they justified the polled modem control explicitly, I think it was just a question of not being able to fit a scanner onto the board or into the (cramped) Unibus address space they gave themselves. The Dec DZ board was pretty full, and the Unibus registers were already doubled up most annoyingly (i.e. a read-only register and a write-only register with different roles at the same address). -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry