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

[John Carlson <[e-mail]>]

Fyi.

This was not a NT 3.51 dhcp client bug.

My server was sending packets larger than the minimum maximum sized
packet of 576 octets and the NT 3.51 dhcp client was detecting what 
it considered to be an errored packet and exiting.  (Apparently, 
most [all other?] clients, including windows95 and wfw, *do* accept 
offers larger than 576 bytes.)

It turns out that the success of a broadcast of an offer by my server
was a red herring (too twisted to explain here :).


johnc


On Tue, 9 Jul 1996, John Carlson wrote:

> Date: Tue, 9 Jul 1996 21:51:42 -0400
> From: John Carlson <[e-mail]>
> Reply-To: [e-mail]
> To: Multiple recipients of list <[e-mail]>
> Subject: NT 3.51 client bug or dhcp spec violation or what?
> 
> 
> 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		       
> 
> 
>