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
To: busybox@mail.codepoet.org
Wrap sockaddr_in6 in a ifdef CONFIG_FEATURE_IPV6.
Include sys/types.h instead of asm/types.h.
Include netinet/if_ether.h instead of linux/if_ether.h
The ioctl request argument is an int, not an unsigned short.
> Hi,
> this is a first attempt of size optimization for zcip taking into account all
> the hints given so far on the list.
> I've applied just the more obvious busyboxifications so maybe it could be
> optimized more.
BTW: I've ripped out a lot of debug code and changed c++ // comments to /* */
as both were rather confusing for a newbie like me. ;-)
Sorry to the author for that.
I know that this makes mantaining the code easier, but I'm simple minded....
Hello,
Here's a patch for a first attempt at static leases for udhcpd.
Included in the tarball are 2 files (static_leases.c, static_leases.h)
and a patch against the latest cvs.
In the config file you can configure static leases with the following
format:
static_lease 00:60:08:11:CE:4E 192.168.0.54
static_lease 00:60:08:11:CE:3E 192.168.0.44
Comments/suggestions/improvements are welcome.
Wade
>I also don't mean to disagree about leaving 30x status codes until after
>1.0. In fact, although redirecting http://host/dir to http://host/dir/
>with a 301 is common practice (e.g. Apache, IIS), AFAIK it isn't
>actually required (or mentioned) by the HTTP specs.
Ok.
Attached patch have 302 and 408 implemented features.
--w
vodz
Hi!
I've created a patch to busybox' build system to allow building it in
separate tree in a manner similar to kbuild from kernel version 2.6.
That is, one runs command like
'make O=/build/some/where/for/specific/target/and/options'
and everything is built in this exact directory, provided that it exists.
I understand that applyingc such invasive changes during 'release
candidates' stage of development is at best unwise. So, i'm currently
asking for comments about this patch, starting from whether such thing
is needed at all to whether it coded properly.
'make check' should work now, and one make creates Makefile in build
directory, so one can run 'make' in build directory after that.
One possible caveat is that if we build in some directory other than
source one, the source directory should be 'distclean'ed first.
egor
Ming-Ching,
>>No. Here there are no mistakes.
>>You using POST metod.
>>For get data you should read from stdin CONTENT_LENGTH bytes.
>Hower as I posted a little while ago, there is indeed a bug
>in POST method if the CONTENT_LENGTH is bigger
>than sizeof(wbuf[128]). So if your CGI script is expecting to
>read the full CONTENT_LENGTH, it might block forever,
>because it will only transfer sizeof(wbuf) to the CGI.
Ok, Ok. I should find time to understand with a problem.
Try attached patch.
--w
vodz
"I have a need to _really_ know if the interface was properly configured
via ifup so I made busybox's ifupdown pass the return codes through rather
than dropping them on the floor."
"All the functions in ifupdown.c return 1 on success and 0 on failure
(which happens to the opposite of standard practices but whatever).
So it is important for all these functions to not blindly return 1."
"The problem with blindly returning ret, even if it is != 1, is the
callers expect a 0 or 1 and accumulate the return codes. So a function that
makes 3 calls to execute will have a value of 3 accumulated. That value
of 1 (success) was almost always returned even if 1 of the commands in the
command sequence failed. The attached patch fixes the lack of checking
to verify thar result == expected_reult."
