[comp.os.vms] Disallowing logins on Terminal ports

SYSMAN@NMSUVM1.BITNET (05/31/88)

Date: 31 May 88, 15:56:13 GMT
From: Mark Nichols              (505) 646-4183       SYSMAN   at NMSUVM1
To:   INFO-VAX at KL.SRI.COM


We have a problem concerning terminal ports and the NIU's used to
connect to the campus network. Whenever the NIU times out and goes to
the idle state the Vax interprets the response from the NIU as a login
attempt and prompts for a password. The NIU screams back "Invalid Response"
or something like that. The Vax of course kicks back "User Authorization
Failure" to which the NIU responds again with another error message. And
off it goes .... with the Vax and the NIU ping-ponging error messages
messages back and forth and the console spitting out all kinds of access
violation messages.

Is there a way to disable logins on a specific port while still
allowing a user to connect to the port via kermit to go through the
NIU and onto the network? We have tried all sorts of things with the
NIU and it seems doing something from the Vax end is more feasable.


Thanks for _ANY_ help at all.

Mark Nichols
Systems Programmer
New Mexico State University

carl@CITHEX.CALTECH.EDU (Carl J Lydick) (06/04/88)

 > We have a problem concerning terminal ports and the NIU's used to
 > connect to the campus network. Whenever the NIU times out and goes to
 > the idle state the Vax interprets the response from the NIU as a login
 > attempt and prompts for a password. The NIU screams back "Invalid Response"
 > or something like that. The Vax of course kicks back "User Authorization
 > Failure" to which the NIU responds again with another error message. And
 > off it goes .... with the Vax and the NIU ping-ponging error messages
 > messages back and forth and the console spitting out all kinds of access
 > violation messages.
 > 
 > Is there a way to disable logins on a specific port while still
 > allowing a user to connect to the port via kermit to go through the
 > NIU and onto the network? We have tried all sorts of things with the
 > NIU and it seems doing something from the Vax end is more feasable.

You can set the port /NOTYPEAHEAD/PERMANENT.  Then the user can allocate
the port, set it /TYPEAHEAD, and use kermit to connect to the port, etc.

Alternatively, you can set the Initiation Character for the NIU (I assume
you're talking about Ungermann-Bass NIU's) to something non-null (we typically
use control-V here).  Then the user can connect to the port with kermit,
send the initiation character, and then proceed normally.  Doing it this
way, when the NIU goes idle, the VAX will still interpret it as a login
attempt, but since it doesn't send the initiation character as part of the
login prompt, the NIU will ignore it, the login attempt will eventually
time out, and things will remain stable thereafter.

JMS@MIS.ARIZONA.EDU (VAX/VMS---the Unabridged Edition) (06/06/88)

>Mark Nichols              (505) 646-4183       SYSMAN   at NMSUVM1
writes:

>We have a problem concerning terminal ports and the NIU's used to
>connect to the campus network. Whenever the NIU times out and goes to
>the idle state the Vax interprets the response from the NIU as a login
>attempt and prompts for a password. The NIU screams back "Invalid Response"
>or something like that. The Vax of course kicks back "User Authorization
etc.

First my assumption: what you call the "NIU" is some sort of data
PBX system, like the Equinox, IDX3000, Sytek Localnet, etc.  Most campuses
have this.  The function is that people have access to the data PBX,
and get through it to a limited number of ports on VAX systems (or
whatever else is connected).

The problem is that you have either (1) not wired the NIU-to-VAX interface
as a modem connection or (2) not told the VAX that the NIU ports are
modem ports.

