Error when attempting tftp upload

[Rob Landley]

On Tuesday 27 April 2010 01:53:37 Denys Vlasenko wrote:
> On Tuesday 27 April 2010 07:12, Rob Landley wrote:
> > On Wednesday 21 April 2010 06:47:45 Chuck Kuecker wrote:
> > > Hello,
> > >
> > > This might be a simple problem, but so far I've not found a good
> > > solution.
> > >
> > > I am running Busybox in an ARM embedded system. I want to be able to
> > > transfer a file from the embedded device to my Linux host. The host
> > > system has tftp working - that's how I load the ARM system files.
> > >
> > > I issue tftp -p -l /mjpeg.api 192.168.0.200 69 at the embedded system
> > > to transfer the .avi file to the host machine. I get this error:
> > >
> > > tftp: server error: (2) Access violation
> > >
> > > What does this mean. and what should I look at to fix it?
> >
> > Add an ssh client to your box?
> >
> > Statically linked dropbear binaries for a bunch of architectures:
> >
> >   http://impactlinux.com/fwl/downloads/binaries
> >
> > Alternately, if you're asking what you can do with busybox, I'd suggest
> > ftpget and ftpput to an ftpd on the host.  (The tftp protocol is kind of
> > sat, use real ftp.)
> >
> > But busybox ftpd requires an inetd variant to run under, and the easy way
> > to do that (netcat's server mode) is broken in busybox:
> >
> >   $ netcat -l -p 12345 -e cat bigfile &
> >   $ telnet 127.0.0.1 12345 > outfile
> >   127.0.0.1: Connection reset by peer
> >   Connection closed by foreign host.
> >   $ ls -l bigfile outfile
> >   -rw-r--r-- 1 landley landley 22940512 2010-04-26 23:51 bigfile
> >   -rw-r--r-- 1 landley landley 20775272 2010-04-26 23:54 outfile
> >
> > That's a basic sanity test this implementation isn't passing.
>
> How did you manage to run busybox nc as "netcat"?
> Please show "netcat --help" output.

My bad.  I screwed up twice here:

1) I hand-edited

  landley at driftwood:~$ ~/firmware/firmware/build/host/busybox nc -l -p 12345 -e 
cat glibc-2.7.tar.bz2

Into a more readable command line, and screwed it up when I did so.  (It was 
nc. In toybox netcat is a synonym for nc, in busybox it isn't but I was 
testing the busybox one.)

2) I also didn't want to use netecat as both the sending and receiving 
program, so I could tell which half of the transaction was causing which 
behavior.  I forgot the telnet escape sequence stuff happens even when it 
doesn't get a controlling TTY.

> Why do you think telnet is a good method for downloading
> raw binary data? It mangles 0xff bytes, for one.
> It tries to respond to TELOPT_TTYPE options (255,24 byte pairs)
> by sending back $TERM value. If it happens enough times,
> network pipe fills up (since cat doesn't read stdin in this case),
> and everything stalls.

Yeah, that's probably what happened here.  Again, my bad.

> > I used to have this working, but git commit 29fe7265b8c1917ebc blew away
> > my code with a completely unrelated external port that doesn't even get
> > the basic bidirectional shutdown() stuff right.
>
> Clue me in what is this shutdown() thing.

man 2 shutdown.  It closes down one half of a connection, so that when the 
other end reads from a pipe they get EOF, but can still write to it.  (Or vice 
versa.)

The first version of netcat I messed with (circa 2001) wasn't doing shutdown 
handling at all, and thus something like:

  echo "GET /" | netcat www.cnn.com 80

Wouldn't work, because as soon as netcat saw the end of input, it would 
close(fd) the network connection and thus no longer be able to receive any 
data from the remote server.  But if it just ignored it the result would be a 
hang instead because the remote server won't start sending data back in that 
case unless it reads EOF from the socket because otherwise it'll sit there 
waiting for HTTP 1.1 headers when it's only going to get HTTP 1.0.  (It's a 
funky corner case.  There's a lot of those.)

Apparently the "upstream" netcat has since been fixed, and the bug I was 
hitting was actually due to the behavior of Ubuntu's telnet.  Sorry about 
that.

> > It also doesn't have things like the
> > persistent server option (-L), or the ability to allocate a tty (-t), or
> > the connect to file option (netcat -f) which let netcat attach stdin and
> > stdout to an arbitrary char device (such as /dev/ttyS0) instead of a
> > network socket.  (I was kind of proud of that one.)
>
> Every new reimplementation of nc adds more features. Yours is actually
> better than most, because others don't bother to not *break compatibility*.

So to get these features put back into busybox I'd have to get them into an 
"upstream" project?

In toybox -l -L -t are under the config symbol NETCAT_LISTEN, to provide server 
options.  Possibly I should probably move -f into there too, but I don't 
really bang on that much anymore...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds