X/Y/Zmodem transfers over SSH

[Nathanael]

My project this month is putting an RCPM system online. I have one final hurdle: file transfer.

I'll be running the system in a chroot jail, and connection will be via ssh. Since I'm going for authenticity, I'd like to get file transfer via x/y/zmodem and or kermit running, but I've no clue how to do that over an ssh connection. Anyone have any experience or suggestions on this?

--nathanael

[Udo Munk]

Doesn't matter if the connection is with ssh, telnet or tty, this is all transparent for
data transfer. One can run x/y/z modem or kermit protocols over any such
connections. On a RCPM system you could install generic CP/M kermit
and one would be able to use it, communication needs to be set to the console tty
and not some other auxiliary port of course, so that it communicates with the
remote kermit.

[Tony Nicholson]

As far as RCP/M is concerned - all it needs is an 8-bit clean bi-directional
"serial" connection. TCP/IP connections via ssh (or Telnet) handle the
flow-control and should be error-free (unlike the old modem days).

My list of "get a 'round tuit" projects include resurrecting my old RCP/M
system too. I've also used ROS (a compiled menu-driven remote-access
system written in TurboPascal for CP/M) - which has file transfer via
X/Y modem protocol built-in. The source-code for this is on SIG/M
volume 251.

Tony

[Grant Taylor]

On 2/4/21 2:35 PM, Tony Nicholson wrote:
> all it needs is an 8-bit clean bi-directional "serial" connection.
> TCP/IP connections via ssh (or Telnet) handle the flow-control and
> should be error-free (unlike the old modem days).

My experience is that the telnet protocol (proper) is not 8-bit clean.

I've tried to run some things that need 8-bit clean connections a few
times and they have failed every time.



--
Grant. . . .
unix || die

[Tony Nicholson]

Telnet normally intercepts a character (by default it is Ctrl-] under Linux or
Ctrl-^ on OpenVMS) which it calls an escape character (and not to be
confused with the ASCII ESC 01Bh) to do out-of-band mode changes
and similate sending a BREAK etc. The protocol also allows option
negotiation for things like half-duplex echoing and to set various attributes
for a connection. To send this escape character (and not have it
interpreted) you can type it twice - or I think you can force 8-bit clean
by using the -8 or --binary command-line switch when you invoke the
telnet command under Linux (gnu Telnet from inetutils).

Also, running a program like ckermit will also take care of the various
Telnet options when you're trying to use 8-bit clean mode when using it
as a telnet client program.

Tony

[hl351ge]

I've written several Telnet server and client instances, and tested them
with various counterparts. With the exception of few very obscure
antediluvian servers which I consider plain buggy, almost all of them
implemented the RFC856 (binary transmission) and respect a remote
request to use it.

I've seen, OTOH, clients that do not request 8bit by default, though.
Usually, then there is an option to enable it during session initiation.
But since RFC856 is almost one of the first options that get
implemented, any implementation that does not have it is fundamentally
flawed and broken.

This must be distinguished from some obscure, but likewise broken,
telnet software which insists in certain character encodings or
protocols, such as enforcing EBCDIC or 3270 transmission or line modes.
The other side should always be able to reject ("WONT", "DONT") such
non-standard settings, but if the partner doesn't give up this
misbehaviour you get effects that resemble non-8-bit cleanness.

The common modern clients and servers (Windows, Linux, MacOS), though
having subtle differences in what they want to negotiate, at least do
binary transmission correctly.

-hl

[Grant Taylor]

On 2/8/21 1:16 AM, hl351ge wrote:
> I've written several Telnet server and client instances, and tested them
> with various counterparts. With the exception of few very obscure
> antediluvian servers which I consider plain buggy, almost all of them
> implemented the RFC856 (binary transmission) and respect a remote
> request to use it.

This is new information to me. I'll take a look at it some time when I
have a few spare Round-To-Its.

> I've seen, OTOH, clients that do not request 8bit by default, though.
> Usually, then there is an option to enable it during session initiation.
> But since RFC856 is almost one of the first options that get
> implemented, any implementation that does not have it is fundamentally
> flawed and broken.

This is likely the case.

I seem to remember running into the problem on Solaris 6 or 8 systems
and maybe SCO Unix (I don't remember if it was OpenServer or UnixWare).

I do remember going through the manual page at the time and not finding
any option for 8-bit clean.

I ended up writing (read: cobbling together) my own Perl net cat
counterpart.

[rwd...@gmail.com]

I've been testing sc126 with esp-link and telnet and not successfully achieved a good xmodem receive (I'm using ROMWBW with CPM3) using XM, QTERMC3 (cpm3 io calls), QTERMH1 (RomWBW HBIOS calls)). I can transfer in both directions with C-kermit on linux host (doing telnet terminal session) and generic KERM3 on cpm3. I have also tried PuttyTel (which has xmodem support) as host client, and using Tera Term or ZOC with telnet as host terminal.

