Telnet

[nelso...@gmail.com]

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

[The Natural Philosopher]

Putty is definitely an option for an old school vt100 that has a built
in telnet client




--
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him."

Jonathan Swift.

[Martin Gregorie]

Try kermit. ckermit and gkermit are available as Raspian packages.

ckermit looks to be the original Columbia University version
gkermit is a GPLed version.

Been a while since I just it, but you can specify the terminal protocol
you want to use - IIIRC it defaults to VT100

You can also do file transfer with it - its relatively slow but error
correction, retries, etc during file transfers are excellent.

It should work equally well as an interactive tool because it has to talk
to the remote host well enough to handle logging in and, if you want to
transfer files, starting, interacting with and stopping a remote Kermit
session.


--
Martin | martin at
Gregorie | gregorie dot org

[Richard Kettlewell]

Isn’t xterm a superset of vt100? I’m not sure why you think you need to
do anything special.

--
https://www.greenend.org.uk/rjk/

[A. Dumas]

Martin Gregorie <mar...@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

[Nikolaj Lazic]

Dana Thu, 29 Jul 2021 12:12:24 -0700 (PDT), nelso...@gmail.com <nelso...@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.

[Martin Gregorie]

I didn't know that: I initially used it to move files between an
OS-9/68000 box and Windows, though I'm also certain that I've used it to
pull files from the OS/9 system onto a Linux system, but don't recall
which end I'd have driven that from, but I do have distant memories of
setting the terminal type when doing that. It was a long time ago: both
OS/9 and Linux had termcap installed and still do. Back in the day I may
not have had curses/ncurses installed as that wasn't available for OS/9.

[The Natural Philosopher]

On 29/07/2021 20:38, Richard Kettlewell wrote:
> "nelso...@gmail.com" <nelso...@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.
>

You got me looking. Its based on VTE which is a superset of a vt102.

--
"A point of view can be a dangerous luxury when substituted for insight
and understanding".

Marshall McLuhan

[A. Dumas]

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.

[Ahem A Rivet's Shot]

On Fri, 30 Jul 2021 12:58:27 +0200
"A. Dumas" <alex...@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.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[Nikolaj Lazic]

Dana Fri, 30 Jul 2021 12:58:27 +0200, A. Dumas <alex...@dumas.fr.invalid> napis'o:

He wrote "from my rpi to another computer"... surely local.
So... nothing is needed except telnet.

[The Natural Philosopher]

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.

And since it runs headless the first thing I did after I flashed te RAM
card was to ssh into it

Using a gnome terminal/console which is itself pretty much the same as
lxterm I think

--
In theory, there is no difference between theory and practice.
In practice, there is.
-- Yogi Berra

[Chris Green]

Though given that ssh is there by default why not use that, telnet
doesn't really offer any advantage.

--
Chris Green
·

[The Natural Philosopher]

er no, so nothing is needed except *ssh*.

Which comes by default whereas telnet daemons do not

$telnet mipifi
Trying 192.168.0.200...
telnet: Unable to connect to remote host: Connection refused

$ssh mipifi
xxx@mipifi's password:

The only thing I use telnet for is to extract stats from my router that
snmp cant reach.

Why it doesnt have ssh lord only knows.

--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
fully understood.

[Chris Green]

The Natural Philosopher <t...@invalid.invalid> 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
> >> <nelso...@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.
>

It's installed but not enabled, you either have to start it from the
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.

--
Chris Green
·

[The Natural Philosopher]

Yes. I remember I had to quite a lot of stuff in that way (putting stuff
in the boot partition) - for setting up wifi as well..

What amazed me was that following the instructions carefully and
inserting the card and booting, about a minute later ssh into the Pi
zero W 'just worked'.



--
"First, find out who are the people you can not criticise. They are your
oppressors."
- George Orwell

[Pancho]

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
>>> <nelso...@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 :-).

[Ahem A Rivet's Shot]

On Fri, 30 Jul 2021 14:03:09 +0100

The Natural Philosopher <t...@invalid.invalid> wrote:

> The only thing I use telnet for is to extract stats from my router that
> snmp cant reach.

Hmm towel.blinkenlights.nl appears to be down so yes telnet is
running out of uses.

[Tauno Voipio]

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).

--

-TV

[Nikolaj Lazic]

Dana Fri, 30 Jul 2021 17:40:38 +0300, Tauno Voipio <tauno....@notused.fi.invalid> napis'o:

