• Please review our updated Terms and Rules here

MS Kermit File Transfers - What am I missing?

shrike

Member
Joined
Aug 15, 2022
Messages
36
Location
Seattle, WA
I'm tearing my hair out here. I have been trying to figure out how to transfer files to/from some older DOS machines using Kermit. I have tried everything I can think of but Kermit file transfers are completely unreliable and usually just fail. I have tried on-board serial ports, USB-Serial adapters, connecting to Linux hosts, FreeBSD hosts. Several different DOS machines from a 5150 with PC-DOS 3.3 to a 486 with MS-DOS 6.22. I've tried all the speed settings, parity, hardware flow control, software flow control, several different cables... everything I can think of.

I will launch MS Kermit (v3.14) on the DOS machine, set my communication preferences, connect to the server, login and run kermit on the remote host. The remote hosts run whatever versions of ckermit come with their distributions, but are all modern. I put ckermit into server mode, escape back to the local machine. At that point I can run remote commands like 'remote dir' 'remote pwd' etc... all those work fine.

However when I try to actually start a transfer, the same thing happens every time: It will start out fine, the packet counter will start ticking up but then anywhere from 1-30 seconds into the transfer things will stop, the retry will shoot up and the transfer will abort with an error "No response from the host!"

What am I missing? Is Kermit all it's cracked up to be for serial transfers?

The only thing that I have managed to get to work is using 'sz' (lsz) on the remote host and Telix 3.15 on the DOS machine. That arrangement transfers smoothly, and without error. I have tried 1MB files of random data with no problem this way. As a side note, though, ProComm 2.3 also failed when using sz.
 
Been a long long time since I messed with Kermit, but there are multiple types of flow control. Xon/Xoff for example. Then there is CTS/RTS. This needs to be dialed in for Kermit to work.
 
Interesting, 3.14 works for me in between itself without any special configuration. Kerlite on XT, same Kerlite on Win95 machine, no login/terminal stuff, just set commands for ports on both sides (speed/parity/stop), file type to whatever you need and go.
However when I try to actually start a transfer, the same thing happens every time: It will start out fine, the packet counter will start ticking up but then anywhere from 1-30 seconds into the transfer things will stop, the retry will shoot up and the transfer will abort with an error "No response from the host!"

Are you sure you aren't trying to get a binary file over ASCII transfer method?
 
in ckermit before performing the transfer try typing the command "robust"

Yeah, I've tried "robust" "cautious" "fast on both ends, with the same effect.

Are you sure you aren't trying to get a binary file over ASCII transfer method?

I have found Kermit to be pretty good about detecting when to use Binary/ASCII. But I have tried explicitly setting it also, and it still fails the same way.
 
let me give my experience and my conclusion.

The problem is connecting via telnet session. you have to setup a serial to serial connection of some kind.

I have a Altair 8800 and i wanted to connect to my raspberry pi using a wifi modem.

i started to notice an issue when i wanted to connect to telnet BBS via wifi modem.

i would connect to the telnet BBS no problem everything worked until i wanted to download a file from the Telnet BBS.
at that point when downloading Xmodem, i would get CRC errors and time out.

I noticed i could upload via Xmodem to these telnet BBS no problem and no error.

then i noticed that some Telnet BBS did not work when i had Telnet mode enabled... i would turn off telnet mode on the wifi modem. On those BBS i could upload and download no issues.

then i changed to wanting to connect to my raspberry pi. i would use my wifi modem in Telnet mode connect to my telnet session on my pi and everything worked until i tried to use a X-modem transfer.
I could use kermit and i could upload from my altair to my rasberry pi but CRC timeout errors on downloading.

at that point i started to setup diagnosics with an old PC... i found that when i connected wifi modem to wifi modem from my altair to my PC i had no issues with Xmodem transfer. i could even setup a BBS on my PC and connect and send
files back and forth using procomm or kermit.

when i connected from wifi modem over IP to the pc in a telnet method i was once again blocked from downloading but i could upload.

telnet requires two 255 characters be sent and the software usually compensates collapsing the double 255 character into a single. but the wifi modem was not doing
i then could see the same issue occuring when i used two PCs and tried to use a wifi modem on one side of the connection. IP to IP works, Wifi modem to Wifi modem worked, Telnet/ip to wifi modem blocked connection in one direction no matter what.

for months i played around with Getty settings and software. would always block in one direction.

i came to the conclusion i would have to have a direct serial connection to do what i wanted, that was the only way to avoid telnet and the double 255 character.

again i tested this idea with the various telnet BBS, the ones that required telnet mode enabled or disabled and only the disabled accepted sites worked with file transfers.

so i have the same issues with SX and RX on my unix machine.

i started to work on setting up serial with my pi but it kept screwing up and causing the device to lockup and then i would have to create a new SD disk and start over, so i basically gave up.

I know what the issue is now at least and it is not your hardware.

i thought about writing a xmodem transfer program that just ignores checksum or CRC and just sends the packets regardless, i started to write it in basic, but then i lost interest because i could just use my windows 10 machine as a go between.

