daveb@argon.UUCP (Dave Berk) (09/30/88)
I previously posted: > When logging in remotely to my 6386, I noticed if I drop the > line when I am in "vi" , vi does not die and my modem gets hung. > The modem is a Hayes Compatible. If I log off the right way (^d) > the line is dropped. I noticed a few other items: 1. When the line is lost the CD (Carrier Detect) light and the OH (Off Hook) light goes off. This leads me to believe that the modem is fully aware that the line has dropped. 2. The RD (Read Data) and SD (Send Data) lights are still flashing even after the line is lost. It seems that the tty driver is still having some sort of conversation with the modem. I called the AT&T Hotline and some so-called engineer trying to insult my intelligence was attempting to tell me that this was a feature not a bug and this behavior was normal. Finally, after being persistent and talking with a knowledgeable person I was told that this was a known problem and that it may or may be not be fixed in the future. I was also told that this BUG may or may not be fixed in Release 5.3.2 (which I could obtain through a special upgrade for $360) but no one could tell me for sure. Can anyone out there shed any light on this problem ? Why is this a problem that may or may not be fixed ? Is it just me or isn't this a fundamental problem with the tty driver ? How can I ever use it remotely without being paranoid that if the line drops I can't log back in unless I physically am there to kill the processes associated with the port and reset the modem ? Is it worth my while to upgrade to 5.3.2 ? What fixes are actually in 5.3.2 ? Thanx; David Berk
mmengel@cuuxb.ATT.COM (Marc W. Mengel) (10/03/88)
In article <319@argon.UUCP> daveb@argon.UUCP (Dave Berk) writes: > [ Woes of using a Hayes compatable modem on a Unix box ] >Can anyone out there shed any light on this problem ? Well, it's pretty simple, actually; the problem is that your "Hayes compatable" modem doesn't lower CD (Carrier detect) when there is no carrier. Real Hayes modems can be configured to behave this way, and most non-hayes modems *always* act this way. If you set up your modem this way, you just need to set "HUPCL" in the /etc/gettydefs entries used by your modem and *not* set "CLOCAL", and you will be just fine. If your modem can't be taught to drop CD, then there is no way in the world for Unix to magically determine that the phone line was disconnected. Once you do this, you will have to make some use of modem control options in your uucp setup if you wish to call out -- namely if the entry was: ACU tty00 - 2400 hayes change it to ACU tty00,M - 2400 hayes and your Dialers entry should go from hayes .... expect1 send1 expect2 send2 ... to hayes .... "" \M expect1 send1 expect2 send2 ... "" \m so the send expect pairs are done ignoring carrier. >Is it just me or isn't this a fundamental problem with the tty driver ? No, its a fundamental problem with some modems -- they don't signal the host they are connected to that the line was disconnected. This carrier-always-high kluge was done so that devices too brain-dead to talk without carrier detect (like MS-DOS's COM1: device) could dial the thing. >How can I ever use it remotely without being paranoid that if the line >drops I can't log back in unless I physically am there to kill the >processes associated with the port and reset the modem ? Make sure that your modem reflects carrier state properly, and your line has has CLOCAL off in its /etc/gettydefs entry. If your modem doesn't have carrier detect right, and no way to configure it, you could try running a wire from the carrier LED on the modem to the rs232 pin (1/2 :-)). >Is it worth my while to upgrade to 5.3.2 ? It could be -- there are a number of bug fixes, but also lots of new features in order to fold in Xenix compatability. Many common Xenix app's run under 5.3.2, it would be worth your while if you need any of them... >What fixes are actually in 5.3.2 ? Alas, the lists I've seen all have Proprietary stamps on them... The practice has been in the past that if you are suffering from a bug known to be fixed in a later release and call the hotline (assuming you are under warranty or have a support contract) you get the upgrade as the bug fix -- hence the list isn't published to prevent people picking a bug from the list, and calling in with it (even though it hasn't been a problem for them) just to get an upgrade... > >Thanx; > >David Berk -- Marc Mengel mmengel@cuuxb.att.com attmail!mmengel {lll-crg|mtune|att}!cuuxb!mmengel
dave@westmark.UUCP (Dave Levenson) (10/06/88)
In article <2096@cuuxb.ATT.COM>, mmengel@cuuxb.ATT.COM (Marc W. Mengel) writes: > In article <319@argon.UUCP> daveb@argon.UUCP (Dave Berk) writes: > > [ Woes of using a Hayes compatable modem on a Unix box ] > >Can anyone out there shed any light on this problem ? > > Well, it's pretty simple, actually; the problem is that your "Hayes > compatable" modem doesn't lower CD (Carrier detect) when there is > no carrier. Real Hayes modems can be configured to behave this way, > and most non-hayes modems *always* act this way. If you set up > your modem this way, you just need to set "HUPCL" in the /etc/gettydefs > entries used by your modem and *not* set "CLOCAL", and you will > be just fine. If your modem can't be taught to drop CD, then there > is no way in the world for Unix to magically determine that the > phone line was disconnected. This is, indeed, the correct way to configure UUCP to work with a Hayes-Compatible modem. But it only works if the tty driver correctly implements the CLOCAL and HUPCL ioctl modes. The tty driver supplied by AT&T with the UNIX SVR2 Rel 2.1 for the 6300PLUS did not. They corrected this in the Rel 2.5 of the same product. They then released SVR3 for the 6386, with the same problem -- the HUPCL and CLOCAL options to /dev/tty are ignored. Rumor has it that this is being corrected in Rel 3.2 of this product. Can anybody confirm or deny this rumor? -- Dave Levenson Westmark, Inc. The Man in the Mooney Warren, NJ USA {rutgers | att}!westmark!dave
terry@wsccs.UUCP (Every system needs one) (10/12/88)
In article <2096@cuuxb.ATT.COM>, mmengel@cuuxb.ATT.COM (Marc W. Mengel) writes: > In article <319@argon.UUCP> daveb@argon.UUCP (Dave Berk) writes: > > [ Woes of using a Hayes compatable modem on a Unix box ] > >Can anyone out there shed any light on this problem ? [description of setting DCD to follow remote carrier] [description of modifying L-devices to talk to modems] > >Is it just me or isn't this a fundamental problem with the tty driver ? > > No, its a fundamental problem with some modems -- they don't signal > the host they are connected to that the line was disconnected. You neglect the brunt of the problem: If you don't use a modem-control device, it doesn't matter how you bludgeon it; it's not going to work correctly. Under Xenix, modem control devices are characterized by an uppercase letter in the device name (tty1A instead of tty1a, etc). This is not absoulute, of course: you could name your device /dev/phil, if you wanted to. The general UNIX implementation of modem-control devices is that of setting either bit 6 or 7 of the minor device number. To find out for sure which should be used on your system, check sio(7) in your manual. In general, if the minor device is greater than 64, it's a modem control device. > >How can I ever use it remotely without being paranoid that if the line > >drops I can't log back in unless I physically am there to kill the > >processes associated with the port and reset the modem ? This, unfortunately, is bogus. The modem should be set to reset on the high-to-low transition of DTR. It should also go back on hook. The UNIX stty parameter (set in /etc/gettydefs) to cause a drop of DTR on port close is HUPCL (Hang UP on CLose). In addition, the port should be set -CLOCAL (Connection is LOCAL), thereby enabling the SIGHUP signal to be set to all processes in that process group when a high-to-low transition of DCD (Carrier Detect) occurs. A normal login session: UNIX box is off, Modem is off: Modem can not, of course, answer phone UNIX box is off, modem is on: Modem can "hear" rings, but still can not answer the phone until DTR is asserted. UNIX box on, port is disabled: Since we are using a modem-control port, DTR is not asserted by the computer, since the port has not been opened. UNIX box on, port is enabled: /etc/getty calls open. This raises DTR on the port. Modem can now answer the phone if it rings. Since we are using a modem control port, the open is stuck until DCD (carrier) is asserted by the modem. A process status (ps -eda) at this point will show a getty on tty ?. UNIX on, DTR high, phone rings: Modem answers the phone. Connection occurs. Modem sends "CONNECT" message to the computer. [NB: at this point, if the port is not a Modem] [ control port or if DCD is forced high in ] [ the cable or the modem, the computer will] [ echo an invalid login message at the ] [ modem. Since the modem has not raised ] [ DCD, it thinks it's calling out and you ] [ want to hang up, so it does. This can be] [ avoided by setting the modem up right or ] [ turning off result codes. Turning off ] [ result codes is a bad idea, since it can ] [ keep you from dialing out. ] Modem raises DCD. Open completes (a ps -eda will show a getty on tty## now). The getty puts out the banner message in /etc/gettydefs and says "login:" and calls gets(). [NB: while at this point, a recevied "break" ] [ will cause the baud rate to change, if ] [ this is defined in /etc/gettydefs ] After the user types in something and hits return, getty exec's /bin/login on the string and prompts for a password. A ps -eda will show login on tty## now. All future logon tries during this call will be handled by /bin/login, and it is no longer possible to change the baud rate. [The user uses the machine for a while to the sound of "Jeapordy" 'Thinking music'] one of two things happens: 1) The user logs out 2) The user hangs up or is cut off 1) The user logs out: The port is closed in the act of hanging up and a signal is sent to init. Meanwhile, since the port is closed and -CLOCAL was specified, DTR is dropped to the modem. The modem resets and goes on hook, dropping DCD. Init acts on the signal and runs /etc/getty on the port again. The modem can answer the phone again. The cycle repeats. .... .... .... 2) The user hangs up or is cut off: The modem drops DCD. Since the port is set HUPCL, all processes are killed by a SIGHUP unless they were specifically told to ignore the signal. The shell dies (same as logging out). The port is closed and the modem resets. The init process is sent a signal. .... .... .... This is the intended setup. The one disadvantage is that you can't get back in without calling again. This can be subverted. Instead of logging out, you get to your lowest level shell (the one run by you logging in) and type: exec /bin/login You will get a "login:" again. Hope this answers some recurring questions. | Terry Lambert UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'I have an eight user poetic liscence' - me |
dave@onfcanim.UUCP (Dave Martindale) (10/20/88)
In article <727@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: > >The general UNIX implementation of modem-control devices is that of setting >either bit 6 or 7 of the minor device number. To find out for sure >which should be used on your system, check sio(7) in your manual. In >general, if the minor device is greater than 64, it's a modem control >device. I don't know about system V UNIXes, but on all of the older UNIX versions plus the BSD variants, the default device supported modem control - it's the only sane way to handle dialins. Sometimes an upper bit in the minor devices was used to add a "nowait" device, that allowed you to talk to the modem without waiting for Carrier Detect, but this is not always present. Maybe it is just Xenix that gives you no modem control by default? This is pretty brain-damaged behaviour.
woods@ixpierre.uucp (Greg A. Woods) (10/21/88)
In article <16509@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes: >In article <727@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: >> >>The general UNIX implementation of modem-control devices is that of setting >>either bit 6 or 7 of the minor device number. To find out for sure >>which should be used on your system, check sio(7) in your manual. In >>general, if the minor device is greater than 64, it's a modem control >>device. Or asy(7) for 386/ix. >I don't know about system V UNIXes, but on all of the older UNIX versions >plus the BSD variants, the default device supported modem control - it's >the only sane way to handle dialins. > >Sometimes an upper bit in the minor devices was used to add a "nowait" >device, that allowed you to talk to the modem without waiting for >Carrier Detect, but this is not always present. > >Maybe it is just Xenix that gives you no modem control by default? >This is pretty brain-damaged behaviour. I appologize in advance if this is redundant. Terry appears to be talking specifically about Xenix. I worked with an SCO Xenix V/286 2.2.1 system for many months a while back. It supported both "modem control" and "no wait" ports by default. I used this system with out too much trouble with ungetty to support a bi-directional line by running the getty on the modem control device, and uucico on the no wait device. The only problems I had were with getty's getting hung, or with the port getting locked up with a hung open using O_EXCL. (At least this is what appeared to happen.) This system (ixpierre) is 386/ix 1.0.6 (SysVr3). By default, (i.e. when you install it), only "no wait" devices are supplied. One can add the modem control devices by simply mknod'ing the files. I use a modem control device for my incoming line, and a no wait device for my outgoing line. I have yet to make the modem control device operate successfully as a bi-directional port without re-wiring the modem (which is impossible, since it is an internal modem). If the modem control device is used with 'uugetty -r tty01', The modem control device works fine with a standard modem, and does what you would expect it to. The no wait device seems to have a lot of problems. Both cu and uucico often report "lost line errno - 0" when attempting to dial out. However, the port is OK once the call is made, and uucico even seems to pay attention to carrier detect and give up if the line is dropped. If any sufficiently privledged process attempts to open for read either device that is associated with an incoming call (i.e. root running 'stty -a < /dev/tty01'), the modem drops the user. Does anyone besides Microport and Sun support simple bi-directional port usage by having a device driver which will prevent a getty's open on the modem control device from completing whenever the no wait device is open? Does anyone have a version of asy(7) for 386/ix that does this? Why does AT&T seem to instist on keeping the uugetty hack? I see no reason for it given a fully functional modem that adheres to the RS-232 spec. and an intelligent device driver. BTW, pay no attention to the device names I've used. I actually have them backwards here, in order to conform to the ISC naming "standard" (i.e. I didn't want to rename any devices, just add the modem control devices). I've called the incoming line acu00, and the outgoing line tty01. The ACU should really be the outgoing line :-). -- Greg Woods. UUCP: utgpu!woods, utgpu!ontmoh!woods, {ontmoh,tmsoft,telly}!ixpierre!woods VOICE: (416) 443-1743 [h] LOCATION: Toronto, Ontario, Canada
campbell@redsox.UUCP (Larry Campbell) (10/23/88)
In article <1988Oct21.033839.1412@ixpierre.uucp> woods@ixpierre.UUCP (Greg A. Woods) writes: } }Does anyone besides Microport and Sun support simple bi-directional }port usage by having a device driver which will prevent a getty's open }on the modem control device from completing whenever the no wait }device is open? Does anyone have a version of asy(7) for 386/ix that }does this? Why does AT&T seem to instist on keeping the uugetty }hack? I see no reason for it given a fully functional modem that }adheres to the RS-232 spec. and an intelligent device driver. VenturCom provided this feature in VENIX/86, a V7-based UNIX port for 8086 machines. I don't know if their current SV port supports this, but I doubt it, since it's based on 386/ix. The lack of this simple feature is INCREDIBLY ANNOYING, guys. Are you listening, AT&T (and Interactive and SCO and Altos and DEC and...)? -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146
pim@ctisbv.UUCP (Pim Zandbergen) (10/25/88)
In article <1988Oct21.033839.1412@ixpierre.uucp> woods@ixpierre.UUCP (Greg A. Woods) writes: > >Does anyone besides Microport and Sun support simple bi-directional >port usage by having a device driver which will prevent a getty's open >on the modem control device from completing whenever the no wait >device is open? Does anyone have a version of asy(7) for 386/ix that >does this? Why does AT&T seem to instist on keeping the uugetty >hack? I see no reason for it given a fully functional modem that >adheres to the RS-232 spec. and an intelligent device driver. Correct me if I'm wrong, but isn't the current release of 386/ix based on System V release 3.1 ? In that case you only need the modem control device to use your modem bidirectionally. System V release 3.1 and up enables uucico and cu to open the modem control device with O_NDELAY specified, set CLOCAL while dialing and unset CLOCAL after a connection has been made. This is what you specify in Devices: ACU tty00,M - 2400 hayes \T # open tty00 with O_NDELAY This is what you specify in Dialers: hayes =,-, "" \M\dAT\r\c OK\r \EATDT\T\r\c CONNECT \m\c where: \M means: set CLOCAL \m means: unset CLOCAL This way, you can program your modem to be as verbose as possible, because all RINGS etc. will be ignored when DCD is low. You still will need uugetty, because getty would wake up as soon as DCD will raise when a dialout connection has been made. Uugetty won't, because it checks the LCK.. files. But the only minor problem I see in using uugetty in this scheme is having to press <return> to get a login prompt. BTW, I made ct work using this scheme, even though the man pages tell me ct won't work with intelligent modems. However, it takes the following to put in /etc/inittab: 00:234:respawn:sh -c 'sleep 60; exec /usr/lib/uucp/uugetty -rt 60 tty00 2400' The 'sleep 60' is required by ct in order to call back before uugetty respawns. I don't know why this is necessary (ct makes valid LCK.. files) but it is. -- --------------------+------------------------------------+--------------------- Pim Zandbergen | CTI Software BV | Phone: +31 70 542302 pim@ctisbv.UUCP | Laan Copes van Cattenburch 70 | Fax: +31 70 512837 ..!mcvax!ctisbv!pim | 2585 GD The Hague, The Netherlands | Telex: 32133 CTI NL
jim@eda.com (Jim Budler) (10/25/88)
In article <490@redsox.UUCP> campbell@redsox.UUCP (Larry Campbell) writes: | In article <1988Oct21.033839.1412@ixpierre.uucp> woods@ixpierre.UUCP (Greg A. Woods) writes: | }Does anyone besides Microport and Sun support simple bi-directional | }port usage by having a device driver which will prevent a getty's open | }on the modem control device from completing whenever the no wait Ultrix 2.0 provided this capability by specifying it in the almost /etc/ttys file, which was a cross between BSD4.3 ttys and sysV inittab. | The lack of this simple feature is INCREDIBLY ANNOYING, guys. Are you | listening, AT&T (and Interactive and SCO and Altos and DEC and...)? Ultrix is a *nix provided by _____________________________^ -- uucp: {decwrl,uunet}!eda!jim Jim Budler internet: jim@eda.com EDA Systems, Inc.
terry@wsccs.UUCP (Every system needs one) (10/30/88)
In article <16509@onfcanim.UUCP>, dave@onfcanim.UUCP (Dave Martindale) writes: > In article <727@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: > > > >The general UNIX implementation of modem-control devices is that of setting > >either bit 6 or 7 of the minor device number. To find out for sure > >which should be used on your system, check sio(7) in your manual. In > >general, if the minor device is greater than 64, it's a modem control > >device. > > I don't know about system V UNIXes, but on all of the older UNIX versions > plus the BSD variants, the default device supported modem control - it's > the only sane way to handle dialins. Unfortunately this is not true. BSD, particular on Sun systems, requires a kernel reconfiguration to properly handle modem control on a port. The port is useless without proper modem signals unless configured back. I have manual pages for a Sun 3 and references in sio(7) in the Sun manual and management guides. I also have specific release notes dealing with this. > Sometimes an upper bit in the minor devices was used to add a "nowait" > device, that allowed you to talk to the modem without waiting for > Carrier Detect, but this is not always present. The nowait feature is built into the O_NDELAY open flag; using the minor device bit 6 or 7 for this behaviour only ocassionally would be wrong. > Maybe it is just Xenix that gives you no modem control by default? > This is pretty brain-damaged behaviour. All system V systems and all Berk systems I am familair with (Digital, Sun, Icon, etc) work this way. A modem control device is one where an open hangs until modem control signals are asserted. A non-modem control device is one where the open completes without those signals being asserted. Any installation which is using a stright 3-wire cable to their terminals is using a non-modem control port or they have hacked the computer end of the cable to force DCD and possibly CTS/RTS if it is a system V system with AT&T's 3B2-style drivers. Please examine tty.c for the comment "partial open hack" in your UNIX source. The 20 or so lines on either side will be enlightening. | Terry Lambert UUCP: ...{ decvax, uunet } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'I have an eight user poetic liscence' - me |
dave@onfcanim.UUCP (Dave Martindale) (11/04/88)
In article <756@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: >In article <16509@onfcanim.UUCP>, dave@onfcanim.UUCP (Dave Martindale) writes: >> >> I don't know about system V UNIXes, but on all of the older UNIX versions >> plus the BSD variants, the default device supported modem control - it's >> the only sane way to handle dialins. > >Unfortunately this is not true. BSD, particular on Sun systems, requires a >kernel reconfiguration to properly handle modem control on a port. The port >is useless without proper modem signals unless configured back. > [references cited] Now wait a minute. By "older UNIX versions", I mean V6, V7, and the 4BSD versions as distributed by Berkeley itself. These all support modem control, and default to it being enabled. Berkeley added the "flags" word to the configuration info allowing you to tell the driver on a per-line basis that modem control signals were to be ignored. I do not consider SunOS to be "Berkeley UNIX". We don't have any Suns, but comments I've read lead me to believe that they use the same "flags" word as Berkeley, but default to all of the bits set to disable modem control. This does make it easier to hook up terminals to the machine when you don't know anything about modem control, and don't want to, so it is perhaps justfied for machines that are seen as workstations. (I still don't like it.) >The nowait feature is built into the O_NDELAY open flag; using the minor device >bit 6 or 7 for this behaviour only ocassionally would be wrong. O_NDELAY is not supported in the UNIX versions I was talking about. In addition, UNIX tty drivers that use a minor device bit to control "dialout" mode often provide proper interlocking between dialin and dialout operation of a port, in the kernel, with no modification to user code required. >Any installation which is using a stright 3-wire cable to their terminals is >using a non-modem control port or they have hacked the computer end of the >cable to force DCD and possibly CTS/RTS if it is a system V system with >AT&T's 3B2-style drivers. True. People with modem control enabled on their terminal ports either use more than 3 wires (which allows the processor to detect when the terminal has been turned off), or jumper DTR to CXR at the computer end of the wire. >Please examine tty.c for the comment "partial open hack" in your UNIX source. >The 20 or so lines on either side will be enlightening. Not in the machines I was talking about. Dave Martindale