From: HENRY::IN%"cetron%ced%cs.utah.edu%kl.sri.com%csnet-relay.CSNET%relay.cs.net@RCA.COM" 3-JUN-1987 03:46 To: STEINBERGER@KL.SRI.COM, info-vax@KL.SRI.COM Subj: Re: DTR on DHV11 boards 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%relay.cs.net@RCA.COM 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 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