dat@sat-bc.UUCP (Dick Tusia) (12/17/85)
We are running UNIX 4.2 BSD on a VAX 11/750 and it seems that when we call one site that is running UNIX 4.1 BSD our modem will not hang up after the conversation is complete. When calling another 4.2 BSD site we have no problem. I have tried many types of modems with no luck. Has anybody ever come across this problem in the pursuit of true UUCP happiness. Dick Tusia SAT-BC bunker!sat-bc!dat 203-767-2601
paul@vcvax1.UUCP (paul) (12/19/85)
> We are running UNIX 4.2 BSD on a VAX 11/750 and it seems that when we call > one site that is running UNIX 4.1 BSD our modem will not hang up after > the conversation is complete. When calling another 4.2 BSD site we have > no problem. I have tried many types of modems with no luck. > Has anybody ever come across this problem in the pursuit of true > UUCP happiness. My guess is that you are relying on the remote system to hang up the phone when you log out. Your computer ought to be hanging the phone up itself. When you close the line on your side, your terminal driver should be turning of Data Terminal Ready. If your Data Terminal Ready line is wired through to the modem, then your modem will hang up. On the other hand, if you have DTR permanently wired high, then the problem you report will occur.
steve@jplgodo.UUCP (Steve Schlaifer x3171 156/224) (12/20/85)
> We are running UNIX 4.2 BSD on a VAX 11/750 and it seems that when we call > one site that is running UNIX 4.1 BSD our modem will not hang up after > the conversation is complete. When calling another 4.2 BSD site we have > no problem. I have tried many types of modems with no luck. > Has anybody ever come across this problem in the pursuit of true UUCP happiness. > Have you checked to see that the other site's modem is set to hang up when the DTR line is dropped? Also make sure that they have the modem port configured HUPCL so that DTR is dropped when the last process closes on that tty line. I suspect the problem is one of the above. On a Hayes 1200 smartmodem, switch 1 determines how DTR is treated (it should be up). Other modems probably have similar switches. A simple test is to call the other site (via cu), log on and then log off. If the switches are set right the phone should hang up. If it doesn't, it is a problem at their end.
steve@jplgodo.UUCP (Steve Schlaifer x3171 156/224) (12/20/85)
> We are running UNIX 4.2 BSD on a VAX 11/750 and it seems that when we call > one site that is running UNIX 4.1 BSD our modem will not hang up after > the conversation is complete. When calling another 4.2 BSD site we have > no problem. I have tried many types of modems with no luck. > Has anybody ever come across this problem in the pursuit of true UUCP happiness. > Have you checked to see that the other site's modem is set to hang up when the DTR line is dropped? Also make sure that they have the modem port configured HUPCL so that DTR is dropped when the last process closes on that tty line. I suspect the problem is one of the above. On a Hayes 1200 smartmodem, switch 1 determines how DTR is treated (it should be up). Other modems probably have similar switches. A simple test is to call the other site (via cu), log on and then log off. If the switches are set right the phone should hang up. If it doesn't, it is a problem at their end.
walt@rclex.UUCP (Walter L. Weber) (12/20/85)
>> ........... I have tried many types of modems with no luck. > > ...........................If your Data Terminal Ready > line is wired through to the modem, then your modem will hang up. > On the other hand, if you have DTR permanently wired high, then the > problem you report will occur. Many modems have a configuration switch which will tie DTR high, preventing it from hanging up on local disconnect. Hayes Smartmodems and Racal-Vadic VA3450-series both have this feature. -- Walt Weber UUCP: ...harvard!rclex!walt Ridge Computers ARPA: rclex!walt@harvard Lexington, Mass. RidgeNet: wlw@lassen
jc@sdcsvax.UUCP (John Cornelius) (12/20/85)
On the other hand, why should one rely on the remote system hanging up? The L.sys file allows all sorts of peculiar input before establishing a connection but there is no facility for specifying a termination sequence. Since uucico knows that it is done with a connection an originating modem should be able to hang up under control of the L.sys information. Perhaps someone has fixed this oversight? John Cornelius Western Scientific
dave@uwvax.UUCP (Dave Cohrs) (12/21/85)
> > We are running UNIX 4.2 BSD on a VAX 11/750 and it seems that when we call > > one site that is running UNIX 4.1 BSD our modem will not hang up after > > the conversation is complete. I had a problem here that was very similar with a PASSWORD modem. It seem there is a switch that will tie DTR high in the normal case. You have to turn it off. Check a manual on your modem to see if you have such a switch. In a related problem, now that I have done this to my modem (connected to a VAX on a DH), I can't use the thing to call out. I can't force DTR to go high, so the modem is non-available except when someone calls. I'd like the modem to hang up when someone else hangs up, but would like to use the same line to call out (the inout feature in newer uucp's). Anyone with a PASSWORD in a similar configuration that has solved this? If so, could you let me know what you did? -- Dave Cohrs (608) 262-1204 ...!{harvard,ihnp4,seismo,topaz}!uwvax!dave dave@romano.wisc.edu
mats@fortune.UUCP (Mats Wichmann) (12/27/85)
Oh, boy, this is fun. Now I get to flame at cheap modems again.
There was a time when a modem was a device that handled your
phone lines, and an autodialer was a separate device which
connected to one of your available modems and made the call for you.
Then there were personal computers, bringing with them personal
modems. What a bunch of neato folks did to their modems was put
the capability to accept commands typed on your terminal
(or for loons like us, sent by the system software) and use them
to try to establish the connection. What is wrong with this?
Well. modems have the characteristic of only supplying a ready
signal to the outside world when a connection is established.
This is good and proper behavior - you don't want to try to
talk through the modem until there is something on the other
end. But the poor terminal/system can't even send the "transparent"
commands to the modem until it sees this ready signal - like you
can't send out the commands to establish the connection until
the conenction is established (don't they call this Catch-22?).
So what to you do? Well, the modem makers tie the signal permanently
high so they can guarantee the terminal can always talk to the modem's
ROM and make it dial.
Of course, once you have done this, you have broken the modem
as far as auto-answer, becuase your carrier line never changes
state (we just finished fixing it to be permanently on, remember).
Most modems built these days are at least social enough to
give you a switch to select the way this works - either force
the line high (for dialout) or leave it indicating the status
of the connection (for dialin). The first modem I ran into
with this clever mod was a Racal/Vadic which didn't bother
to give you a switch - you had to get inside the mother and
cut a trace on the PC board!!!
Moral of story - if using affordable equipment, make sure it is
affordable enough that you can buy two - one dialin and one dialout.
Otherwise empty your bank account buying a modem with an external
dialer. Sorry, not an elegant solution.
Mats Wichmann
Fortune Systems
{ihnp4,hplabs,dual}!fortune!matssalzman@rdlvax.UUCP (Gumby) (12/29/85)
In article <5821@fortune.UUCP> mats@fortune.UUCP writes: > >Well. modems have the characteristic of only supplying a ready >signal to the outside world when a connection is established. >This is good and proper behavior - you don't want to try to >talk through the modem until there is something on the other >end. But the poor terminal/system can't even send the "transparent" >commands to the modem until it sees this ready signal - like you >can't send out the commands to establish the connection until >the conenction is established (don't they call this Catch-22?). >So what to you do? Well, the modem makers tie the signal permanently >high so they can guarantee the terminal can always talk to the modem's >ROM and make it dial. > Not totally true... You do need to have a ready signal to send commands (DTR is high), and a lot of modems have a switch to tie it high (e.g. Hayes, Pro-modem, USR Password). If you wire the thing correctly (pins 2,3,7,20 - I think that's what we use), you won't have that problem. Pin 20 is the DTR pin and it's supposed to be set high by the host computer. This is done (or should be) when you 'open("/dev/ttyxx", ...)' the modem for dialing out. As soon as you close it, it drops DTR. Also, on modems which are for dial in, I think that if DTR is not always tied high, when the carrier is lost, a hangup signal should get sent to the attached process. At any rate the solution is as follows: 1) Make sure the DTR switch on the modem is set so that DTR is *not* always tied high. 2) The rs-232 cable has pin 20 (DTR) wired from the modem to the machine. 3) Make sure your device drivers are supporting DTR. If not, you're outa luck! -- * Isaac Salzman (Gumby) * Research Development Labs (RDL) * Culver City, California, 90230 * UUCP: ...{ttidca,psivax}!rdlvax!salzman * ARPA: ttidca!rdlvax!salzman@Rand-unix.arpa
roger@celtics.UUCP (Roger Klorese) (12/30/85)
In article <5821@fortune.UUCP> mats@fortune.UUCP (PUT YOUR NAME HERE) writes: >Oh, boy, this is fun. Now I get to flame at cheap modems again. > >Moral of story - if using affordable equipment, make sure it is >affordable enough that you can buy two - one dialin and one dialout. >Otherwise empty your bank account buying a modem with an external >dialer. Sorry, not an elegant solution. > ...or build software that uses "soft carrier"... i.e., I'll pretend there's carrier if you will... -- ... "What were you expecting, rock'n'roll?" Roger B.A. Klorese Celerity Computing, 40 Speen St., Framingham, MA 01701, (617) 872-1772 UUCP: seismo!harvard!bu-cs!celtics!roger ARPA: celtics!roger@bu-cs.ARPA
chad@anasazi.UUCP (Chad R. Larson) (12/31/85)
In article <5821@fortune.UUCP> mats@fortune.UUCP (PUT YOUR NAME HERE) writes: > >Oh, boy, this is fun. Now I get to flame at cheap modems again. ... >Well. modems have the characteristic of only supplying a ready >signal to the outside world when a connection is established. ... >Well, the modem makers tie the signal permanently high so they >can guarantee the terminal can always talk to the modem's >ROM and make it dial. > >Of course, once you have done this, you have broken the modem >as far as auto-answer... The problem is not primarily with the modem manufacturer's use of the Carrier Detect lead (pin 8), but with stupid comm port hardware/software that uses only Carrier Detect to determine the status of a call. Most UNIX systems are guilty of this. An incomming call should be detected with the Ring Indicate lead (pin 22) and answered by asserting Data Terminal Ready (pin 20). Calls should be terminated or aborted by dropping the DTR. None of this has anything to do with whether or not you can send to/receive from the modem's dialer. Permission to send is controlled by Clear to Send (pin 5) and presence of valid receive data is gated by Carrier Detect or (in some cases) Data Set Ready (pin 6). Some of the modem people have tried to help these brain-damaged systems by providing non-standard operation (usually switch selectable). For example, the UDS 212A/D has a switch that determines the state of the CD lead when the terminal/system is talking to the dialer as opposed to a remote system. The simple case is forcing some leads high as mats@fortune.UUCP (PUT YOUR NAME HERE) mentioned. A better solution would be to fix the communications software to make use of the information it has available to it. (No extra charge super-flame follows) While they are at it they can fix UNIX's so no crummy kludges are necessary to get getty et. al. out of the way on ports you would like to use for both originating and recieving UUCP calls. -crl The usual generic disclamers go here.
chris@umcp-cs.UUCP (Chris Torek) (12/31/85)
In article <5821@fortune.UUCP> mats@fortune.UUCP (Mats Wichmann) writes: > ... modems have the characteristic of only supplying a ready > signal to the outside world when a connection is established. > This is good and proper behavior - you don't want to try to > talk through the modem until there is something on the other > end. But the poor terminal/system can't even send the "transparent" > commands to the modem until it sees this ready signal - like you > can't send out the commands to establish the connection until > the conenction is established (don't they call this Catch-22?). > So what to you do? But first, what do others do? > Well, the modem makers tie the signal permanently high so they > can guarantee the terminal can always talk to the modem's ROM > and make it dial. Ah, but that is the wrong solution: > Of course, once you have done this, you have broken the modem > as far as auto-answer, becuase your carrier line never changes > state (we just finished fixing it to be permanently on, remember). The *right* solution is to allow the terminal/system to talk to the modem *before* there is a connection. Of course you only want to do this when you are really dialing out. Dial-out mode to the rescue! See mod.sources for details. 4.3BSD version only, sorry; but at least the changes should be obvious to your local Unix guru, who can then apply them to your system. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
ronc@fai.UUCP (Ronald O. Christian) (01/22/86)
>>[various things about the phone not hanging up after a uucp] > >My guess is that you are relying on the remote system to hang up the phone >when you log out. Your computer ought to be hanging the phone up itself. >When you close the line on your side, your terminal driver >should be turning of Data Terminal Ready. If your Data Terminal Ready >line is wired through to the modem, >then your modem will hang up. On the other hand, if you have DTR >permanently wired high, then the problem you report will occur. **** I can verify this, as we had the same problem until I ripped out the existing 4 wire RS232 cables and put in some 8 wire cables. (Pass pins 2 through 8 and 20.) If you replace the cables, don't forget to reconfigure your modems to look for DTR, or the problem won't go away. -- -- Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.) ihnp4!pesnta!fai!ronc Oliver's law of assumed responsibility: "If you are seen fixing it, you will be blamed for breaking it."