[BusyBox] udhcp patches/ endianess

[Russ Dill]

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.

> 
> And there is the additional issue that someone might be tempted to use
> the code to calculate IP checksum for other types of datagrams, which
> will work nicely as long as the sum does not exceed the value 2^31,
> thereby affecting the sign bit of the int32_t and turning the 'fold'
> loop into an endless loop, which is an effect that I would rather
> prevent than fix (and people will mindlessly copy to code out of
> there). 

then why not just change the singed int to an unsigned one?


> > 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. You
can work extra hard in the code to count all the bytes, and make
variable length packets, or you can just assume a full packet. The
interopability problems are with certain dhcp clients and dhcp servers.

udhcp used to count bytes and do variable length packets. Too much
incompatibility.