Hi.

I have some weird trouble while connecting to the console
on my DS25 through a terminal server, Lantronix ETS8P. It
is one of these a little older term.servers that still had
the familiar DECserver admin interface.

I connect from Reflection using the IP-address of the
Lantronix and port 3008 (port 8 on the term-server).

The connection to the DS25 console port (COM1) is OK,
everything works just fine, as long as OPA0 was logged in
before I switch cable to the Lantronix.

The problem is when I try a login over this connection.
And it is the same problem to do an initial login if the
console is logged out, or to do a "telnet localhost" while
logged in. Doesn't matter.

What happens is that I get the "Username:" prompt just fine.
I enter the/any username end hits ENTER. Now the "Password:"
prompt displays as expected, but it is just as I had hitted
ENTER again at the Password prompt without entering anything.

I get a "login failure", of course.

I behaves exactly as if one presses ENTER at the Password
prompt without entering anything at all.

It seems as it has something with "echo" to do. I made this
short file ABC.COM :

$ set term /echo
$ inq zzz "xxx"
$ write sys$output zzz
$!
$ set term /noecho
$ inq zzz "yyy"
$ write sys$output zzz
$!
$ set term /echo

When run trough a normal SSH or telnet terminal this
works as expected:

$ @abc
xxx: 111  ( type "111" and press ENTER)
111
yyy:  ( type "222" and press ENTER)
222
$

But when run through the Lantronix/consol I get :

$ @abc
xxx: 111 ( type "111" and press ENTER)
111
yyy:

$

Here I never get the chance to enter anything at the "yyy" prompt.
The terminal just skips over and print an empty string.

There are *no* differencs in SHO TERM between OPA0 and my
other session.

How can "set term /noecho" have this effect ?

