[BusyBox] udhcp patches/ endianess

[Rainer Weikusat]

Russ Dill <Russ.Dill at asu.edu> writes:
> On Wed, 2005-02-02 at 19:32 +0100, Rainer Weikusat wrote:
>> Russ Dill <Russ.Dill at asu.edu> writes:
>> >> So unless I am very much mistaken, this is correct for both
>> >> cases.
>> >
>> > Why not keep the known, working crc algorithm?
>> 
>> <nitpicking>
>> This isn't a CRC algorithm.
>> </>
>
> If it doesn't work for big-endian...leads me to believe it isn't very
> well fielded and tested.

You haven't looked at the actual code, right? There is a single place
in the whole algortihm where endianess actually matters and that's
where the 'left over octet' is added. The RFC states that it should be
padded with a zero octet 'to the right', meaning the following memory
layout should be simulated:

	<left over octet> 0

This sequence is to be added as 16 bit quantity, using whatever
endianess the machine calculating the sum happens to have. There are two
obvious solutions:

	a) use a memory buffer to store data octet and pad in the
	order given above and add the 16 bit quantity you get by doing so.

        b) given the endianess is known (by configuration option,
        test, inclusion of glibc headers or whatnot), the correct number
        can be calculated without resorting to a temporary buffer.

[...]

>> > Some clients and server barf on packets that don't have the full payload
>> > size.
>> 
>> There is no such thing as the 'full DHCP payload size' anymore (since
>> 1997). ISC uses 300 as minimum payload size, probably for
>> interoperability with BOOTP relay agents. I would agree that it makes
>> sense to provides this kind of behaviour on request to work around an
>> actual problem, I (and that's only me) just don't like it as a default
>> which cannot be easily changed.
>
> There are multiple clients and servers that barf on short packets.

Quoting from the udhcp-changelog:

 Drop calc_length(), some servers choke on smaller packets (me)
 <URL:http://udhcp.busybox.net/>

The entry is dated 020526, ie 26th of May 2002. Which server were you
talking about?