DHCP offer ignored - Ethereal trace
The Other Roger
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
Rhett Gong [MSFT]
Looking at the nature of this issue, it is not a development problem but
more like a system configuration issue which could be properly handled in
microsoft.public.windowsxp(embedded).
The reason why we recommend posting appropriately is you will get the most
qualified pool of respondents, and other partners who the newsgroups
regularly can either share their knowledge or learn from your interaction
with us. Also, this is to make sure that the responders can better track
the problem Thank you for your understanding.
PS: microsoft.public.win32.programmer.networks mainly focused on MS NET
APIs. If you get any problems on using MS NET APIs, please feel free to
post them here.
Best regards,
Rhett Gong [MSFT]
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties and confers no rights.
The Other Roger
1. Why are you pointing me to the XPe newsgroup? Please read my post again - it
does not involve XPe at all. The machines involved in this problem are an XP
Professional client and a Windows 2003 server.
2. You say this is not the appropriate newsgroup. I have searched through all
the MS newsgroups that contain the word "network" and I can find no closer
English language newsgroup for an XP and DHCP problem. If there is a newsgroup
that is more appropriate for this problem please identify it.
3. You are contending that this is a configuration issue. If you know that to
be true then please state what you have mind. You should understand that I have
not done any configuration of DHCP beyond specifying that it should be used. If
the configuration is "wrong" then there is a problem with the default setup and
Microsoft should be willing to address that issue.
Roger Levy
Alexander Nickolov
is not a programming question. However, the group he has
redirected you to is not exactly suitable either... Try one of
these instead:
microsoft.public.windows.server.networking
microsoft.public.windowsxp.network_web
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnic...@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================
"The Other Roger" <bloo...@online.nospam> wrote in message
news:42249279...@online.nospam...
Rhett Gong [MSFT]
Since you have asked a samiliar question on XPe in your previous thread, I
think this question may be corresponding to that one.
I know you don't do any configuration in your side. Could I ask if you have
any code for this problem?If yes, whic call fails and could you let me know
what error it returns? Do you have a call stack trace for this problem?
You may have them, but at least, from your post, I can't see anything.
My responsibility (or this group) is mainly focused on MS Net APIs ----- I
cover questions on
1> how to implement a functionality on MS platform with MS NetAPI
2> if you meet any problem when using MS NetAPI, I am glad to assist you to
trouble shooting it and assist you for a workaround using some other way.
3> if you've found any bugs in our platform when you programming with our
platform, I am aslo glad to assist you for a fix.
Actually, I 've taken a close look at your post and check RFC to see if it
is one of our features which does not meet the RFC. however, it behaves the
same as rfc described, and fom your post, you don't do anything
programatically but post to say XP( or 2003 or XPe) does not exhibit the
behavior as you expected and you would like to know if there is way to
force XP ( or 2003 or XPe) client to take the offers. Such question should
better be handled in our platform group (not platformsdk or ddk); As
Alexander suggests, these groups are:
microsoft.public.windows.server.networking
microsoft.public.windowsxp.network_web
Or you may contact our PSS directly at:
http://support.microsoft.com/gp/CNTACTMS. I believe it will be a platform
support engineer who takes your case rather than of a dev support enginerr.
Thanks and good luck,
Roger H. Levy
I am posting to this group because I believe this problem fits your
description #3 -- I am encountering bugs when I attempt to use the NET
API. Specifically, I have an automatic service that determines how many
network interfaces the host has and then it starts broadcasting messages
on each interface so that potential clients have a way a locating
available servers. The problem is that when there are unusual delays in
getting IP addresses assigned to the network interfaces, my service
finds no interfaces to use so it generally is aborted, I think by the
SCM, because of timeouts. Since I have found that it can not be
predicted how many DHCP Offers the Windows DHCP client will ignore, it
is not possible to handle this problem in a deterministic way. My
position is that a service that requires network capabilities should
find those capabilities to be available when the system starts the
service -- there should not be an indefinite delay until those
capabilities are available to the service.
I have some additional information on the problem. My hardware has dual
gigabit interfaces and I find that this problem does not occur if one of
the interfaces is disabled. My best guess is that the DHCP client may
experience some kind of race or destructive resource contention when it
receives two DHCP Offers in a short period of time. Usually, the system
responds correctly with DHCP Requests after a couple of timeouts and
it is typical that the Discovers and Offers from the two interfaces do
not occur as close together after those timeouts. Also remember that
this problem only occurs if the full DHCP protocol starting with
Discover is executed. In many cases Windows clients start the protocol
with Request since they "remember" the last IP address that was assigned
to them. One way to force the protocol to start with Discover is to
execute "ipconfig /release" before shut down.
I think my configuration and the problem reproduction scenario I
described occurs rarely and so I expect this bug has not affected many
users however I very much believe I am describing a bug and not a
configuration issue or a symptom of a problem in my code. That is why I
have separated the description of this problem and its reproduction
scenario from any of my code. In other words, I have told you how the
problem affects my service when it is installed but until now I have
been describing what's going on without having my code involved.
Roger
Rhett Gong [MSFT]
Thanks for your detailed description. It reminds me of one of your posts
before ---- the auto typed service can't find any interface during system
startup.
As I said before, our implemetation is based on RFC in this case. So far as
I can tell, it is impossible to change such basic device driver currently,
but if this impact your product, you may contact our PSS to request a
hotfix on this problem (it is free of charge).
But if you will change your service to get it work in current situation,
could you let us know more details on your service, such as service type
(is it a driver or something else), what you have done inside, please?
If I remember correctly, a community member suggested ServiceGroupOrder for
this problem, have you tried it? Generally, if we enable DHCP on an
interface, dhcp service's start type is set to 2(SERVICE_AUTO_START) with
start group set TDI.
Thanks,