Now, this *does* work using PyTTY if I check the box in the config
called "Return key sends Telnet New Line instead of ^M". That option
is checked by default, b.t.w. A telnet "New Line" seems to be a CRLF
sequence. I fail to see how this relates to the problem seen and
I fail to find any similar option in Reflection ("Attachmate
Reflection for UNIX and OpenVMS 14.0").

So a workaround for the time beeing seems to be to use PyTTY for
remote console work, but I'd like to understand better what
is happening here.


Jan-Erik.

On 2012-02-26 01:47, Jan-Erik Soderholm wrote:
> Hi.
>
> I have some weird trouble while connecting to the console
> on my DS25 through a terminal server, Lantronix ETS8P. It
> is one of these a little older term.servers that still had
> the familiar DECserver admin interface.
>
> I connect from Reflection using the IP-address of the
> Lantronix and port 3008 (port 8 on the term-server).
>
> The connection to the DS25 console port (COM1) is OK,
> everything works just fine, as long as OPA0 was logged in
> before I switch cable to the Lantronix.
>
> The problem is when I try a login over this connection.
> And it is the same problem to do an initial login if the
> console is logged out, or to do a "telnet localhost" while
> logged in. Doesn't matter.
>
> What happens is that I get the "Username:" prompt just fine.
> I enter the/any username end hits ENTER. Now the "Password:"
> prompt displays as expected, but it is just as I had hitted
> ENTER again at the Password prompt without entering anything.
>
> I get a "login failure", of course.
>
> I behaves exactly as if one presses ENTER at the Password
> prompt without entering anything at all.
>
> It seems as it has something with "echo" to do. I made this
> short file ABC.COM :
>
> $ set term /echo
> $ inq zzz "xxx"
> $ write sys$output zzz
> $!
> $ set term /noecho
> $ inq zzz "yyy"
> $ write sys$output zzz
> $!
> $ set term /echo
>
> When run trough a normal SSH or telnet terminal this
> works as expected:
>
> $ @abc
> xxx: 111 ( type "111" and press ENTER)
> 111
> yyy: ( type "222" and press ENTER)
> 222
> $
>
> But when run through the Lantronix/consol I get :
>
> $ @abc
> xxx: 111 ( type "111" and press ENTER)
> 111
> yyy:
>
> $
>
> Here I never get the chance to enter anything at the "yyy" prompt.
> The terminal just skips over and print an empty string.
>
> There are *no* differencs in SHO TERM between OPA0 and my
> other session.
>
> How can "set term /noecho" have this effect ?
>
> Now, this *does* work using PyTTY if I check the box in the config
> called "Return key sends Telnet New Line instead of ^M". That option
> is checked by default, b.t.w. A telnet "New Line" seems to be a CRLF
> sequence. I fail to see how this relates to the problem seen and
> I fail to find any similar option in Reflection ("Attachmate
> Reflection for UNIX and OpenVMS 14.0").
>
> So a workaround for the time beeing seems to be to use PyTTY for
> remote console work, but I'd like to understand better what
> is happening here.

Are you really sure that the /NOECHO is the key here? What if you remote 
the SET TERM commands from that command file, and run it again. Will it 
work right or wrong then?

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Johnny Billquist wrote 2012-02-26 10:58:
> On 2012-02-26 01:47, Jan-Erik Soderholm wrote:
>> Hi.
>>
>> I have some weird trouble while connecting to the console
>> on my DS25 through a terminal server, Lantronix ETS8P. It
>> is one of these a little older term.servers that still had
>> the familiar DECserver admin interface.
>>
>> I connect from Reflection using the IP-address of the
>> Lantronix and port 3008 (port 8 on the term-server).
>>
>> The connection to the DS25 console port (COM1) is OK,
>> everything works just fine, as long as OPA0 was logged in
>> before I switch cable to the Lantronix.
>>
>> The problem is when I try a login over this connection.
>> And it is the same problem to do an initial login if the
>> console is logged out, or to do a "telnet localhost" while
>> logged in. Doesn't matter.
>>
>> What happens is that I get the "Username:" prompt just fine.
>> I enter the/any username end hits ENTER. Now the "Password:"
>> prompt displays as expected, but it is just as I had hitted
>> ENTER again at the Password prompt without entering anything.
>>
>> I get a "login failure", of course.
>>
>> I behaves exactly as if one presses ENTER at the Password
>> prompt without entering anything at all.
>>
>> It seems as it has something with "echo" to do. I made this
>> short file ABC.COM :
>>
>> $ set term /echo
>> $ inq zzz "xxx"
>> $ write sys$output zzz
>> $!
>> $ set term /noecho
>> $ inq zzz "yyy"
>> $ write sys$output zzz
>> $!
>> $ set term /echo
>>
>> When run trough a normal SSH or telnet terminal this
>> works as expected:
>>
>> $ @abc
>> xxx: 111 ( type "111" and press ENTER)
>> 111
>> yyy: ( type "222" and press ENTER)
>> 222
>> $
>>
>> But when run through the Lantronix/consol I get :
>>
>> $ @abc
>> xxx: 111 ( type "111" and press ENTER)
>> 111
>> yyy:
>>
>> $
>>
>> Here I never get the chance to enter anything at the "yyy" prompt.
>> The terminal just skips over and print an empty string.
>>
>> There are *no* differencs in SHO TERM between OPA0 and my
>> other session.
>>
>> How can "set term /noecho" have this effect ?
>>
>> Now, this *does* work using PyTTY if I check the box in the config
>> called "Return key sends Telnet New Line instead of ^M". That option
>> is checked by default, b.t.w. A telnet "New Line" seems to be a CRLF
>> sequence. I fail to see how this relates to the problem seen and
>> I fail to find any similar option in Reflection ("Attachmate
>> Reflection for UNIX and OpenVMS 14.0").
>>
>> So a workaround for the time beeing seems to be to use PyTTY for
>> remote console work, but I'd like to understand better what
>> is happening here.
>
> Are you really sure that the /NOECHO is the key here? What if you remote
> the SET TERM commands from that command file, and run it again. Will it
> work right or wrong then?
>
> Johnny
>

Well, if Echo is the "key" or not, I'm not sure. I just
noticed that it did a difference. I'm not sure what
you mean with "remote the SET TERM" command. Wait, it
should be "remove", right?

If i change all set term to "/echo" it works :

$ @abc
xxx: 1
1
yyy: 2
2
$

If I remove all SET TERM commands, it depends on the
current setting of echo/noecho in the session :

$ type abc.com
$ inq zzz "xxx"
$ write sys$output zzz
$!
$ inq zzz "yyy"
$ write sys$output zzz
$!

Having echo on works as usual :

$ set term/echo
$ @abc
xxx: 111
111
yyy: 222
222
$

But having echo off does not :

$ set term/noecho
$
$
$     (typed "@abc" and ENTER here)
xxx:  (This prompt was simply skipped)

yyy:  (typed "222" and ENTER here)
222
$

All the above was using Reflection.
In PyTTY this works (but gives an extra blank line) :

$ set term/noecho
$ @abc
xxx:  (typed "111" and ENTER here)

111
yyy:  (typed "222" and ENTER here)

222
$

But on the other hand, I can not type commands with echo
off and simply pressing ENTER gives weird results (PyTTY) :

$ (only pressed ENTER here)
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
  \
   \
$ (only pressed ENTER here)
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
  \
   \
$ (only pressed ENTER here)
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
  \
   \
$

In Reflection this works "better" but gives en extra line :

$ (only pressed ENTER here)
$
$ (typed "sh time" and pressed ENTER here)
   26-FEB-2012 11:48:30
$
$ (Cursor waits here)

Anyway, the important thing is that I can login over the
terminal server at all, even if not using my prefered
emulator (Reflection).

Nothing of this happens using Reflection over a usual
telnet/SSH connection :

$ set term/echo
$ @abc
xxx: 111
111
yyy: 222
222
$ set term /noecho
$     (typed "@abc" and ENTER here)
xxx:
111
yyy:
222
$     (typed "sh time" and ENTER here)
   26-FEB-2012 11:56:10
$ (Cursor waits here)

And it also works just localy on-site using a serial
cable between a COM port on my laptop to the consol
port (using both PyTTY and Reflection).

It is something with the additional terminalserver
in between, I guess (?).

I also have to disable "Local echo" in PyTTY and Reflection,
if not, I get each character typed dubbled (this is from PyTTY) :

$
$ sshh  ttiimmee
   26-FEB-2012 12:06:59
$
$ @@aabbcc
xxx: 11
1
yyy: 22
2
$

Actualy I have to change both "Local echo" and "Local Line Editing"
from "Auto" to "Force off".

Oh well... :-)

Jan-Erik.

On 2012-02-26 12:11, Jan-Erik Soderholm wrote:
> Johnny Billquist wrote 2012-02-26 10:58:
>> On 2012-02-26 01:47, Jan-Erik Soderholm wrote:
>>> Hi.
>>>
>>> I have some weird trouble while connecting to the console
>>> on my DS25 through a terminal server, Lantronix ETS8P. It
>>> is one of these a little older term.servers that still had
>>> the familiar DECserver admin interface.
>>>
>>> I connect from Reflection using the IP-address of the
>>> Lantronix and port 3008 (port 8 on the term-server).
>>>
>>> The connection to the DS25 console port (COM1) is OK,
>>> everything works just fine, as long as OPA0 was logged in
>>> before I switch cable to the Lantronix.
>>>
>>> The problem is when I try a login over this connection.
>>> And it is the same problem to do an initial login if the
>>> console is logged out, or to do a "telnet localhost" while
>>> logged in. Doesn't matter.
>>>
>>> What happens is that I get the "Username:" prompt just fine.
>>> I enter the/any username end hits ENTER. Now the "Password:"
>>> prompt displays as expected, but it is just as I had hitted
>>> ENTER again at the Password prompt without entering anything.
>>>
>>> I get a "login failure", of course.
>>>
>>> I behaves exactly as if one presses ENTER at the Password
>>> prompt without entering anything at all.
>>>
>>> It seems as it has something with "echo" to do. I made this
>>> short file ABC.COM :
>>>
>>> $ set term /echo
>>> $ inq zzz "xxx"
>>> $ write sys$output zzz
>>> $!
>>> $ set term /noecho
>>> $ inq zzz "yyy"
>>> $ write sys$output zzz
>>> $!
>>> $ set term /echo
>>>
>>> When run trough a normal SSH or telnet terminal this
>>> works as expected:
>>>
>>> $ @abc
>>> xxx: 111 ( type "111" and press ENTER)
>>> 111
>>> yyy: ( type "222" and press ENTER)
>>> 222
>>> $
>>>
>>> But when run through the Lantronix/consol I get :
>>>
>>> $ @abc
>>> xxx: 111 ( type "111" and press ENTER)
>>> 111
>>> yyy:
>>>
>>> $
>>>
>>> Here I never get the chance to enter anything at the "yyy" prompt.
>>> The terminal just skips over and print an empty string.
>>>
>>> There are *no* differencs in SHO TERM between OPA0 and my
>>> other session.
>>>
>>> How can "set term /noecho" have this effect ?
>>>
>>> Now, this *does* work using PyTTY if I check the box in the config
>>> called "Return key sends Telnet New Line instead of ^M". That option
>>> is checked by default, b.t.w. A telnet "New Line" seems to be a CRLF
>>> sequence. I fail to see how this relates to the problem seen and
>>> I fail to find any similar option in Reflection ("Attachmate
>>> Reflection for UNIX and OpenVMS 14.0").
>>>
>>> So a workaround for the time beeing seems to be to use PyTTY for
>>> remote console work, but I'd like to understand better what
>>> is happening here.
>>
>> Are you really sure that the /NOECHO is the key here? What if you remote
>> the SET TERM commands from that command file, and run it again. Will it
>> work right or wrong then?
>>
>> Johnny
>>
>
> Well, if Echo is the "key" or not, I'm not sure. I just
> noticed that it did a difference. I'm not sure what
> you mean with "remote the SET TERM" command. Wait, it
> should be "remove", right?

Right. Sorry for the misspelling. :-)

> If i change all set term to "/echo" it works :
>
> $ @abc
> xxx: 1
> 1
> yyy: 2
> 2
> $
>
> If I remove all SET TERM commands, it depends on the
> current setting of echo/noecho in the session :
>
> $ type abc.com
> $ inq zzz "xxx"
> $ write sys$output zzz
> $!
> $ inq zzz "yyy"
> $ write sys$output zzz
> $!
>
> Having echo on works as usual :
>
> $ set term/echo
> $ @abc
> xxx: 111
> 111
> yyy: 222
> 222
> $
>
> But having echo off does not :
>
> $ set term/noecho
> $
> $
> $ (typed "@abc" and ENTER here)
> xxx: (This prompt was simply skipped)
>
> yyy: (typed "222" and ENTER here)
> 222
> $
>
> All the above was using Reflection.
> In PyTTY this works (but gives an extra blank line) :
>
> $ set term/noecho
> $ @abc
> xxx: (typed "111" and ENTER here)
>
> 111
> yyy: (typed "222" and ENTER here)
>
> 222
> $
>
> But on the other hand, I can not type commands with echo
> off and simply pressing ENTER gives weird results (PyTTY) :
>
> $ (only pressed ENTER here)
> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
> \
> \
> $ (only pressed ENTER here)
> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
> \
> \
> $ (only pressed ENTER here)
> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
> \
> \
> $
>
> In Reflection this works "better" but gives en extra line :
>
> $ (only pressed ENTER here)
> $
> $ (typed "sh time" and pressed ENTER here)
> 26-FEB-2012 11:48:30
> $
> $ (Cursor waits here)
>
> Anyway, the important thing is that I can login over the
> terminal server at all, even if not using my prefered
> emulator (Reflection).
>
> Nothing of this happens using Reflection over a usual
> telnet/SSH connection :
>
> $ set term/echo
> $ @abc
> xxx: 111
> 111
> yyy: 222
> 222
> $ set term /noecho
> $ (typed "@abc" and ENTER here)
> xxx:
> 111
> yyy:
> 222
> $ (typed "sh time" and ENTER here)
> 26-FEB-2012 11:56:10
> $ (Cursor waits here)
>
> And it also works just localy on-site using a serial
> cable between a COM port on my laptop to the consol
> port (using both PyTTY and Reflection).
>
> It is something with the additional terminalserver
> in between, I guess (?).
>
> I also have to disable "Local echo" in PyTTY and Reflection,
> if not, I get each character typed dubbled (this is from PyTTY) :
>
> $
> $ sshh ttiimmee
> 26-FEB-2012 12:06:59
> $
> $ @@aabbcc
> xxx: 11
> 1
> yyy: 22
> 2
> $
>
> Actualy I have to change both "Local echo" and "Local Line Editing"
> from "Auto" to "Force off".
>
> Oh well... :-)

Good.

Much more reasonable than the first assertion.

There are several thing playing in here. I'll try to sort through them 
all one by one.

Local echo: this should always be off. It is a case of your terminal 
emulator itself echoing what you are typing. You do not want this. The 
remote operating system (VMS) are designed with terminals that do not 
echo in mind. If you have local echo, your system cannot ask for 
passwords and similar things that do not show on the terminal when you 
type them. The normal behavior of VMS is that VMS will echo whatever you 
type, if echo is in order.

Local line editing is something in your terminal emulator that I do not 
know for sure what it might be. I would expect it to not be very 
important in this case, but forcing it off will not hurt.

SET TERM/...   Whenever you do this, you will flush the input buffer. 
The flushing is important to know about and understand.

Telnet connections... The last, but very important piece. When you press 
the enter key (or Return, or whatever it is labelled) in your terminal 
emulator, a bunch of different things can be sent to the remote system 
depending on what the telnet session have negotiated. It can be CR, LF, 
CR+LF, or Telnet newline. The remote end should hopefully have the same 
idea as the local end does, otherwise things will become even more 
confusing.

So, what is happening? VMS expects any line sent to it to be terminated 
by a single CR. If you send CR+LF, VMS will actually consider the LF to 
be a second line termination. Under some circumstances, you are flushing 
that LF that is in the input buffer. If you send the telnet newline 
sequence, it might be translated to CR, LF or CR+LF before being passed 
on to VMS. Also, depending on telnet handling, there might be NULs 
inserted in the stream as well.

I hope this allows you to understand why you sometimes do not stop at 
the second prompt, but instead pass right on (you got two line 
terminations in the input stream), as well as the illegal command at DCL 
(also two line termination, but a NUL in between, which DCL tries to 
parse). Also why you sometimes get an extra blank line (the LF is 
actually included as a part of the input string, and not terminated upon).

There are so many variations on what can happen. You've seen a bunch 
now. :-)

