Vista doesn't ack dhcp offer

Phil Mayers p.mayers at
Thu Sep 20 21:04:40 UTC 2007

On Thu, 2007-09-20 at 14:11 -0500, Doug Tucker wrote:
> Well, in theory, wasn't that done when I was trying it wirelessly?  And
> keep in mind, if I apply the MS registry hack, then it gets an address
> no problem.  So are you suggesting that our switches, as well as our
> wireless access points, due to this broadcast flag setting, are refusing
> to pass the traffic being sent from the dhcp server back the the client?
> What would the dhcp server itself be doing to create this issue based on
> the type of client request it received in the first place?

I think an overview of what you've found might help. Perhaps I can
re-state the problem, and you can correct me if you're wrong.

You have a network. Broadly, the topology of this network is:

default route <-- [eth0] Linux host [eth1] --> wireless net

The Linux host serves as both the default gateway and DHCP server for
the wireless network?

WinXP and Win2K clients (which work) make DHCP requests like so:

ether src=clientmac dst=ff:ff:ff:ff:ff:ff
ip src= dst=
BOOTREQUEST broadcast=0
  <various dhcp/bootp params>

...and the server, because broadcast is 0, replies like so:

ether src=eth1mac dst=clientmac
ip src=serverip dst=
  <dhcp/bootp params>

This setup has been working fine until Vista clients came along. Vista
sets broadcast=1 so the reply looks like this:

ether src=eth1mac dst=ff:ff:ff:ff:ff:ff
ip src=serverip dst=
  <dhcp/bootp params>

Note the difference; the destination MAC address is all ones. That
should, in theory, be the only difference.

The client capture is useful, but only to confirm what we already
suspected from the capture of the server; the all-ones broadcast packets
are not leaving eth1 of your server; this is why we didn't see them on
the server tcpdump.

You need to find out why this is happening; all the fiddling with the
dhcp config will not help; you *either* hack the Vista registry to
accept unicast replies (which as you've said is impractical) or find out
why broadcast replies aren't making it through your OS network stack.

As I said earlier, the only explanations I can think of are that:
 1. dhcpd is using the wrong socket calls (or wrong flags or arguments
to those calls), so the packets aren't being generated
 2. your os network stack or hardware is dropping the packets

The reason it's working for other people and not for you is that
(hazarding a guess) most peoples' DHCP servers are probably *not* on the
same layer2 network as their Vista clients, so dhcpd is replying with a
unicast UDP packet via the dhcp relay.

I don't know enough about how dhcpd sends its replies to comment, but
regarding 2nd possibility you need to look for:

 1. iptables / etables (bridging)
 2. nic hardware issues - checksum offload

Anything odd at all about the OS network setup? Is it a Xen domU for
example? Are the "NICs" actually vlan interfaces? Anything at all?

There are two other things you can try:

 1. Temporarily obtain a small router and make this the dhcp relay; set
the forwarding address to eth0 on your linux server, and stop dhcpd from
listening on eth1. The requests/replies will be forwarded from/to the
router via unicast. If that works, you've got a workaround

 2. Perform a similar trick, but using dhcrelay on the same or another
linux box.

More information about the dhcp-users mailing list