dhcpcd-discuss

On Thu, Apr 4, 2013 at 3:10 PM, Roy Marples <roy@xxxxxxxxxxxx> wrote:

> On 04/04/2013 22:20, Roy Marples wrote:
>
>> In this specific scenario, the target DHCPD server is not the same
>>> one giving this IP to the client so it remains silent. (this is by the
>>> spec IMO).
>>> client backs off for 10 second and start again with DISCOVER. From
>>> this point everything goes as it should be.
>>>
>>
> I would also point out that it's recommended these days that DHCP servers
> are authorative which means they should NAK any invalid address.
> Only non authorative DHCP servers would remain silent.
>

Totally agree with you on this one. This would solve my issue. There is a
"but" :) here:
What I noticed is that if your client moved from one IP subnet config
network (say 192.168.1.0/24) to another network with a different IP subnet
config network (e.g. 10.10.1.0/24), then DHCP will NAK immediately (well, I
still needed to config "always-reply-rfc1048" on the DHCP server).
But if the client moved from one network to another network and both
networks have the same IP subnet config (e.g. both has 192.168.1.0/24) then
DHCP will *not* NAK despite always-reply-rfc1048 is on. Simple googling
shows that it is really the expected behavior.

If -k in dhcp_stop releases the lease and restart from fresh (DISCOVER),
then it would a perfect fit to my solution since I do know that I'm on a
different network and there is no point to run DHCP RENEW.

Thanks,
Kobi.


>
> Thanks
>
> Roy
>
>