Vista doesn't ack dhcp offer

Doug Tucker tuckerd at
Thu Sep 20 21:38:43 UTC 2007

You are 100% correct in your overview.

Setting up a relay or router with the existing server is not a quick and 
easy test, so I just took another approach, and connected the machine to 
another network with a different type dhcp server that I already knew was 
working fine going through a relay, put this machine on the same vlan as 
the dhcp server, wallah, I got an address no problem, so that rules out 
the forwarding "helping" the others.

Nothing unusual about the server itself, it's a debian machine with 
sh-2.05b# uname -a
Linux dgate2 #1 SMP Tue Aug 2 17:25:50 CDT 2005 i686 GNU/Linux

installed.  iptables is running on the box, however to recap, I shut down 
talbes yesterday to eliminate it, and still no workie.  It's not virtual, 
and no indication of any ethernet hardware issues.

Last ditch effort here, we're going to upgrade the kernel on the box since 
it has not been done in some time, and hope there is something odd about 
the existing kernel causing the problem.  I will update tomorrow morning 
after the upgrade.

On Thu, 20 Sep 2007, Phil Mayers wrote:

> 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