[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: problems with dhcpd3-server



On Fri, Jun 23, 2006 at 11:03:39AM -0700, Andrew Sharp wrote:
> I'm wondering if anyone else is running dhcp3-server on their amd64 box
> and seeing (or not seeing) the same problem.
> 
> The problem is that dhcp3-server is sending out dhcp offer packets with
> an 8 byte lease time, for reasons that I can't fathom.  Ie, I think it's
> a bug.
> 
> However, it does properly say that the option is 8 bytes long, the only
> thing is, apparently all clients (that I have tried) assume that the
> option is 4 bytes long and don't observer the length specified by
> dhcp3-server.
> 
> In addition, the correct number 600 actually seems to be in the first
> four bytes, but none of the clients seem able to deal with that.
> Instead they set their lease time(s) to 3-4 minutes which is just nutty.
> 
> So, is the bug in the clients or the server?  Clients I tested were
> dhcp3-client (irony) on a 32-bit X86 box, and the udhcpc client in
> busybox on a mipsel box.
> 
> Output from ethereal (on the amd64 box):
> 
> .
> .
> .
> Option 51: IP Address Lease time - length isn't 4
> .
> .
> .
> 33 08 00 00 02 58 00 00 00 00
> .
> .
> .
> 
> 
> 
> 
> Yes, ethereal put's in that comment about the length not being 4.
> 
> 33 (hex) is option 51, 08 is the length, and 00 00 02 58 is "600" lease
> time.  The X86 client actually says something about 4 'garbage' bytes
> after the lease time, but gets the lease time wrong -- it sets it at 260
> seconds or something like that.
> 
> Kind of annoying.  Not sure which one(s) I should file a bug against.

According to RFC 2132, option 51 MUST by 4 in length, so unless there is
a newer spec (which would be incompatible with prior dhcp versions),
then the dhcp server is currently buggy/broken.

Probably the code uses long somewhere that was supposed to be 32bit, but
on amd64 that is 64bit.

Len Sorensen



Reply to: