dhcpinform or dhcprequest

[David W. Hankins]

On Wed, Sep 02, 2009 at 05:22:54PM +0200, Tom Schmitt wrote:
> Sadly I have not much hope that the vendor will change anything: The Client is a HP workstation with Windows XP and Microsoft is not well known for changing their software based on a request from a single person.

the windows XP client is not known to behave as you describe, sending
a DHCPINFORM in lieu of a DHCPREQUEST...

quite the opposite, it is well known to renew at the correct time.

the DHCPINFORM packets a client sends aren't based on lease time
expiration, but rather are a random delayed window after bootup, when
the Microsoft Industry Updater ("automatic updates") tries to check
for patches.  the MIU wants the unofficial "WPAD" option to try local
http proxies first.

you can suppress the DHCPINFORM packets at DHCPREQUEST time by sending
a 'poison pill' wpad option contents.  windows caches this poison pill
and will not send a DHCPINFORM when the MIU starts up.  this also
stops the client from trying to locate proxies by DNS or other methods,
and so it is in general a good idea if you aren't actually using WPAD.

although it's not impossible for an attacker to insert a WPAD option
at DHCP time, succeeding in giving a poison pill means it is impossible
for an attacker to succeed via any other WPAD transport mechanism...a
net gain.

i've considered including it in our example dhcpd.conf, except that
this raises questions about how we would document the option.  the
only reference that describes the option is an expired I-D.


anyway.

the only time i've ever heard of a similar situation was with
failover servers in early 3.0.x, where the client was processed by both
servers, so ddns updates were performed (identically) by both servers.

the bug comes when the servers record inconsistent lease times, and
the client binds to the longer lease time of the two.  the early lease
time comes, and in expiring the lease the server tears down ddns
state.  but we fixed this long ago, such that expiration events are
only processed when both servers agree the lease has expired.

so you are probably a victim to some unusual order of operations that
causes the servers to agree that the client has been given a shorter
lease time than it has bound to...

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090902/72985667/attachment.bin>