different DHCP-ack option through DHCP-request and DHCP-inform

[Mohr, Andreas]

hi shane,
i check dhcp-3.0.5 for fix "DHCPINFORM handling for clients that
properly set ciaddr and come to the server via a relay aget has been
repaired.".

DHCP-ACK on DHCP-INFORM bug is not fixed in 3.0.5. 
Do you need more informations?

- DHCP-INFORM via relay agent
- DHCP-ACK from dhcp server with wrong option domain-name-servers select
- right option domain-name-servers select within DHCP-REQUEST/DISCOVER
- wrong option domain-name-servers select within DHCP-INFORM

subnet 10.165.0.0 netmask 255.255.0.0 {
	option domain-name-servers 10.1.1.1; // wrong one for
DHCP-Inform from dynamic clients
	 pool {
        		option domain-name-servers 10.165.1.2;   //
right one for DHCP-Inform from dynamic clients
        		range 10.165.107.1 10.165.108.255;
    	}
}


>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Mohr, Andreas wrote:
>> hi,
>> we using isc dhcp 3.0.4 under solaris9
>> and observe different DHCP-ack option through DHCP-request and
>> DHCP-inform packets
>> from same host.
>>  
>> our config:
>
><snip/>
>
>> Why dont use dhcp-ack for dhcp-inform not the group host
>> domain-name-servers option?
>
>I think the answer lies in this value in the DHCPINFORM packet:
>
>    Relay agent IP address: 10.165.1.1 (10.165.1.1)
>
>If this value (giaddr) is set, then DHCPINFORM uses it to decide which
>subnet to use. The DHCPREQUEST relies only on the client address to
>select the subnet.
>
>I think this is a bug, but it was coded specifically to behave in this
>way, so maybe there is something I'm missing. I'll check this out and
>we'll fix it if it is a bug.
>
>- --
>Shane
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.4 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFEvNjLMsfZxBO4kbQRArIxAJ4geVJi6cy6KSitmUfPl+8vwDD8PQCgzPmw
>zo2r88Rh/hq2VABD2eWirhE=
>=7hG0
>-----END PGP SIGNATURE-----