|
Home > Archive > Unix Programming > December 2004 > File transfer over serial port
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
File transfer over serial port
|
|
| Anirudh Ramachandran 2004-11-20, 5:49 pm |
| Hi,
I have to transfer files from one unix machine to another over the
serial port. I know that there are standard protocols (x/y/z modem),
and I have also implemented a client-server model application, where
the server listens to, say /dev/ttyS0, and gets the file (using a very
minimal handshake protocol).
But what I need to do is this: The server end cannot be accessed by any
means other than the serial port, and neednt even have a c compiler
running. I have to put the binaries for the server using some basic
unix utility (not a third party modem program). I can assume that I
have root on the server machine (so that I can give write access to
/dev/ttyS0), but which basic tool listens to communication on this
port?
Thanks in advance,
Anirudh
| |
| Victor Wagner 2004-11-20, 5:49 pm |
| Anirudh Ramachandran <anirudhvr@gmail.com> wrote:
> Hi,
> I have to transfer files from one unix machine to another over the
> serial port. I know that there are standard protocols (x/y/z modem),
> and I have also implemented a client-server model application, where
> the server listens to, say /dev/ttyS0, and gets the file (using a very
> minimal handshake protocol).
> But what I need to do is this: The server end cannot be accessed by any
> means other than the serial port, and neednt even have a c compiler
> running. I have to put the binaries for the server using some basic
> unix utility (not a third party modem program). I can assume that I
> have root on the server machine (so that I can give write access to
> /dev/ttyS0), but which basic tool listens to communication on this
> port?
Typically, if there is no other way to access machine, getty program
listens on the port. It asks you for username and invokes login process,
which ends up having shell running with you uid, attached to this port
with its stdin/stdout/stderr.
> Thanks in advance,
> Anirudh
--
One of the signs of Napoleon's greatness is the fact that he once had a
publisher shot.
-- Siegfried Unseld
| |
| Lőrinczy Zsigmond 2004-11-20, 5:49 pm |
| Anirudh Ramachandran wrote:
> Hi,
>
> I have to transfer files from one unix machine to another over the
> serial port. I know that there are standard protocols (x/y/z modem),
> and I have also implemented a client-server model application, where
> the server listens to, say /dev/ttyS0, and gets the file (using a very
> minimal handshake protocol).
> But what I need to do is this: The server end cannot be accessed by any
> means other than the serial port, and neednt even have a c compiler
> running. I have to put the binaries for the server using some basic
> unix utility (not a third party modem program). I can assume that I
> have root on the server machine (so that I can give write access to
> /dev/ttyS0), but which basic tool listens to communication on this
> port?
Perhaps tar -f /dev/ttyS0 ?
Use stty beforehand to set port-options on both side
| |
|
| Hi,
maybe you can use kermit
Johan
"Anirudh Ramachandran" <anirudhvr@gmail.com> schreef in bericht
news:1100966054.279074.151810@z14g2000cwz.googlegroups.com...
> Hi,
>
> I have to transfer files from one unix machine to another over the
> serial port. I know that there are standard protocols (x/y/z modem),
> and I have also implemented a client-server model application, where
> the server listens to, say /dev/ttyS0, and gets the file (using a very
> minimal handshake protocol).
> But what I need to do is this: The server end cannot be accessed by any
> means other than the serial port, and neednt even have a c compiler
> running. I have to put the binaries for the server using some basic
> unix utility (not a third party modem program). I can assume that I
> have root on the server machine (so that I can give write access to
> /dev/ttyS0), but which basic tool listens to communication on this
> port?
>
> Thanks in advance,
> Anirudh
>
| |
| Anirudh Ramachandran 2004-11-21, 7:47 am |
| tar says that it needs one of the '-Acdtrux' options. I assume that we
want to extract files from the device, so I specified tar -xf
/dev/ttyS0...nothing happens, though the connection is up and all port
settings are correct (I used the program miniterm.c, provided with the
linux programmers guide examples to test the connection). What could be
the problem?
Thanks,
-- Anirudh
| |
| Trent Buck 2004-11-21, 7:47 am |
| Quoth Anirudh Ramachandran on or about 2004-11-21:
> tar says that it needs one of the '-Acdtrux' options. I assume that we
> want to extract files from the device, so I specified tar -xf
> /dev/ttyS0...nothing happens, though the connection is up and all port
> settings are correct (I used the program miniterm.c, provided with the
> linux programmers guide examples to test the connection). What could be
> the problem?
This may be completely wrong...
Serial lines work like a pipes, right? So tar is sitting there because
it's waiting for the sender to send something?
Sender:
tar -C /usr/local/bin cf /dev/ttyS0 *
Receiver:
tar -C /usr/local/bin xf /dev/ttyS0
-trent
| |
| Floyd L. Davidson 2004-11-21, 5:49 pm |
| "Anirudh Ramachandran" <anirudhvr@gmail.com> wrote:
>tar says that it needs one of the '-Acdtrux' options. I assume that we
>want to extract files from the device, so I specified tar -xf
>/dev/ttyS0...nothing happens, though the connection is up and all port
>settings are correct (I used the program miniterm.c, provided with the
>linux programmers guide examples to test the connection). What could be
>the problem?
The miniterm.c program is, ahem... horrible.
But, if you know what you are doing or are lucky, it will
accomplish exactly what you want, which is to test a serial
port. However, the fact that it works when you run _miniterm_
says *nothing* about "the connection is up and all port settings
are correct". It does say that *if and when* all port settings
are correct, then the serial port connection will be up.
You'd have to use _stty_ to configure the port settings if you
insist on using something like _tar_, which was not designed to
control a serial port connection and does nothing to configure
one. It seems to me that you'd be far better off using
something which does exactly that. In any case you will need
some type of script or configured program. Why not use one that
was intended for serial port use and makes it easier?
_Kermit_ seems to be the choice of those who do that the most.
Certainly other programs can do it too. _Minicom_, _pcomm_, _seyon_,
_cu_, or you could even set up UUCP or a PPP connection over the
serial port, and then use network oriented tools. (I see *no*
advantages to UUCP or any of those listed before it. They are
merely examples of things that a knowledgable person could make
do with in a bind.) I'd personally say a PPP connection is by
far the most versatile, but using _kermit_ is certainly adaquate
and simple for just file transfers.
And of course, yes if you want to write your own script and do
it the oddest way possible, using _stty_ and _tar_ will work and
you will learn a bit! In that respect, Trent Buck did give you
essentially the right commands for _tar_, but that isn't the
best approach.
#!/bin/sh
#
# This is not a complete script and it has not been tested.
#
# put all commands into a subshell that is redirected to the
# desired serial port, thus allowing the port to be configured
# with one command and used by another, while inside the
# subshell which keeps the port open, and thus retains the
# configuration between commands.
(
stty ... # port configuration commands as necessary
tar -C /usr/local/bin cf - * # sender script
#tar -C /usr/local/bin xf - # receiver script
) > /dev/ttyS0 < dev/ttyS0
# end of file
One possible way to find the right configuration would be to use
_miniterm_ (or any other serial port terminal program) on both
ends and get a working port configuration. Then use _stty_, in
another window while _miniterm_ has the port open, to save the
configuration of each side,
stty -g < /dev/ttyS0 > port.config
Which will print one big line of settings to file /port.config/,
which will look something like this:
500:5:cbd:8a3b:3:1c:7f:15:4:0:1:0:11:13:
1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:
0:0:0:0
You can put that directly into your script, or keep it in a file
if you like. The _stty_ command might look something like this,
CONFIGFILE=.../port.config
CONFIG=$(cat $CONFIGFILE)
(
stty $CONFIG
tar ...
) ...
Maybe _kermit_ is a good idea... eh?
--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com
| |
| Stefaan A Eeckels 2004-11-21, 5:49 pm |
| On Sun, 21 Nov 2004 14:36:49 GMT
Trent Buck <NOSPAMfubarbaz@bigpond.com> wrote:
> Quoth Anirudh Ramachandran on or about 2004-11-21:
>
> This may be completely wrong...
It is.
> Serial lines work like a pipes, right? So tar is sitting there because
> it's waiting for the sender to send something?
>
> Sender:
> tar -C /usr/local/bin cf /dev/ttyS0 *
> Receiver:
> tar -C /usr/local/bin xf /dev/ttyS0
Better use Kermit. It's available pre-compiled for almost
any machine, recent or ancient, and is the tool of choice
for this kind of situation.
Take care,
--
Stefaan
--
"What is stated clearly conceives easily." -- Inspired sales droid
| |
| Bill Marcum 2004-11-24, 2:59 am |
| On 20 Nov 2004 07:54:14 -0800, Anirudh Ramachandran
<anirudhvr@gmail.com> wrote:
> Hi,
>
> I have to transfer files from one unix machine to another over the
> serial port. I know that there are standard protocols (x/y/z modem),
> and I have also implemented a client-server model application, where
> the server listens to, say /dev/ttyS0, and gets the file (using a very
> minimal handshake protocol).
> But what I need to do is this: The server end cannot be accessed by any
> means other than the serial port, and neednt even have a c compiler
> running. I have to put the binaries for the server using some basic
> unix utility (not a third party modem program). I can assume that I
> have root on the server machine (so that I can give write access to
> /dev/ttyS0), but which basic tool listens to communication on this
> port?
>
> Thanks in advance,
> Anirudh
>
If the server has pppd, start that on the serial port, and use ftp,
nfs, any network protocol. Otherwise, try uucp.
--
"At a scheduled time, the robot would pull the flush lever and scream as
it got sucked down the drain." --Kibo
| |
| Anirudh Ramachandran 2004-12-07, 5:52 pm |
| Thanks for the helpful advice. tar works in most cases, but if the file
is a binary, it's pretty likely to be screwed up. Since I want to put a
binary on a computer which is accessible only via a serial port, I was
thinking along the lines of a bootstrapping method, viz, first transfer
executable code (since I don't have a compiler) as text (say), then use
this to create a better server etc. etc. How feasible does this seem?
Any hints or tips on how to go about it are welcome.
Thanks in advance,
Anirudh
| |
| Chris Barts 2004-12-07, 5:52 pm |
| Anirudh Ramachandran wrote:
> Thanks for the helpful advice. tar works in most cases, but if the file
> is a binary, it's pretty likely to be screwed up. Since I want to put a
> binary on a computer which is accessible only via a serial port, I was
> thinking along the lines of a bootstrapping method, viz, first transfer
> executable code (since I don't have a compiler) as text (say), then use
> this to create a better server etc. etc. How feasible does this seem?
> Any hints or tips on how to go about it are welcome.
> Thanks in advance,
> Anirudh
>
First, are you sure binary files are going to be munged in transit? I
home you aren't trying to use a system that's this broken, since it's
likely so primitive it will lack other things, making bootstrapping it
that much harder.
Anyway, I think uuencode and uudecode have been available on Unix
systems and systems that had to talk to Unix systems since the very
early days. uuencode will turn an arbitrary binary file into a longer
text file, and uudecode will reverse the process. They were designed for
precisely this purpose: Sending binary files over communications lines
that would munge any binary file.
Assuming you can create binaries for the target system on the sending
system, uuencode/uudecode sound like a good bet simply because they're
likely to exist on both machines.
| |
| Mark Rafn 2004-12-08, 5:54 pm |
| Anirudh Ramachandran <anirudhvr@gmail.com> wrote:
>But what I need to do is this: The server end cannot be accessed by any
>means other than the serial port, and neednt even have a c compiler
>running. I have to put the binaries for the server using some basic
>unix utility (not a third party modem program).
You need to specify the system, as there isn't much definition of "basic unix
utility". Your options are many and varied, and all depend on what tools you
have available.
If the system has UUCP, just set up a login to use that, and transfer the
files that way. This is a pretty basic unix utility, and is nicely reliable
over many types of connection, including serial.
>I can assume that I
>have root on the server machine (so that I can give write access to
>/dev/ttyS0), but which basic tool listens to communication on this
>port?
This depends on what system it is. Most commonly the basic tool to listen on
a port is getty, which sets port parameters, and runs login to prompt for user
and password. There are other tools available on some systems.
If this isn't the port you're logged in on, you may be able to just disable
the login on that port, use stty to set whatever serial params you need, and
cat < /dev/ttyS0 > outputfile
This won't work for files containing EOF, though, or if the serial connection
is not 8-bit clean. If you have uudecode on the recieving system, that solves
the problem. If you don't, but you have an 8-bit connection, try
dd if=/dev/ttyS0 of=outputfile bs=1 count=<filesize>
If you have a 7-bit connection and no uudecode, you're in for some fun.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>
| |
| nospam@geniegate.com 2004-12-17, 7:50 am |
| Anirudh Ramachandran <anirudhvr@gmail.com> wrote:
> Thanks for the helpful advice. tar works in most cases, but if the file
> is a binary, it's pretty likely to be screwed up. Since I want to put a
> binary on a computer which is accessible only via a serial port, I was
> thinking along the lines of a bootstrapping method, viz, first transfer
> executable code (since I don't have a compiler) as text (say), then use
> this to create a better server etc. etc. How feasible does this seem?
> Any hints or tips on how to go about it are welcome.
> Thanks in advance,
> Anirudh
What have you got to work with on the other end?
kermit is supposed to be good at serial stuff and it's multi-platform.
Then there is old stuff like X/Y/Z-modem
If you've got absolutely no serial software on the remote machine, you might
have to resort to GW-BASIC (if it's a DOS machine) or any language on-board to
write a small program to transfer files across. Very tedious job for a program
that will be used only once or twice.
Best bet is to find some old terminal software like kermit. (or telix if it's a
DOS machine)
If it's UNIX on the other end, check for the programs: rz, rx, kermit, etc..
those were designed for what you have in mind.
Jamie
--
http://www.geniegate.com Custom web programming
User Management Solutions PERL / php / Java / UNIX
|
|
|
|
|