It does not behave as it does under straight serial connections.

I did notice that my Tera Term is defaulting to line mode on telnet, and not yet discovered how to configure into character mode.

I will do testing to plain cpm, not romwbw, on some other systems, but waiting for a PCB to arrive to allow a link between rc2014 serial header and esp-01s

Richard

[Nathanael]

My last step is getting file transfers working, and I'm failing.

The system is running under CP/M3 / Z3Plus, under YAZE-AG. Currently, the host system is Ubuntu Focal, but I want to run it on a Pi4 ultimately, in a chroot jail, with connection via ssh.

On my Ubuntu host I'm running tty0tty to supply pairs of virtual null-modem-connected ports, and I can get John Saxton's 4COMMS utilities (Tesseract vol. 96) working with Minicom on the host, with "attach aux /dev/tnt0" in YAZE. I've located a generic CP/M3 MEX overlay, but as far as I can tell it can't see the tcpser modem on tnt0.

Has anyone gotten x/y/zmodem / Kermit working under YAZE?

--nathanael

[hl351ge]

Am 05.02.2021 um 01:57 schrieb Tony Nicholson:
> On Friday, February 5, 2021 at 10:47:40 AM UTC+11, Grant Taylor wrote:
>> On 2/4/21 2:35 PM, Tony Nicholson wrote:
>>> all it needs is an 8-bit clean bi-directional "serial" connection.
>>> TCP/IP connections via ssh (or Telnet) handle the flow-control and
>>> should be error-free (unlike the old modem days).
>> My experience is that the telnet protocol (proper) is not 8-bit clean.
>>
>> I've tried to run some things that need 8-bit clean connections a few
>> times and they have failed every time.
>
> Telnet normally intercepts a character (by default it is Ctrl-] under Linux or
> Ctrl-^ on OpenVMS) which it calls an escape character (and not to be
> confused with the ASCII ESC 01Bh) to do out-of-band mode changes
> and similate sending a BREAK etc. The protocol also allows option

The intercept character is not part of the RFC standard; you can well
write a Telnet handler that performs mode changes or OOB signalling
through another channel like a REST API or through cmdline settings. In
such a case there is no special handling, nor entering it twice, and a
CTRL-] is just another character, namely ASCII 0x1D or GS.

The mentioned Telnet clients need this escaping just for historical
reasons because there were no reliable OOB characters, outside the 8 bit
character set, that could be used. Some terminals had an "Attention", or
"Send" or "Interrupt" key which a OS terminal driver could detect and
send something like a signal to a process to have it switch its
online/offline modes. In (BSD) Unix with its wide support of different
terminals one could not rely on a existance of such a key; thus they
fell back to some seldomly used ASCII control code. BREAK on a terminal
does not work since it often just ties the RS-232 TXT line to low level.

In the mainframe world with its line/block mode terminals, usually such
a dedicated key existed, and today it would be possible to recognize
some CTRL-ALT-META-SHIFT-something for that function in order to avoid
the problem that CTRL-] needed to be typed twice.

-hl

[Udo Munk]

hl351ge schrieb am Freitag, 12. Februar 2021 um 15:56:34 UTC+1:
> > Telnet normally intercepts a character (by default it is Ctrl-] under Linux or
> > Ctrl-^ on OpenVMS) which it calls an escape character (and not to be
> > confused with the ASCII ESC 01Bh) to do out-of-band mode changes
> > and similate sending a BREAK etc. The protocol also allows option
> The intercept character is not part of the RFC standard; you can well
> write a Telnet handler that performs mode changes or OOB signalling
> through another channel like a REST API or through cmdline settings. In
> such a case there is no special handling, nor entering it twice, and a
> CTRL-] is just another character, namely ASCII 0x1D or GS.

Such telnet clients have an option to stop using an escape character,
with OSX (and probably other BSD telnet's) -E will do this. See manual.

[Andreas Gerlich]

Hello Nathanael,

Am 12.02.21 um 13:46 wrote Nathanael:

In the tar archive and also in the windows binaries is a .ydsk-file
called "kermit_szrz.ydsk". In this ydsk-file is kermit and sz/rz for
CP/M 3.1.
I use it for a serial connection between a CPU280-System (from Tilmann
Reh) and a Linux PC and kermit runs without any problems. On Linux I
have ckermit an gkermit. Both runs whitout any problem. Sz/rz on CP/M
3.1 runs with the Linux implementation of sz/rz and minicom.

Best Regards
Andreas

--
University of Ulm, Germany
Dipl.-Ing. (FH) Andreas Gerlich
Open Source Projekt: Yet Another Z80 Emulator by AG (YAZE-AG)
http://yaze-ag.de