What you need to do is to get the telnet setting right, so that a simple 
CR arrives at VMS when you press the enter key, and then you'll be happy.
How you achieve that, however, is beyond what I can answer. It depends 
on your terminal program. It might be that it is buggy enough that it is 
not possible to get right. I dislike most terminal emulators because 
they do not implement thing correctly, and the author only tested them 
against some forgiving (and perhaps buggy) telnet server.

One common problem, though, is that if you run telnet in 8-bit clean 
mode, I've noticed that the VMS telnet server often do not negotiate any 
other parts of the telnet protocol, so you'll get funny results on 
newline. Just a suggestion...

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Johnny Billquist wrote 2012-02-26 13:46:
> On 2012-02-26 12:11, Jan-Erik Soderholm wrote:
>> Johnny Billquist wrote 2012-02-26 10:58:
>>> On 2012-02-26 01:47, Jan-Erik Soderholm wrote:
>>>> Hi.
>>>>
>>>> I have some weird trouble while connecting to the console
>>>> on my DS25 through a terminal server, Lantronix ETS8P. It
>>>> is one of these a little older term.servers that still had
>>>> the familiar DECserver admin interface.
>>>>
>>>> I connect from Reflection using the IP-address of the
>>>> Lantronix and port 3008 (port 8 on the term-server).
>>>>
>>>> The connection to the DS25 console port (COM1) is OK,
>>>> everything works just fine, as long as OPA0 was logged in
>>>> before I switch cable to the Lantronix.
>>>>
>>>> The problem is when I try a login over this connection.
>>>> And it is the same problem to do an initial login if the
>>>> console is logged out, or to do a "telnet localhost" while
>>>> logged in. Doesn't matter.
>>>>
>>>> What happens is that I get the "Username:" prompt just fine.
>>>> I enter the/any username end hits ENTER. Now the "Password:"
>>>> prompt displays as expected, but it is just as I had hitted
>>>> ENTER again at the Password prompt without entering anything.
>>>>
>>>> I get a "login failure", of course.
>>>>
>>>> I behaves exactly as if one presses ENTER at the Password
>>>> prompt without entering anything at all.
>>>>
>>>> It seems as it has something with "echo" to do. I made this
>>>> short file ABC.COM :
>>>>
>>>> $ set term /echo
>>>> $ inq zzz "xxx"
>>>> $ write sys$output zzz
>>>> $!
>>>> $ set term /noecho
>>>> $ inq zzz "yyy"
>>>> $ write sys$output zzz
>>>> $!
>>>> $ set term /echo
>>>>
>>>> When run trough a normal SSH or telnet terminal this
>>>> works as expected:
>>>>
>>>> $ @abc
>>>> xxx: 111 ( type "111" and press ENTER)
>>>> 111
>>>> yyy: ( type "222" and press ENTER)
>>>> 222
>>>> $
>>>>
>>>> But when run through the Lantronix/consol I get :
>>>>
>>>> $ @abc
>>>> xxx: 111 ( type "111" and press ENTER)
>>>> 111
>>>> yyy:
>>>>
>>>> $
>>>>
>>>> Here I never get the chance to enter anything at the "yyy" prompt.
>>>> The terminal just skips over and print an empty string.
>>>>
>>>> There are *no* differencs in SHO TERM between OPA0 and my
>>>> other session.
>>>>
>>>> How can "set term /noecho" have this effect ?
>>>>
>>>> Now, this *does* work using PyTTY if I check the box in the config
>>>> called "Return key sends Telnet New Line instead of ^M". That option
>>>> is checked by default, b.t.w. A telnet "New Line" seems to be a CRLF
>>>> sequence. I fail to see how this relates to the problem seen and
>>>> I fail to find any similar option in Reflection ("Attachmate
>>>> Reflection for UNIX and OpenVMS 14.0").
>>>>
>>>> So a workaround for the time beeing seems to be to use PyTTY for
>>>> remote console work, but I'd like to understand better what
>>>> is happening here.
>>>
>>> Are you really sure that the /NOECHO is the key here? What if you remote
>>> the SET TERM commands from that command file, and run it again. Will it
>>> work right or wrong then?
>>>
>>> Johnny
>>>
>>
>> Well, if Echo is the "key" or not, I'm not sure. I just
>> noticed that it did a difference. I'm not sure what
>> you mean with "remote the SET TERM" command. Wait, it
>> should be "remove", right?
>
> Right. Sorry for the misspelling. :-)
>
>> If i change all set term to "/echo" it works :
>>
>> $ @abc
>> xxx: 1
>> 1
>> yyy: 2
>> 2
>> $
>>
>> If I remove all SET TERM commands, it depends on the
>> current setting of echo/noecho in the session :
>>
>> $ type abc.com
>> $ inq zzz "xxx"
>> $ write sys$output zzz
>> $!
>> $ inq zzz "yyy"
>> $ write sys$output zzz
>> $!
>>
>> Having echo on works as usual :
>>
>> $ set term/echo
>> $ @abc
>> xxx: 111
>> 111
>> yyy: 222
>> 222
>> $
>>
>> But having echo off does not :
>>
>> $ set term/noecho
>> $
>> $
>> $ (typed "@abc" and ENTER here)
>> xxx: (This prompt was simply skipped)
>>
>> yyy: (typed "222" and ENTER here)
>> 222
>> $
>>
>> All the above was using Reflection.
>> In PyTTY this works (but gives an extra blank line) :
>>
>> $ set term/noecho
>> $ @abc
>> xxx: (typed "111" and ENTER here)
>>
>> 111
>> yyy: (typed "222" and ENTER here)
>>
>> 222
>> $
>>
>> But on the other hand, I can not type commands with echo
>> off and simply pressing ENTER gives weird results (PyTTY) :
>>
>> $ (only pressed ENTER here)
>> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
>> \
>> \
>> $ (only pressed ENTER here)
>> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
>> \
>> \
>> $ (only pressed ENTER here)
>> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
>> \
>> \
>> $
>>
>> In Reflection this works "better" but gives en extra line :
>>
>> $ (only pressed ENTER here)
>> $
>> $ (typed "sh time" and pressed ENTER here)
>> 26-FEB-2012 11:48:30
>> $
>> $ (Cursor waits here)
>>
>> Anyway, the important thing is that I can login over the
>> terminal server at all, even if not using my prefered
>> emulator (Reflection).
>>
>> Nothing of this happens using Reflection over a usual
>> telnet/SSH connection :
>>
>> $ set term/echo
>> $ @abc
>> xxx: 111
>> 111
>> yyy: 222
>> 222
>> $ set term /noecho
>> $ (typed "@abc" and ENTER here)
>> xxx:
>> 111
>> yyy:
>> 222
>> $ (typed "sh time" and ENTER here)
>> 26-FEB-2012 11:56:10
>> $ (Cursor waits here)
>>
>> And it also works just localy on-site using a serial
>> cable between a COM port on my laptop to the consol
>> port (using both PyTTY and Reflection).
>>
>> It is something with the additional terminalserver
>> in between, I guess (?).
>>
>> I also have to disable "Local echo" in PyTTY and Reflection,
>> if not, I get each character typed dubbled (this is from PyTTY) :
>>
>> $
>> $ sshh ttiimmee
>> 26-FEB-2012 12:06:59
>> $
>> $ @@aabbcc
>> xxx: 11
>> 1
>> yyy: 22
>> 2
>> $
>>
>> Actualy I have to change both "Local echo" and "Local Line Editing"
>> from "Auto" to "Force off".
>>
>> Oh well... :-)
>
> Good.
>
> Much more reasonable than the first assertion.
>
> There are several thing playing in here. I'll try to sort through them all
> one by one.
>
> Local echo: this should always be off. It is a case of your terminal
> emulator itself echoing what you are typing. You do not want this. The
> remote operating system (VMS) are designed with terminals that do not echo
> in mind. If you have local echo, your system cannot ask for passwords and
> similar things that do not show on the terminal when you type them. The
> normal behavior of VMS is that VMS will echo whatever you type, if echo is
> in order.
>
> Local line editing is something in your terminal emulator that I do not
> know for sure what it might be. I would expect it to not be very important
> in this case, but forcing it off will not hurt.
>
> SET TERM/... Whenever you do this, you will flush the input buffer. The
> flushing is important to know about and understand.
>
> Telnet connections... The last, but very important piece. When you press
> the enter key (or Return, or whatever it is labelled) in your terminal
> emulator, a bunch of different things can be sent to the remote system
> depending on what the telnet session have negotiated. It can be CR, LF,
> CR+LF, or Telnet newline. The remote end should hopefully have the same
> idea as the local end does, otherwise things will become even more confusing.
>
> So, what is happening? VMS expects any line sent to it to be terminated by
> a single CR. If you send CR+LF, VMS will actually consider the LF to be a
> second line termination. Under some circumstances, you are flushing that LF
> that is in the input buffer. If you send the telnet newline sequence, it
> might be translated to CR, LF or CR+LF before being passed on to VMS. Also,
> depending on telnet handling, there might be NULs inserted in the stream as
> well.
>
> I hope this allows you to understand why you sometimes do not stop at the
> second prompt, but instead pass right on (you got two line terminations in
> the input stream), as well as the illegal command at DCL (also two line
> termination, but a NUL in between, which DCL tries to parse). Also why you
> sometimes get an extra blank line (the LF is actually included as a part of
> the input string, and not terminated upon).
>
> There are so many variations on what can happen. You've seen a bunch now. :-)
>
> What you need to do is to get the telnet setting right, so that a simple CR
> arrives at VMS when you press the enter key, and then you'll be happy.
> How you achieve that, however, is beyond what I can answer. It depends on
> your terminal program. It might be that it is buggy enough that it is not
> possible to get right. I dislike most terminal emulators because they do
> not implement thing correctly, and the author only tested them against some
> forgiving (and perhaps buggy) telnet server.
>
> One common problem, though, is that if you run telnet in 8-bit clean mode,
> I've noticed that the VMS telnet server often do not negotiate any other
> parts of the telnet protocol, so you'll get funny results on newline. Just
> a suggestion...
>
> Johnny
>

