pjh@mccc.UUCP (Peter J. Holsberg) (01/22/88)
3B2/400
SysV r3.0 with HDB
Hayes-compatible modems
From time to time, a remote user does something that causes a modem to lock
up. When locked up, its RD/SD lights flash continuously and the OH light
is on. Also, an incoming call to that modem gets NO ANSWER. A call to the
other modem gets answered, but the response is slow, jerk, and characters
are frequently not received.
I've played with switch and register settings to no avail. I'm wondering
if the default options in the gettydefs file might have something to do with
the problem.
If you have any suggestions, please let them fly via email. Thanks.
--
Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh
Technology Division CompuServe: 70240,334
Mercer College GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800scl@virginia.acc.virginia.edu (Steve Losen) (01/22/88)
In article <142@mccc.UUCP> pjh@mccc.UUCP (Peter J. Holsberg) writes: > >From time to time, a remote user does something that causes a modem to lock >up. When locked up, its RD/SD lights flash continuously and the OH light >is on. Also, an incoming call to that modem gets NO ANSWER. A call to the >other modem gets answered, but the response is slow, jerk, and characters >are frequently not received. This is the classic "babbling getty syndrome" The problem is that the getty is sending a login: prompt to the modem while the modem is in command mode and the modem is echoing these characters back. Getty then thinks that someone is trying to login, sends the password prompt and this promptly gets echoed back. Then getty sends error messages and these get echoed back as well. Some characters that the modem echoes are re-echoed back to the modem by the 3b2. This accounts for the SD/RD problem. The resulting massive explosion of serial I/O puts such a strain on the kernel that I/O on other ports is seriously impaired. Be sure that the modem switches are set so that carrier detect follows the state of the phone line. That is, after the user breaks the phone connection, carrier detect should drop. This will cause the current getty to exit with SIGHUP and prevent the next getty from opening the tty port to the modem until another call has come in. Unfortunately, this will probably also prevent cu and uucico from opening the modem so you will not be able to dialout on this modem. Also set the HUPCL flag /etc/gettydefs. This will cause unix to drop DTR to the modem (and the modem hangs up the phone) when someone logs off. Unfortunately HUPCL means "hang up on *last* close", so if someone leaves a process running in background that still has the tty open, unix won't drop DTR. If you are using the modem for dialout, for heaven's sake turn off that getty! If you want to use the modem for both dialout and dialin good luck. It is possible, but it is not at all trivial to do. You have to use uugetty instead of getty and do a lot of playing around with your modem until you hit upon the correct configuration. Basically, uugetty opens the tty line and does a read before typing any prompt. When the read completes (presumably after someone has connected and hit a CR) uugetty checks for a lockfile to see of some other process (such as uucico or cu) has locked the line. If the line is clear, uugetty logs in the user. If uugetty sees a lockfile, it goes to sleep (it can't exit or init will spawn another uugetty) and periodically checks the lockfile. Once the uucico or cu is done, uugetty exits and init spawns another one. It is sad to say, but the simplest solution to the dialin/out problem is to reserve some of your modems for dialout only and turn off getty's to those lines. The rest can be used for dial in. -- Steve Losen scl@virginia.edu University of Virginia Academic Computing Center
chris@mimsy.UUCP (Chris Torek) (01/24/88)
In article <564@virginia.acc.virginia.edu> scl@virginia.acc.virginia.edu (Steve Losen) writes: >If you want to use the modem for both dialout and dialin good luck. It is >possible, but it is not at all trivial to do. It *is* trivial *if* your vendor has provided reasonable kernel support. Sun does, at least in SunOS 3.4. I modified 4.1, 4.2, and now 4.3 BSD to do it. It is wonderful to be able simply to point the dialout programs at /dev/dialXX and the getty at /dev/ttyXX and have everything work. The amusing (or sad, depending on your point of view) part is that the kernel support required is trivial. >It is sad to say, but the simplest solution to the dialin/out problem is >to reserve some of your modems for dialout only and turn off getty's to >those lines. This, of course, works well in any case. It is more expensive but it is also more reliable. There is an irremovable race condition induced by using one modem for both dial in and dial out: if you attempt to dial out at the same time that someone else dials in, you can wind up talking to the wrong machine! -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
pjh@mccc.UUCP (Peter J. Holsberg) (01/25/88)
Well, we're using SysV R3.0, so apparently it is not trivial. (Wonder
what kind of kernel support is needed and why AT&T didn't provide it?)
--
Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh
Technology Division CompuServe: 70240,334
Mercer College GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800guy@gorodish.Sun.COM (Guy Harris) (01/25/88)
> Well, we're using SysV R3.0, so apparently it is not trivial. (Wonder > what kind of kernel support is needed The Sun version provides *two* "/dev" entries for each serial port; the minor device number for the dial-out version is the minor device number for the dial-in version plus 128 (i.e., the 8th bit is set). Here is the description from a manual page for the CPU serial ports: To allow a single tty line to be connected to a modem and used for both incoming and outgoing calls, a special feature, controlled by the minor device number, has been added. Minor device numbers in the range 128 - 139 correspond to the same physical lines as those above (that is, the same line as the minor device number minus 128). A dial-in line has a minor device in the range 0 - 11 and is conventionally renamed "/dev/ttydN", where N is a number indicating which dial-in line it is (so that "/dev/ttyd0" is the first dial-in line), and the dial-out line corresponding to that dial-in line has a minor device number 128 greater than the minor device number of the dial-in line and is conventionally named "/dev/cuaN", where N is the number of the dial-in line. The "/dev/cuaN" lines are special in that they can be opened even when there is no carrier on the line. Once a "/dev/cuaN" line is opened, the corresponding tty line can not be opened until the "/dev/cuaN" line is closed. Also, if the "/dev/ttydN" line has been opened successfully (usually only when carrier is recognized on the modem) the corresponding "/dev/cuaN" line can not be opened. This allows a modem to be attached to e.g. "/dev/ttyd0" (renamed from "/dev/ttya") and used for dialin (by enabling the line for login in "/etc/ttytab") and also used for dialout (by tip(1C) or uucp(1C)) as "/dev/cua0" when no one is logged in on the line. (The names are purely conventional; you can call the ports anything you wish, and it won't affect the operation of this mechanism.) When it says "the corresponding tty line can not be opened until the '/dev/cuaN' line is closed", it means that a blocking "open" on "/dev/ttydN" will block until 1) the "/dev/cuaN" line is closed, which should cause DTR to drop with carrier dropping shortly afterwards and 2) carrier comes back up after that. The "open" won't fail with an error; it will just wait until the dial-out program is finished with the line and somebody dials in after that. I presume other implementations of this work much the same way. It requires only minor changes to the device drivers, and adds only a negligible amount of extra text and data to the kernel. (And despite a claim made in an earlier discussion of this feature, there is no problem whatsoever making this work with streams. Only one of the two devices can be open at a time - no-delay opens of the dial-in device must fail if the dial-out device is open - so there can't be two streams opened above the same device.) It requires *NO* changes to "getty", UUCP, "tip", "cu", etc.; it's all done transparently by the driver. > and why AT&T didn't provide it?) Beats me. It's certainly not hard to do, and it's not expensive in terms of code or data space; it also means "uugetty", which is a MUCH clumsier way of doing the same thing, could be deep-sixed (which would be a major maintenance win, since they'd no longer have source to two almost-identical flavors of "getty" to maintain, with fixes to one perhaps not getting propagated to the other). (And, before anybody asks, I have no idea whatsoever whether this will appear in the merged Enhanced System V or not; it's done in the device driver, so it's ultimately up to the hardware vendor to put it into their drivers.) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
brw@jim.odr.oz (Brian Wallis) (01/27/88)
In article <10321@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > In article <564@virginia.acc.virginia.edu> scl@virginia.acc.virginia.edu > (Steve Losen) writes: > >If you want to use the modem for both dialout and dialin good luck. It is > >possible, but it is not at all trivial to do. > > It *is* trivial *if* your vendor has provided reasonable kernel > support. The kernel support needs to be able to reset the modem to a useable state as well, since the dialout program may have put it into an unuseable state. Say set the modem to not answer any incoming calls, or to answer them all at 300 baud! -- Brian Wallis (brw@jim.odr.oz) (03) 562-0100 Fax: (03) 562-0616, Telex: Jacobs Radio (Bayswater) 152093 ^ What What What What What! Only 5 whats, that's not very bright!
wtm@neoucom.UUCP (Bill Mayhew) (01/27/88)
Hmmmm. See below. I was wondering about the warning in the /usr/lib/uucp/L-devices file on the 3b1 Sys V, relase 3.51. It tells you to be careful not to have any dialer devices that have names that begin with the letters "cua...". I was wondering why; I think I'm starting to get the picture now... This bears further investigation: + + The "/dev/cuaN" lines are special in that they can be opened even when + there is no carrier on the line. Once a "/dev/cuaN" line is opened, + the corresponding tty line can not be opened until the "/dev/cuaN" + line is closed. Also, if the "/dev/ttydN" line has been opened + successfully (usually only when carrier is recognized on the modem) + the corresponding "/dev/cuaN" line can not be opened. This allows a + modem to be attached to e.g. "/dev/ttyd0" (renamed from "/dev/ttya") + and used for dialin (by enabling the line for login in "/etc/ttytab") + and also used for dialout (by tip(1C) or uucp(1C)) as "/dev/cua0" + when no one is logged in on the line. + + (The names are purely conventional; you can call the ports anything you wish, + and it won't affect the operation of this mechanism.) When it says "the + corresponding tty line can not be opened until the '/dev/cuaN' line is closed", + it means that a blocking "open" on "/dev/ttydN" will block until 1) the + "/dev/cuaN" line is closed, which should cause DTR to drop with carrier + dropping shortly afterwards and 2) carrier comes back up after that. The + "open" won't fail with an error; it will just wait until the dial-out program + is finished with the line and somebody dials in after that. + + I presume other implementations of this work much the same way. --Bill
ejablow@dasys1.UUCP (Eric Robert Jablow) (01/28/88)
Well, it need not be as simple as that for the Suns running OS 3.[24]
either. At Stony Brook, we have a phone system made by ROLM,
and it seems that the system itself screws around with the signaling
wires. We don't have enough wires for full modem control, I think,
and neither ROLM nor the university's communication office can seem to
help us. So far, we can only dial out.
Besides, no one in the math department has enough expertise to figure
out a solution. Can someone contact me here or by voice-phone
or snailmail at:
Eric Jablow
Dept. of Math
SUNY at Stony Brook
Stony Brook, NY, 11794-3651
(516)632-8276
Thanks in advance. I wonder if it's because ROLM is owned by IBM :-)
--
Eric Jablow {allegra,philabs,cmcl2}!phri\
Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!ejablow
New York, NY, USA Soon to be eric@fawn.sb.edu.
Copyright 1988 First Category Pressnaomi@gtx.com (Naomi Walker) (01/28/88)
In article <10321@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <564@virginia.acc.virginia.edu> scl@virginia.acc.virginia.edu >(Steve Losen) writes: >>If you want to use the modem for both dialout and dialin good luck. It is >>possible, but it is not at all trivial to do. > >It *is* trivial *if* your vendor has provided reasonable kernel >support. Sun does, at least in SunOS 3.4. I modified 4.1, 4.2, >and now 4.3 BSD to do it. It is wonderful to be able simply to >point the dialout programs at /dev/dialXX and the getty at /dev/ttyXX >and have everything work. > > Sun supports some modems, but not all. Though things may have changed, I tried evrything and every person I could think of to make our Hayes modems work bi-directionally. We finally ended up buying a US Robotics modem, which solved all our problems (though EXPENSIVE), because it was supported. ------------------------------------------------------------------------------ Naomi Walker (N7FSA) - GTX Corporation - UUCP: ihnp4!sun!sunburn!gtx!naomi | To Iterate is Human, To Recurse is Divine ------------------------------------------------------------------------------
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (01/29/88)
In article <2743@dasys1.UUCP> ejablow@dasys1.UUCP (Eric Robert Jablow) writes: |Well, it need not be as simple as that for the Suns running OS 3.[24] |either. |We don't have enough wires for full modem control, I think, |and neither ROLM nor the university's communication office can seem to |help us. So far, we can only dial out. Last time I got dial-in/dial-out modems working on Suns was SunOS 2.0 But as I recall - you need a ribbon cable connecting every pin on the modem to every pin on the Sun serial port. You also have to set the modem up to be Hayes compatible. (or VenTel) Also set these modes: Hardware DTR Numeric Results Send results code No echo commands Answer incomming calls Hardware carrier detect Connection to RJ11 Modular Jack Enable COmmand Recognition. There also has to be a special flag set in the config file for the kernal. Something like: device zs0 at mb0 csr 0xeec800 flags 0x3 priority 2 flags (was 0x3) has to be changed to enable hardware carier detect: 0x2 - hardware carrier detect on ttya 0x1 - hardware carrier detect on ttyb 0x0 - hardware carrier detect on ttya & ttyb After building the new kernal, you have to create the devices with the different minor device numbers. See page 159, Chapter 5 Adding Hardware to your system - Sun System Administration manual. And also - make sure the /etc/ttys entry has a 1 (not a 0) for the serial port. Once it is done, you will only see the getty process when the carrier detect line is enabled. When the carrier detect is not there, you can use tip to dial out. As I said - this is from memory. (Okay - I peeked at the manual too! :-) -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
jerry@oliveb.olivetti.com (Jerry Aguirre) (01/30/88)
In article <39831@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >The Sun version provides *two* "/dev" entries for each serial port; the minor >device number for the dial-out version is the minor device number for the >dial-in version plus 128 (i.e., the 8th bit is set). Here is the description I have Chris Torek's mods installed on a 4.3BSD system. They perform the same function but the dialout device uses a different major device number and the same minor number. This means that I am not restricted to the first 12 ttys or to 12 ttys max. >> and why AT&T didn't provide it?) Easy. Without these mods I would be forced to buy more telephone lines.
sl@van-bc.UUCP (Stuart Lynne) (01/30/88)
In article <178@jim.odr.oz> brw@jim.odr.oz (Brian Wallis) writes: >> >If you want to use the modem for both dialout and dialin good luck. It is >> >possible, but it is not at all trivial to do. >The kernel support needs to be able to reset the modem to a useable state as >well, since the dialout program may have put it into an unuseable state. Say >set the modem to not answer any incoming calls, or to answer them all at 300 >baud! The best way to do this is to configure your modem to re-init itself when DTR is dropped. If you have a Telebit as opposed to Hayes 2400 you can even have it not answer the phone while DTR is low :-). I just implemented a serial driver for System V / 386 with this type of support. The added code for the driver is fairly trivial and allows for much simpler configuration of everything above it. Getty just waits for a successful open and runs. Things like cu/uucico either get the line and use it, or are told it's unavailble (ENXIO). The only remaining problem is the short window where your outgoing calls can be talking to someone who just dialed in. With HDB this seems to be less of a problem than with older uucp's, it just times out and retries. There doesn't seem to be any inherent security problems with this, just a slight problem with getting out reliably. If possible arrange your Devices file so that you choose your outgoing modems in reverse order of the incoming dial sequence to minimize collisions. Perhaps this type of support should be standardized in one of the appropriate Unix standards? -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532
cutter@cutsys.UUCP (Bernie Hoffstadt ) (01/31/88)
In article <39831@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >> Well, we're using SysV R3.0, so apparently it is not trivial. (Wonder >> what kind of kernel support is needed > >The Sun version provides *two* "/dev" entries for each serial port; the minor >device number for the dial-out version is the minor device number for the I guess Microport deserves a plug here. They have 3 minor device numbers for each device on System5 v2.2; ttyn - for direct (clocal) connection where open doesn't wait for DCD from the periperal. Open does however fail with an I/O error if a process has ttyMn open - see below. ttymn - here we wait for DCD before we return from a blocking open. No interaction with ttyn or ttyMn is noted in the manual, though I haven't tested this. ttyMn - like ttymn, but if ttyn is already open, we wait until it's closed again. Of course, there has to be DCD before a blocking open returns. Like with the Sun setup, we can hook up a getty to ttyM0 for dialins, and tell uucp to use tty0 for dialout. -- Bernie Hoffstadt (503) 752-5929 * Internet: cutter%cutsys.UUCP@CS.ORST.EDU 1437 N.W. 9th st. -or- 753-1646 * -or- cutter@jacobs.CS.ORST.EDU Corvallis, Oregon 97330 **** UUCP: {tektronix,hp-pcd}!orstcs!cutsys!cutter
chip@ateng.UUCP (Chip Salzenberg) (02/02/88)
In article <14002@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes: >I have Chris Torek's mods installed on a 4.3BSD system. >>> and why AT&T didn't provide it?) >Easy. Without these mods I would be forced to buy more telephone lines. Well, that's true; but I suspect that AT&T's oversight is more due to the fact that AT&T people don't have to worry about phone lines. Thus they have little personal reason to invest time in software that minimizes phone line usage. -- Chip Salzenberg UUCP: "{codas,uunet}!ateng!chip" A T Engineering My employer's opinions are a trade secret. "Anything that works is better than anything that doesn't."
sean@killer.UUCP (Sean McCollister) (02/02/88)
> >I have Chris Torek's mods installed on a 4.3BSD system. > >>> and why AT&T didn't provide it?) > >Easy. Without these mods I would be forced to buy more telephone lines. That's got to be one of the silliest explanations I've seen. As we all know, AT&T hasn't been in the "dial-tone" business for 4 years now. Go ahead and ring up your long distance bill, please! But why would Jim Olsen care how much you pay your local Baby Bell? :-)