12 Dec
2016
12 Dec
'16
1:04 p.m.
Hi folks,
I don't know if this is the best place to ask this question, but I don't
know of any better forums for PDP-10 discussion, so hopefully it's
on-topic enough.
I recently set up the KLH10 PDP-10 emulator on my network, running
TOPS-20 7.1. It's on a box in my 192.168.1.0/24 network. TCP/IP works
great, I can telnet to it from within my network without any issue.
I also set up my firewall (a box running CentOS 7.1) to port forward
from external TCP port 2320 to internal TCP port 23 on
the KLH10 box.
Interestingly, when I telnet from _outside_ the network to my firewall's
port 2320, it works, but Telnet goes into line mode rather than
character mode! I can fix it with telnet escape (^]) by setting
character mode explicitly with "mode character", but that's kind of
annoying to do each time I connect.
It feels like Telnet is no longer doing line mode / character mode
negotiation when I'm port forwarding. It's most mysterious.
If you want to see for yourself, you can telnet to
gatekeeper.retronet.net 2320, which is the KLH10 instance.
Does this ring any bells for anyone?
-Seth
--
Seth Morabito
seth at loomcom.com
13 Dec
13 Dec
1:10 a.m.
On Mon, Dec 12, 2016 at 11:04 AM, Seth Morabito
<lists+cctalk at loomcom.com> wrote:
Hi folks,
I don't know if this is the best place to ask this question, but I don't
know of any better forums for PDP-10 discussion, so hopefully it's
on-topic enough.
I recently set up the KLH10 PDP-10 emulator on my network, running
TOPS-20 7.1. It's on a box in my 192.168.1.0/24 network. TCP/IP works
great, I can telnet to it from within my network without any issue.
I also set up my firewall (a box running CentOS 7.1) to port forward
from external TCP port 2320 to internal TCP port 23 on the KLH10 box.
Interestingly, when I telnet from _outside_ the network to my firewall's
port 2320, it works, but Telnet goes into line mode rather than
character mode! I can fix it with telnet escape (^]) by setting
character mode explicitly with "mode character", but that's kind of
annoying to do each time I connect.
It feels like Telnet is no longer doing line mode / character mode
negotiation when I'm port forwarding. It's most mysterious.
If you want to see for yourself, you can telnet to
gatekeeper.retronet.net 2320, which is the KLH10 instance.
Does this ring any bells for anyone?
I'm guessing that this is the classic "Many telnet clients default to
line mode for only for port 23." issue.
Warner
1:15 a.m.
On Mon, Dec 12, 2016 at 11:10 PM, Warner Losh <imp at bsdimp.com> wrote:
On Mon, Dec 12, 2016 at 11:04 AM, Seth Morabito
<lists+cctalk at loomcom.com> wrote:
For a recent telnet in FreeBSD, I had to do a 'mode linemode' before
it would behave like you are describing. Connect, hit return, hit the
escape character (traditional one is ^]). mode linemode <return>. then
I saw local echo and things looked approximately like I'd expect.
Warner
Hi folks,
I don't know if this is the best place to ask this question, but I don't
know of any better forums for PDP-10 discussion, so hopefully it's
on-topic enough.
I recently set up the KLH10 PDP-10 emulator on my network, running
TOPS-20 7.1. It's on a box in my 192.168.1.0/24 network. TCP/IP works
great, I can telnet to it from within my network without any issue.
I also set up my firewall (a box running CentOS 7.1) to port forward
from external TCP port 2320 to internal TCP port 23 on the KLH10 box.
Interestingly, when I telnet from _outside_ the network to my firewall's
port 2320, it works, but Telnet goes into line mode rather than
character mode! I can fix it with telnet escape (^]) by setting
character mode explicitly with "mode character", but that's kind of
annoying to do each time I connect.
It feels like Telnet is no longer doing line mode / character mode
negotiation when I'm port forwarding. It's most mysterious.
If you want to see for yourself, you can telnet to
gatekeeper.retronet.net 2320, which is the KLH10 instance.
Does this ring any bells for anyone?
I'm guessing that this is the classic "Many telnet clients default to
line mode for only for port 23." issue. 
7:02 a.m.
On Mon, 12 Dec 2016 23:10:57 -0700, Warner Losh wrote:
On Mon, Dec 12, 2016 at 11:04 AM, Seth Morabito
<lists+cctalk at loomcom.com> wrote:
I've tried connecting using the Multinet telnet client under VMS. It seems to
work fine. However, this telnet client does not seem to have a way to manually
set line mode versus character mode so I don't seem to have a way of simulating
the problem to ensure that I am not seeing it.
Typing a question mark on it's own without pressing return results in a list
of commands being displayed so I think I am in character mode and this is the
expected behaviour.
I would agree with what Warner said regarding many telnet clients, except
maybe he meant they default to line mode for ports other than port 23. You
could test the theory by temporarily port forwarding external port 23 to the
emulator. Bear in mind that you will probably get lots of botnets trying to
break in on that port while you are testing.
Another possibility is that if the firewall is trying to be clever, it might
be intercepting the telnet negotiations instead of just doing straightforward
port forwarding. I used to come across a lot of commercial firewall products
generally sticking their nose in where it wasn't wanted and making a mess (of
SMTP for example) but it doesn't sound like you are using one of those devices.
Regards,
Peter Coghlan
Hi folks,
I don't know if this is the best place to ask this question, but I don't
know of any better forums for PDP-10 discussion, so hopefully it's
on-topic enough.
I recently set up the KLH10 PDP-10 emulator on my network, running
TOPS-20 7.1. It's on a box in my 192.168.1.0/24 network. TCP/IP works
great, I can telnet to it from within my network without any issue.
I also set up my firewall (a box running CentOS 7.1) to port forward
from external TCP port 2320 to internal TCP port 23 on the KLH10 box.
Interestingly, when I telnet from _outside_ the network to my firewall's
port 2320, it works, but Telnet goes into line mode rather than
character mode! I can fix it with telnet escape (^]) by setting
character mode explicitly with "mode character", but that's kind of
annoying to do each time I connect.
It feels like Telnet is no longer doing line mode / character mode
negotiation when I'm port forwarding. It's most mysterious.
If you want to see for yourself, you can telnet to
gatekeeper.retronet.net 2320, which is the KLH10 instance.
Does this ring any bells for anyone?
I'm guessing that this is the classic "Many telnet clients default to
line mode for only for port 23." issue.
Warner 
10:52 a.m.
Interestingly, when I telnet from _outside_ the
network to my
firewall's port 2320, it works, but Telnet goes into line mode rather
than character mode!
Probably, as I think someone said, telnet noticing it's not using the
standard telnet port and not even trying to go character-at-a-time.
I did a telnet myself, snooping the network traffic, and...
me -> you SYN
you -> me SYN|ACK
me -> you ACK
you -> me data: IAC WILL ECHO
me -> you data: IAC DO ECHO
you -> me data: \r\n DECTEN, PANDA TOPS-20...
Nowhere, in particular, is there any attempt at LINEMODE negotiation.
And, when I type ?, nothing is sent until I press RETURN, upon which my
end sends ?\r\n.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
11:56 a.m.
Interestingly, when I telnet from _outside_ the
network to my
firewall's port 2320, it works, but Telnet goes into line mode rather
than character mode!
Probably, as I think someone said, telnet noticing it's not using the
standard telnet port and not even trying to go character-at-a-time.
I did a telnet myself, snooping the network traffic, and...
me -> you SYN
you -> me SYN|ACK
me -> you ACK
you -> me data: IAC WILL ECHO
me -> you data: IAC DO ECHO
you -> me data: \r\n DECTEN, PANDA TOPS-20...
Nowhere, in particular, is there any attempt at LINEMODE negotiation.
And, when I type ?, nothing is sent until I press RETURN, upon which my
end sends ?\r\n.
2:08 p.m.
It's the SGA (suppress go-ahead) negotiation that's necessary to avoid line
mode.
Many telnet clients don't try to negotiate any telnet options if you
connect to a non-standard port, because they assume that you're talking to
something other than a telnet server, and that you therefore want an 8-bit
transparent connection with local line editing. Examples would be to telnet
to an SMTP server, FTP server, etc. for testing purposes.
A telnet client that has that behavior but no provision for overriding it
is defective, and should either be fixed, if possible, or deleted with
prejudice.
3:01 p.m.
It's the SGA (suppress go-ahead) negotiation that's necessary to avoid line
mode.
Many telnet clients don't try to negotiate any telnet options if you
connect to a non-standard port, because they assume that you're talking to
something other than a telnet server, and that you therefore want an 8-bit
transparent connection with local line editing. Examples would be to telnet
to an SMTP server, FTP server, etc. for testing purposes.
A telnet client that has that behavior but no provision for overriding it
is defective, and should either be fixed, if possible, or deleted with
prejudice.
My telnet client works just fine for testing SMTP servers etc. I suspect
that it only decides to issue the SGA on ports other than the standard telnet
port when the server at the other end has already revealed that it is a telnet
server by sending out some telnet negotiation from it's side.
(I do recall a customer once insisting to me that I would not be able to use
a telnet client to connect to his SMTP server to test it because the two
aren't compatible or something. At the time, it was something I did every
day of the week but there was no convincing him.)
Regards,
Peter Coghlan.
2850
days inactive
2851
days old
7 comments
5 participants
participants (5)
-
cctalk＠beyondthepale.ie -
imp＠bsdimp.com -
lists+cctalk＠loomcom.com -
mouse＠Rodents-Montreal.ORG -
spacewar＠gmail.com