Re: NT 3.51 client bug or dhcp spec violation or what?

[Shawn Mamros <[e-mail]>]

John Carlson <[e-mail]> writes:
>The NT 3.51 client does not set the broadcast bit in either the DISCOVER
>or the REQUEST packet (that is, desires a unicast response).  However, 
>when the NT 3.51 client receives an IP unicast reply, it ceases to emit 
>dhcp packets and reports a failure to the user and enters an empty log 
>message.  If the NT 3.51 client receives a directed broadcast (ie. of the 
>form a.b.c.255 on an 8 bit subnet) response, it happily and successfully
>completes the dhcp transaction.  I noticed this by placing the server and 
>client on the same subnet and forcing the server to broadcast a response 
>regardless of the client's non-setting of the broadcast bit.
>
>Has anyone else seen this behaviour?  (The behaviour is masked by the use 
>of a NT dhcp server, since it appears to respond with a broadcast regardless 
>of the broadcast bit setting within the client's discover/request packets.)
>Are there users of NT 3.51 dhcp clients which have evidence to the contrary?

I do... I have an NT 3.51 machine here, and we are using the DHCP server
provided in FTP Software's OnNet Server 2.0 (of course :-).  This server
will unicast its replies when the client does not set the broadcast bit.
I've just enabled the DHCP client on the NT machine and ran a network
trace.

Results: The client does not set the broadcast bit, the server unicasts
(actually, the relay agent unicasts; the server is on another network;
don't think that should really matter though...), and the client gets
the response just fine, ARPs for the address, and begins using it.
No warning or error messages reported to the user; everything seems fine.

(I know we've tested the NT client against our server before; I just
wanted to double-check it just now. :-)

-Shawn Mamros
E-mail to: [e-mail]