Thanks !

 > > Local echo: this should always be off.

The default is "Auto". There is some kind of negotiation between
the emulator and the telnetserver. He, just found that PyTTY
has a "Event log" where the negotiation can be seen.

A normalt telnet session against VMS looks like :

2012-02-26 13:51:16	Looking up host "192.168.1.10"
2012-02-26 13:51:16	Connecting to 192.168.1.10 port 23
2012-02-26 13:51:16	client:	WILL NAWS
2012-02-26 13:51:16	client:	WILL TSPEED
2012-02-26 13:51:16	client:	WILL TTYPE
2012-02-26 13:51:16	client:	WILL NEW_ENVIRON
2012-02-26 13:51:16	client:	DO ECHO
2012-02-26 13:51:16	client:	WILL SGA
2012-02-26 13:51:16	client:	DO SGA
2012-02-26 13:51:16	server:	WILL ECHO  <<<===  !!
2012-02-26 13:51:16	server:	WILL SGA
2012-02-26 13:51:19	server:	DO NAWS
2012-02-26 13:51:19	client:	SB NAWS 80,24
2012-02-26 13:51:19	server:	DONT TSPEED
2012-02-26 13:51:19	server:	DO TTYPE
2012-02-26 13:51:19	server:	SB TTYPE SEND
2012-02-26 13:51:19	client:	SB TTYPE IS XTERM
2012-02-26 13:51:19	server:	DONT NEW_ENVIRON
2012-02-26 13:51:19	client:	WILL OLD_ENVIRON
2012-02-26 13:51:19	server:	SB TTYPE SEND
2012-02-26 13:51:19	client:	SB TTYPE IS XTERM
2012-02-26 13:51:19	server:	DONT OLD_ENVIRON

