Vista doesn't ack dhcp offer

[Doug Tucker]

And here you will see the discover and offer, but no ack, just the
client re-requesting.  So it does seem the client doesn't understand
what it is getting back from the server with the broadcast stuff turned
on it's wireless interface.


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/
> > 
> > 
> 
>