Vista doesn't ack dhcp offer

[Frank Bulk - iNAME]

I would have to agree with Hankins....the packet is being dropped
somewhere....start port spanning or using a hub to track it down.

Frank

-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf
Of Doug Tucker
Sent: Thursday, September 20, 2007 4:39 PM
To: dhcp-users at isc.org
Subject: RE: Vista doesn't ack dhcp offer

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
kernel:
sh-2.05b# uname -a
Linux dgate2 2.6.12.3 #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=0.0.0.0 dst=255.255.255.255
> 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=255.255.255.255
> BOOTREPLY
>  <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=255.255.255.255
> BOOTREPLY
>  <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.
>
>
>