I guess the "server: WILL ECHO" line will make PuTTY
shut off local echo (if set to "Auto")...

A session against port 3008 on the Lantronix :

2012-02-26 13:56:55	Looking up host "192.168.1.15"
2012-02-26 13:56:55	Connecting to 192.168.1.15 port 3008
2012-02-26 13:56:55	client:	WILL NAWS
2012-02-26 13:56:55	client:	WILL TSPEED
2012-02-26 13:56:55	client:	WILL TTYPE
2012-02-26 13:56:55	client:	WILL NEW_ENVIRON
2012-02-26 13:56:55	client:	DO ECHO
2012-02-26 13:56:55	client:	WILL SGA
2012-02-26 13:56:55	client:	DO SGA

That is all. Note the lack of any "server:" entries at all.
So any "Auto" setting in PuTTY will have trouble.

A session against the standard (port 23) telnet admin port
on the Lantronix, otoh, gives a similar log as against
the VMS host above with both client and server entries.


 > Local line editing is something in your terminal emulator
 > that I do not know for sure what it might be.

It seems that when "on" PuTTY doesn't send anything until
the line is terminated and the whole line is sent/shown at
once. When "off" each character typed is sent and echoed
back from VMS at once.


Jan-Erik.

On 26.02.2012 14:22, Jan-Erik Soderholm wrote:

