Convergent Technologies MightyFrame: UMODEM - more than just an obsolete file transfer protocol...

OK, well not really...BUT...since this is the only relevant protocol to transfer files that I can find on the UNIX PC, I'm going to figure out how to get it to run on a modern linux machine. The FTP protocol that we all know and love today, and still use, seems nowhere to be found on the UNIX PC.

So...

Page 4-10 of the UNIX PC Terminal Emulation guide talks about it, but helps little.
Knowing how it was used with other UNIX PCs in 1985 is a start, and only a start.

See the version with settings and blunders

Now that that's done, what about communicating with a modern machine capable of being connected with the outside world?

locating the right file to configure UMODEM in ubuntu 11.10

Well that went nowhere...how about

page 15 of 'Computer News - For HP Field Personnel Worldwide - January 15, 1985'

"Files can be transferred using the UMODEM protocol, which is the same protocol as XMODEM and MODEM7 which is built into the terminal program in The Portable."

Same as XMODEM and MODEM7? What the heck are those?

Well, if they are the same, then sending a file via XMODEM should be able to be read by UMODEM...right??

and BINGO! We have liftoff!!!

Send file by xmodem or kermit protocol with GNU screen

Which tells us: the best way to pass a file through xmodem is to use 'sx'. In debian this application is part of 'lrzsz' package.

apt-get install screen lrzsz

Once that is complete:

screen /dev/ttyUSB0 9600

Then press Ctrl-A followed by : and type:

exec !! sx yourbinary.bin

This will send the file to ttyUSB0 over xmodem protocol

And it WORKS!

Using a USB to COM port adapter on the linux machine (thus the ttyUSB0 device), and a full handshake null modem adapter to DB25 cable, to RS232 port on the UNIX PC.

Make the call from the UNIX PC first just like shown above. Initially, there will be no response, ie, a blank screen.

Then, open a terminal on the linux machine, and execute the commands listed above to transfer files.

In this case, I'm sending the 'gkermit' file

Sending /home/mightyframe/Desktop/UNIX-PC/gkermit, 338 blocks: Give your local XMODEM receive command now.

Then back on the UNIX PC, go through the same steps to receive a file using UMODEM.

Now, can I do this in reverse, and send a file the other way?

YES! I can...It's simply

exec !! rx /home/mightyframe/Desktop/UNIX-PC/[filename]

and then Transmit File - UMODEM on the UNIX PC instead of Receive file.

For reference, this magic program is located on the hard drive at:

/usr/bin/umodem

I created this File Transfer Time Status Calculator
The shaded green cell is the only cell that must be edited, where you enter the file size (in number of bytes) that is being transferred using the UModem 9600 baud process

----------------------------------------------

CPIO - The key to transferring a full hard drive dump over UMODEM?

NO! Forget CPIO...use TAR! If you want to see all about why below. Then jump to the TAR section

Maybe...let's see...first hurdle:

Creating the CPIO file on the Xubuntu machine using these commands, where my intent is to create a cpio file containing the contents of the "install" directory at

/home/mightyframe/Desktop/Part1.tar/install/

I execute these commands:

cd Desktop/Part1.tar/install

find -print | cpio -o > /home/mightyframe/Desktop/UNIX-PC/SendFiles/install.cpio

Then I use the UMODEM procedure I demonstrate above to transfer the newly created install.cpio file from the Xubuntu machine to the UNIX PC. The transfer processes without error or incident.

Then, on the UNIX PC, executing the

chmod ugoa=rwxrwxrwx install.cpio

So far, so good. Then, I do this:

#cpio -i -t < install.cpio

Out of phase--get help

What???

This ends up being a very short google search...

Now in this google search is this gem, discussing a somewhat related cpio issue with the 3b1. This discsses a non-related but important topic for me...the dev/xxxx that writes VHBs to both floppies, and hard drives...if dev/rfp021 skips the header, there is one that writes to the header...hmmm...

How about dd? Can I use that on both the Xubuntu and UNIX PC ends, and get the formats to be uniform?

Or installing tar on the UNIX PC??

I am so new to this so old stuff...

----------------------------------------------

TAR - a better option for transferring groups of files to the UNIX PC

I downloaded the "3b1 copy", if there is such a thing, from this site:

http://unixpc.taronga.com/arcinfo.html

Then transferred it to the UNIX PC.

I had to change the rights with

# chmod ugoa+z tar

At least I can type tar and get commands.

From: Tom Trebisky
Date: Sat, Oct 18, 2014 at 11:11 AM
Subject: Re: or tar?
To: Convergent MightyFrame

Holy cow! Well tar is one of those things I use almost every day in the linux world.

So now if you were gonna move say the whole bin directory you would do

1) on linux
cd ctix/bin
tar cvf /home/AJ/ctix_bin.tar .

2) tansfer the gigiantic ctix_bin.tar via umodem. Note that I use an absolute path to tell it to write the tar archive outside the current directory. Sometimes I use ../ctix_bin.tar to put it one directory back. It is just problematic to write the tar file inside the directory you are tarring up. It isn't the end of the world to do so, I think you usually just get a silly zero length tar file inside the yada.tar file or something, but I avoid it.

3) then on the unixpc:
cd /mnt/bin
tar xvf /home/wally/ctix_bin.tar

The other command I use all the time with tar is:

tar tvf yada.tar

This just shows the contents of the tar file without extracting it.

AHA!! I just peeked at your screen shot and there is a major time saver available, namely the "z" switch which compresses the archive. So change the above commands to:

tar czvf /some/place/ctix_bin.tz

tar xzvf /some/other/place/ctix_bin.tz

The "tz" ending just makes things clear. Often you see .tgz files distributed. The compression should make the tar files significantly smaller and probably save hours in the umodem transfer.

Of course test fly all this with something small first ...

-----------------------------------------

So, first try error on the linux machine:

I previously extracted all files from your part1.tar.gz file to /ctixhd/

install is one of the directories within, that is smaller, seemingly all text files, so I have been testing with this one.

# cd /ctixhd/install

# ls -l
total 52
-rw-rw-r-- 1 mightyframe mightyframe 24787 Sep 20 23:07 ctinstall
-rw-rw-r-- 1 mightyframe mightyframe 212 Sep 20 23:07 CTIXRel
-rw-rw-r-- 1 mightyframe mightyframe 873 Sep 20 23:07 getfopts
-rw-rw-r-- 1 mightyframe mightyframe 1021 Sep 20 23:07 getgrps
-rw-rw-r-- 1 mightyframe mightyframe 1244 Sep 20 23:07 Ins.Core1
-rw-rw-r-- 1 mightyframe mightyframe 1343 Sep 20 23:07 Ins.Core2
-rw-rw-r-- 1 mightyframe mightyframe 3768 Sep 20 23:07 Ins.Core4

# tar cvf /home/mightyframe/Desktop/UNIX-PC/SendFiles/install.tar
tar: Cowardly refusing to create an empty archive
Try 'tar --help' or 'tar --usage' for more information.

I'm glad that it admits that it's being Cowardly, but why does it not see any files to create?

http://bit.ly/1tC8sam

So I got the inspiration for a work around from this post/article:
https://discussions.apple.com/thread/879214?tstart=0

Specifically in:
foilpan Mar 6, 2007 3:57 PM
Re: create tarball reading file paths from stdin? in response to foilpan
the original poster omitted the find command from his testing. this works for me:

find ~/tarred -type f | xargs tar cvf tarred.tar

results in tarred.tar containing just the regular files in the ~/tarred directory.

is that closer to what you're looking for?