It is impossible to formulate sane ABI based on
size of ulong because it can be 32-bit or 64-bit.
Basically it means that you cannot portably use
more that 32 option chars in one call anyway...
Make it explicit.
things like xasprintf() into xfuncs.c, remove xprint_file_by_name() (it only
had one user), clean up lots of #includes... General cleanup pass. What I've
been doing for the last couple days.
And it conflicts! I've removed httpd.c from this checkin due to somebody else
touching that file. It builds for me. I have to catch a bus. (Now you know
why I'm looking forward to Mercurial.)
- remove dangling file if get fails (spotted and fixed by Jason Schoon)
- shrink it (Bernhard Fischer)
Thanks, all!
text data bss dec hex filename
2684 0 0 2684 a7c networking/tftp.o.orig
2748 0 0 2748 abc networking/tftp.o.allfixed
2666 0 0 2666 a6a networking/tftp.o.+shrink
We were seeing some timeouts when getting files with the busybox tftp
client.
With tcpdump, we saw that the tftp client was receiving blocks and
ack'ing them, but the server was failing to receive the occasional
ack.
When that happened, the server would send the last block over again,
but the tftp client was expecting the next block.
This patch allows the client to recover from this situation
(it sends an ack for the repeat block but does not write it
to the local file).
I hope it meets your approval, please don't hesitate to send
me comments for improvement.
The patch is against "head" in svn, I tested it on an older version
of busybox in our environment. It applied cleanly to the older
version.
Credit for this goes to my co-worker John McCarthy for finding
it and me for fixing it (assuming it works for everyone else too).
cheerio,
bjb
Hi,
Package: BusyBox
Version: 1.0.0-pre10
When an incomplete read or write from/to a local file occurs (i.e.
not an EOF condition), the tftp client prematurely exits. This
problem can be reproduced by slowly piping data to the tftp client
like this:
(for v in 1 2 3; do echo $v; sleep 1; done) | \
tftp -p -l - -r output.txt <host>
The output file on the TFTP server will contain "1".
The attached patch provides a possible solution to this problem.
I can reproduce this on ARM sa1110 and ARM xscale boards, both
running Linux-2.6.4 & glibc-2.3.2. Thanks for the wonderful
program!
Robin
