Considering ZMODEM forwarding about twin

[vanrein]

I decided to have a look at server/tty.c which seems to be the ZMODEM target area.

Some documents on ZMODEM are:

• ZMODEM protocol
• how to support ZMODEM
• lrzsz source code

And in summary they say:

• ZMODEM starts sending proactively with ZPAD,ZPAD,ZDLE,ZHEX or ZPAD,ZDLE,ZBIN or ZPAD,ZDLE,ZBIN32 sequences.
• ZMODEM starts receiving proactively by sending the same variants; the difference follows in the content after these markers.
• The ZPAD are padding, and are the character * which can be skipped; looking for ZDLE suffices. ZDLE is octal 030 or hexadecimal 0x18 or decimal 24.
• There is a formal protocol end, but also a bail-out form of a sequence of ZDLE, five of which count as a break signal to the recipient (the sender actually sends more).

In TtyWriteAscii(), the ZDLE character would be marked as non-printable, so unless control characters were setup for printing, the character would be passed to write_ctrl(). This holds a case 24 setting DState = ESnormal to cause normal printing. Supposedly, the ZDLE code (called CAN in ASCII, and entered manually as ^X) is not used in normal terminal uses, so this is probably a generic treatment for an unknown code? At least stty -a does not list ^X as a signal generator.

So here's the plan that's ripening:

1. Pickup on ZDLE and switch the tty.c module to a mode for ZMODEM transport.
2. Have a builtin.c element (or tty.c globals) to which ZMODEM traffic is passed.
3. In this builtin, recognise the difference between send and receive headers.
4. When sender and receiver meet, proxy traffic between them.
5. Detect breakdown of ZMODEM and decouple at that time; return tty.c to normal.

This allows sz in one window and rz in another, and TWIN would couple them. No issue if the commands run on different hosts, of course. They must be true TTY sessions though, nothing like MOSH. SSH would be transparant to these commands though, so remote access is no problem.

There could be room for default connections to the enclosing terminal. This might require option setting. It might cause multiple attached displays to exchange files too.

Zmodem is a bear. I implemented it similarly to your strategy early on for Qodem, but could not obtain some of the values I wanted to expose on the download/upload screen. In the end I implemented the entire protocol myself and discovered numerous errors in both the protocol and the (l)rzsz implementation. Most are noted at the top of this.

If you are just looking for a way to do Zmodem download inside any terminal session, LCXterm in passthru mode ('lcxterm -p') will do Zmodem (and Kermit) autostart and download.

[vanrein]

Spooky, I just compiled QODEM today! Now also got LCXTERM [0], as it seems to be an interesting tool -- TWIN has value as a TUI that does many of the things you do with LCXTERM, but LCXTERM can be run in other/graphical environments to do the same.

I started this topic with an idea that is new AFAIK, namely to directly connect two terminal sessions engaging in ZMODEM where the TUI or GUI is merely a connector; in the understanding that an admin would trust the sites he visited, he could send from one logged-in host and receive on another, and use this to share files. I regularly need that to keep replicated setups properly in sync. This is a new idea, and it could be very pleasant. I did not finish the work, mostly because I'm better at infrastructure than at user interface code, but the idea is still lurking in my mind.

Other uses of ZMODEM that I can see include running a remote configuration shell and needing to pass data in and out for commands, such as certificates or other goodies. When we operate the shell as an AMQP command queue I can easily attach files to commands, but it would be wonderful to have a shell analogon.

[0] Note that your v0.9 release does not have a tag in Git, and lacks the Makefile.in in the release download.