Re: Microsoft Windows95 DHCP Timeout

[Dave Pacheco <[e-mail]>]

     
     This is a recognized bug in Win95: Microsoft is aware of it and it may 
     be fixed in the next revision.
     
     What seems to be happening, and what we have observed through Sniffers 
     here, is that the Win95 DHCP client times out its DCHPDISCOVER after 
     just under 2 seconds.  It then proceeds to send out another one.
     
     Our situation is that our Sun DHCP server pings the network several 
     times for the IP address it intends to give the client, to make sure 
     that it is available.  That means it does not get back to the client 
     with a DHCPOFFER until about 4 secs after the initial DHCPDISCOVER 
     packet, by which time the client has already sent out two more 
     DHCPDISCOVERs. The server must respond to these and assume the 
     DHCPOFFER it sent was not received, which means it has to go out and 
     ping the network again.
     
     By the time a DHCPREQUEST and DHCPOFFER travel back and forth across 
     the network, the DHCP client has reached a "total DHCP request time" 
     time-out, and it comes back with a message claiming it could not see 
     the server (which is misleading, since it has been communicating with 
     it all along).
     
     The solutions are:
     
     1) Reconfigure the DHCP server so that it takes less time to get back 
     to the client, either by pinging less times or not pinging at all (the 
     latter not being very desirable)
     
     2) Wait for the next bug fix from MS.  This fix will increase the 
     time-out for the initial DHCPDISCOVER, so that the DHCPOFFER comes in 
     before the DISCOVER is resent.  Windows NT had this same problem, and 
     was fixed in the same way.
     
     3) Purchase a 3rd party TCP/IP implementation.  OnNet32, from ftp 
     Software, is an excellent implementation, but not free by a long shot. 
      Yes, MS' TCP/IP stack is free, but if you need solid connectivity 
     programs, it doesn't come with much.
     
       - Dave Pacheco
     


______________________________ Reply Separator _________________________________
Subject: Microsoft Windows95 DHCP Timeout
Author:  "Alan S. Dobkin" <[e-mail]> at FILM-INTERNET-BURBANK
Date:    2/28/96 4:58 PM


     
Since we're on the topic of Microsoft's DHCP software, I thought I'd ask 
this group (and specifically the Microsoft folks) for some help with this 
problem.  We are currently testing Sun's SolarNet PC-Admin 1.5 server for 
use as a campus-wide DHCP/BootP server at Emory.  So far, I have had 
success using DHCP with Windows95 in the same subnet as the server, but 
the negotiation fails if the Windows95 client is in a different subnet, 
using the helper-address function of our Cisco routers.  Incidentally, 
Apple's Open Transport client works using the same server in either the 
same subnet or accross the router.  Specifically, the Windows95 client 
sends the DHCP request, the router passes it on, the server sees it and 
responds with an IP number, but the Windows95 client states that it has 
not gotten a response.
     
After doing some research, I've noticed that a similar problem has been 
posted to the Windows95 Networking Bugs FAQ.  Has Microsoft addressed 
this problem?  Is there a solution?
     
http://WWW-Leland.Stanford.Edu/~llurch/win95netbugs/faq.html 
http://WWW-Leland.Stanford.Edu/~llurch/win95netbugs/faq-c.html#c28
     
C.28. What do I do if Win95 won't wait long enough for my DHCP server to 
assign an address?
     
Date: Mon, 6 Nov 1995 10:55:17 -0600
From: David Devereaux-Weber <[e-mail]> 
Message-ID: <[e-mail]>
     
[Complain, I guess, until Microsoft fixes this.] 
     
We have had difficulty with Microsoft's implementation of DHCP in WIN95. 
the DHCP client is supposed to wait a reasonable period of time for the 
server to check an address before it is given to the client. Microsoft's 
client doesn't wait very long - it bails out early and reports no 
response. The people at Sun hacked their client software for us to 
temporarily work around the problem. Unfortunately, trying to get 
Microsoft to understand and support the official protocol has been 
unsuccessful to date. 
     
/--------------------------------+---------------------+-----------------\ 
| Alan S. Dobkin, LAN Specialist | 1784 N. Decatur Rd. | E-Mail Address: | 
| Networked Workstation Support  | Suite 300 (3rd Fl.) |     ADobkin     | 
| ITD Network Systems, Emory U.  | Atlanta, GA 30322   |   @Emory.Edu    | 
| <URL:http://NWS.CC.Emory.Edu/> |  [phone]     | FAX #: [phone] | 
\--------------------------------+---------------------+-----------------/