> A session against port 3008 on the Lantronix :
>
> 2012-02-26 13:56:55 Looking up host "192.168.1.15"
> 2012-02-26 13:56:55 Connecting to 192.168.1.15 port 3008
> 2012-02-26 13:56:55 client: WILL NAWS
> 2012-02-26 13:56:55 client: WILL TSPEED
> 2012-02-26 13:56:55 client: WILL TTYPE
> 2012-02-26 13:56:55 client: WILL NEW_ENVIRON
> 2012-02-26 13:56:55 client: DO ECHO
> 2012-02-26 13:56:55 client: WILL SGA
> 2012-02-26 13:56:55 client: DO SGA
>
> That is all. Note the lack of any "server:" entries at all.
> So any "Auto" setting in PuTTY will have trouble.
>
> A session against the standard (port 23) telnet admin port
> on the Lantronix, otoh, gives a similar log as against
> the VMS host above with both client and server entries.

Did you also try port 2008? There is a distinction between port
2008 and 3008 - one of them is a "raw tcp socket" connection,
the other is more like a "telnet" connection, with all fancy
telnet protocol things. Maybe you'd better choose 2008 here,
but I don't know, it's been too long since I used the Lantronix
terminal servers. BTW, both use physical port 8, of course.

There are also maybe port settings that can change the behavior
of the outgoing telnet session, particularly concerning CR/LF
etc., which may be important, as Johnny Billquist wrote.

