Vista doesn't ack dhcp offer

Doug Tucker tuckerd at engr.smu.edu
Wed Sep 19 18:28:43 UTC 2007


If they weren't leaving the interface, then they would never work,
correct?  The only clients that do NOT work, are vista clients that do
not have the registry hack applied...once applied, even those work.
Unless you are suggesting that the request itself is something the dhcp
server doesn't understand and is ignoring, but in that case, why would
we see an offer by the dhcp daemon in the syslog?

On Wed, 2007-09-19 at 18:42 +0100, Phil Mayers wrote:
> On Wed, 2007-09-19 at 12:15 -0500, Doug Tucker wrote:
> > 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
> 
> Well, since you can't see the OFFER packets with tcpdump one of two
> things must be true:
> 
>  1. the packets aren't leaving the ethernet interface. This could be
> because:
>     * dhcpd is not using the correct socket calls
>     * your network stack is dropping the packets
>  2. you did the tcpdump wrong - unlikely I suspect
> 
> Could you describe again in detail the network config of this box?
> 
> The obvious difference that means it works for others, whereas not for
> you, is that my DHCP server is on a little subnet and only ever receives
> unicast, forwarded DHCP packets and only ever replied with unicast,
> reverse-forwarded DHCP packets, and the router on the subnet takes care
> of sending this on as IP broadcast and either a L2 unicast or broadcast
> depending on the "broadcast" flag.
> 
> 
> > 
> > ....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.
> 
> We understand that.
> 
> Perhaps someone more familiar with the nest of vipers (in a nice way!)
> that is dhcpd's packet transmission methods could chip in here. It's the
> packet transmission path that needs to be looked at.
> 
> > 
> > 
> > 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