He needs telnet daemon on OTHER machine.

[Nikolaj Lazic]

Dana Fri, 30 Jul 2021 15:06:38 +0100, Pancho <Pancho.Do...@outlook.com> napis'o:

And the best thing is... that OP never wrote anything after that
initial post...

[Pancho]

But you need a telnet client on Raspbian. Which apparently is doesn't have.

FWIW, further to my other post in the thread, the arm64 version of
Ubuntu Server does have it installed by default :-).

[Chris Elvidge]

nc (ncat or netcat) can do telnet
and is installed in RaspianOS

--
Chris Elvidge
England

[A. Dumas]

Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Fri, 30 Jul 2021 12:58:27 +0200
> "A. Dumas" <alex...@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.

[Martin Gregorie]

On Fri, 30 Jul 2021 12:58:27 +0200, A. Dumas wrote:

> 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.

My RPi, initially set up with jessie or wheezy, and then successively
upgraded to Buster, does not have telnet installed.

[Tauno Voipio]

Not quite. Please get the basic Telnet RFC (RFC854) and have a look at
the Telnet control functions definitions.

--

-TV

[Chris Elvidge]

It works well enough for me.

--
Chris Elvidge
England

[Theo]

Tauno Voipio <tauno....@notused.fi.invalid> wrote:
> Not quite. Please get the basic Telnet RFC (RFC854) and have a look at the
> Telnet control functions definitions.

Not quite. Look up -t in the 'nc' man page.

Theo ;-)

[The Natural Philosopher]

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?


--
"What do you think about Gay Marriage?"
"I don't."
"Don't what?"
"Think about Gay Marriage."

[Martin Gregorie]

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 a
> default, and at current network and CPU speeds the encryption doesn't
> adversely affect performance, so who needs telnet?
>

The retro-computing crowd.

[The Natural Philosopher]

On 30/07/2021 21:50, Martin Gregorie wrote:
> 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 a
>> default, and at current network and CPU speeds the encryption doesn't
>> adversely affect performance, so who needs telnet?
>>
> The retro-computing crowd.
>
>

They can look back in nostalgia. I was there. fuck that for a game of
soldiers.

Like I don't miss carburettors and distributors one little bit, either.

Or engines that needed new bearings every 30, 000 miles and a rebore,
regrind and new pistons at 90,000

[Eli the Bearded]

In comp.sys.raspberry-pi, Ahem A Rivet's Shot <ste...@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?

Elijah
------
https://github.com/Eli-the-Bearded/vt100-slowcat

[Chris Elvidge]

On 30/07/2021 09:50 pm, Martin Gregorie wrote:
> 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 a
>> default, and at current network and CPU speeds the encryption doesn't
>> adversely affect performance, so who needs telnet?
>>
> The retro-computing crowd.
>
>

I use it (well nc actually) to remotely control VLC.

--
Chris Elvidge
England

[Ahem A Rivet's Shot]

On Fri, 30 Jul 2021 21:15:14 -0000 (UTC)
Eli the Bearded <*@eli.users.panix.com> wrote:

> In comp.sys.raspberry-pi, Ahem A Rivet's Shot <ste...@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.)

Oh good! I was using IPv4, no native IPv6 here and the tunnel
messes up geo-ip.

[A. Dumas]

Eli the Bearded wrote on 30-07-2021 at 23:15:
> In comp.sys.raspberry-pi, Ahem A Rivet's Shot <ste...@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.)

Same, but yes, seems down on ipv4.

> Does anyone have that "video" as a file instead of streaming from there?

Might be prudent to save it somewhere, yes.

[nelso...@gmail.com]

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

[Ralph Spitzner]

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 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
>

a wild guess :-)

the $TERM on the client is not set to vt100, probably expects xterm-256color responses...

-rasp

[Tauno Voipio]

On 30.7.21 23.47, The Natural Philosopher wrote:
> On 30/07/2021 17:21, A. Dumas wrote:
>> Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>> On Fri, 30 Jul 2021 12:58:27 +0200
>>> "A. Dumas" <alex...@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.
>>
> 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?

There is a perfectly good reason for small embedded devices,
as a Telnet daemon is far simpler and smaller than a SSH one.

--

-TV

[Martin Gregorie]

On Fri, 30 Jul 2021 22:07:52 +0100, The Natural Philosopher wrote:

