[HN Gopher] Fun with Kermit and ZMODEM over SSH
___________________________________________________________________
Fun with Kermit and ZMODEM over SSH
Author : fcambus
Score : 102 points
Date : 2023-04-25 16:45 UTC (6 hours ago)
(HTM) web link (www.cambus.net)
(TXT) w3m dump (www.cambus.net)
| bm3719 wrote:
| My only source of internet in undergrad was dialing into my
| university's modem pool and getting a shell on the main server (a
| DEC Alpha running OSF/1). Browsing the web was done through lynx.
|
| That worked fine but every now and then, a site would have some
| inline image that I'd want to see, so I'd view source to get the
| img URL and then download that to /tmp and transfer the file to
| my local machine via zmodem. Usually, it wouldn't be worth the
| effort. I'd also download mp3s off IRC via DCC and queue up a
| bunch of data for zmodem to transfer overnight or when I was in
| class. I really appreciated those bytes back then. Now, not so
| much.
| stuff4ben wrote:
| LOL!! I thought I was the only person who did this. Back in the
| mid-90's I did the same thing. One day I was feeling a bit
| randy and decided to visit a certain centerfold magazine
| website and download some images that way.
| devilbunny wrote:
| One summer, I had access to a local university's Ultrix machine
| (on 4.2 BSD) via dialup. The connection was 7E1, so Zmodem was
| out.
|
| But I could uuencode into a big buffer on my terminal program
| and uudecode locally.
| defaultcompany wrote:
| This reminded me that I used to view images over my dialup
| connection directly in the terminal by catting the image to
| pbmtoascii and making my terminal font 1 pixel high. It wasn't
| exactly pretty but it worked.
| thrownaway561 wrote:
| LOL... The good old days of writing modem strings for OS/2.
| sedatk wrote:
| Thankfully, ZModem existed. I'd never been able to use Kermit
| successfully back in the days, always had trouble with it. I even
| had more success with XModem.
| Koshkin wrote:
| My recent experience reviving an old DOS laptop with a serial
| port is consistent with this.
| themodelplumber wrote:
| Jumping from Kermit to ZModem was quite a revelation for this
| Muppets fan. I was so sad to find I'd been needlessly reducing
| my download speed just by going with the fuzzy green frog, when
| presented with all of the different download options.
| devilbunny wrote:
| You probably didn't have Kermit configured correctly; most of
| us didn't.
|
| When someone finally showed me how to set the options (which
| default to reliable-but-godawfully-slow) for _much_ higher
| speed transmission (bigger segments, sliding windows for ACK,
| maybe a few other things?), it was entirely comparable to
| Zmodem.
| themodelplumber wrote:
| That's pretty funny. I don't remember ever coming across
| configs for Kermit or other protocols, just the [K]ermit |
| [Z]modem -type options on the front end of whatever clients
| I was trying out.
|
| I wonder why more than one client would default to such
| comparatively-lame settings for Kermit though.
| devilbunny wrote:
| The whole protocol does.
|
| IIRC you basically have to get a Kermit prompt and issue
| your commands to the server. Which is easy if you use an
| actual Kermit client, like Columbia put out (though
| apparently for the last 12 years it's been an independent
| project no longer affiliated with the university), but
| most people just used the internal version that came with
| their terminal program - with the primary effect being
| that most people had no idea it was actually a fast,
| flexible protocol (see the long explanation at
| http://www.columbia.edu/kermit/misconceptions.html).
|
| The stated reason for this is that it should always
| default to _working_ , and it's up to you to configure it
| to work _well_ if your connection is better than rusty
| barbed wire.
| myself248 wrote:
| What gets me is that ZModem-Resume had effective continuation
| of failed transfers _decades_ before HTTP got it right. The
| early days of the web drove me bonkers, having to start over
| with a long file that failed in the middle.
| blueflow wrote:
| > before HTTP got it right
|
| In the spec, yes. But since servers use Content-Encoding
| instead of Transfer-Encoding for on-the-fly compression,
| its unspecified now whether the byte offsets in the
| resumption refer to the compressed or uncompressed file.
| Result: Download resumption did not work reliably and got
| removed from browsers.
| Sohcahtoa82 wrote:
| I remember using a program...I forget what it was called,
| but it was popular in the 56K days for resuming HTTP
| downloads. It would even allow you to provide mirror URLs
| so you could download from multiple sources at once.
|
| I want to say it was called WinGet, but now there's
| something else called that, so I can't confirm it.
|
| EDIT: It was called GetRight.
| jedberg wrote:
| Kermit and ZMODEM, now that takes me back. Haven't thought about
| those protocols for a _long_ time.
| pimlottc wrote:
| This is great! Just make sure you upload something as well to
| keep your ratio intact.
| mikecoles wrote:
| The article mentions 'Terminate'. That software was a joy to use.
|
| https://web.archive.org/web/19980627010642/http://www.termin...
| myth_drannon wrote:
| The swiss knife of BBSing... it even had a Cost Manager that I
| used, so my parents won't kill me because of high phone bills.
| rikthevik wrote:
| Yeah, Terminate was a big step up from Telix. Wow that takes me
| back.
| mikecoles wrote:
| Checking up on other old favorites such as BitchX/irssi and
| slrn, I found they're still being developed:
|
| slrn --- NNTP/spool-based Usenet newsreader last updated:
| 2023-03-18T04:31:51 [UTC] repository:
| git://git.jedsoft.org/git/slrn.git tarfile: slrn-
| pre1.0.4-9.tar.gz ( size: 1563860 bytes; md5:
| f193d983e104a82ef4fd70b1037f8b60 ) github:
| https://github.com/jedsoft/slrn
|
| https://github.com/BitchX/BitchX1.3
|
| https://irssi.org/2023/03/31/irssi-1.4.4-released/
| blueflow wrote:
| I'm using irssi right now! There are still active irc
| communities.
| knorker wrote:
| IRC is still alive. I have irssi on a monitor on the side
| all the time, both for friends and work.
|
| IRC is not as big as it used to be, but at its highest it
| was mainstream even for computer illiterates.
| icedchai wrote:
| I still use slrn. In the old days, I used tin! Also, I use
| mutt for one of my old email accounts (used to use elm...)
| anthk wrote:
| I use SLRN daily.
| johnturek wrote:
| Wow. I miss those days. Back when life was simple. I really
| wish my kids could experience working with TSR dos programs,
| and being intentional of what you are trying to do with a
| computer. Every k mattered back then.
| sedatk wrote:
| I even remember its creator's name: Bo Bendsten. I hope he's
| doing okay.
| bananaboy wrote:
| I tried to track him down a few years ago so I could register
| my (previously pirated) copy of terminate. I figured better
| late than never. But I couldn't find him.
|
| I recall that there were some shenanigans with the sale of
| the company. I think there's some messages floating around on
| newsgroups and around the place about it. I found this
| https://paste.ee/p/Z0ywP
| johng wrote:
| HS/Link was the pinnacle during my modem days.
| jerf wrote:
| Hello! Thank you for starting me up! I'm the Kermit protocol and
| I'm happy to hel... wait, you want to transfer _what_ file? What
| the hell is a _giga_ byte? Well, man, OK, you're the user so you
| know best, but man, this is going to take like, days man, settle
| in, here we gooo
|
| ooooooo whooooooo OOOOOOOOO _AAAAAAAAAAAAAAA !!!!!!!!!!1!!
| qcjqrjrcorRC!!!_
|
| WHAT THE HECK WAS THAT? Did I just do _megabytes per second_?
| Holy shit. Am I high or something? What is this hardware? What is
| going on here?
|
| No... wait... is that the end? Am I done here? No! No, I want to
| transfer more! More! Megabytes per second! Gigabytes per second!
| I can see it now, I want it, I want more, please, let's transfer
| another file, come on man, I want to ride again, please ple
| EXECUTION COMPLETED $
| yjftsjthsd-h wrote:
| Thanks for the laugh (but also kind of serious) - reminds me of
| https://xkcd.com/2221/ (what a fast floppy drive you have!)
| Sohcahtoa82 wrote:
| Now I'm wondering if there's ever been emulated software that
| crashed because it tried to calculate a data transfer rate,
| but the emulator transferred the data faster than the delta
| in the time measuring in the emulated machine, so it divided
| by zero.
| Lammy wrote:
| There's a bug like this in all versions of Windows 95, the
| original release of Windows 98, and all of the
| Nashville/Memphis beta releases in between: https://web.arc
| hive.org/web/20030819124031/https://support.m...
|
| "The timing calibration code in the Network Driver
| Interface Specification (NDIS) driver causes a divide by
| zero if the CPU runs at 2.2 GHz or faster. This problem
| does not occur with CPUs that run at 2.1 GHz or slower."
|
| It was patched for Windows 98 (312108USA8.EXE), but '95 was
| left without an official fix due to its age:
| http://lonecrusader.x10host.com/fix95cpu.html
| LeoPanthera wrote:
| The original Macintosh ROM does some floppy drive
| calibration routines on startup to measure jitter in the
| spin rate. A common source of errors when writing a
| Macintosh emulator is emulating a "perfect" floppy drive.
| If the spin rate jitter is zero, the ROM attempts to a
| divide by zero and crashes.
| RobotToaster wrote:
| Not emulated as such, but I seem to remember certain old
| computers having problems with compact flash adapters
| replacing the hard drive because they were too fast.
| kej wrote:
| Emulated or not, old Turbo Pascal programs would crash on
| any computer faster than about 200MHz. The initialization
| code for the CRT module would try to calibrate timing for
| the Delay function and the division would overflow if the
| processor was too fast. See
| https://retrocomputing.stackexchange.com/questions/12111/
| jerf wrote:
| Well, certainly a lot of people running older software have
| had the joy of their disk size being larger than the
| software can handle. There's plenty of software that
| expects the disk size in bytes to fit into an signed or
| unsigned 32-bit int.
|
| I also don't know about data transfer rates but if you want
| to emulate the _really_ old stuff in DOSBox, you 'll need
| to carefully examine pages like
| https://www.dosbox.com/wiki/Performance because there are
| plenty of games that do a divide-by-zero crash when they're
| trying to time the CPU for running at the desired speed.
| mmaunder wrote:
| A few decades from now we'll start seeing interactive AIs on
| emulated platforms asking about president Jon Stewart and
| other 2030s trivia.
| gerdesj wrote:
| My Commodore 64 has a USB interface nowadays (and a few
| replaced caps). Originally it only had a tape "drive" ie
| cassette. After a few years we got a 1541 floppy disc unit.
| Tick, tick tick, whiirrrrrrrr (think: trilled r on speed), fut
| (etc). Instead of 10-15 mins to load a game it loaded in a fair
| few seconds. Bear in mind that the 64 refers to 64 kilobytes.
| $ ls -lh /usr/bin/cp -rwxr-xr-x 1 root root 123K Apr 3
| 19:00 /usr/bin/cp
|
| The copy command on this laptop is 123Kb! ls is 135K. Elite on
| the C-64 has filled 3D polygonal space ships, space stations
| and stuff, a whopper of a galaxy and a HUD that gives you an
| excellent idea of what is where in 3D. You get a trading system
| and ship upgrades etc. Oh and music - The Blue Danube should
| play when one is docking with a space station. Obviously you'll
| need a driver for the joystick and keyboard too. You don't get
| the whole 64Kb to play with either - a fair bit of that is used
| by the system itself.
|
| Before the C64 I used a ZX81 and before that a ZX80 - they had
| roughly 1 kilobyte of RAM. The ZX81 had a RAM pack upgrade
| which added 16Kb. It was a bit wobbly and required a strip of
| Bluetac to stop it crashing the computer when nudged. An uncle
| of mine calls "bloody luxury" on that - he learned programming
| with punched cards - probably ForTran.
|
| This laptop's kernel is 12M and initramfs is 14M and a fallback
| image of 70M. Add to that a microcode image (7M).
|
| You'll be glad to hear that Kermit weighs in at a svelte 26K
| (I've just installed it from the Arch AUR)
| zabzonk wrote:
| i wrote implementations of the kermit protocol (and vt100
| terminal emulators) for z80 cp/m machines and for the 6502-based
| BBC micro (both purely in assembler) way back in the mid 1980s.
| it was fun, and the protocol was really well documented, unlike
| some others i've had to deal with (i'm looking at you DDE &
| CORBA). oh, happy times! a bit later i wrote an implementation in
| C (and a bit of assembler for the interrupt-driven i/o) for the
| ibm pc.
| jebr224 wrote:
| Kermit is still used in the embedded space, on modern platforms
| specifically for uboot.
|
| zmodem can also be used in embedded spaces to retrieve files if
| the only interface is a serial port.
| jabbany wrote:
| This! I still recall using zmodem not that long ago for this
| exact purpose of sending firmware blobs over just a serial
| connection.
| thomashabets2 wrote:
| Here's an ugly script to do zmodem over an SSH connection:
| https://github.com/ThomasHabets/ssh-scripts
|
| Should work through multiple SSH hops, and not giving the hassle
| of using scp through those same sets of hops.
| tech-no-logical wrote:
| zmodem... that brings be back to my BBS days when I had a fido
| node 2:281/909.4. why do I still know that by heart ? playing
| glorious BBS door-games over 2400 baud :)
| marcodiego wrote:
| Project for the future: write an Arduino sketch which will send
| its own (compressed) source code using one of these protocols
| over the serial interface.
| rcfox wrote:
| A telequine?
| Tepix wrote:
| I remember having to deal with Kermit on the dialup line to the
| university. The connection wasn't 8-bit clean and IIRC XON/XOFF
| wouldn't work either on their modem, so it was very finicky and
| flaky whenever you wanted to transfer something.
|
| Aren't brains amazing, storing all those ancient unused acronyms
| for decades?
| [deleted]
| seanmceligot wrote:
| I still miss sz and rz when I ssh from a computer with no ssh
| server like nearly every windows box. If I remember right, sz =
| send a file from the server I'm in back to the client server. rz
| = receive a file from the client server.
|
| You can accomplish the with a new scp session on the client
| server, but it's an extra step. I use this as a helper when for
| building the scp command.
|
| function scppath() { echo
| $USER@$(hostname).$(dnsdomainname):$(realpath $1) ]
| [deleted]
| kej wrote:
| There's a "zssh" project that wraps an SSH session with ZModem
| handling, but it would be neat to see a tool like that this
| didn't require sz and rz installed.
|
| [0] https://zssh.sourceforge.net/
| ractive wrote:
| I never thought, I'd read again about ZMODEM and Kermit. To learn
| programming and dive more into C/C++, I implemented both
| protocols while writing a Windows application to transfer files
| from the PC to a HP48 graphics calculator over the serial port in
| ca. 1999. This app then became the "official" PC link program
| "HPComm", released under the GPL. Almost 25 years go... :-o
|
| https://hpcomm.sourceforge.net/index-old.html
| YesThatTom2 wrote:
| sz and rz! Such good memories.
| geocrasher wrote:
| I came here to say this. I still think rz and sz should be
| supported everywhere. Even now, I can't tell you how many times
| I wish I could grab a file straight form the terminal. We lost
| something when we stopped using zmodem. (and for the record,
| yes, I do know about all the other things that aren't saving a
| file direct from the terminal)
| nrclark wrote:
| On the off-chance that your use-case is "minicom to some
| Linux serial-console", you might be surprised to learn that
| minicom has rz/sz support built right into it! Assuming that
| your remote device has lrzsz installed, you can copy files
| right through your terminal, exactly like you're describing.
| It's certainly not the fastest transfer-rate, but it's handy
| in a pinch.
| spudlyo wrote:
| At my last job, I worked in the PCI cardholder data environment,
| and we were very careful to limit egress from our systems in
| order to make it hard to exfiltrate data in the unlikely event of
| a breach. I remember thinking, if I were a wily hacker and I
| managed to pop a shell on one of these hosts, I would not be
| deterred by network egress roadblocks. I'd figure out a way to
| get `sz` on to a host and exfiltrate data to my heart's content
| with ZMODEM like we did back in the day.
|
| Looks like it's still quite possible, I wonder if our network
| monitoring tools would have noticed gigabytes of data flowing out
| of the network that way.
| yjftsjthsd-h wrote:
| > I'd figure out a way to get `sz` on to a host and exfiltrate
| data to my heart's content with ZMODEM like we did back in the
| day.
|
| Probably as easy as `cat > sz` and then paste it over the wire?
| Maybe run through base64 first. Although actually depending on
| the situation you might be able to just do that directly and
| not bother with this? Like just as a super simple non-
| scientific test: $ ssh someserver cat /bin/ls
| > ./test-ls $ ssh someserver md5sum /bin/ls ; md5sum
| ./test-ls b3535289b2932e25650074aa6d89bf3c /bin/ls
| b3535289b2932e25650074aa6d89bf3c ./test-ls
|
| That looks to work.
| jerf wrote:
| A related trick that can be actually useful is tar'ing on one
| side and untar'ing on the other:
| https://unix.stackexchange.com/questions/19804/compress-a-
| di...
|
| scp is miserably slow on transferring lots of small files and
| this can be wildly faster, plus you get your choice of
| compression program based on what is on each side of the
| connection and what the bandwidth vs. CPU is.
| knorker wrote:
| I tried to sell the OpenSSH team on implementing inline file
| transfer with zmodem once, but they were not interested.
| nvahalik wrote:
| If there is one thing I've hankered for more often than not...
| it's been the ability to send a file over my existing SSH
| connection.
|
| Why this isn't something that isn't supported out of the box is
| beyond me. Doesn't SSH have a control channel? Couldn't it
| support this without text mode hacks?
| knorker wrote:
| SSH has both control channels and escape codes. They could
| add this to the \n~? codes.
| diydsp wrote:
| > There is something quite special about seeing ZMODEM transfers
| reach speeds close to 600 MBit/s. It's hard to explain.
|
| Yep that's 1.5 million times the speed I used to get.
| rsync wrote:
| So, on the one hand ...
|
| I have actually used 'sz' and 'rz' in _relatively_ modern times
| for quick and dirty file transfer and found it very convenient in
| a very narrow set of use-cases.
|
| However ...
|
| It's a serious violation of the cleanliness and available attack
| surface involved in a terminal interface and we should be on the
| lookout for, _and reject_ , similar interfaces and applications.
|
| In order for zmodem to work over the terminal, the terminal
| program itself needs to know something about the text flowing
| over the connection and then invoke special, extra routines based
| on monitoring that textual flow.
|
| This opens up all manner of weird, extra attack surface.
|
| The _beauty of the text terminal_ is that I can, theoretically,
| _cat any file I want to_ without fear of what it contains. I can
| open up (perhaps with 'strings' or 'hexedit') any email
| attachment without fear of the strings that it contains. I can do
| this because I am using a _dumb terminal_.
|
| As soon as the terminal is smart - even a little bit - you've got
| vectors for weird strings doing things you don't want them to.
| blueflow wrote:
| I have bad news for you. Do you know what (n)curses is for? Its
| basically a library for those magic strings (and ascii control
| characters) that run extra routines in the terminal. And every
| terminal has these routines.
| mbreese wrote:
| As I see it, the parent is specifically worried about the
| terminal needing to monitor input and fork a process in
| response. Control character handling should be pretty robust
| (or worst-case, a NOP). Curses-based programs read/write
| specific control characters to move the cursor, etc (really
| any tty should support control characters).
|
| But they don't fork a new process... (unless I'm very
| mistaken).
| blueflow wrote:
| See xterm manpage, "printerCommand" or urxvt manpage,
| "print-pipe". They may be triggered remotely by the media
| copy commands. Good news is, this is supposed to be
| disabled per default.
| jmclnx wrote:
| Interesting, I used kermet on Coherent to dial into work. Once I
| started it, work would call be back so I would not have to pay
| for the session on my phone bill.
| distantsounds wrote:
| lrzsz is one of the first packages i install when configuring a
| new system. being able to send and receive files between remote
| and local without needing a separate ssh session is such a time
| saver. it's really fast as well. i do wonder if anyone has
| developed something more modern to make it even more performant?
| svennek wrote:
| how do you do that, also through qodem or ?
| somat wrote:
| I have used bare netcat to transfer files. works well enough
| when the link is good, when it's not... Well I suspect that is
| when you dig out better tools.
|
| nc -l 1234 > fname
|
| nc host 1234 < fname
| poettering wrote:
| Still would love if desktop terminal emulators would implement
| the zmodem receiver side, so that you can ssh into some host of
| your choice and just type "sz" to copy arbitrary files of your
| choice onto your local system.
| anthk wrote:
| Just use sshfs, or rclone mount, and use the old
| cp -r
|
| to get your files. MC can connect to ssh/ftps too, and you can
| copy files and dirs from pane to pane.
| glonq wrote:
| Last year we implemented "ymodem over BLE" for reasons that are
| complicated and possibly stupid.
|
| It felt familiar but strange and wrong to do such a thing. Worked
| great though.
| jhallenworld wrote:
| I still use these protocols for embedded systems. There is
| almost always a CLI on a UART, so one should be able to
| transfer files.
|
| Ymodem is simpler and smaller than Zmodem, but we've used both.
| I've used Zmodem at 921600 baud, but it needs fairly large
| buffers (for a UART) to work.
|
| One of the big advantages is that TeraTerm for Windows exists,
| and supports xyzmodem. It means that I often don't have to
| write any host-side software for things like firmware update,
| and more important, don't have to touch Windows.
| kevin_thibedeau wrote:
| A former employer still insists on using Xmodem-1K even
| though Ymodem is almost the same and provides so many quality
| of life improvements with the header block. It was endlessly
| annoying to have to manually tell the receiving end the file
| size and name when a simple upgrade would obviate the need.
___________________________________________________________________
(page generated 2023-04-25 23:00 UTC)