I want to telnet from my rpi (buster) to another computer as a
'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my lxterminal for rpi use. Suggestions? --Steve
I want to telnet from my rpi (buster) to another computer as a 'VT100'
(or similar, vt102 etc) terminal. I don't want to mess up my lxterminal
for rpi use. Suggestions?
--Steve
Try kermit. ckermit and gkermit are available as Raspian packages.
I want to telnet from my rpi (buster) to another computer as a 'VT100'
(or similar, vt102 etc) terminal. I don't want to mess up my
lxterminal for rpi use. Suggestions?
Martin Gregorie <martin@mydomain.invalid> wrote:
Try kermit. ckermit and gkermit are available as Raspian packages.
I saw this:
The communication program C-Kermit (sometimes just called kermit)
doesn't do terminal emulation for Linux (in 2006). But Kermit can
emulate many terminals in its non-free MS Windows versions so you`ll see
lots of claims that Kermit can do terminal emulation. With Linux, it's
merely a semi-transparent pipe between whatever terminal you are on and
the remote site you are connected to. Thus if you use kermit on a Linux
PC the terminal type will be "Linux".
on https://tldp.org/HOWTO/Text-Terminal-HOWTO-10.html
I want to telnet from my rpi (buster) to another computer as a 'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my lxterminal for rpi use. Suggestions?
--Steve
"nelso...@gmail.com" <nelsonse48@gmail.com> writes:
I want to telnet from my rpi (buster) to another computer as a 'VT100'
(or similar, vt102 etc) terminal. I don't want to mess up my
lxterminal for rpi use. Suggestions?
Isn’t xterm a superset of vt100? I’m not sure why you think you need to do anything special.
Dana Thu, 29 Jul 2021 12:12:24 -0700 (PDT), nelso...@gmail.com <nelsonse48@gmail.com> napis'o:
I want to telnet from my rpi (buster) to another computer as a 'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my lxterminal for rpi use. Suggestions?
--Steve
Just type
telnet other.machine.ip
you have to enable telnetd on other machine.
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
Nikolaj Lazic wrote on 30-07-2021 at 01:26:
Dana Thu, 29 Jul 2021 12:12:24 -0700 (PDT), nelso...@gmail.com <nelsonse48@gmail.com> napis'o:
I want to telnet from my rpi (buster) to another computer as a 'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my lxterminal for rpi use. Suggestions?
--Steve
Just type
telnet other.machine.ip
you have to enable telnetd on other machine.
Yeah, I'm not sure we understand OP's problem, seems nothing is needed
to just go ahead and do it. (I found telnet in my path on latest RaspiOS
but I don't remember if I manually installed it.) Unless it *has* to be
a certain, specific terminal emulation.
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
Nikolaj Lazic wrote on 30-07-2021 at 01:26:
Dana Thu, 29 Jul 2021 12:12:24 -0700 (PDT), nelso...@gmail.com
<nelsonse48@gmail.com> napis'o:
I want to telnet from my rpi (buster) to another computer as a
'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my
lxterminal for rpi use. Suggestions?
--Steve
Just type
telnet other.machine.ip
you have to enable telnetd on other machine.
Yeah, I'm not sure we understand OP's problem, seems nothing is needed
to just go ahead and do it. (I found telnet in my path on latest RaspiOS
but I don't remember if I manually installed it.) Unless it *has* to be
a certain, specific terminal emulation.
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
Dana Fri, 30 Jul 2021 12:58:27 +0200, A. Dumas <alexandre@dumas.fr.invalid> napis'o:
Nikolaj Lazic wrote on 30-07-2021 at 01:26:for rpi use. Suggestions?
Dana Thu, 29 Jul 2021 12:12:24 -0700 (PDT), nelso...@gmail.com <nelsonse48@gmail.com> napis'o:
I want to telnet from my rpi (buster) to another computer as a 'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my lxterminal
--Steve
Just type
telnet other.machine.ip
you have to enable telnetd on other machine.
Yeah, I'm not sure we understand OP's problem, seems nothing is needed
to just go ahead and do it. (I found telnet in my path on latest RaspiOS but I don't remember if I manually installed it.) Unless it *has* to be
a certain, specific terminal emulation.
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
He wrote "from my rpi to another computer"... surely local.
So... nothing is needed except telnet.
Dana Fri, 30 Jul 2021 12:58:27 +0200, A. Dumas <alexandre@dumas.fr.invalid> napis'o:
Nikolaj Lazic wrote on 30-07-2021 at 01:26:
Dana Thu, 29 Jul 2021 12:12:24 -0700 (PDT), nelso...@gmail.com <nelsonse48@gmail.com> napis'o:
I want to telnet from my rpi (buster) to another computer as a 'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my lxterminal for rpi use. Suggestions?
--Steve
Just type
telnet other.machine.ip
you have to enable telnetd on other machine.
Yeah, I'm not sure we understand OP's problem, seems nothing is needed
to just go ahead and do it. (I found telnet in my path on latest RaspiOS
but I don't remember if I manually installed it.) Unless it *has* to be
a certain, specific terminal emulation.
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
He wrote "from my rpi to another computer"... surely local.
So... nothing is needed except telnet.
On 30/07/2021 11:58, A. Dumas wrote:
Nikolaj Lazic wrote on 30-07-2021 at 01:26:
Dana Thu, 29 Jul 2021 12:12:24 -0700 (PDT), nelso...@gmail.com
<nelsonse48@gmail.com> napis'o:
I want to telnet from my rpi (buster) to another computer as a
'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my >>> lxterminal for rpi use. Suggestions?
--Steve
Just type
telnet other.machine.ip
you have to enable telnetd on other machine.
Yeah, I'm not sure we understand OP's problem, seems nothing is needed
to just go ahead and do it. (I found telnet in my path on latest RaspiOS but I don't remember if I manually installed it.) Unless it *has* to be
a certain, specific terminal emulation.
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
Yes. I did install a telnet demon on a machine a few years back. But
frankly who uses it today - I even use ssh between machines on the same network behind a firewall
Pretty sure sshd is enabled by default on a Raspian pi. I don't recall actually enabling it on mine.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 30/07/2021 11:58, A. Dumas wrote:It's installed but not enabled, you either have to start it from the
Nikolaj Lazic wrote on 30-07-2021 at 01:26:
Dana Thu, 29 Jul 2021 12:12:24 -0700 (PDT), nelso...@gmail.com
<nelsonse48@gmail.com> napis'o:
I want to telnet from my rpi (buster) to another computer as a
'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my >>>>> lxterminal for rpi use. Suggestions?
--Steve
Just type
telnet other.machine.ip
you have to enable telnetd on other machine.
Yeah, I'm not sure we understand OP's problem, seems nothing is needed
to just go ahead and do it. (I found telnet in my path on latest RaspiOS >>> but I don't remember if I manually installed it.) Unless it *has* to be
a certain, specific terminal emulation.
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
Yes. I did install a telnet demon on a machine a few years back. But
frankly who uses it today - I even use ssh between machines on the same
network behind a firewall
Pretty sure sshd is enabled by default on a Raspian pi. I don't recall
actually enabling it on mine.
GUI or as follows (copied from raspberrypi.org):-
For headless setup, SSH can be enabled by placing a file named ssh,
without any extension, onto the boot partition of the SD card from
another computer. When the Pi boots, it looks for the ssh file. If it
is found, SSH is enabled and the file is deleted. The content of the
file does not matter; it could contain text, or nothing at all.
On 30/07/2021 11:58, A. Dumas wrote:
Nikolaj Lazic wrote on 30-07-2021 at 01:26:
Dana Thu, 29 Jul 2021 12:12:24 -0700 (PDT), nelso...@gmail.com
<nelsonse48@gmail.com> napis'o:
I want to telnet from my rpi (buster) to another computer as a
'VT100' (or similar, vt102 etc) terminal. I don't want to mess up
my lxterminal for rpi use. Suggestions?
--Steve
Just type
telnet other.machine.ip
you have to enable telnetd on other machine.
Yeah, I'm not sure we understand OP's problem, seems nothing is needed
to just go ahead and do it. (I found telnet in my path on latest
RaspiOS but I don't remember if I manually installed it.) Unless it
*has* to be a certain, specific terminal emulation.
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
Yes. I did install a telnet demon on a machine a few years back. But
frankly who uses it today - I even use ssh between machines on the same network behind a firewall
Pretty sure sshd is enabled by default on a Raspian pi. I don't recall actually enabling it on mine.
The only thing I use telnet for is to extract stats from my router that
snmp cant reach.
I want to telnet from my rpi (buster) to another computer as a 'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my lxterminal for rpi use. Suggestions?
--Steve
On 29.7.21 22.12, nelso...@gmail.com wrote:
I want to telnet from my rpi (buster) to another computer as a 'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my lxterminal for rpi use. Suggestions?
--Steve
It seems that a Telnet client is not in the standard install
of Raspbian (Raspi OS). You can install it:
sudo apt install telnet
After installation, just start it from the terminal:
telnet tar_get_machine_ip_or_name
For connecting to another computer, you do not need
the Telnet server (daemon).
On 30/07/2021 13:59, The Natural Philosopher wrote:
On 30/07/2021 11:58, A. Dumas wrote:
Nikolaj Lazic wrote on 30-07-2021 at 01:26:
Dana Thu, 29 Jul 2021 12:12:24 -0700 (PDT), nelso...@gmail.com
<nelsonse48@gmail.com> napis'o:
I want to telnet from my rpi (buster) to another computer as a
'VT100' (or similar, vt102 etc) terminal. I don't want to mess up
my lxterminal for rpi use. Suggestions?
--Steve
Just type
telnet other.machine.ip
you have to enable telnetd on other machine.
Yeah, I'm not sure we understand OP's problem, seems nothing is needed
to just go ahead and do it. (I found telnet in my path on latest
RaspiOS but I don't remember if I manually installed it.) Unless it
*has* to be a certain, specific terminal emulation.
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
Yes. I did install a telnet demon on a machine a few years back. But
frankly who uses it today - I even use ssh between machines on the same
network behind a firewall
Pretty sure sshd is enabled by default on a Raspian pi. I don't recall
actually enabling it on mine.
Nope. After your write the Raspbian image to the SSD, you have to save
an empty file named ssh to the root folder of the SD card. I did it
wrong, which is always a good aide-memorie.
I did that two years ago. About a month or two ago, I changed a couple
of rpis to Ubuntu Server (still not sure if that was a good idea, bad
idea or irrelevant). I have no idea how that SSH works on that, but it
does, so I guess I got it right :-).
Dana Fri, 30 Jul 2021 17:40:38 +0300, Tauno Voipio <tauno.voipio@notused.fi.invalid> napis'o:
On 29.7.21 22.12, nelso...@gmail.com wrote:
I want to telnet from my rpi (buster) to another computer as a 'VT100' (or similar, vt102 etc) terminal. I don't want to mess up my lxterminal for rpi use. Suggestions?
--Steve
It seems that a Telnet client is not in the standard install
of Raspbian (Raspi OS). You can install it:
sudo apt install telnet
After installation, just start it from the terminal:
telnet tar_get_machine_ip_or_name
For connecting to another computer, you do not need
the Telnet server (daemon).
He needs telnet daemon on OTHER machine.
On 30/07/2021 16:30, Nikolaj Lazic wrote:
Dana Fri, 30 Jul 2021 17:40:38 +0300, Tauno VoipioBut you need a telnet client on Raspbian. Which apparently is doesn't have.
<tauno.voipio@notused.fi.invalid> napis'o:
On 29.7.21 22.12, nelso...@gmail.com wrote:
I want to telnet from my rpi (buster) to another computer as a
'VT100' (or similar, vt102 etc) terminal. I don't want to mess up
my lxterminal for rpi use. Suggestions?
--Steve
It seems that a Telnet client is not in the standard install
of Raspbian (Raspi OS). You can install it:
sudo apt install telnet
After installation, just start it from the terminal:
telnet tar_get_machine_ip_or_name
For connecting to another computer, you do not need
the Telnet server (daemon).
He needs telnet daemon on OTHER machine.
FWIW, further to my other post in the thread, the arm64 version of
Ubuntu Server does have it installed by default :-).
On Fri, 30 Jul 2021 12:58:27 +0200
"A. Dumas" <alexandre@dumas.fr.invalid> wrote:
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
Even on a private network, unless you trust everyone using it *and*
are sure that there are no compromised systems on it.
Yeah, I'm not sure we understand OP's problem, seems nothing is needed
to just go ahead and do it. (I found telnet in my path on latest RaspiOS
but I don't remember if I manually installed it.) Unless it *has* to be
a certain, specific terminal emulation.
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
On 30.7.21 19.07, Chris Elvidge wrote:
On 30/07/2021 04:44 pm, Pancho wrote:
On 30/07/2021 16:30, Nikolaj Lazic wrote:
Dana Fri, 30 Jul 2021 17:40:38 +0300, Tauno VoipioBut you need a telnet client on Raspbian. Which apparently is doesn't
<tauno.voipio@notused.fi.invalid> napis'o:
On 29.7.21 22.12, nelso...@gmail.com wrote:
I want to telnet from my rpi (buster) to another computer as a
'VT100' (or similar, vt102 etc) terminal. I don't want to mess up >>>>>> my lxterminal for rpi use. Suggestions?
--Steve
It seems that a Telnet client is not in the standard install
of Raspbian (Raspi OS). You can install it:
sudo apt install telnet
After installation, just start it from the terminal:
telnet tar_get_machine_ip_or_name
For connecting to another computer, you do not need
the Telnet server (daemon).
He needs telnet daemon on OTHER machine.
have.
FWIW, further to my other post in the thread, the arm64 version of
Ubuntu Server does have it installed by default :-).
nc (ncat or netcat) can do telnet
and is installed in RaspianOS
Not quite. Please get the basic Telnet RFC (RFC854) and have a look at
the Telnet control functions definitions.
On 30/07/2021 04:44 pm, Pancho wrote:
On 30/07/2021 16:30, Nikolaj Lazic wrote:
Dana Fri, 30 Jul 2021 17:40:38 +0300, Tauno VoipioBut you need a telnet client on Raspbian. Which apparently is doesn't
<tauno.voipio@notused.fi.invalid> napis'o:
On 29.7.21 22.12, nelso...@gmail.com wrote:
I want to telnet from my rpi (buster) to another computer as a
'VT100' (or similar, vt102 etc) terminal. I don't want to mess up
my lxterminal for rpi use. Suggestions?
--Steve
It seems that a Telnet client is not in the standard install
of Raspbian (Raspi OS). You can install it:
sudo apt install telnet
After installation, just start it from the terminal:
telnet tar_get_machine_ip_or_name
For connecting to another computer, you do not need
the Telnet server (daemon).
He needs telnet daemon on OTHER machine.
have.
FWIW, further to my other post in the thread, the arm64 version of
Ubuntu Server does have it installed by default :-).
nc (ncat or netcat) can do telnet
and is installed in RaspianOS
Not quite. Please get the basic Telnet RFC (RFC854) and have a look at the Telnet control functions definitions.
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On Fri, 30 Jul 2021 12:58:27 +0200
"A. Dumas" <alexandre@dumas.fr.invalid> wrote:
Of course, if this is via a public network in any way, then always use
ssh instead of telnet.
Even on a private network, unless you trust everyone using it *and*
are sure that there are no compromised systems on it.
Yeah OK. I'm the only one on my private network (as far as I know....) and
I never had a compromised system (except Chinese and American hardware....) but I always use ssh anyway.
On Fri, 30 Jul 2021 21:47:28 +0100, The Natural Philosopher wrote:
Frankly I used to use telnet, but all distros now favour ssh as aThe retro-computing crowd.
default, and at current network and CPU speeds the encryption doesn't
adversely affect performance, so who needs telnet?
Frankly I used to use telnet, but all distros now favour ssh as a
default, and at current network and CPU speeds the encryption doesn't adversely affect performance, so who needs telnet?
Hmm towel.blinkenlights.nl appears to be down so yes telnet is
running out of uses.
On Fri, 30 Jul 2021 21:47:28 +0100, The Natural Philosopher wrote:
Frankly I used to use telnet, but all distros now favour ssh as aThe retro-computing crowd.
default, and at current network and CPU speeds the encryption doesn't
adversely affect performance, so who needs telnet?
In comp.sys.raspberry-pi, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
Hmm towel.blinkenlights.nl appears to be down so yes telnet is
running out of uses.
Worked for me just now. (IPv6 address.)
In comp.sys.raspberry-pi, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
Hmm towel.blinkenlights.nl appears to be down so yes telnet is
running out of uses.
Worked for me just now. (IPv6 address.)
Does anyone have that "video" as a file instead of streaming from there?
Thanks for all the responses. Telnet on my rpi is installed and working. a telnet daemon (telnetd) is running and working on my "other" machine. I can telnet 192.168.0.169 and connect. However, the "other" machine is expecting a vt100 typeterminal. The raspberrypi is NOT acting like one. So I can see text but cursor linefeeds etc are not working. The last line of output is usually over written by the "other" machine prompt. A true vt100 works however. I need to get lxterm or whatever
The "other" machine is an Apple //e running A2OSX. No ssh there! It only supports unencrypted telnet :-) and cifsd only works with guest-only SMB1 servers. Again the rpi fails to make the cut. Windows works but I don't do windows.
--Steve
On 30/07/2021 17:21, A. Dumas wrote:
Ahem A Rivet's Shot <steveo@eircom.net> wrote:Frankly I used to use telnet, but all distros now favour ssh as a
On Fri, 30 Jul 2021 12:58:27 +0200
"A. Dumas" <alexandre@dumas.fr.invalid> wrote:
Of course, if this is via a public network in any way, then always use >>>> ssh instead of telnet.
Even on a private network, unless you trust everyone using it *and* >>> are sure that there are no compromised systems on it.
Yeah OK. I'm the only one on my private network (as far as I know....)
and
I never had a compromised system (except Chinese and American
hardware....)
but I always use ssh anyway.
default, and at current network and CPU speeds the encryption doesn't adversely affect performance, so who needs telnet?
On 30/07/2021 21:50, Martin Gregorie wrote:
On Fri, 30 Jul 2021 21:47:28 +0100, The Natural Philosopher wrote:They can look back in nostalgia. I was there. fuck that for a game of soldiers.
Frankly I used to use telnet, but all distros now favour ssh as aThe retro-computing crowd.
default, and at current network and CPU speeds the encryption doesn't
adversely affect performance, so who needs telnet?
[1] Redundant these days I know - when was the last time you saw a
monochrome monitor.
Finally getting a DEC VT100 or, better, a Wyse 140 terminal was wonderful!
TERM$ is xterm-256colors. How do I temporarily set term=vt100 for a telnet session?
On Sat, 31 Jul 2021 19:26:09 +0100, Ahem A Rivet's Shot wrote:
[1] Redundant these days I know - when was the last time you saw aI still own one: actually a 12" green screen TV monitor attached to a
monochrome monitor.
memory mapped 24x80 display on a self-assembled 6809 box - the first
computer I owned. Needs some TLC but should run again given that
treatment.
nelso...@gmail.com <nelsonse48@gmail.com> wrote:
TERM$ is xterm-256colors. How do I temporarily set term=vt100 for a
telnet session?
$ TERM=vt100 telnet theserver
But! I saw this at https://tldp.org/HOWTO/Text-Terminal-HOWTO-10.html
Some have erroneously thought that they could create an emulator at a
Linux console (monitor) by setting the environment variable TERM to the
type of terminal they would like to emulate. This does not work. The
value of TERM only tells an application program what terminal you are
using. This way it doesn't need to interactively ask you this question
(and it's too dumb to be able to probe the terminal to find out what
type it is). If you're at a Linux PC monitor (command line interface)
it's a terminal of type "Linux", and since you can't change this, TERM
must be set to "Linux". But this "Linux" should be set automatically,
without you needing to do anything.
If you set it to something else, you are fibbing to an application
program.
As a result, it will incorrectly interpret certain escape sequences from
the console resulting in a corrupted interface. Since the Linux console behaves almost like a vt100 terminal, it could still work almost OK if
you falsely claimed it was a vt100 (or some other terminal which is
close to a vt100). In this case it may seeming work OK most of the time
but once in a while will give errors.
Thanks for all the responses. Telnet on my rpi is installed and
working. a telnet daemon (telnetd) is running and working on my
"other" machine. I can telnet 192.168.0.169 and connect. However,
the "other" machine is expecting a vt100 type terminal. The
raspberrypi is NOT acting like one. So I can see text but cursor
linefeeds etc are not working. The last line of output is usually
over written by the "other" machine prompt. A true vt100 works
however. I need to get lxterm or whatever to be a vt100. xterm
connects too but isn't vt100. What am I missing?
The "other" machine is an Apple //e running A2OSX. No ssh there! It
only supports unencrypted telnet :-) and cifsd only works with
guest-only SMB1 servers. Again the rpi fails to make the cut.
Windows works but I don't do windows. --Steve
Eli the Bearded wrote on 30-07-2021 at 23:15:
Does anyone have that "video" as a file instead of streaming from there?Might be prudent to save it somewhere, yes.
nelso...@gmail.com wrote on 7/31/21 5:42 PM:terminal. The raspberrypi is NOT acting like one. So I can see text but cursor linefeeds etc are not working. The last line of output is usually over written by the "other" machine prompt. A true vt100 works however. I need to get lxterm or whatever
Thanks for all the responses. Telnet on my rpi is installed and working. a telnet daemon (telnetd) is running and working on my "other" machine. I can telnet 192.168.0.169 and connect. However, the "other" machine is expecting a vt100 type
a wild guess :-)
The "other" machine is an Apple //e running A2OSX. No ssh there! It only supports unencrypted telnet :-) and cifsd only works with guest-only SMB1 servers. Again the rpi fails to make the cut. Windows works but I don't do windows.
--Steve
the $TERM on the client is not set to vt100, probably expects xterm-256color responses...
Dana Sat, 31 Jul 2021 18:06:30 +0200, Ralph Spitzner <rasp@spitzner.org> napis'o:terminal. The raspberrypi is NOT acting like one. So I can see text but cursor linefeeds etc are not working. The last line of output is usually over written by the "other" machine prompt. A true vt100 works however. I need to get lxterm or whatever
nelso...@gmail.com wrote on 7/31/21 5:42 PM:
Thanks for all the responses. Telnet on my rpi is installed and working. a telnet daemon (telnetd) is running and working on my "other" machine. I can telnet 192.168.0.169 and connect. However, the "other" machine is expecting a vt100 type
a wild guess :-)
The "other" machine is an Apple //e running A2OSX. No ssh there! It only supports unencrypted telnet :-) and cifsd only works with guest-only SMB1 servers. Again the rpi fails to make the cut. Windows works but I don't do windows.
--Steve
the $TERM on the client is not set to vt100, probably expects xterm-256color responses...
That should do the trick.
export TERM=vt100
Thanks for all the responses. Telnet on my rpi is installed and
working. a telnet daemon (telnetd) is running and working on my "other" machine. I can telnet 192.168.0.169 and connect. However, the "other" machine is expecting a vt100 type terminal. The raspberrypi is NOT
acting like one. So I can see text but cursor linefeeds etc are not
working. The last line of output is usually over written by the "other" machine prompt. A true vt100 works however. I need to get lxterm or whatever to be a vt100. xterm connects too but isn't vt100. What am I missing?
nelso...@gmail.com wrote on 7/31/21 5:42 PM:
Thanks for all the responses. Telnet on my rpi is installed anda wild guess :-)
working. a telnet daemon (telnetd) is running and working on my
"other" machine. I can telnet 192.168.0.169 and connect. However,
the "other" machine is expecting a vt100 type terminal. The
raspberrypi is NOT acting like one. So I can see text but cursor
linefeeds etc are not working. The last line of output is usually
over written by the "other" machine prompt. A true vt100 works
however. I need to get lxterm or whatever to be a vt100. xterm
connects too but isn't vt100. What am I missing?
The "other" machine is an Apple //e running A2OSX. No ssh there! It
only supports unencrypted telnet :-) and cifsd only works with
guest-only SMB1 servers. Again the rpi fails to make the cut.
Windows works but I don't do windows.
--Steve
the $TERM on the client is not set to vt100, probably expects
xterm-256color responses...
-rasp
On 30.7.21 23.47, The Natural Philosopher wrote:
On 30/07/2021 17:21, A. Dumas wrote:
Ahem A Rivet's Shot <steveo@eircom.net> wrote:Frankly I used to use telnet, but all distros now favour ssh as a
On Fri, 30 Jul 2021 12:58:27 +0200
"A. Dumas" <alexandre@dumas.fr.invalid> wrote:
Of course, if this is via a public network in any way, then always use >>>>> ssh instead of telnet.
Even on a private network, unless you trust everyone using it *and*
are sure that there are no compromised systems on it.
Yeah OK. I'm the only one on my private network (as far as I
know....) and
I never had a compromised system (except Chinese and American
hardware....)
but I always use ssh anyway.
default, and at current network and CPU speeds the encryption doesn't
adversely affect performance, so who needs telnet?
There is a perfectly good reason for small embedded devices,
as a Telnet daemon is far simpler and smaller than a SSH one.
On 2021-08-01, Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> wrote:terminal. The raspberrypi is NOT acting like one. So I can see text but cursor linefeeds etc are not working. The last line of output is usually over written by the "other" machine prompt. A true vt100 works however. I need to get lxterm or whatever
Dana Sat, 31 Jul 2021 18:06:30 +0200, Ralph Spitzner <rasp@spitzner.org> napis'o:
nelso...@gmail.com wrote on 7/31/21 5:42 PM:
Thanks for all the responses. Telnet on my rpi is installed and working. a telnet daemon (telnetd) is running and working on my "other" machine. I can telnet 192.168.0.169 and connect. However, the "other" machine is expecting a vt100 type
a wild guess :-)
The "other" machine is an Apple //e running A2OSX. No ssh there! It only supports unencrypted telnet :-) and cifsd only works with guest-only SMB1 servers. Again the rpi fails to make the cut. Windows works but I don't do windows.
--Steve
the $TERM on the client is not set to vt100, probably expects xterm-256color responses...
That should do the trick.
export TERM=vt100
As has been explained by others, setting TERM is only relevant to
program outputting the data - not the terminal emulator itself.
Finally getting a DEC VT100 or, better, a Wyse 140 terminal was wonderful!
On 31/07/2021 18:50, Martin Gregorie wrote:
Finally getting a DEC VT100 or, better, a Wyse 140 terminal was wonderful!
I did a computer course in 1969 as an apprentice and learnt FORTRAN on a flexowriter, So appalling was the experience of handing a paper tape to
the operator and getting a listing of compile errors the *next week*,
that I forsook computing until microcomputers with terminals arrived,
With a turn round time of under a second to sort BASIC syntax errors, I
could actually learn how to program the beasts.
I did a computer course in 1969 as an apprentice and learnt FORTRAN on a flexowriter, So appalling was the experience of handing a paper tape to
the operator and getting a listing of compile errors the *next week*,
I did a computer course in 1969 as an apprentice and learnt FORTRAN on a flexowriter, So appalling was the experience of handing a paper tape to
the operator and getting a listing of compile errors the *next week*,
that I forsook computing until microcomputers with terminals arrived,
With a turn round time of under a second to sort BASIC syntax errors, I
could actually learn how to program the beasts.
[1] Redundant these days I know - when was the last time you saw a
monochrome monitor.
On 31/07/2021 18:33, Tauno Voipio wrote:
On 30.7.21 23.47, The Natural Philosopher wrote:This is indeed completely true, and its probably why the embedded linux busybox routers use it, as they are penny pinching RAM stealers
On 30/07/2021 17:21, A. Dumas wrote:
Ahem A Rivet's Shot <steveo@eircom.net> wrote:Frankly I used to use telnet, but all distros now favour ssh as a
On Fri, 30 Jul 2021 12:58:27 +0200
"A. Dumas" <alexandre@dumas.fr.invalid> wrote:
Of course, if this is via a public network in any way, then always >>>>>> use
ssh instead of telnet.
Even on a private network, unless you trust everyone using it >>>>> *and*
are sure that there are no compromised systems on it.
Yeah OK. I'm the only one on my private network (as far as I
know....) and
I never had a compromised system (except Chinese and American
hardware....)
but I always use ssh anyway.
default, and at current network and CPU speeds the encryption doesn't
adversely affect performance, so who needs telnet?
There is a perfectly good reason for small embedded devices,
as a Telnet daemon is far simpler and smaller than a SSH one.
And then run a web server instead???!
Actually Tauno, I suspect its simply because it comes with busybox and
sshd doesnt.
That was a long enough delay to make compile errors something to
avoid at all costs - we soon learned the value of desk checking. These days we run static code analysis tools (aka linters) and run compilers with all the warnings on instead.
On 2021-08-02, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
That was a long enough delay to make compile errors something to
avoid at all costs - we soon learned the value of desk checking. These
days we run static code analysis tools (aka linters) and run compilers
with all the warnings on instead.
They still don't catch logic and design errors, though. :-)
On 3 Aug 2021 18:01:53 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
They still don't catch logic and design errors, though. :-)
No they don't, code review and design walkthroughs are the best
tools I know for those.
On 03/08/2021 20:16, Ahem A Rivet's Shot wrote:
On 3 Aug 2021 18:01:53 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
They still don't catch logic and design errors, though. :-)
No they don't, code review and design walkthroughs are the best
tools I know for those.
Viewing a computer program as though it is a complex machine of
several interacting components, it can take several days for
any one person to become familiar with it (and a program can
be of a size several orders of magnitude more complex than
most mechanical marvels)
This is where reviews and walkthroughs fall down, because the
reviewers have complex machines of their own to husband and cannot
pay much more than scan attention to the programs under inspection.
Sounds like it's time to pay a little more attention to the KISS
principle.
(I realize that large corporations might want to burn me at the stake
for this heresy...)
On Wed, 04 Aug 2021 17:56:02 +0000, Charlie Gibbs wrote:
Sounds like it's time to pay a little more attention to the KISS
principle.
(I realize that large corporations might want to burn me at the stake
for this heresy...)
Indeed, and very often the way to achieve that is to break the design
into modules with rigidly defined interfaces while roughly grouping them
by function.
It goes without saying that there is almost certainly some
sort of module hierarchy, but its depth needs to be kept as shallow as possible.
This approach simplifies design reviews, makes design validation a lot
easier and also makes costing the project simpler.
It also simplifies the code and module test phase because, if the design documents are any good, writing test harnesses and specifying module test suites becomes straight forward and also lets you catch bugs well before
they become horridly apparent during integration testing, let alone, as
I've <<shudder>> seen, when they surface, inexcusably late, during
acceptance or performance testing.
Ideally, the test harnesses and scripts will be kept under version
control - just like the production code - because they will be extremely
On Wed, 4 Aug 2021 20:30:06 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:
This approach simplifies design reviews, makes design validation a lot
easier and also makes costing the project simpler.
It also simplifies the code and module test phase because, if the
design documents are any good, writing test harnesses and specifying
module test suites becomes straight forward and also lets you catch
bugs well before
You can even go one further and write the module tests
independently of the code based solely on the design documents, it is
amazing how well this picks up hidden assumptions in the design document
as implementer and tester interpret it differently. IME the spirit of friendly competition it inspires leads to really good tests that probe
edge cases as well as the obvious and really solid code because the implementer knows what the tester is up to.
There's always the ones reserved for the customer to find.
On Wed, 04 Aug 2021 22:36:08 +0100, Ahem A Rivet's Shot wrote:
You can even go one further and write the module tests
independently of the code based solely on the design documents, it is amazing how well this picks up hidden assumptions in the design document
as implementer and tester interpret it differently. IME the spirit of friendly competition it inspires leads to really good tests that probe
edge cases as well as the obvious and really solid code because the implementer knows what the tester is up to.
I thought doing that would be the obvious approach, so didn't spell it
out. Mea culpa.
There is a widespread convention that code and tests must be
written together by the same person - test driven development done wrong.
On Wed, 4 Aug 2021 23:18:41 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:
On Wed, 04 Aug 2021 22:36:08 +0100, Ahem A Rivet's Shot wrote:
You can even go one further and write the module testsI thought doing that would be the obvious approach, so didn't spell it
independently of the code based solely on the design documents, it is
amazing how well this picks up hidden assumptions in the design
document as implementer and tester interpret it differently. IME the
spirit of friendly competition it inspires leads to really good tests
that probe edge cases as well as the obvious and really solid code
because the implementer knows what the tester is up to.
out. Mea culpa.
There is a widespread convention that code and tests must be
written together by the same person - test driven development done
wrong.
Module and system tests should be written by the designer and acceptance
tests should be written by whoever signed off the system specs on the
user side.
On Thu, 5 Aug 2021 12:30:11 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:
Module and system tests should be written by the designer and
acceptance
Slightly better if they're written by another developer who only
gets to see the design docs and not the code. This tends to expose
places where the design document has ambiguities.
tests should be written by whoever signed off the system specs on the
user side.
Yep - you should have heard the howls the one and only time I saw
this insisted upon. After the first misunderstanding was found the prime howler became the staunchest defender of the principle and ran the most draconian acceptance tests I've ever seen.
On Thu, 5 Aug 2021 12:30:11 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:
Module and system tests should be written by the designer and acceptance
Slightly better if they're written by another developer who only
gets to see the design docs and not the code. This tends to expose places where the design document has ambiguities.
"nelso...@gmail.com" <nelsonse48@gmail.com> writes:
I want to telnet from my rpi (buster) to another computer as a 'VT100'
(or similar, vt102 etc) terminal. I don't want to mess up my
lxterminal for rpi use. Suggestions?
Isn’t xterm a superset of vt100? I’m not sure why you think you need to do anything special.
On 29.7.21 22.12, nelso...@gmail.com wrote:
I want to telnet from my rpi (buster) to another computer as a 'VT100'
(or similar, vt102 etc) terminal. I don't want to mess up my
lxterminal for rpi use. Suggestions?
--Steve
It seems that a Telnet client is not in the standard install
of Raspbian (Raspi OS). You can install it:
sudo apt install telnet
After installation, just start it from the terminal:
telnet tar_get_machine_ip_or_name
For connecting to another computer, you do not need
the Telnet server (daemon).
On 2021-07-30 10:40 a.m., Tauno Voipio wrote:
On 29.7.21 22.12, nelso...@gmail.com wrote:
I want to telnet from my rpi (buster) to another computer as a 'VT100'
(or similar, vt102 etc) terminal. I don't want to mess up my
lxterminal for rpi use. Suggestions?
--Steve
It seems that a Telnet client is not in the standard install
of Raspbian (Raspi OS). You can install it:
sudo apt install telnet
After installation, just start it from the terminal:
telnet tar_get_machine_ip_or_name
For connecting to another computer, you do not need
the Telnet server (daemon).
For modern purposes you really shouldn't be using telnet. You can enable >vt100 emulation mode in most ssh software - for instance putty offers
vt100 compatibility mode in the "settings" panel. kterm also offers
vt100 mode via a command flag iirc.
I'm pretty sure that's widespread knowledge by now...has been for probabbly at least 20 years. That said, there are plenty of devices out there that don't support ssh: old 8-bit computers serving up a BBS
through an ESP8266 on the serial port, not-so-old managed network
accessed from outside our network, for instance), the world isn't going
to end if you telnet in to something.
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?
there are plenty of devices out there that don't support ssh: old 8-bit computers serving up a BBS through an ESP8266 on the serial port
Scott Alfter wrote:
there are plenty of devices out there that don't support ssh: old 8-bit
computers serving up a BBS through an ESP8266 on the serial port
The ESP could handle the SSH and just send/receive terminal traffic on
the serial port ... I don't know if puTTY's ANSI emulation is as good as telix/procomm?
On Mon, 18 Oct 2021 13:19:28 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:
On a public network - well if people are to be believed every man and
his dog from the CCP to the CIA are sniffing everything, so remember to
put on a good show with lots of references to assassinating the
president and starting a Jihad in your local boy scout camp.
Did the semtex arrive safely ? The plutonium is delayed a bit but
it will be coming. Anthrax is out of stock I'm afraid.
On a public network - well if people are to be believed every man and
his dog from the CCP to the CIA are sniffing everything, so remember to
put on a good show with lots of references to assassinating the
president and starting a Jihad in your local boy scout camp.
On 18/10/2021 14:27, Ahem A Rivet's Shot wrote:
On Mon, 18 Oct 2021 13:19:28 +0100Well there is a local shortage of revolutionaries anyway, so we are in
The Natural Philosopher <tnp@invalid.invalid> wrote:
On a public network - well if people are to be believed every man and
his dog from the CCP to the CIA are sniffing everything, so remember to >>> put on a good show with lots of references to assassinating the
president and starting a Jihad in your local boy scout camp.
Did the semtex arrive safely ? The plutonium is delayed a bit but
it will be coming. Anthrax is out of stock I'm afraid.
no hurry...
On a switched network, you can't.
Wifi is more problematic, but its fairly well encrypted.
On Mon, 18 Oct 2021 14:59:21 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 18/10/2021 14:27, Ahem A Rivet's Shot wrote:
On Mon, 18 Oct 2021 13:19:28 +0100Well there is a local shortage of revolutionaries anyway, so we are in
The Natural Philosopher <tnp@invalid.invalid> wrote:
On a public network - well if people are to be believed every man and
his dog from the CCP to the CIA are sniffing everything, so remember to >>>> put on a good show with lots of references to assassinating the
president and starting a Jihad in your local boy scout camp.
Did the semtex arrive safely ? The plutonium is delayed a bit but
it will be coming. Anthrax is out of stock I'm afraid.
no hurry...
Really? There doesn't seem to be a shortage of revolting people round here.
In article <c87cc99f-5fb5-2988-ac09-c979633def6e@nimbulus.xyz>,
randon <randon@nimbulus.xyz> wrote:
For modern purposes you really shouldn't be using telnet.
I'm pretty sure that's widespread knowledge by now...has been for probabbly at least 20 years. That said, there are plenty of devices out there that don't support ssh: old 8-bit computers serving up a BBS through an ESP8266
on the serial port, not-so-old managed network equipment (I have a bunch of older Cisco gear at work that doesn't speak ssh), etc. As long as you're aware of the security implications and take steps to mitigate what you can (those switches at work can't be accessed from outside our network, for instance), the world isn't going to end if you telnet in to something.
Really? There doesn't seem to be a shortage of revolting people round
here.
For modern purposes you really shouldn't be using telnet.
You can
enable vt100 emulation mode in most ssh software - for instance putty
offers vt100 compatibility mode in the "settings" panel. kterm also
offers vt100 mode via a command flag iirc.
On 18/10/2021 08:41, Andy Burns wrote:
Scott Alfter wrote:
there are plenty of devices out there that don't support ssh: old
8-bit computers serving up a BBS through an ESP8266 on the serial
port
The ESP could handle the SSH and just send/receive terminal traffic
on the serial port ... I don't know if puTTY's ANSI emulation is as
good as telix/procomm?
Telnet was dangerous on a student network formed of coaxial
cable...you could sniff passwords.
On a switched network, you can't.
Wifi is more problematic, but its fairly well encrypted.
On a public network - well if people are to be believed every man and
his dog from the CCP to the CIA are sniffing everything, so remember
to put on a good show with lots of references to assassinating the
president and starting a Jihad in your local boy scout camp.
randon <randon@nimbulus.xyz> wrote:
For modern purposes you really shouldn't be using telnet.
Not for actual communication, no. But as a quick and dirty means of
checking for a running server, and usually seeing the server's banner,
it's difficult to beat. I've also been known to test SMTP servers that
way.
Joe wrote:
randon <randon@nimbulus.xyz> wrote:
For modern purposes you really shouldn't be using telnet.
Not for actual communication, no. But as a quick and dirty means of checking for a running server, and usually seeing the server's
banner, it's difficult to beat. I've also been known to test SMTP
servers that way.
Though it's not unusual nowadays to find an SMTP server that gets
upset at the slow speed a human can turn around the commands ...
Andy Burns <usenet@andyburns.uk> wrote:
Joe wrote:
randon <randon@nimbulus.xyz> wrote:
For modern purposes you really shouldn't be using telnet.
Not for actual communication, no. But as a quick and dirty means of
checking for a running server, and usually seeing the server's
banner, it's difficult to beat. I've also been known to test SMTP
servers that way.
Though it's not unusual nowadays to find an SMTP server that gets
upset at the slow speed a human can turn around the commands ...
Yes, possibly, though my server asks for an ident from connecting
SMTP servers. Nobody runs an ident server nowadays, so a timeout of
thirty seconds is imposed before the transaction continues.
Only spammers drop out in the timeout. As far as I'm aware, I've never
lost an email because a legitimate SMTP server will not wait for thirty seconds.
Joe <joe@jretrading.com> wrote:
Yes, possibly, though my server asks for an ident from connecting
SMTP servers. Nobody runs an ident server nowadays, so a timeout of
thirty seconds is imposed before the transaction continues.
What do you do if the ident server replies?
$ grep ^ident /etc/services
ident 113/tcp
identify 2987/tcp # identify
identify 2987/udp # identify
$ telnet localhost 113
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
jddj
0 , 0 : ERROR : X-INVALID-REQUEST
Connection closed by foreign host.
$
I don't know how to speak the ident protocol, but it is running on
this machine. My recollection is you feed it an IP address and port
and it tells you the identity of the user who has opened the connection.
I know that the default Apache log entry has a field for identd
value, to be compatible with NCSA httpd, but I don't think anyone
enables the ident module these days.
Eli the Bearded <*@eli.users.panix.com> writes:
I don't know how to speak the ident protocol, but it is running onhttps://datatracker.ietf.org/doc/html/rfc1413
this machine. My recollection is you feed it an IP address and port
and it tells you the identity of the user who has opened the connection.
I know that the default Apache log entry has a field for identd
value, to be compatible with NCSA httpd, but I don't think anyone
enables the ident module these days.
Andy Burns wrote:
it's not unusual nowadays to find an SMTP server that gets
upset at the slow speed a human can turn around the commands ...
Yes, possibly, though my server asks for an ident from connecting
SMTP servers. Nobody runs an ident server nowadays, so a timeout of
thirty seconds is imposed before the transaction continues.
Only spammers drop out in the timeout. As far as I'm aware, I've never
lost an email because a legitimate SMTP server will not wait for thirty seconds.
In comp.sys.raspberry-pi, Joe <joe@jretrading.com> wrote:
Andy Burns <usenet@andyburns.uk> wrote:
Joe wrote:
randon <randon@nimbulus.xyz> wrote:
For modern purposes you really shouldn't be using telnet.
Not to telnetd servers probably, but it has other uses. And the post
you replied to did mention not needing a telnet daemon.
Not for actual communication, no. But as a quick and dirty means
of checking for a running server, and usually seeing the server's
banner, it's difficult to beat. I've also been known to test SMTP
servers that way.
And nntp, and web, and redis, and dictd, and ...
Though it's not unusual nowadays to find an SMTP server that gets
upset at the slow speed a human can turn around the commands ...
Can't say I've noticed that, but I don't do much raw SMTP. I've seen
that with NNTP.
Yes, possibly, though my server asks for an ident from connecting
SMTP servers. Nobody runs an ident server nowadays, so a timeout of
thirty seconds is imposed before the transaction continues.
What do you do if the ident server replies?
ident is one of the few protocols I tend to configure firewalls to send an >active reject, rather than a silent drop, but that was a habit developed 15+ >years ago, no idea how many ident requests get sent nowadays.
In article <ita6veFapqeU1@mid.individual.net>,
Andy Burns <usenet@andyburns.uk> wrote:
ident is one of the few protocols I tend to configure firewalls to send an >active reject, raththan a silent drop, but that was a habit developed 15+ >years ago, no idea how many ident reques
get sent nowadays.
I've been fooling around with the Internet for over 30 years (including using telnet to send test emails and talk to IRC servers), but I've never even heard of this "ident" thing until it was brought up here. I've never had to configure any hosts, firewalls, or whatever with it in mind, and I've run my own mail ser
for over 20 years, so I suspect that if it ever
really was a thing, by now it's pretty much a non-issue.
(Someone else commented on my sig in another reply. The ASCII Apple has been in it since 1989, though for the first four years it had "IIe" in the middle instead of
"IIGS," because that's what I was using. The IIGS is no longer my daily driver, but I still hav
it and it lives on here. :-) )
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?
In article <ita6veFapqeU1@mid.individual.net>,
Andy Burns <usenet@andyburns.uk> wrote:
ident is one of the few protocols I tend to configure firewalls to send an >> active reject, rather than a silent drop, but that was a habit developed 15+ >> years ago, no idea how many ident requests get sent nowadays.
I've been fooling around with the Internet for over 30 years (including
using telnet to send test emails and talk to IRC servers), but I've never even heard of this "ident" thing until it was brought up here. I've never had to configure any hosts, firewalls, or whatever with it in mind, and I've run my own mail server for over 20 years, so I suspect that if it ever
really was a thing, by now it's pretty much a non-issue.
(Someone else commented on my sig in another reply. The ASCII Apple has
been in it since 1989, though for the first four years it had "IIe" in the middle instead of "IIGS," because that's what I was using. The IIGS is no longer my daily driver, but I still have it and it lives on here. :-) )
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?
I've been fooling around with the Internet for over 30 years
(including using telnet to send test emails and talk to IRC servers),
but I've never even heard of this "ident" thing until it was brought
up here. I've never had to configure any hosts, firewalls, or
whatever with it in mind, and I've run my own mail server for over 20
years, so I suspect that if it ever really was a thing, by now it's
pretty much a non-issue.
Eli the Bearded <*@eli.users.panix.com> wrote:
What do you do if the ident server replies?Get on with the transaction immediately. I don't think I've ever
noticed this happening in the log file.
In comp.sys.raspberry-pi, Joe <joe@jretrading.com> wrote:
Eli the Bearded <*@eli.users.panix.com> wrote:
What do you do if the ident server replies?Get on with the transaction immediately. I don't think I've ever
noticed this happening in the log file.
So just that? No logging of the identity or adding it to mail headers somehow?
I just used `telnet mail.jretrading.com smtp` to send you
some mail from this host. I didn't notice any 30 second delays, but
there was a ~1 second pause after the RCPT command. Is that when the
ident kicks in?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 371 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 37:34:44 |
| Calls: | 7,932 |
| Calls today: | 2 |
| Files: | 12,998 |
| Messages: | 5,805,631 |