my altair is connected via serial USB to my windows 10 machine and i wrote some Xmodem software that just transfers back and forth between the two machines via direct connect.
but the raspberry pi is remote so there is no physical connection.

at any rate i can connect via wifi modem to my PI and then use the utilities on there like browsing the web using Elinks.
then i can download what i need and connect via my windows 10 machine and just telnet session transfer from the PI to the windows 10 machine then just transfer to my Altair 8800, its round about and it breaks that RPG feeling of vintage computing
but really what can you really do with a vintage computer online today anyway.

plus all the telnet BBS in existence are pretty broken now anyway they have really nothing of interest you can't find directly from the original sources like winworld or some CP/M backup site.

there was one interesting telnet BBS i found for the HP 48 calculator then i found out i could just download the entire archive that the BBS was hosting, and the archives on that BBS were corrupted anyway.

anyway
here is a Elinks session on my altair with graphics.



so to recap. i went down the same road as you with Kermit and Kermit Server, found the connection was basically one way for file transfers, i could upload from altair to pi no problem, but downloading from PI to altair resulted in CRC error and time out all the time.
found out if i did not have to use telnet mode on my wifi modem then i could transfer files in both direction with ZERO issues and i could use RX and SX, RY,RZ,SY,SZ also so long as i used different software, but mostly i use IMP 2.45 8 bit hacked.
i spent months ripping my hair out using multiple computers to setup tests to figure out what was happening as well.

conclusion, have to direct serial connect between 2 machines then telnet is not a problem anymore and i can transfer back and forth via Xmodem.

however i already have a direct serial connection to a windows PC so that kind of gets around the issue anyway, its just i can't direct download, i have to download in a temp area, transfer it from another machine then put it on the machine i wanted to directly transfer to.


hope this helps.
 
When I was using Kermit 3.13 with a Victor 9000, I played around a bit to get it to work with a modern kermit on my mac. I ended up using:

On Victor:
set baud 38400
set xon-xoff off


On Mac:
set line /dev/tty.usbserial-FTCGX2CN
set baud 38400
set mode flow-control rts/cts
set window 3
set receive packet-length 1000

then type
receive filename
on the machine you want to move the file to.
 
IIRC it should just work - or very nearly. Earlier this year I transferred the entire contents of a 20MB disk in an old Turbo XT over serial to my windows PC and it worked fine. I was running MS-Kermit 3.16 Beta 7 on DOS, and Kermit 95 3.0 beta 5 (C-Kermit 10 beta 10) on Windows 11.

I do remember having some initial difficulty getting things to transfer reliably - I think lowering the serial port speed in the end fixed it, but it was several months ago now. What I do remember was that I spent more time getting the transfer to preserve directories than I did getting it to transfer files reliably.
 
Last edited:
The 3.14 commands I used

Code:
SET PORT COM1  
SET SPEED 19200  
SET PARITY EVEN
SET FLOW NONE

The realistic transfer speed on my XT is about 14.4 kbaud or a bit less than 2 kB/s. No flow control and 19200 baud on both sides yields me stable transfers. I've moved several MB in hours stably.

P.S. one of massive QoL for my XT in file transfers is Ethernet/MTCP and ftp transfers or just http downloads. The real transfer speed is N-fold, about 15kB/s. If you find yourself in situation where you repeatedly move data from old boxes via the wire, see whether getting them on LAN suits you.
 
I've had pretty good successes with my Kaypro 4s and my modern Linux laptop using Kermit 3.??.

All I did was use a standard null-modem-to-USB cable.

Transfers FROM the Kaypros were good at 9600 BPS.
However, TO the Kaypros were limited to 300 BPS. It was mainly a flow control issue because the Kaypros needed to pause to write the data to disk and if that took too long, the transfer would fail.

na103's suggestion of using "robust" on the Linux side did a really good job of making the transfers more reliable.
 
Thanks for your responses everyone!

To close the loop on this, the magic incantation for transferring files from a fast UNIX machine to a slow vintage PC is to lower the 'send packet-length' on the UNIX/CKermit side:

SET SEND PACKET-LENGTH 300

300-500 seems to be about the upper limit over a 38400 bps link to my 5150, where I can get up to about 2000 on a 57600 bps link on my 486.

Previously I had been trying to limit the packet length using 'SET RECEIVE PACKET-LENGTH' on the PC/486 side, but my fast UNIX servers were just overwhelming the poor little machines and Kermit couldn't keep up with limiting the packet length automatically (as I understand it is designed to do).

Cheers
 
That just seems really weird. I mean, it is what it is, but with proper flow control, the faster machine should not be able to overwhelm the smaller machines, regardless of the packet length.

With a longer packet length I assume you're more likely to run into an error, and thus discard the entire packet (particularly expensive over a slow connection) -- that's why packet length might matter at all. But over a clean connection, it really shouldn't matter.

But, hey, as long as it works, bravo!
 
Back
Top