Any data PBX must simulate modem lines to VAX/VMS.  This means, preferably,
wiring RI (pin 22), so that the VAX knows when a "call" is coming in and
so that the VAX can raise DTR (pin 20) (assuming that the modem also has
DSR (pin 6) high) and so that the modem can answer the call and bring up
CD (pin 8).  You need at least one modem control line in each direction,
as well as one data line, and a ground.  To make most modems work, it is
correct to wire 2,3,6,7,8,20,22.  Don't wire 1 (that's illegal), and
you can probably do without 4,5 and almost certainly all the rest (well,
the VAX won't look at them anyway).  You may have to fake something up
by jumpering on either end.  This can still be a black art.  

In any case, playing with something like TYPEAHEAD or other strange 
software solution will not work.  The VAX won't pay attention to characters
on modem lines if the proper signals aren't there, and your NIU-thingy
better provide those signals.

jms

+----------------------------+ BITNET: jms@arizmis.BITNET
|Joel M Snyder               | Inter: jms@mis.arizona.edu     
|Univ of Arizona Dep't of MIS| Phone: 602.621.2748   ICBM: 32 13 N / 110 58 W
|Tucson, AZ 85721            | Quote: "Design is everything. 
+----------------------------+         Implementation is trivial."

IMHW400@INDYVAX.BITNET (06/07/88)

I believe that the way we did this for a plotter that caused us similar
annoyances, was to set the line /NOTYPEAHEAD.  This means, of course, that
when a connection has been established there must always be a pending read
in order to avoid losing data, but KERMIT (to use your example) can recover
from the occasional overrun.  Or, your program can toggle the /NOTYPEAHEAD
bit with QIOs.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mark H. Wood    IMHW400@INDYVAX.BITNET   (317)274-0749 III U   U PPPP  U   U III
Indiana University - Purdue University at Indianapolis  I  U   U P   P U   U  I
799 West Michigan Street, ET 1023                       I  U   U PPPP  U   U  I
Indianapolis, IN  46202 USA                             I  U   U P     U   U  I
[@disclaimer@]                                         III  UUU  P      UUU  III

MCGUIRE@GRIN1.BITNET ("The Sysco Kid ", McGuire,Ed) (06/07/88)

------------------------------ Begin Reference -------------------------------
Date: Tue, 31 May 88 16:09:59 gmt
Received: From NDSUVM1(MAILER) by GRIN1 with Jnet id 0590,
          for MCGUIRE@GRIN1; Tue,  7 Jun 88 08:55 CDT,
          by NDSUVM1 (Mailer X1.25) id 0583; Tue, 07 Jun 88 08:53:49 CDT
Reply-to:
INFO-VAXKL.SRI.COM
Sender: "INFO-VAX Discussion" <INFO-VAX@UBVM.BITNET>
Comments: CROSSNET mail via SMTP@INTERBIT
From: SYSMAN%NMSUVM1.BITNET@CUNYVM.CUNY.EDU
Subject: Disallowing logins on Terminal ports
Comments: To: info-vax@kl.sri.com
To:   "Ed McGuire (McGuire,Ed)" <MCGUIRE@GRIN1.Bitnet>

Date: 31 May 88, 15:56:13 GMT
From: Mark Nichols              (505) 646-4183       SYSMAN   at NMSUVM1
To:   INFO-VAX at KL.SRI.COM


We have a problem concerning terminal ports and the NIU's used to
connect to the campus network. Whenever the NIU times out and goes to
the idle state the Vax interprets the response from the NIU as a login
attempt and prompts for a password. The NIU screams back "Invalid Response"
or something like that. The Vax of course kicks back "User Authorization
Failure" to which the NIU responds again with another error message. And
off it goes .... with the Vax and the NIU ping-ponging error messages
messages back and forth and the console spitting out all kinds of access
violation messages.

Is there a way to disable logins on a specific port while still
allowing a user to connect to the port via kermit to go through the
NIU and onto the network? We have tried all sorts of things with the
NIU and it seems doing something from the Vax end is more feasable.


Thanks for _ANY_ help at all.

Mark Nichols
Systems Programmer
New Mexico State University
------------------------------- End Reference --------------------------------

Mark,

It was not clear to me whether your Kermit users are starting on the VAX and
connecting to remote systems (outbound), or whether they are starting on remote
systems such as microcomputers and connecting to the VAX (inbound).

If your Kermit connects are outbound, then you can change the characteristics
of the port with the command SET TERMINAL/NOTYPEAHD/PERMANENT.  That will stop
the looping, because the job controller will no longer check for unsolicited
input on the port and start LOGINOUT.

If your connects are inbound, then you won't want to do that because your users
will be unable to log in.  In that case, one VAX solution is to have an
operator do SET TERMINAL/TYPEAHD/PERMANENT whenever someone wants to connect,
and then SET TERMINAL/NOTYPEAHD/PERMANENT when the connection is broken.  This
is rather inconvenient, of course.

Can you change your communications equipment to do full modem control?  If the
VAX port is set /MODEM/PERMANENT, then the VAX will use RS-232 control signals
as documented in the I/O manual in the section on the terminal driver.  I think
a side effect of this is that the VAX will ignore all incoming data unless it
sees control signals that indicate that a connection is being established.

Ed

SEYMOUR@phast.phys.washington.EDU (06/09/88)

Mark Nichols had a question about disallowing logins by "intelligent"
devices attached to VAX ports.

If he wishes to only reach OUT from the VAX to those ports, he should
SET TERM/notype_ahead
That will prevent the VAX from trying to create a process running
loginout.  DEC claims that it's the only way.

Unfortunately it might also damage KERMIT's use of the line.

To get around that, you could modify KERMIT's code (or maybe it already
does this for you) to set the line to TYPE_AHEAD with a
QIO set characteristics call.

We do this for pdp11's running micropower pascal talking to a microvax.
If he's also trying to allow incoming access to those ports, this
answer will not work.
-- dick seymour    seymour@uwaphast.bitnet

rrk@byuvax.bitnet (06/13/88)

Setting a terminal port to "/NOTYPEAHEAD" may be a "strange software solution",
according to jms in Arizona, but according to the VMS documentation it is the
way to disable logins on a port while maintaining the ability to use the
port to communicate.  Whats more: it works.  Try it.