🚀 go-pugleaf

> 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.

> 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.

> 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.

>> ........... 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

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

> > 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

Well, I have once again been confused by uucp.  After I got a couple
letters with suggestions (thanks!), I went back and tried acucntrl
again.  Lo and behold, it worked.  I mistakenly assumed that things
weren't working when I couldn't get 'tip' to work (I am working with
a 4.3beta system, a US Robotics Password on a DH).  However, dialing
still didn't work.  I seems that the Password isn't completely Hayes
compatable.  When it receives a <CR>, you have to wait a bit before
sending it something else.  I remembered this because I have the same
problem with my Password at home.  Anyway, in 'hys.c', when it sends
the phone number, it sends a "\rATDT" (or "P").  The phone number gets
lost so the dial fails.  I took out the superfluous <CR> and it worked.

-- 
Dave Cohrs
(608) 262-1204
...!{harvard,ihnp4,seismo,topaz}!uwvax!dave
dave@romano.wisc.edu

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!mats

In article <5821@fortune.UUCP>, mats@fortune.UUCP (Mats Wichmann) writes:
> 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.

Maybe the real moral is that if you buy "affordable" system software,
buy two modems.  Sun's uucp and tip support dialin & dialout on the
same port with cheap modems and it works great.  I have a 1-port system
with a Hayes Smartmodem and only have minor trouble with it.

The key is that the driver must support talking to a modem which is not
indicating "carrier detect", but must generate a HUP when carrier drops
(so a line drop won't hang the port).  You set the modem switches so
carrier detect actually reflects carrier on the phone line, but the
driver selectively ignores this indication when dialing out.

Don't complain about the modems -- they work.  Fix your software.
I'll repost the driver fix if enough people haven't seen it.

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

In article <364@l5.uucp> gnu@l5.uucp (John Gilmore) writes:
>
>Maybe the real moral is that if you buy "affordable" system software,
>buy two modems.
> [discussion of how a modified tty driver can talk to a modem
> even though Carrier Detect is still low]
>Don't complain about the modems -- they work.  Fix your software.
>I'll repost the driver fix if enough people haven't seen it.

Indeed, this mechanism works well for supporting dialout.  However, it
is still worth looking carefully at the features of various modems,
with an eye to how you are going to use them.

One difference is in how "chatty" a modem is, and under what
circumstances.  The ideal behaviour is for them to be perfectly silent,
just like a dumb modem, when someone is calling in so getty doesn't get
"CONNECTED" or some other announcement and try to use it as a login
name.  But for dialout, you want the modem to talk back, telling you
that the call succeeded or failed.

Hayes Smartmodems are a pain to use for dialin and dialout, since there
is only one switch that selects whether they are silent or chatty.  If
you want to use it for dialin, you make the modem silent, but then you
get no information when you are making a call.

My other modem experience has been with the VADIC 3450 series, and they
do just what you want - silent answering but verbose calling.

Also, if you want to give people the same modems to use at home as you
put on your computer, you may want them to remember a few phone numbers
so they can be called without typing the number every time.  Many modems
with autodialers have this, but the Hayes loses again here.  (In my mind,
this makes naming the Hayes modem a "smartmodem" rather laughable).

If you do a lot of long-distance dialing, you may want tone dialing; some
modems are pulse-dial only.  Also, some computers can be reached only by
tone dialing, since you have to dial a regular phone number and then dial an
access code to a PBX at the far end.

Some modems adapt to tone or pulse dialing automatically by sending the
first digit as a tone and seeing if it breaks dial tone.  If it doesn't,
they redial the number from the beginning using pulse.  Some telephone
exchanges do not break the dial tone after the first digit, or give you
a second dial tone (particularly if the digit is "9" to get an outside line).
You can't use one of these modems with one of these telephone lines.
Better to have a modem where you can explicitly tell it which parts of
a number are to be tone and pulse, with no guessing on the modem's part.

	Dave Martindale

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

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.

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

In article <481@uwvax.UUCP> dave@uwvax.UUCP (Dave Cohrs) writes:
>...  It seems that the Password isn't completely Hayes
>compatable.  When it receives a <CR>, you have to wait a bit before
>sending it something else.  I remembered this because I have the same
>problem with my Password at home.  Anyway, in 'hys.c', when it sends
>the phone number, it sends a "\rATDT" (or "P").  The phone number gets
>lost so the dial fails.  I took out the superfluous <CR> and it worked.

I guess this is more common than I thought. We couldn't get tip to work
on an Anchor Automation Signalman Mk XII for the same reason. If only
we had source to remove the problem from the software :-).

A couple of notes about this type of problem:
	- uucp dials without the extra <cr> and hence has no trouble
	- the problem doesn't exist on other modems by the same mfg's
		(USR Courier 2400 works just fine, as do the newer
		Signalman modems)

-- 
  OOO   __| ___      Peter Holzmann, Octopus Enterprises
 OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014
  OOOOO \___/        UUCP: {hplabs!hpdsd,pyramid}!octopus!pete
___| \_____          Phone: 408/996-7746

>>[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."