Vista doesn't ack dhcp offer

John Miller miller at muskingum.edu
Wed Sep 19 17:31:16 UTC 2007


With what the logs and the dump are showing, the OFFER is never getting to
the client. It does not seem to be leaving the server, even though the logs
say it is. We had a similar problem when running v3.1.0 on a Tru64 box. The
"client" was a Cisco Wireless LAN controller. XP clients worked fine and we
did not have any Vista machines at the time. We moved the server to a Linux
machine and things work fine. This does not explain why the registry hack in
the client fixes the problem, but the issue is strangely similar and the
packet captures look identical, as do the logs.

-----
John H. Miller
Asst. Dir. of CNS for Telecom
Muskingum College
Computer & Network Services
163 Stormont Street
New Concord, Ohio  43762
Phone (740) 826-8052
Fax   (740) 826-8065


-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf
Of Doug Tucker
Sent: Wednesday, September 19, 2007 1:16 PM
To: dhcp-users at isc.org
Subject: Re: Vista doesn't ack dhcp offer


sh-2.05b# uname -a
Linux dgate2 2.6.12.3 #1 SMP Tue Aug 2 17:25:50 CDT 2005 i686 GNU/Linux

By system firewall... you mean the server or the client?  Definately not the
issue with the client...applying the registry hack found here:

http://support.microsoft.com/kb/928233/en-us

....fixes the problem without any further changes to the server or client.
But, doing this to every vista instance is simply impossible, I need the
server to somehow understand, and reply back with what the client expects,
to come back.


On Wed, 2007-09-19 at 10:07 -0700, David W. Hankins wrote:
> On Wed, Sep 19, 2007 at 11:03:57AM -0500, Doug Tucker wrote:
> > http://engr.smu.edu/~tuckerd/dump.txt
> > 
> > Sep 19 11:02:57 dgate2 dhcpd: DHCPDISCOVER from 00:13:e8:23:e5:a7
> > (LENOVO-PC) via eth1
> > Sep 19 11:02:57 dgate2 dhcpd: DHCPOFFER on 129.119.128.108 to 
> > 00:13:e8:23:e5:a7 (LENOVO-PC) via eth1
> 
> The server logs transmitting the offer but it's not in your dump. The 
> suggested filter should catch it if it were there (source or 
> destination port).
> 
> Directly after the log message, we literally call sendto() on the 
> Packet Filter socket.  You would see 'send_packet:' error logs if that 
> were failing, so it must also be succeeding.
> 
> I can only assume that something is discarding the transmission to the 
> all-ones broadcast, but since debian's 3.0.4-13 uses ISC DHCP's "LPF" 
> method, I don't think that can be the system's local firewall, can it?
> 
> uname -a?
> 
> --
> Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
> Why settle for the lesser evil?
https://secure.isc.org/store/t-shirt/






More information about the dhcp-users mailing list