Considering ZMODEM forwarding

[vanrein]

Is it a strange idea to support ZMODEM passthrough via a service in the event interface? I still think of it as a highly useful protocol, but it is ancient... so, to refresh your memory:

• ZMODEM stems from download-and-upload-during-tty-sessions era, for instance used with modems and BBS dial-in.
• ZMODEM is well integrated into ttyd as you can see from running sz or rz as contained in package lrzsz on a TTYD-supported terminal
• ZMODEM would not work over MOSH sessions
• ZMODEM predecessors XMODEM and YMODEM were never formally deprecated, but add nothing.

What could make sense?

1. Sending sz and rz initiation frames to a central place, which connects them
2. ZMODEM in terminals may relay directly to ZMODEM with their container (the dial-in modem, so to say, or TTYD)
3. ZMODEM in terminals might be cross-connected (transport data from /dev/pts/7 to /dev/pts/12)
4. There might be a way to criss-cross between TWIN sessions? Attach and Display are still unclear to me though.
5. Directories like $HOME/Downloads or dynamic plugins such as USB storage sticks may provide a ZMODEM upload/download target.
6. Tools based on twdialog or dialog could arrange file transmission via sz.
7. We're working towards a hosted storage facility that could also connect to such a ZMODEM file services, even for stateless/PXE environments.

The flavour one would desire is a matter of taste, I suppose. All it requires is recognising the initial TTY codes for ZMODEM, and passing them to a central place in the TWIN environment that implements the personal taste.

I was wondering if it made sense to use your event system for these ZMODEM connections, but I cannot tell as I find the code difficult to follow. Any suggestions or guidance?

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

[ghost]

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.