Last point: we used to set up services on the Lantronix servers
to connect to remote console ports, but I don't know if this was
only for convenience, or if it gave us better connections. And
then we also used another trick: with a given service that uses
port 8 for an outgoing connection, we used a telnet connection
to the standard terminal server console (port 23), and then we
used "c console1 e p" (connect console1 environment passall),
where 'console1' is the service name. This way you can use
direct XON/XOFF flow control between your terminal emulation
and the target console port and use other control characters
like CTRL/P that would otherwise be used by the Lantronix
server for session control.

Albrecht

Albrecht Schlosser wrote 2012-02-28 15:59:
> On 26.02.2012 14:22, Jan-Erik Soderholm wrote:
>
>> A session against port 3008 on the Lantronix :
>>
>> 2012-02-26 13:56:55 Looking up host "192.168.1.15"
>> 2012-02-26 13:56:55 Connecting to 192.168.1.15 port 3008
>> 2012-02-26 13:56:55 client: WILL NAWS
>> 2012-02-26 13:56:55 client: WILL TSPEED
>> 2012-02-26 13:56:55 client: WILL TTYPE
>> 2012-02-26 13:56:55 client: WILL NEW_ENVIRON
>> 2012-02-26 13:56:55 client: DO ECHO
>> 2012-02-26 13:56:55 client: WILL SGA
>> 2012-02-26 13:56:55 client: DO SGA
>>
>> That is all. Note the lack of any "server:" entries at all.
>> So any "Auto" setting in PuTTY will have trouble.
>>
>> A session against the standard (port 23) telnet admin port
>> on the Lantronix, otoh, gives a similar log as against
>> the VMS host above with both client and server entries.
>
> Did you also try port 2008? There is a distinction between port
> 2008 and 3008 - one of them is a "raw tcp socket" connection,
> the other is more like a "telnet" connection, with all fancy
> telnet protocol things. Maybe you'd better choose 2008 here,
> but I don't know, it's been too long since I used the Lantronix
> terminal servers. BTW, both use physical port 8, of course.
>
> There are also maybe port settings that can change the behavior
> of the outgoing telnet session, particularly concerning CR/LF
> etc., which may be important, as Johnny Billquist wrote.
>
> Last point: we used to set up services on the Lantronix servers
> to connect to remote console ports, but I don't know if this was
> only for convenience, or if it gave us better connections. And
> then we also used another trick: with a given service that uses
> port 8 for an outgoing connection, we used a telnet connection
> to the standard terminal server console (port 23), and then we
> used "c console1 e p" (connect console1 environment passall),
> where 'console1' is the service name. This way you can use
> direct XON/XOFF flow control between your terminal emulation
> and the target console port and use other control characters
> like CTRL/P that would otherwise be used by the Lantronix
> server for session control.
>
> Albrecht

