| Age | Commit message (Collapse) | Author |
|---|
|
|
|
*: s/include "busybox.h"/include "libbb.h"
|
|
if blocksize option doesn't look good (it was a FIXME. +33 bytes code);
make code more readable.
|
|
function old new delta
static.errcode_str - 32 +32
tftp_main 359 345 -14
tftp_bb_error_msg 32 - -32
.rodata 130931 130899 -32
tftp 1720 1558 -162
------------------------------------------------------------------------------
(add/remove: 1/1 grow/shrink: 0/3 up/down: 32/-240) Total: -208 bytes
|
|
a bit.
-916 byte
|
|
It's a GPL-ed 'clone' of Dan Bernstein's tcpserver.
Author: Gerrit Pape <pape@smarden.org>
http://smarden.sunsite.dk/ipsvd/
size tcpsvd.o
text data bss dec hex filename
2571 4 16 2591 a1f tcpsvd.o
|
|
|
|
|
|
|
|
no preceding prototype
|
|
|
|
|
|
|
|
unknown number likely introduced...
|
|
|
|
|
|
few other applets: #ifdef CONFIG_ -> #if ENABLE_
traceroute: fix exposed bugs
defconfig: update
|
|
|
|
|
|
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.)
|
|
xlseek and fdlength() for the new mkswap.
|
|
says "our implementation makes it impossible to use blocksizes smaller than
22 octets" right above a check for blocksize < 8.
|
|
- expand the cmd_get/cmd_put macros
- Jason Schoon writes: unlink only if non-stdio
|
|
|
|
|
|
- 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
|
|
Thanks Erik Hovland
|
|
text data bss dec hex filename
825015 9100 645216 1479331 1692a3 busybox.old
824919 9100 645216 1479235 169243 busybox
|
|
|
|
bb_xopen some more while at it.
Also use shorter boilerplate while at it.
|
|
|
|
|
|
it's the darn bug generator again.)
|
|
|
|
0000271: [PATCH] tftp -g fails if a TFTP_ACK is lost
|
|
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
|
|
which were otherwise cluttering the global namespace.
|
|
extra const's also.
|
|
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
|
|
s/fileno\(stdout\)/STDOUT_FILENO/g
|
|
|
|
|
|
|
|
|
|
putting more than 0xffff blocks.
|
|
/etc/services support for inetd, netcat and tftp.
|
|
|
|
The client gives up way too soon because timeout is set to 0 ...
There's a solution for that problem.
|
|
|