> On 30/07/2021 21:50, Martin Gregorie wrote:
>> 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 a
>>> default, and at current network and CPU speeds the encryption doesn't
>>> adversely affect performance, so who needs telnet?
>>>
>> The retro-computing crowd.
>>
>>
> They can look back in nostalgia. I was there. fuck that for a game of
> soldiers.
>

The only thing (comms-wise) I don't miss from those days was the early
green screen terminal protocols and 12 key hand punches for cards.

I was quite happy paper tape: tolerated teletypes and loved Flexowriters.
Dropping a card deck was a bitch if there wasn't a handy card sorter or
the cards didn't have sequence numbers, but scrambled paper tape was a
breeze: hold onto one end, chuck the mess down a stair well and then wind
it up again on a tape winder.

The early teletype replacements were fine too: they worked exactly like a
24 x 80 terminal display, but the early mainframe terminals only sent and
received a whole screen at a time and some were dead slow, especially
those using 3270 bisync or LU2 protocols: several terminals were
typically multi-dropped on an often slow communal line, after hitting
send you waited while the polling sequence got round to polling your
terminal.

ICL kit could treat the 24x80 screen as an editable text page - so when
programming you got sent 20 or so lines of text (space left at the bottom
for adding lines) and edited the screen locally before hitting SEND to
save that part of the file and receive the next chunk. Not pretty, but at
least it beat the hell out of programming with 12 key card punches.

Finally getting a DEC VT100 or, better, a Wyse 140 terminal was wonderful!

[Ahem A Rivet's Shot]

On Sat, 31 Jul 2021 17:50:13 -0000 (UTC)
Martin Gregorie <mar...@mydomain.invalid> wrote:

> Finally getting a DEC VT100 or, better, a Wyse 140 terminal was wonderful!

Yep, then the workspace filled up with keyboards and screens
at odd heights and angles as you tried to fit all the terminals needed onto
the desk space available and suddenly there was the 19" NCD X terminal -
monochrome and marvellous, one screen one keyboard to rule them all. Fast
forward to today and there are two 27" high definition colour[1] monitors
attached to my work laptop which has enough oomph to emulate everything I
ever connected a dumb terminal to without even noticing the load.

[1] Redundant these days I know - when was the last time you saw a
monochrome monitor.

[Martin Gregorie]

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 a
> monochrome monitor.
>

I still own one: actually a 12" green screen TV monitor attached to a
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]

Ralph Spitzner has the better guess. TERM$ is xterm-256colors. How do I temporarily set term=vt100 for a telnet session?

[A. Dumas]

nelso...@gmail.com <nelso...@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.

[Martin Gregorie]

I'd phrase that a bit differently:

Setting the UNIX/Linux TERM environment variable is telling the keyboard
and screen handling software used by an application:

1) what character sequence to send when a keypress is input to your
application
2) what effect a received character sequence shoiuld have on the display
area managed by your applicatiin

The specific keyboard and screen handling package that used depends on
both the operating system your system uses and what programming language
the application is written in:

- a C program running under Linux/UNIX is most likely to be using the
ncurses package (or termcap it its really old).

- a Java program will be using a combination of AWT and Swing classes,
no matter what hardware or OS its running on.

Other language/OS combinations will have their own display and keyboard
handlers.

[Jim Jackson]

Try

man xterm

It has loads of command line options for altering it's behaviour, and
CONTROL-MiddleMouse button gets you some options you can change.
The manual entry says it emulates a VT102 pretty well.

I'm beginning to think you are not running xterm but another terminal
emulator - qterminal?


Jim

[Eli the Bearded]

I used `script` to capture it and added it under videos/other/ here:

https://github.com/Eli-the-Bearded/vt100-slowcat

It's not the same experierence, but it is close.