Interesting !
I have never heard about the 200x port range. :-)

Connecting to 2008 gave this handshake :

2012-02-28 16:08:08	Connecting to 192.168.1.15 port 2008
2012-02-28 16:08:08	client:	WILL NAWS
2012-02-28 16:08:08	client:	WILL TSPEED
2012-02-28 16:08:08	client:	WILL TTYPE
2012-02-28 16:08:08	client:	WILL NEW_ENVIRON
2012-02-28 16:08:08	client:	DO ECHO
2012-02-28 16:08:08	client:	WILL SGA
2012-02-28 16:08:08	client:	DO SGA
2012-02-28 16:08:08	server:	WILL ECHO
2012-02-28 16:08:08	server:	WILL SGA
2012-02-28 16:08:08	server:	DO TTYPE

By using port 2008 instead of 3008 I can now leave both
"Local echo" and "Local line editing" in their default
"Auto" setting.

And now that I know, I have also located the following
part in the ETSP reference manual :

 > Note: The 30nn range of ports is 8-bit clean. If Telnet
 > IAC interpretation is needed, form a connection to the
 > 20nn range of ports.

When we create application TNA ports for our background
processes (reading barcode scanners, PLCs and other equipment)
we have alsways used the 300x ports. And on newer term.servers
(like the wire-less Lantronix WiBox 2-port server) we use
1000x. I have no idea if there is an alternate port range
on those servers.

Thanks for the tip about the 200x range!

Jan-Erik.

Albrecht Schlosser <vms-news@go4more.de> wrote:

(snip)
> Did you also try port 2008? There is a distinction between port
> 2008 and 3008 - one of them is a "raw tcp socket" connection,
> the other is more like a "telnet" connection, with all fancy
> telnet protocol things. Maybe you'd better choose 2008 here,
> but I don't know, it's been too long since I used the Lantronix
> terminal servers. BTW, both use physical port 8, of course.

I have some serial port print servers that I use for the console
port on my VMS machines, until I get TCP/IP running.

There are some effects, presumably related to this, that make
it confusing. 

-- glen

On Tue, 28 Feb 2012 16:23:38 +0100, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> wrote:


>By using port 2008 instead of 3008 I can now leave both
>"Local echo" and "Local line editing" in their default
>"Auto" setting.
>
>And now that I know, I have also located the following
>part in the ETSP reference manual :
>
> > Note: The 30nn range of ports is 8-bit clean. If Telnet
> > IAC interpretation is needed, form a connection to the
> > 20nn range of ports.
>
>When we create application TNA ports for our background
>processes (reading barcode scanners, PLCs and other equipment)
>we have alsways used the 300x ports. And on newer term.servers
>(like the wire-less Lantronix WiBox 2-port server) we use
>1000x. I have no idea if there is an alternate port range
>on those servers.
>
>Thanks for the tip about the 200x range!
>
>Jan-Erik.

and since you mentioned that this was a DS25,
it may have a RMC card installed (i think all the DS25's did ..)

I recall that line-ending protocol was different when talking to 
the RMC itself (versus VMS, or SRM).  But by now, you'll recognize the symptoms.

Another place I could recall line-endings being an issue, 
was when using a MOP-client (TSM, or linux moprc) to talk to a DECserver. 

The line-ending conflicts get really annoying if you get locked out 
of a system for bad-password retries, before recognizing the issue. 

Joe Bloggs wrote 2012-03-01 06:56:
> On Tue, 28 Feb 2012 16:23:38 +0100, Jan-Erik Soderholm<jan-erik.soderholm@telia.com>  wrote:
>
>
>> By using port 2008 instead of 3008 I can now leave both
>> "Local echo" and "Local line editing" in their default
>> "Auto" setting.
>>
>> And now that I know, I have also located the following
>> part in the ETSP reference manual :
>>
>>> Note: The 30nn range of ports is 8-bit clean. If Telnet
>>> IAC interpretation is needed, form a connection to the
>>> 20nn range of ports.
>>
>> When we create application TNA ports for our background
>> processes (reading barcode scanners, PLCs and other equipment)
>> we have alsways used the 300x ports. And on newer term.servers
>> (like the wire-less Lantronix WiBox 2-port server) we use
>> 1000x. I have no idea if there is an alternate port range
>> on those servers.
>>
>> Thanks for the tip about the 200x range!
>>
>> Jan-Erik.
>
> and since you mentioned that this was a DS25,
> it may have a RMC card installed (i think all the DS25's did ..)
>

Yes, with a flat battery and "corrupt flash". :-)
I moved a jumper (I think it was J65) to disable RMC,
I don't need it for this system.




> I recall that line-ending protocol was different when talking to
> the RMC itself (versus VMS, or SRM).  But by now, you'll recognize the symptoms.
>
> Another place I could recall line-endings being an issue,
> was when using a MOP-client (TSM, or linux moprc) to talk to a DECserver.
>
> The line-ending conflicts get really annoying if you get locked out
> of a system for bad-password retries, before recognizing the issue.
>
>
>
>
>
>
>
>
>
>