DHCP offer ignored - Ethereal trace

From: The Other Roger (blooline_at_online.nospam)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 12:08:35 -0500

The following is an Ethereal trace, edited to essential information, from an XP
Pro/SP2 system with a dual Intel Pro 1000 ethernet controller as it executes the
DHCP protocol:

Time Source Info
75.731634 0.0.0.0 DHCP Discover - ID 0xa482183
75.731652 0.0.0.0 DHCP Discover - ID 0x22ce6b9e
75.732642 192.168.100.5 DHCP Offer - ID 0xa482183
75.733154 192.168.100.5 DHCP Offer - ID 0x22ce6b9e
91.731426 0.0.0.0 DHCP Discover - ID 0xa482183
91.731445 0.0.0.0 DHCP Discover - ID 0x22ce6b9e
91.732435 192.168.100.5 DHCP Offer - ID 0xa482183
91.732442 192.168.100.5 DHCP Offer - ID 0x22ce6b9e
125.125116 0.0.0.0 DHCP Discover - ID 0x2b106a29
125.125623 192.168.100.5 DHCP Offer - ID 0x2b106a29
125.126133 0.0.0.0 DHCP Request - ID 0x2b106a29
125.127669 192.168.100.5 DHCP ACK - ID 0x2b106a29
128.123783 192.168.100.23 DHCP Request - ID 0x31855ca9
128.125295 192.168.100.5 DHCP ACK - ID 0x31855ca9
129.122128 0.0.0.0 DHCP Discover - ID 0xa4800033
129.122625 192.168.100.5 DHCP Offer - ID 0xa4800033
129.123137 0.0.0.0 DHCP Request - ID 0xa4800033
129.124161 192.168.100.5 DHCP ACK - ID 0xa4800033

At approximately 75 seconds the XP Pro DHCP client broadcasts Discover messages
for each interface. A Windows 2003 Server DHCP server rapidly responds with two
DHCP Offers. The client does not respond for either interface with the expected
Request and about 16 seconds later, at approximately 91 seconds, two more
Discovers are broadcast followed by rapid server response of two Offers. Again
the client does not respond and about 33 seconds later a Discover is sent for
one interface and about 37 seconds later a Discover is sent for other
interface. Each 3rd Discover broadcast has a different protocol ID than the
first two for each interface. The DHCP protocol then completes in both cases.
Of interest, but not of great significance to me, is the presence of a seemingly
superfluous Request and Ack at 128 seconds.

This data shows that the client ends up getting both addresses assigned more
than 53 seconds after it would have the assignments if the client has not
abandoned the initial protocol sequences. This 53 second delay is critical for
machines that I will be using for an enterprise critical application.

I have not configured the DHCP client in any way so if this issue is claimed to
be due to configuration then it is a result of the default configuration. Why
does the DHCP client repeatedly ignore Offers and how can that problem be
corrected?

Roger

Relevant Pages

  • Re: Does DNSMasq (or other DNS/DHCP Servers) Cache Old Addresses?
    ... Originally, when Debian set up the system, it used DHCP instead of a static ... I finally shut down the new system and rebooted the DNS server -- after ... problem with the client. ... interface was then brought up correctly, ...
    (Debian-User)
  • Re: Cannot discover any client
    ... I have a PC that uses DHCP IP Address that has WINS Entry. ... and when discover it manage to find the old DHCP IP ... collection of database that might be cache. ... DHCP Client have no problem. ...
    (microsoft.public.sms.admin)
  • Re: repost: routing and remote access - why no dhcp options
    ... > VPN clients not receiving DHCP options. ... >> connection between a client and an RRAS server, ... >> interface routing connection on another machine running server 2003. ...
    (microsoft.public.windows.server.networking)
  • Re: repost: routing and remote access - why no dhcp options
    ... VPN clients not receiving DHCP options. ... > connection between a client and an RRAS server, ... > dhcp to be disabled on the PPP interface. ...
    (microsoft.public.windows.server.networking)
  • Re: assigning multiple IP address to one interface via dhcpd
    ... If you want to assign by MAC address, then every virtual interface must ... I think a better idea may be to allocate using a DHCP name. ... client to use a different name for each interface. ...
    (comp.os.linux.networking)