STEINBERGER@KL.SRI.COM.UUCP (05/29/87)
I've recently hooked up a modem (Microcom, 9600 baud) to a port of a DHV11 board on a uVAX II. The DTR indicator light on the modem stays on for 5 - 10 secs then goes off briefly (a few seconds) then comes back on and the cycle repeats. Apparently the modem won't answer incoming calls when the DTR signal is absent. Has anyone else noticed this? Does this reflect the way DEC designed the driver for that board? It would be nice, I think, to have the DTR signal not oscillate. Is there an appropriate software setting to change this, or some other software fix? I think the DTR should be asserted until the connection is broken (by logging off), then the VAX toggle the DTR line to tell the modem to hangup. Any suggestions or similar experiences? Thanks to all who respond. -Ric Steinberger steinberger@kl.sri.com -------
cetron%ced@CS.UTAH.EDU.UUCP (05/29/87)
ok, here goes what I consider the definitive answer and vms modem
control (or at least until v5. shows up)
Path: utah-cs!ut-sally!husc6!mit-eddie!rutgers!lll-crg!ames!ucbcad!ucbvax!UTAH-CS.ARPA!cetron%utah-ced
From: cetron%utah-ced@UTAH-CS.ARPA (Ed Cetron)
Newsgroups: mod.computers.vax
Subject: modem control on dhv-11's
Message-ID: <8612052214.AA01929@utah-ced.ARPA>
Date: 5 Dec 86 22:14:21 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 85
Approved: info-vax@sri-kl.arpa
I received the following request:
From: K. Sankara Rao
<NU043109%NDSUVM1.BITNET@WISCVM.WISC.EDU>
Subject: Microvax and modem interconnect problems
Dear Ed:
We here, in Electrical Engg. Department of North Dakota
State University have a MicroVAXII running under VMS 4.4. There is
a Gandolf PACX network in the University and we want to connect the
MicroVax to it with full modem control. THe port controllers are DHV-11.
That is where the trouble started.
When the port is set as a MODEM: as soon as somebody
comes on to the line, in exactly 30 seconds time, the system logs
him off with an error SYSTEM - E - HANGUP massage. What seems to be
happening is this. For some reason, DTR from the line is dropped for
a short duration (We cannot see it happening with leds) and as a
consequence, the PACX swith drops (again for a short duration)
either DSR or Carrier signal and the system senses a line hangup
and logs the terminal off. Have you ever heard of any such problems
before and can you suggest a solution?
At present we are using the uVAX on the PACX seeting
the ports as NOMODEM and we do not have any modem control (like
the process being deleted if the line drops, i.e, a user forgetting
to logout before switching the line off) and this is not a 'safe'
solution.
Thanks in advance.
Rao
Department of EEE
NDSU, Fargo, ND 58105
Tel : (701)237-7217
no problem, I've read the dhv-11 manual....it says:
dhv-11 will assert RTS and DTR all of the time when /modem
then the modem should raise RI
then pause
then raise DSR indicating phone line connection established
the raise DCD when carrier is established
then raise CTS when ready to transmit/receive
so I wrote back:
I thought the answer was the following:
vax brings up dtr and rts
modem brings up dsr (and maybe ring if needed)
pause by modem to establish carrier
modem brings up carrier detect AND CTS
vax no allows you to speak to/from it just fine
if you don't login completely within 30 seconds (or whatever you have set in
sysgen), vax will lower dtr for 4 seconds, then lower rts also, then
raise them both after 1-2 seconds...
empirical data:
our one system with an able mux master works just fine now when we brin
g up cts with cd. but would do exactly what you describe except the error was
file read error when we didn't raise cts...
-ed cetron
BUT!!!!!
before i sent this, I tried to verify this on my real dhv-11.... I set the
line /modem/hangup/dialup/disconnect/perm, forced my breakout box (pretending
it was the modem) to hold cd, cts, and dsr low. I then connected a terminal
to tx and rd and tried it. IT WORKED!!! but its not supposed to....no till
I raise cd, cts and dsr....I am sooooo..... confused......
Did I set something wrong????, is the dhv-11 brain-damaged???
and I thought I understood the way dec handled modem control.....Before I
start reading the fiche, does anyone understand what is happening????
-ed cetron
(sorry for the length)
s
-----------------------------
and then
-----------------------------
From cetron Mon Dec 8 12:37:34 1986
Received: by utah-ced.ARPA (5.31/4.40.2)
id AA02511; Mon, 8 Dec 86 12:37:30 MST
Date: Mon, 8 Dec 86 12:37:30 MST
From: cetron (Ed Cetron)
Message-Id: <8612081937.AA02511@utah-ced.ARPA>
To: CETRON@UTAH-CED.UTAH-CS, NU043109%NDSUVM1.BITNET@WISCVM.WISC.EDU
Subject: Re: Microvax and modem interconnect problems
Cc: cetron, info-vax@sri-kl.arpa
Status: R
well, I have spent the last 3 hours hacking around with the modem signals on
the dhv11 as well as two hours deciphering the modem state tables within the
vms ttdriver source code.
I think that I have the situation down now and I will pass along the results of
my explorations:
First the empirical results:
(remember, the situation is a terminal connected to a breakout box and then to
the dhv-11, only gnd, td and rd are passed by the breakout box. All other
signals can be set/reset via the breakout box....)
1. if dsr, dcd, and cts low: you can log in, and work with NO troubles. In
this case vms does not know that you are on a modem line.....there is NO
cts flow control (obviously since cts is low).
2. if dsr goes active (high) and stays, cts,dcd low: you can log in but within
30 seconds the system prints:
%RMS-F-RER, file read error
-SYSTEM-F-HANGUP, dataset hang-up
then it lowers dtr for 4 seconds (while it logs you off), then lowers
rts also for an additional 2 seconds, then brings them both high.
3. if dsr goes active, followed by dcd, cts held low: same result as 2 above.
4. dsr up, then dcd up, the cts up: normal login, stays logged in and
everything is fine....this is supposed "standard" modem protocol.
5. if logged in via 4. and cts then goes low: all output is suspended, input
is not, and when cts goes high, all output is resumed. THIS IMPLIES THAT VMS
CAN DO PROPER (though one-way) RTS-CTS FLOW CONTROL!!!!!!!
6. if logged in via 4., and then dsr goes low: immediate logoff and error
sequence as in 2.
7. if logged in via 4., and the dcd goes low: nothing for 2 seconds and then
if dcd still low, logoff and errors as in 2.
conclusions:
VMS will allow you to log in regardless of the state of the modem
signals. This means input and output are always enabled on all modem lines
in the 'idle' state. To obtain proper modem control response [which includes
things like suspending output when cts goes low, dropping the line if dsr goes
low or carrier lost] one must cycle dsr. If dsr is NOT cycled, you can still
login and have a valid session, but you will appear as if you are NOT A MODEM.
Results from the microfiche:
All of the above situations are born out by the modem control state tables..
apparently, the table is linear in such a manner that you cannot jump into a
later state without starting from the bottom...
here is a quick form of the state table: (limited to dhv/dhu transitions)
state: off (no modem, stay forever)
state: idle (just set to /modem, or second stage of shutdown)
lower dtr and rts
wait for 2 seconds
go to wait state
state: wait (normal 'idle' modem state but input and output are
still enabled...)
set dtr and rts high
wait for modem line transition
if modem transition AND dsr is active, go to init1 state (note that
this is why dsr must go active to indicate a modem protocoled
line... if dsr isn't active, all other modem transitions such
as dcd going active, do nothing)
state: init1 (simple delay)
wait 1 second and then go to init2 state
state: init2 (start timer and wait for cts and carrier)
make sure dtr and rts are high (if not already)
wait 30 seconds...
if timer expires goto shutdown state
if modem transition AND dsr AND dcd AND cts are active, goto trasmit0
else continue waiting
state: transmit0 (signal connect and allow the login...)
indicate to vms remote login, and indicate in the ucb cts is high,
and resume output (if cts low stopped)
wait 30 seconds
if modem transition AND dsr low, go to shutdown state
if modem transition AND dcd low, goto transmit1 state
if timer has expired (waited 30 seconds) got to transmit state
state: transmit (all hunky-dory, do cts flow control)
if modem transition AND dsr low, go to shutdown state
if modem transition AND dcd low, goto transmit1 state
if modem transition AND cts low, goto ctslow state
state: transmit1 (loss of carrier)
wait 2 seconds
if timer expires, goto shutdown
if modem transition AND dsr has also gone low, goto shutdown state
if modem transition AND dcd has gone high again, goto transmit state
state: shutdown (start shutdown)
set timer to 1 second
lower dtr and indicate to vms to hangup this process/line
if timer expires goto shut1 state
state: shut1 (complete shutdown and clear the line)
set timer for 2 seconds
if transition to /nomodem, goto off state
if timer expires, goto idle state
if modem transition AND dsr goes low, goto idle state
state: ctslow (flow control with low cts)
if modem transition and AND cts high, goto transmit state
if modem transition AND dsr low, go to shutdown state
if modem transition AND dcd low, goto transmit1 state
conclusions:
the code should somehow check for 'illegal' states such as dsr low
dcd and/or cts high. Whether it should reset such lines, or jump in the middle
is up for discussion, but it should at least recognize them. I also think that
the output and input should be disable until one reaches one of the various
transmit states...... While I can read their code, I simply can't second
guess what the developers had in mind what they intended this code to do...
But I can see how this code has many 'states' that the vms terminal driver
simply can't handle and therefore simply ignores....
The big question is whether or not this type of functionality can be
construed (or exploited) as a security risk......
And the big answer is: if your modem does not raise dsr, dcd and cts,
then jumper them all together to whichever signal it does raise....
-ed cetron
center for engineering design
univ of utah
-------------------------------
good luck...
ed