Elijah
------
welcomes a better version (or other vt100 `cat`able videos

[Nikolaj Lazic]

Dana Sat, 31 Jul 2021 18:06:30 +0200, Ralph Spitzner <ra...@spitzner.org> napis'o:

That should do the trick.
export TERM=vt100

[Jim Jackson]

As has been explained by others, setting TERM is only relevant to
program outputting the data - not the terminal emulator itself.

[Ahem A Rivet's Shot]

On Sat, 31 Jul 2021 08:42:37 -0700 (PDT)
"nelso...@gmail.com" <nelso...@gmail.com> wrote:

> 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?

It sounds like you're not getting a decent VT100 emulation which is
odd because xterm should provide one, not so sure about lxterm though. You
could try installing xvt which is a pure vt100 emulator.

[The Natural Philosopher]

This is indeed completely true, and its probably why the embedded linux
busybox routers use it, as they are penny pinching RAM stealers

And then run a web server instead???!

Actually Tauno, I suspect its simply because it comes with busybox and
sshd doesnt.

--
A lie can travel halfway around the world while the truth is putting on
its shoes.

[The Natural Philosopher]

+1

>     -rasp


--
“Puritanism: The haunting fear that someone, somewhere, may be happy.”

H.L. Mencken, A Mencken Chrestomathy

[The Natural Philosopher]

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.

[The Natural Philosopher]

yes, you need to set it in the *server* so that sends the correct sequences.

And then only if it used ncurses to read it and adapt the control
sequences it outputs

If the app is hardwired to vt102 sequences, then lxterminal ain't gonna
work - try putty for a start - its a telnet client as well


--
How fortunate for governments that the people they administer don't think.

Adolf Hitler

[Charlie Gibbs]

On 2021-08-02, The Natural Philosopher <t...@invalid.invalid> wrote:

> 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.

My FORTRAN course was in 1968 and was card-based, rather than paper
tape. We had overnight turnaround. It was still a lot of incentive
for desk checking, but in my case I was so fascinated by computers
that I considered it worth it. Then I got a job in a small shop where
I could stay after hours and put in all the runs I wanted with quick
turnaround. The nice thing about microcomputers was that I could
then do it all at home - but the fun thing was being able to do it
at all, and a small mainframe in a building to which I had the key
was just about as good.

--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgi...@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana

[Ahem A Rivet's Shot]

On Mon, 2 Aug 2021 03:23:59 +0100

The Natural Philosopher <t...@invalid.invalid> wrote:

> 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*,

One week turnaround is rough, at school in 1974 we had next day (or
weekend) turnaround by way of a sixth former dialing up the local tech on a
modem and acoustic coupler then running our tapes through the reader while
the operator ran the output tape from the previous day through their reader.
Finally said sixth former[1] would separate the punched tape (there was a
trick that punched a gap and readable initials in front of each set of
results) and distribute to pigeonholes.

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.

[1] Before and after running the tapes he was also trying to chat up the
operator[2] over a teletype link.

[2] When I discovered that there was a "hands on" hour every day when you
could go to the tech[3], use the 029s then go into the machine room, put
your deck in the hopper and collect printout from the 1403, I also
discovered that the operator in question was well into her twenties and
mildly amused by the efforts of sixteen/seventeen year old hopefuls at most
of the schools in the county[4], none of whom had ever met her.

[3] Half hour walk - well worth it!

[4] Not quite sure why she let the fourteen year old me in on the secret,
but I did find it funny.

[Martin Gregorie]

On Mon, 02 Aug 2021 03:23:59 +0100, The Natural Philosopher wrote:

> 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've heard those horror stories, but never experienced them. At
University (Elliott 503 + flexowriters) the flexowriters almost never had
a queue and the worst turnround we got from the Elliott was overnight,
which was all that was guaranteed, and often we'd get a run back in an
hour or two if the system wasn't busy. 'short jobs' got 3 minutes of
runtime and most of the stuff I was doing (compile and run an Algol
curve fitting program to analyse the output from a 400 channel multi-
channel analyser connected to a Mossbauer spectrometer) executed in
rather less than 3 minutes.

Once I joined ICL (writing in PLAN assembler first and then COBOL) got us
overnight test runs plus a shorter lunchtime test slot. That was with
everything on cards - three years later (early 70s) we were running
George 3 and using teletypes for interactive program development.

[nelso...@gmail.com]

Thanks for all the responses and memories of early computing. As for telnet, xvt will fill my needs for now. Thnx!
--Steve

[Scott Alfter]

In article <20210731192609.fb17...@eircom.net>,

Ahem A Rivet's Shot <ste...@eircom.net> wrote:

>[1] Redundant these days I know - when was the last time you saw a
>monochrome monitor.

I still have a couple packed away: a green Apple Monitor II and an amber
Zenith.

Lately I've been going through different methods of connecting the Apple
IIGS to HDMI displays. I currently have a VidHD
(https://www.callapple.org/vidhd/; basically an Orange Pi Zero on an adapter
board that monitors the bus for changes and recreates the Apple II display
modes in 1080p) and an Extron RGB-to-HDMI converter (not too bad once you
get it adjusted right, and it just plugs into the RGB monitor port), and I'm
considering the RGBtoHDMI (https://github.com/hoglet67/RGBtoHDMI; runs
bare-metal on a Raspberry Pi Zero for faster start, but requires tapping
digital RGB off of the motherboard).

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

[Tauno Voipio]

You're still thinking something containing Linux.

My embedded devices can e.g. be a Cortex-M3 with 256 kbytes of Flash and
64 kbytes of RAM. The Ethernet and TCP/IP stacks with a simple Telnet
daemon can be squeezed there, but the encryption needed for SSH is
absolutely a no-no. The thing should also fit the code for its
intended use.

--

-TV

[Charlie Gibbs]

On 2021-08-02, Ahem A Rivet's Shot <ste...@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. :-)

[Ahem A Rivet's Shot]

On 3 Aug 2021 18:01:53 GMT

Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:

> On 2021-08-02, Ahem A Rivet's Shot <ste...@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. :-)

No they don't, code review and design walkthroughs are the best
tools I know for those.

[gareth evans]

On 03/08/2021 20:16, Ahem A Rivet's Shot wrote:
> On 3 Aug 2021 18:01:53 GMT
> Charlie Gibbs <cgi...@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.

[Charlie Gibbs]

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...)

[Martin Gregorie]

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
useful later for regression testing as and when requirements change and
the code gets modified to suit.

And, before you ask, I've worked on projects that were designed and
implemented using exactly this strategy:

- On one large project that had a very complex data model that needed
its database to be populated before the system was remotely useful.
This approach let us use an incremental release strategy, i.e. the
system initially went live with the online system's navigation and help
subsystems complete, but with with only the screens and reports needed
for the users to create the two catalogues that everything else
depended on. Other functions were build and put live after the main
catalogues were complete enough to be useful.

This wasn't a financial or manufacturing system: the underlying data
structure was a lot more complex than those generally need because it
had to track 'products' from initial concept through design, production,
use and partial reuse so those involved could be paid for the use and
reuse of their individual contributions.

- a large consultancy I worked for used exactly those design principles
to cost projects we were bidding on: the project manager, application
and database designers were all on the bid team from the start and had
a large hand in costing what they would deliver if we got the contract.

[Ahem A Rivet's Shot]

On Wed, 4 Aug 2021 20:30:06 -0000 (UTC)
Martin Gregorie <mar...@mydomain.invalid> wrote:

> 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.

Yes, yes and thrice yes!

> 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.

Initially yes and if you're building a single program - but if
you're building a toolkit on which to base applications then once you have
the fundamentals down solid it is time to build higher level constructs
guided by emerging common themes in the applications being built. Do not
do this prematurely!

I once got to do this for seven years straight (we called it
sedimentary programming and put down a lot of really well defined layers) -
by the time we'd finished that toolkit was like a well stocked magicians
staff, nearly everything at the application level had become declarative,
the source still fitted on a floppy and the range of applications had
expanded vastly over the original conception.

At one point we came across a performance bottleneck and tracked it
down to the oldest, lowest level of the stack - because everything had well
defined APIs and comprehensive unit tests I was able to completely rewrite
that bottom layer to eliminate the bottleneck and once I had it passing all
the tests the only effect of releasing it was to greatly improve the
performance and scalability - no other code broke or needed changing
despite there being several years of layering by then.

The project was shut down because it was found by highest
management to be in the hands of "men with ponytails" and that was
unacceptable so an IBM Websphere replacement was commissioned and anything
it couldn't do was deemed undesirable. I moved on of course.

> 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.

> they become horridly apparent during integration testing, let alone, as
> I've <<shudder>> seen, when they surface, inexcusably late, during
> acceptance or performance testing.

There's always the ones reserved for the customer to find.

> Ideally, the test harnesses and scripts will be kept under version
> control - just like the production code - because they will be extremely

Of course.

[Martin Gregorie]

On Wed, 04 Aug 2021 22:36:08 +0100, Ahem A Rivet's Shot wrote:

> On Wed, 4 Aug 2021 20:30:06 -0000 (UTC)
> Martin Gregorie <mar...@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.
>

I thought doing that would be the obvious approach, so didn't spell it
out. Mea culpa.

Nowadays, and using Java (or any other language with an equivalent
development tool to javadoc), I'd go further and say that the module
specification should be compilable: in Java terms it would contain all
publicly declared constants, constructors and methods, each preceded by a
comment describing the purpose of the item and how it should be used.

Since its quick to do, these specifications must clean compile before the
designer signs them off.

> There's always the ones reserved for the customer to find.
>

:-{

But if the unit test scripts, which ideally should be specified BEFORE
any code is written, are reasonably well thought out, then there should
not be a lot for the customer to find.


--

[Ahem A Rivet's Shot]

On Wed, 4 Aug 2021 23:18:41 -0000 (UTC)
Martin Gregorie <mar...@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 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.

[gareth evans]

On 05/08/2021 08:39, Ahem A Rivet's Shot wrote:
>
> There is a widespread convention that code and tests must be
> written together by the same person - test driven development done wrong.
>

Having worked in two safety-critical areas, railway brakes and saloon
car power steering that comment is not made in fun :-(

[Martin Gregorie]

On Thu, 05 Aug 2021 08:39:46 +0100, Ahem A Rivet's Shot wrote:

> On Wed, 4 Aug 2021 23:18:41 -0000 (UTC)
> Martin Gregorie <mar...@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 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.

Total agreement that the 'widespread convention' is utterly, stupidly
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.

[Ahem A Rivet's Shot]

On Thu, 5 Aug 2021 12:30:11 -0000 (UTC)
Martin Gregorie <mar...@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.

[Martin Gregorie]

On Thu, 05 Aug 2021 14:12:34 +0100, Ahem A Rivet's Shot wrote:

> On Thu, 5 Aug 2021 12:30:11 -0000 (UTC)
> Martin Gregorie <mar...@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.
>

Fair comment

>> 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.
>

Reminds me of the time when I was acceptance test manager for an
experimental[*] secure interbank network we'd developed for Austrian
outfit that provided ATM and interbank comms for their banks. It ran on
Stratus fault-tolerant kit that had been shipped to us develop the system
on. The Austrians had done a super job writing acceptance tests and an
equally good one setting up comms when they got the Stratus it back: it
had to handle encrypted messages using X.25, DECnet, and IBM SNA (LU.2
and LU6) protocols.

Anyway, acceptance testing started with us mainly sitting round twiddling
thumbs, but what we couldn't understand was why the acceptance test
crew's faces got longer and longer as the days went by. Then after
several days big grins appeared and a happy cry of "We found a bug!" was
heard. It turned out that the long faces were because the acceptance team
hadn't found any problems and thought they weren't doing thorough enough
testing.

[*] experimental, because there was ongoing discussion among the banks
about exactly what traffic they wanted the interbank network to carry, so
we'd been asked to create a secure, fault tolerant multiprotocol switch
to carry user-defined messages. After 2-3 years they'd decided what the
national switch neeeded to do and came back to us the write it. Can't
recall what I was doing at that point, but I wasn't on that project.
Pity, because I liked the gang we were dealing with and enjoyed my time
in Vienna.

[Charlie Gibbs]

On 2021-08-05, Ahem A Rivet's Shot <ste...@eircom.net> wrote:

> On Thu, 5 Aug 2021 12:30:11 -0000 (UTC)
> Martin Gregorie <mar...@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.

Or omissions. I was once given a set of specs so detailed I could
almost have written a compiler for them. But it didn't cover all
cases. I asked what I should do if X happened, and got the answer
which is now at the top of my list of Famous Last Words: "Oh, don't
worry about that; it'll never happen." By this time I had enough
experience to realize that "never" is usually about six months, and
got really hard-nosed about having everything covered by the specs.

[Big Bad Bob]

On 2021-07-29 12:38, Richard Kettlewell wrote:
> "nelso...@gmail.com" <nelso...@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.
>

might have to experiment a bit with TERM/term. SHould work. Check any
compat settings in the menu.

You could also install a different xterm-like application and run THAT
one. Or, my favorite, run lxterminal as a DIFFERENT user, and keep
those settings separate from the normal ones. (how to do that, think of
it as an exercise in "know Linux")


--
(aka 'Bombastic Bob' in case you wondered)

'Feeling with my fingers, and thinking with my brain' - me

'your story is so touching, but it sounds just like a lie'
"Straighten up and fly right"

[randon]

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.

[Scott Alfter]

In article <c87cc99f-5fb5-2988...@nimbulus.xyz>,

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.

[Paul Hayton]

On 18 Oct 2021 at 01:41a, Scott Alfter pondered and said...

SA> I'm pretty sure that's widespread knowledge by now...has been for
SA> probabbly at least 20 years. That said, there are plenty of devices out
SA> there that don't support ssh: old 8-bit computers serving up a BBS
SA> through an ESP8266 on the serial port, not-so-old managed network

[snip]

SA> accessed from outside our network, for instance), the world isn't going
SA> to end if you telnet in to something.
SA>
SA> _/_
SA> / v \ Scott Alfter (remove the obvious to send mail)
SA> (IIGS( https://alfter.us/ Top-posting!
SA> \_^_/ >What's the most annoying thing on
SA> Usenet?

Nice signature BTW

Agree, there are still BBS running telnet around the globe but also offering
SSH too.

I'm typing this reply from one now :)

[Andy Burns]

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?

[The Natural Philosopher]

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.


--
"It is an established fact to 97% confidence limits that left wing
conspirators see right wing conspiracies everywhere"

[Ahem A Rivet's Shot]

On Mon, 18 Oct 2021 13:19:28 +0100

The Natural Philosopher <t...@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.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

[The Natural Philosopher]

On 18/10/2021 14:27, Ahem A Rivet's Shot wrote:
> On Mon, 18 Oct 2021 13:19:28 +0100
> The Natural Philosopher <t...@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.
>

Well there is a local shortage of revolutionaries anyway, so we are in
no hurry...


--
New Socialism consists essentially in being seen to have your heart in
the right place whilst your head is in the clouds and your hand is in
someone else's pocket.

[Folderol]

On Mon, 18 Oct 2021 14:59:21 +0100

The Natural Philosopher <t...@invalid.invalid> wrote:

>On 18/10/2021 14:27, Ahem A Rivet's Shot wrote:
>> On Mon, 18 Oct 2021 13:19:28 +0100
>> The Natural Philosopher <t...@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.
>>
>Well there is a local shortage of revolutionaries anyway, so we are in
>no hurry...

Really? There doesn't seem to be a shortage of revolting people round here.

--
Basic

[druck]

On 18/10/2021 02:41, Scott Alfter wrote:
> In article <c87cc99f-5fb5-2988...@nimbulus.xyz>,
> randon <ran...@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.

It's one thing having old telnet servers when they are the only remote
shell supported on legacy devices, it's quite another to enable a telnet
server on a modern system when you should be sshd.

---druck

[The Natural Philosopher]

I find it helps to avoid the supermarkets...

--
I would rather have questions that cannot be answered...
...than to have answers that cannot be questioned

Richard Feynman

[Richard Falken]

Re: Re: Telnet
By: The Natural Philosopher to Andy Burns on Mon Oct 18 2021 01:19 pm

> On a switched network, you can't.
> Wifi is more problematic, but its fairly well encrypted.

Switches vary greatly in quality.

Most you can trick into serving somebody else's traffic to you via arp
poisoning or
some other nift trick.

This is very useful if you are trying to send an important college essay and
your flat
mates are preventing you from doing so by consuming all the bandwidth via porn
torrent
downloads. You may use arp poisoning to redirect their traffic to a router you
control
and throttle the connection so the network is usable by everybody else.

--
gopher://gopher.richardfalken.com/1/richardfalken

[Ahem A Rivet's Shot]

On Mon, 18 Oct 2021 16:19:00 +0100
Folderol <gen...@musically.me.uk> wrote:

> Really? There doesn't seem to be a shortage of revolting people round
> here.

Leave them on the side of the plate and stop complaining.

[Joe]

On Mon, 18 Oct 2021 13:19:28 +0100
The Natural Philosopher <t...@invalid.invalid> wrote:

> 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.
>
>

By all means pull the tiger's tail. But he takes a dim view of jokers
and has far bigger teeth than you.

--
Joe

[Joe]

On Sun, 17 Oct 2021 01:02:06 -0400
randon <ran...@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.

> 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.

And do they use the same commands as the telnet client? The ones I've
been using for decades?

--
Joe

[Andy Burns]

Joe wrote:

> randon <ran...@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 ...

[Joe]

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

[Eli the Bearded]

In comp.sys.raspberry-pi, Joe <j...@jretrading.com> wrote:
> Andy Burns <use...@andyburns.uk> wrote:
>> Joe wrote:
>>> randon <ran...@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?

$ 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.

> 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.

"tar-piting" SMTP servers are not unknown, specifically to slow down
spammers by exercising their slow talker acceptance.

https://www.youtube.com/watch?v=B2g_TCYuIAM

Elijah
------
fingerd is also running here

[Richard Kettlewell]

Eli the Bearded <*@eli.users.panix.com> writes:

> Joe <j...@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.

https://datatracker.ietf.org/doc/html/rfc1413

--
https://www.greenend.org.uk/rjk/

[Eli the Bearded]

I have no serious interest in learning how to do ident lookups. They
are meaningless unless you can trust the site operator to enforce
them to be accurate. The last time I needed to use a site that checked
ident was probably in the 1990s.

Here's the Apache module that I don't think anyone uses:

https://httpd.apache.org/docs/2.4/mod/mod_ident.html

There are "zarro" bugs reported for mod_ident, and it isn't mentioned
once in the 300k CHANGES_2.4 file, going back to Apache 2.3.0-dev.
There's one mention in the 2.2.x changes, where it is moved from core to
it's own module as part of the 2.1.1 changes. The last real change
was in Apache 2.0.27, where a bug was fixed that was causing it to
always "bungling" the request thus ensuring a "nobody" response.

Elijah
------
betting the bungling happened on the path from 1.x Apache to 2.x Apache

[Andy Burns]

Joe wrote:

> 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.

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.

> 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.

I was talking more about the SMTP server getting upset if you don't e.g. send
an RCPT TO: within a second or two after the MAIL FROM:

[Joe]

On Tue, 19 Oct 2021 21:19:43 -0000 (UTC)
Eli the Bearded <*@eli.users.panix.com> wrote:

> In comp.sys.raspberry-pi, Joe <j...@jretrading.com> wrote:
> > Andy Burns <use...@andyburns.uk> wrote:
> >> Joe wrote:
> >>> randon <ran...@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?
>
>

Get on with the transaction immediately. I don't think I've ever
noticed this happening in the log file.

--
Joe

[Scott Alfter]

In article <ita6ve...@mid.individual.net>,

Andy Burns <use...@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?

[The Natural Philosopher]

On 20/10/2021 18:39, Scott Alfter wrote:
> In article <ita6ve...@mid.individual.net>,
> Andy Burns <use...@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. :-) )
>

The problem is it is not a sig
vvvvvvvvvvvvvvvvvvvvvvvvvv

> _/_
> / v \ Scott Alfter (remove the obvious to send mail)
> (IIGS( https://alfter.us/ Top-posting!
> \_^_/ >What's the most annoying thing on Usenet?
>

--
“I know that most men, including those at ease with problems of the
greatest complexity, can seldom accept even the simplest and most
obvious truth if it be such as would oblige them to admit the falsity of
conclusions which they have delighted in explaining to colleagues, which
they have proudly taught to others, and which they have woven, thread by
thread, into the fabric of their lives.”

― Leo Tolstoy

[Joe]

On Wed, 20 Oct 2021 17:39:12 GMT
Scott Alfter <sc...@alfter.diespammersdie.us> wrote:


>
> 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.

It's very old, one of the primeval protocols of the Net, like finger,
from the days when most people who used the Net were academics and
were moderately trustworthy.

--
Joe

[Richard Falken]

Re: Re: Telnet
By: Scott Alfter to use...@andyburns.uk on Wed Oct 20 2021 05:39 pm

> In article <ita6ve...@mid.individual.net>,
> Andy Burns <use...@andyburns.uk> wrote:
> >ident is one of the few protocols I tend to configure firewalls to send an
> >active reject, rath

> than 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?

Ident is still relevant for some IRC services. Some IRC servers in actual
networks don't let you in
if your Ident responsie is not convincing.

This still makes sense because a bunch of users connect to IRC using remote
shells.

--
gopher://gopher.richardfalken.com/1/richardfalken

[Eli the Bearded]

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?

Elijah
------
or it could have been normal internet lag

[Joe]

On Wed, 20 Oct 2021 19:21:18 -0000 (UTC)

Eli the Bearded <*@eli.users.panix.com> wrote:

> In comp.sys.raspberry-pi, Joe <j...@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 don't think I've ever had even one reply. I do see 'timeout exceeded'
messages throughout the log, and a lot of obvious spammer connections
dropped for no other reason. Not all, unfortunately.

> 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?

Probably. Most of the rejection code is in RCPT, on the theory that if
told there is no such recipient, they won't bother ringing back. I
don't know how well that works, but it is/was standard advice.

I do know that I found it convenient to run ident on my main
workstation, though I'm not worried about timeouts elsewhere. But I
sometimes send a string of emails quite quickly from the workstation,
and the thirty seconds were irritating.

--
Joe