NT 3.51 client bug or dhcp spec violation or what?

[John Carlson <[e-mail]>]

I've encountered what appears to be a loose or misleading interpretation
of the dhcp spec or a bug in the NT 3.51 dhcp client.  (Perhaps I should
send this note to the implementor's list?)

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?

The dhcp server used in our environment was written by me and has been 
running on our campus for over one year.  The set of clients which have 
continually successfully interoperate with my server includes, but is not 
limited to, Windows95, Windows for Workgroups and Macintosh OpenTransport.  

The problem is further complicated when using a Cisco router (at least 
IOS versions 9.1 (11.7) and 11.0 (8.4)) as a relay agent, since it appears 
to ignore the *server's* broadcast bit setting.  My *theory* is that, for 
performance reasons, the Cisco router records the broadcast bit setting 
of the client discover/request packets and uses a subsequent quick index 
lookup rather than parsing the server's dhcp responses when forwarding 
replies to the client.  The result being a unicast by the relay agent to 
the client (which had requested a unicast) rather than a broadcast as 
specified by the broadcast bit in the server's response.  I don't think 
that this necessarily violates the letter of the spec, but it certainly 
prevents hacking the server to overcome the NT client deficiency.


johnc
-------------------------------------------------------------------------------
John D. Carlson
Networks and Distributed Computing     EMAIL: [e-mail] 
University of Washington               BELL:     [phone]
4545 15th Ave NE                       FAX:	 [phone] 
Seattle, WA  98105